The issues of this type are further grouped based on:
Source of data
Mode of evaluation
Details about each of these grouping parameters is present in the adjacent tabs.
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:
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.
This defines the context in which the data is executed. The two contexts are:
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
Data is also in HTML format
Data is in non-HTML format
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.
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.
Sboxr captures a lot of details about the code execution process. The following steps can be followed to view these details: