White Hat Institute

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.

Cross Site Scripting 13
Cross-Site Scripting

Then click on the “Submit” button, and the script will be executed, displaying the message window on the screen

Cross Site Scripting 2

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.

Cross Site Scripting 3

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.

Cross Site Scripting 13

As it is shown in the screenshot, the script was not executed and replaced with clear text.

Cross Site Scripting 4

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.

Cross Site Scripting 5

To see this in action, type the following alert script and click on “Submit.”

Cross Site Scripting 14
Cross Site Scripting 6

As you can see, the script was successfully executed and displayed the message on the screen.

Cross Site Scripting 7

We can also display the session ID by executing the following simple script.

Cross Site Scripting 15
Cross Site Scripting 8
Cross Site Scripting 9

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: ( dvwa/vulnerabilities/xss_r/?name=“%3cSCriPt%3ealert(document.cookie)%3c/script%3e)

Cross Site Scripting 10

Once you hit “Enter,” the script will be executed and display the message on the screen.

Cross Site Scripting 11

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.

Cross site request forgery 14

To bypass the high-security level, use elements of HTML, for instance, use image source tag to generate the string inside the web-server.

Cross Site Scripting 16
Cross Site Scripting 12