Reflected

Low

On the first level, when entering, we find an input field that asks for the name. When entered, we observe that the system prints directly what has been entered in the field. This is because the running code picks up the variable and prints it directly without any validation or sanitization process. This can present a security risk, as it allows the insertion of unwanted code to be executed in the browser.

<?php 

// Is there any input? 
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) { 
    // Feedback for end user 
    echo '<pre>Hello ' . $_GET[ 'name' ] . '</pre>'; 
} 

?>

Given this behavior, the first thing we would do to test the XSS vulnerability would be to perform the most basic XSS attack, which consists of:

<script>alert(1);</script>

This code attempts to inject a JavaScript script that executes an alert in the user's browser. If when you enter this code in the input field and submit it, the web page displays an alert with the message "XSS", then it is clear that the application is vulnerable to Cross-Site Scripting attacks. This is because the user input is not being properly validated or sanitized before being rendered on the web page.

If when inserting the code in the input field we notice that it is reflected in the address bar, it indicates that we are dealing with a case of reflected XSS where the injected code is transmitted through the URL.

If we share this link with someone and they open it in their browser, the XSS code we have entered will be executed automatically. This can result in anyone clicking on the link being susceptible to information theft attacks, session hijacking, among others, depending on the nature of the XSS code used. It is critical to ensure that web applications properly validate and clean all entries to avoid such vulnerabilities.

Medium

At the medium level, we note that the initial reflected XSS vulnerability is no longer executed using the traditional method due to a mitigation measure implemented in the server's PHP code.

The relevant code that implements this protection is:

<?php

// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
    // Get input
    $name = str_replace( '<script>', '', $_GET[ 'name' ] );

    // Feedback for end user
    echo "<pre>Hello ${name}</pre>";
}

?>

This part of the code uses str_replace to specifically remove the string <script> from the name entered by the user. However, the str_replace function is case sensitive, which means that it will only remove <script> tags written exactly that way (in lower case).

To test the robustness of this security measure, we can try an XSS attack that bypasses this mitigation by changing the case of the letters in the <script> tag:

<SCRIPT>alert("medium")</SCRIPT>

When executing this code, if we observe that the alert with the message "medium" is produced, we confirm that the XSS attack has been successful.

This indicates that, although a security measure has been implemented, its effectiveness is limited due to its inability to handle variations in the case of letters, resulting in incomplete protection against XSS attacks. This demonstrates the importance of implementing more robust and case-sensitive sanitization methods, or better yet, more comprehensive approaches such as the use of whitelists or output encoding for special characters in HTML.

High

At the last level of the reflected XSS attacks, we observe that direct injection methods using <script> tags are no longer effective due to the implementation of a more robust regular expression in the PHP code, which effectively filters these tags regardless of case variations:

<?php

// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
    // Get input
    $name = preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $_GET[ 'name' ] );

    // Feedback for end user
    echo "<pre>Hello ${name}</pre>";
}

?>

This approach effectively avoids the use of <script> tags by manipulating the letters and spaces in between. However, this measure still leaves open the possibility of using other attack vectors that do not directly depend on these tags. A common technique in these cases is the use of HTML events that can trigger JavaScript indirectly.

Use of the onerror attribute in a <img> tag

An alternative is to exploit attributes such as onerror in HTML elements that execute JavaScript code when an error occurs, such as an error loading an image:

<img src=x onerror="alert('High')">

In this case, since "x" is not a valid image URL, the browser will attempt to load it, fail, and then execute the JavaScript code inside the onerror attribute, displaying an alert.

Using SVG for JavaScript execution

Another effective method is the use of SVG elements, which also allow the inclusion of JavaScript:

<svg/onload=alert('High2')>

Here, the onload event inside an SVG element is used to execute JavaScript when the SVG is loaded, which happens immediately, since SVGs are processed as part of the DOM.

Both methods demonstrate that while specific mitigations for <script> tags can be effective against certain forms of XSS attacks, it is crucial to consider and protect against other vectors that use different HTML elements and attributes. It is advisable to adopt a layered security approach, including both input validation and sanitization as well as content security policies (CSP) that restrict the execution of unauthorized scripts.

Expansion of techniques

For those interested in deepening their knowledge of web application security and specifically Cross-Site Scripting (XSS) attack prevention and mitigation, I highly recommend exploring two outstanding resources. The XSS Cheat Sheet by PortSwigger provides a detailed guide with multiple techniques and practical examples that are indispensable for understanding and testing XSS defenses in modern applications. In addition, the OWASP XSS Filter Evasion Cheat Sheet provides a comprehensive compendium of XSS filter evasion strategies, a critical tool for security designers and auditors looking to harden web applications against malicious attacks. These pages are essential for any cyber security professional looking to keep up to date with the latest practices in the field of web security.