What is XSS ?

XSS stands for Cross Site Scripting. Don’t get it confused with CSS which stands for Cascading Style Sheets(Used for styling web pages). Cross site scripting is a web app exploitation technique that is very popular. It is estimated that 68%+ webpages have this vulnerability. XSS can be very destructive and can be used for things such as cookie attacks, defaces etc.

Types of XSS

There are two main types of XSS :

• Non-Persistent (Reflected)
• Persistent

1) Non-Persistent (Reflected)

Non-Persistent is pretty self explanatory. This means the attack is executed on the web client. This attack is pretty popular. It can be used for cookie stealing etc..
The attacker can insert a script that visits their cookie stealer page. The attacker creates a page(probably on a free host) that will log cookies into a logfile with the IP etc. Then they get the victim to click on the link that has the XSS vulnerability. Once the victim clicks the link the attackers page uses PHP and javascript(used in the XSS) to log the cookies. Here is an example of a simple non-persistent script that will make the word “Poison” come up in a box.

<script> alertundefined“Poison”); </script>

This is of course just one simple example. Some servers may have an IDS or something similar to help prevent XSS attacks. I will provide a link later on that has tons of XSS queries for attackers to use. A popular method of masking the XSS query is encoding.

Persistent

Persistent XSS is a bit of a different story. This one is a lot more destructive. Persistent XSS is stored on the web server so everybody who visits that page will have the XSS query executed on their machine. This means an attacker can make malicious scripts execute including a cookie stealer. A good example of a persistent XSS attack would be a guestbook that doesn’t sanitize user input.
XSS, both persistent and non-persistent is vulnerable because of not validating user input. In the next section I will show a vulnerable PHP code that takes user input and just echos it back. This is of course very insecure as tags are not stripped so malicious attackers can easily preform an XSS attack. I’ll show an example of non-persistent dealing with echo $userinput; and an example dealing with a guestbook through SQL.

Where/How to fix it?

The problem lies within vulnerable PHP code. I will show you non-persistent first.
Take this for example:
UserInput.php
PHP Code :

<form method="”get”" name="”input”"> Text: <input name="”input”" type="”text”" /><br /> <input type="”submit”" value="”Submit”" /></form>

Can you find where the problem lies? It’s in
PHP Code :
echo $userinput;
The reason is, it’s just taking input from a user and spitting it back out. No tag stripping is done or anything to prevent XSS. So you get an XSS hole. Now how do we fix it? Simple. We use some extra PHP functions.
PHP Code:

<form method="”get”" name="”input”"> Text: <input name="”input”" type="”text”" /><br /> <input type="”submit”" value="”Submit”" /></form>

This is a quick and easy fix. We strip tags from the user input and trim so the user can’t craft any malicious scripts. The PHP page strips it from them and just returns back the value. So no hole occurs. There are more advanced techniques to get through this but this suffices quite enough.
And now, Persistent XSS. This one is the more damaging one. This code will take user input, insert it to an SQL database and echo that value. This will not strip any tags or trim anything, so the raw input goes into the SQL database without sanitizing and gets called out, without sanitizing. This source is taken right from Damn Vulnerable Web App(Download link is below)
PHP Code:
’ . mysql_error() . ‘’ );
}
?>
See what happens? We trim but don’t properly sanitize the user input. The user input is stored in the table “guestbook”. Here is the high application security page for stored XSS used by DVWA
PHP Code :
’ . mysql_error() . ‘’ );
}
?>

This is more secure but still not the most secure option. A bit of a more secure option would be to use
PHP Code :
strip_tags()
I hope this was simple to understand and helped you

Xss attack Details

• XSS Shell is a cross-site scripting backdoor into the victim's browser which enables an attacker to issue commands and receive responses. 
• During a normal XSS attack an attacker only has one chance to control a victim's browser; however, the XSS Shell keeps the connection between the attacker and the victim open to allow the attacker to continuously manipulate the victim's browser. 
• XSS Shell works by setting up an XSS Channel, an AJAX application embedded into the victim's browser, that can obtain commands and send back responses. 
• To enable the XSS Shell an attacker needs to inject the XSS Shell's Javascript reference by utilizing a XSS flaw on a website. 
• Once the victim's browser is infected with the XSS Shell and the XSS Channel is created, the attacker can issue instructions to the infected browser. 
• Also, the Attacker can use a XSS Tunnel to transfer HTTP traffic through the XSS Channel and the victim's browser; in turn, exploiting the victim's credentials to bypass authentications and IP Restrictions. 
• The XSS Tunnel is a HTTP Proxy that sits on an attacker's computer, and any tool that is configured to use it will tunnel its traffic through the XSS Channel.