XSS - Persistent and Reflected

XSS - Persistent and Reflected

XSS is not a single form of attack. XSS can generally be split up between two different kinds of attack vectors: Persistent and Reflected.

Persistent attacks, are attacks where the payload sits inside the web server or back-end database and the attack is towards the general audience of the infected site.

Reflected, on the other hand, is a target attack where the attack is reflected by using the vulnerable site and attack the victim.

Persistent XSS

Attacks are when the payload is sent to the web server and stored.

This is why it is called persistent, because the payload is stored on the web server and can be displayed to any victim who views it, This is one of the most dangerous forms of XSS because instead of a single target, the attacker now has multiple targets from a single attack.

Prime vectors for this attack would be forms that submit content to the web server and then display that content back to the user.

Elements such as: Comment boxes, User profiles, and Forums, are susceptible to a persistent XSS attack.

Reflected XSS

Attack that does not store it's payload in the web server.

This is not as devastating as a persistent attack, but do not let that trick you into thinking it is harmless.

Instead of uploading the payload into the web server, the attacker tries to trick the victim into clicking the malicious url with the payload which exloits the XSS vulnerability in the web application and reflects the payload on to the victim's browser.

Reflected XSS is more common than persistent.

Compared to persistent XSS attacks, reflected XSS attacks don't require a submission form where data is being stored on the web server.

Reflected attacks can happen by any means where submitted parameters are reintroduced in the same page source code, such as a serch function.

Normally, when submitting a search in a website, te search parameters will be displayed in the search page.

This would be a prime target for a Reflected XSS as well as any other function that returns user generated data.

Besides enter data into an input box, XSS can be entered directly in the url for a reflected attack.

Notice how the the url takes in a parameter and returns the corrrect user's homepage.

Now if i change the url to an unknown user, it returns an error saying that there is no homepage for this user.

This is a prime target for a reflected XSS.

The website is returning our query without actually storing anything in the database. Taking advantage of this, an attack can submit a maliciously crafted url producing a reflected XSS attack.

In this example, the link crafted by the attacker is : http://nerv0.blogspot.kr/list/search?uid=<script>alert('Reflected XSS')</script>.

Sending this link to a victim produces an alert box proving that a XSS vulnerability exists and the victim has been attacked.

In this demonstration, an alert box was used, but keep in mind something more malicious and stealthy could have been used as a payload.