Cross-Site Scripting - Non-persistent (reflected) XSS
Cross-Site Scripting (XSS) assaults are a kind of injection, in which vindictive contents are infused into generally trusted websites. XSS assaults happen when an aggressor utilizes a web application to send malicious code, by and large as a browser side script, to an alternate end user. An attacker can use XSS to send malicious content to a clueless user.
The end user’s browser has no real way to realize that the content should not be trusted and will execute the script. Since it thinks the script came from a trusted source. The malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rework the content of the HTML page.
XSS assaults can, for the most part, be ordered into two classes: non-persistent (or reflected) and persistent (or stored). There is a third, considerably less notable kind of XSS assault called DOM Based XSS, which we will talk about it later in this chapter.
Non-persistent (reflected) XSS
The “non-persistent (or reflected) XSS” vulnerability is by a long shot the most fundamental kind of web weakness.
There are different methods by which an aggressor may actuate a victim user to make a solicitation that they control, to convey a reflected XSS assault. It incorporates setting links on a site constrained by the attacker, or on another site that enables content to be generated.
If an aggressor can control a script that is executed in the victim’s browser, at that point, they can ultimately compromise that client. In addition to other things, the assailant can:
· Play out any activity inside the application that the client can perform.
· View any data that the client can see.
· Alter any data that the client can adjust.
· Start connections with other application clients, including malevolent assaults, that will seem to originate from the underlying victim user.
Low-security level
To perform these types of attacks, go to the DVWA website, select the “XSS reflected” tab, and type the following script below.
Then click on the “Submit” button, and the script will be executed, displaying the message window on the screen
Medium-security level
At this level, the application attempts to avert XSS by removing any string that contains “<script>” in the input field. Now and again, it is conceivable that signature-based filters can be just vanquished by obfuscating the assault. Ordinarily, you can do this through the inclusion of unexpected variations in the syntax or the encoding. These variations are tolerated by browsers as substantial HTML when the code is returned, but the filter could likewise accept them.
Let’s change the security level of the web-server to medium and start compromising it.
If you try to perform a basic XSS attack on a secured web server, there is a high chance that the attack might fail. To see it in action, type the script, and submit the request.
As it is shown in the screenshot, the script was not executed and replaced with clear text.
Let’s view the source code to analyze it more deeply. The restriction was applied to the string “<script>” within the input field, which is all lowercase. If you try to replace “<script>” with “<SCriPt>” and submit the request, you might bypass the restriction.
To see this in action, type the following alert script and click on “Submit.”
As you can see, the script was successfully executed and displayed the message on the screen.
We can also display the session ID by executing the following simple script.
Another way to exploit this type of vulnerability would be though the URL manipulation. You can use the same script (<ScRiPt>alert(document.cookie)</ScRiPt>) but encoded in to the URL language (%3cSCriPt%3ealert(document.cookie)%3c/script%3e) and added to the end of the (IP/dvwa/vulnerabilities/xss_r/?name=“).
Ex: (10.10.10.5/ dvwa/vulnerabilities/xss_r/?name=“%3cSCriPt%3ealert(document.cookie)%3c/script%3e)
Once you hit “Enter,” the script will be executed and display the message on the screen.
High-security level
At the high-security level, the “preg_replace” PHP function is used to perform regular expressions to disable JavaScript. “Preg_replace” function searches a string for matches to pattern and replaces them with substitution. If you try to use the above technique, you won’t be successful because that particular PHP function will search for every valid input character for the text field and replace the invalid character into a blank space.
To bypass the high-security level, use elements of HTML, for instance, use image source tag to generate the string inside the web-server.
