DOM
Low
At the low level of our XSS analysis, we are faced with DOM-based XSS testing. Here, we find a select element in the user interface that, when activated, generates a URL with a "default" parameter set to a specific value, in this case, "French".
http://localhost/vulnerabilities/xss_d/?default=French
Following the approach used in previous levels, we performed a basic XSS attack by adding an alert script in the URL to see how the application reacts. By including the script in the URL as a value for the "default" parameter, we observe that the attack succeeds and an alert is displayed on the page.
http://localhost/vulnerabilities/xss_d/?default=French<script>alert("low")</script>
And we see that the attack has an effect.
This result demonstrates a persistent XSS vulnerability at the low level of the application. Although these types of attacks may seem simple, they are a significant threat when not properly addressed. Identifying and remediating these vulnerabilities is crucial to ensure the security of web applications against possible malicious attacks.
Medium
At the mid-level of our XSS assessment, we follow the usual approach of starting with a simple attack to check for vulnerabilities. However, we note that the most basic attack we have previously employed does not succeed at this level.
This result suggests that the middle level may have more robust security measures compared to the low level. Additional controls or stricter filters may have been implemented to prevent XSS attacks.
Since the simplest attack did not work, we must take a more advanced approach or explore other techniques to find possible XSS vulnerabilities at this medium level. This may involve further analyzing the application source code, identifying possible entry points for XSS and testing different attack vectors to find possible exploitation.
Examining the relevant source code, we notice that the stripos function is used, which finds the position of the first occurrence of a substring in a case-insensitive string. This function is probably used to validate or process the value of the parameter provided in the URL.
# Do not allow script tags
if (stripos ($default, "<script") !== false) {
header ("location: ?default=English");
exit;
}
When attempting to inject the script tag into the URL to execute an XSS script, we find that the stripos function detects the presence of this string, resulting in a redirect to the default URL or to a predefined action in the code. This indicates that security measures have been implemented to detect and prevent XSS attempts by inspecting the URL content.
As we have seen in another XSS example, we are going to use HTML events, so we test the following url
English<img src=x onerror=alert("medium")>
This technique demonstrates an effective strategy for mitigating XSS vulnerabilities at the mid-level by using PHP functions that examine string content in a case-sensitive manner to prevent potential XSS attacks. However, we must continue to evaluate other potential vulnerabilities and exploitation techniques at this level to ensure application security in a comprehensive manner.
Staying as in the previous case, but let's inspect the element in case something happened.
We can observe that, the code that we insert in the URL has been put inside the option, reason why we have to close the option and the select so that it writes it outside.
English"></option></select><img src=x onerror=alert("medium")>
By doing this we observe that the code injection has been successful.
High
At the high level of our XSS analysis, when applying the same attacks we used in the previous levels, we noticed that the select element of the user interface does not react to code injection attempts. This suggests that the security measures implemented at this level are more stringent and effective in preventing XSS attacks.
When inspecting the relevant code at this high level, we can see that a switch check is performed to determine whether the value provided is valid.
switch ($_GET['default']) {
case "French":
case "English":
case "German":
case "Spanish":
# ok
break;
default:
header ("location: ?default=English");
exit;
}
The use of a switch in this context indicates that a more robust validation mechanism has been implemented to ensure that only certain predefined values are accepted. This may be a security measure intended to protect the application against possible malicious or unexpected data manipulation attempts.
The use of a control structure as a switch for validation is a best practice in web application development, as it allows for efficient handling of multiple cases and ensures that only specific values that are secure and legitimate are accepted.
This implementation demonstrates a proactive approach to application security, helping to reduce the risk of vulnerabilities such as XSS by limiting inputs to validated, predefined values. However, it is important to continue to regularly evaluate and update security measures to adapt to new threats and emerging vulnerabilities.
In URLs, anchors are used to identify and navigate to specific sections within a web page. The part of the URL that follows the "#" symbol (called the fragment) is known as the anchor. It is important to note that the URL fragment, including the "#" symbol, is not sent to the server when an HTTP request is made.
http://localhost/vulnerabilities/xss_d/?default=English#dvwa
Because the URL fragment is not sent to the server, it cannot be filtered or processed by server logic. This means that characters or content after the "#" are not considered in determining the server's response. Therefore, code injection attacks, such as XSS attacks, cannot be prevented or mitigated by server-side URL fragment filtering.
When testing the above url we find that it is painted in the select.
This is due to poor programming of the JavaScript that renders the page.
if (document.location.href.indexOf("default=") >= 0) {
var lang = document.location.href.substring(document.location.href.indexOf("default=")+8);
document.write("<option value='" + lang + "'>" + decodeURI(lang) + "</option>");
document.write("<option value='' disabled='disabled'>----</option>");
}
That as we see it paints as it arrives from the URL what is in default, so if we execute the following URL.
http://localhost/vulnerabilities/xss_d/?default=English#<script>alert("high")</script>
We managed to carry out the attack.
It is important to take this limitation into account when designing security measures to protect a web application. Although the URL snippet does not pose a direct security risk, it is critical to implement other security measures, such as user input validation and filtering, data sanitization, and the use of content security policies, to protect against potential vulnerabilities, including XSS attacks.