Cross Site Scripting (XSS) | Performing Reflected Attacks
In our last post to Cross Site Scripting we discussed some basics related to XSS attacks where I mentioned there are two types of XSS attacks one is reflected and another is stored. Assuming that you have installed Damn Vulnerable Web Application (DVWA) on your system I‘ll demonstrate how a reflected XSS attack is performed. Browse to your DVWA link it will ask you for creating a database click on create database if it fails then browse to XAMPP folder and double click mysql_start.bat. Then login to your DVWA account with username “admin” and password “password”. Now from left side pane click on DVWA Security and select security level “low”. Click on “XSS reflected” and you’ll be presented with following screen.
Now its time to check the application is vulnerable or not. Type following to check vulnerability,
<script>alert(‘DEVILS BLOG ON SECURITY’)</script>
Above code should pop up a window with alert “DEVILS BLOG ON SECURITY”. That’s how we verified it is vulnerability for script level attacks. Now let’s verify for HTML level attacks so type,
<a href="http://bit.ly/nrupen">DEVILS BLOG ON SECURITY</a>
If it creates a link to “DEVIL’S BLOG ON SECURITY” then it is also vulnerable to HTML tag level attacks. Please don’t forget to have a look on URL after each test. Now change security level to medium and try both strings again this time you’ll find that that first string will fail to work while second will be in working condition. For those who can understand PHP coding click on “view source” button on right hand bottom side. You’ll get following code,
The marked code will replace every instance of <script> with blank and hence first line of vulnerability code will not work, by the way you can see clearly that there’s isn’t any condition for handling HTML tags and hence HTML tag based code works without any problem. Is there any way to fool this security mechanism and the answer is yes. Type script level vulnerability in all caps and try again and this time you’ll succeed because the pattern matching algorithm is case sensitive and therefore <script> and <SCRIPT> both are different for it and hence it doesn’t get replaced. Now change security level to high. This time none of our tricks will work, why? click on view source,
The marked code will disallow all types of HTML special characters thus we can not fool it this time. By the way the third level of security is rarely found in real world web application. And you’ll find nearly 75% web applications can be hacked using medium level security level, by the way same trick will not work everywhere so you’ll need a sheet of cheats that can bypass XSS filtering. No worries about it, the link to complete cheat sheet is provided in same window below “More Info” in DVWA.
Now some important information reflected XSS vulnerability can be found and exploited in single input boxes and URLs so it’s also important for you to check for exploitable URLs. Syntax of URLs may not change more than what you’ll experience while trying above cheats. Before writing real exploitable XSS codes its better to check for what kind of cheat code web application is vulnerable to. The XSS codes above are not really exploit codes they are just used for checking vulnerability, real exploit script and code is left to how good you are in coding HTML and related browser supported scripts. Acunetix web vulnerability scanner has provided a real online XSS vulnerable web application for practice once you are done with your lab practice visit http://testasp.vulnweb.com/search.asp and try some real deal.
I hope that was easy and complete. Please feel free to ask if you have any queries, in next post to this we will discus stored XSS attacks. Till then thanks for reading, have a nice time and keep visiting.
