Code Execution Issues

If Sboxr identifies that potentially untrusted data is being evaluated as JavaScript or HTML by the application then it shows those issues here.

The issues of this type are further grouped based on:

• Source of data

• Mode of evaluation

• Data format

Info

Details about each of these grouping parameters is present in the adjacent tabs.

Source of Data

This is the source of the potentially untrusted data. Sboxr recognizes the following as the sources:

• User Input: Data read from Input boxes

• URL based DOM Properties: DOM properties like location.href which have the value of the page's URL

• Navigation based DOM Properties: DOM properties like window.name and document.referrer whose value is set in the previous page

• Communication based sources:

  • Ajax response: this includes both same-origin and cross-origin responses to XMLHttpRequest and Fetch APIs

  • WebSocket messages: the data received from both cross-origin and same-origin WebSocket connections

  • Cross-Window messages: the data received from both cross-origin and same-origin windows/iframes that were sent via the postMessage API

• Storage based sources: data read from the following client-side data stores:

  • Cookies

  • SessionStorage

  • LocalStorage

  • IndexedDB

Some of these data sources are more likely to be controlled by an attacker than others. The issues are rated based on that.

URL based DOM properties and Navigation based DOM properties have a high likelihood of being controlled by an attacker and so are rated as Errors.

User Input requires some social engineering to be controlled by an attacker so it is rated as Warning.

Communication based sources are rated based on whether they are from the same origin or from external origin. And also on the format of the data, this is explained in the Data Format section below.

Data from external origins or cross-origin data is more dangerous as it is from another entity and can be considered as malicious as it is not controlled by the application owner. Data from the same origin can also be attacker controlled depending on the application's logic. If the application accepts data from untrusted sources, including user input, and stores it in its database and then sends it to the client via a communication channel then it will be considered as untrusted even though it comes from same origin.

Data stored in DOM stores can be attacker controlled depending on the application's logic, in case the application takes untrusted data and then stores it in the DOM stores. In other cases, data from the DOM stores can be considered as untrusted if the user is on a shared system, in this case another user can pollute the DOM store with malicious data. In some cases an attacker can make use of a reflected XSS and pollute the DOM store to turn it in to a persistent XSS.

Mode of Evaluation

This defines the context in which the data is executed. The two contexts are:

• HTML

• JavaScript

Inside these contexts the data could be in various contexts, for example it could be inside HTML element attribute or a JavaScript comment block. That information is not used here, only the high-level context is used for grouping.

Data Format

This specifies if the format of the data from the user is consistent with the mode in which it is being evaluated. There are four possible situations here:

Mode of Evaluation	Format of Data from Source	Example
HTML	Data is also in HTML format	<div>Hello user!</div>
HTML	Data is in non-HTML format	Hello user!
JavaScript	Data is also in JavaScript format	alert('Hello user!');
JavaScript	Data is in Non-JavaScript format	Hello user!

This says a lot about the intent of this data and points towards the likelihood of the presence of DOM XSS.

If the format of the data is same as the mode of evaluation then it is likely that the developer is aware of how this data will be treated by the DOM. This means that this behavior is intended so the appropriate security measure might have been taken from the server-side.

If the format of the data is not the same as the mode of evaluation then the developer is most likely not aware of how the data will be treated by the DOM. This means that this behavior is not unintended so the appropriate security measures might not have been taken from the server-side.

For example, if <div>Hello user!</div> is assigned to element.innerHTML then it is clear that the developer wants the data to be treated as HTML as it is in HTML format.

However, if Hello user! is assigned to element.innerHTML then it is likely a mistake as the data is not in HTML format. So it would have made more sense to assign it to element.innerText as it only has to be treated as text.

Viewing Code Execution Details:

Sboxr captures a lot of details about the code execution process. The following steps can be followed to view these details:

• View details of Code execution events that happen due to potentially untrusted data in:

  • JSON format

  • Non-JSON format

• Open Code Execution Event Details

• View Code Execution Flow Details

• Issue Mitigation/Validation Advice

• Representation of duplicate Tainted Data Sources