Cross Site Scripting XSS attack Complete Tutorial guide
Cross Site Scripting, XSS attack vulnerability, Firewall bypass, encoding bypass, URL encoding bypass xss, xss in bug bounty sites, xss in sites, xss vulnerable sites, bug bounty in xss vulnerability.
Cross-site scripting is a type of computer security vulnerability that is found in web-based applications which allows code injection by web users into any webpage that is viewed by other users.
XSS is made possible due to the fact that faulty coding causes XSS holes (vulnerabilities on websites that allows attackers to avoid security measures) in the client-side script that allows for insertion of malicious code. During an attack, “everything looks fine” to the end user, but in actuality they are subject to a wide variety of threats. XSS is a potentially dangerous vulnerability that is easy to execute and very long and arduous to repair. XSS holes exist in 7 out of every 10 websites. Many site owners do not consider an XSS hole to be a big threat, which is a commonly made mistake because the consequences of an XSS attack against web applications and its users have been proven to be extremely serious.
The most frequent kinds of web applications that are victimized by XSS attacks are search engines, discussion boards, web-based emails, and posts. Even the most well-known websites in today’s world like Google, Yahoo!, MySpace, Facebook, PayPal, and WikiPedia were once victims. The most commonly used programming languages during XSS attacks are HTML, XHTML, JavaScript, and Adobe’s Flash. However the most popular and potentially the most detrimental language used by malicious attackers is JavaScript
The most frequent kinds of web applications that are victimized by XSS attacks are search engines, discussion boards, web-based emails, and posts. Even the most well-known websites in today’s world like Google, Yahoo!, MySpace, Facebook, PayPal, and WikiPedia were once victims. The most commonly used programming languages during XSS attacks are HTML, XHTML, JavaScript, and Adobe’s Flash. However the most popular and potentially the most detrimental language used by malicious attackers is JavaScript
How Cross-Site Scripting works:
A website is vulnerable if it accepts and subsequently return the same input back to a user. The most common example is when a user does a search and the Web server returns the same data the user typed in. As an example, a user does a search for “XSS” and the browser returns a message of, “Your search for XSS returned the following.”
A cross-site scripting attack can be done rather easily to a Web server that is not properly protected. Web servers generate both text and HTML markup on their web pages. The client’s browser then interprets the web pages. HTML uses special characters to distinguish text from markup. Different characters are special at different points in the document, depending on the grammar. The less-than sign “
A cross-site scripting attack can be done rather easily to a Web server that is not properly protected. Web servers generate both text and HTML markup on their web pages. The client’s browser then interprets the web pages. HTML uses special characters to distinguish text from markup. Different characters are special at different points in the document, depending on the grammar. The less-than sign “
Types of XSS Attacks :
There are three significant types of XSS vulnerabilities that exist and they are
1.Non-persistent XSS
2.Persistent XSS
3.DOM XSS(Document object model)
1. Non-persistent XSS:
It is also referred as reflected XSS vulnerability. If a web user provides data to a server- side script to instantly generate a resulting page back to him/herself, a resulting page without html encoding can be intercepted by an invalidated user. The malicious client- side code can then be injected into the dynamic page. The attacker can apply a little social engineering (which is the power to manipulate someone to perform actions) to persuade a user to follow a malicious URL that will inject code into the resulting page. After the attacker has accomplished that, he now has full access to that web pages content.
 |
2. Persistent XSS:
It is also referred to as stored XSS vulnerability. This vulnerability is susceptible to the most powerful kinds of attacks. First, the data is stored on the server (in a database, file system, or other location) provided by a web application. Then it is later reopened and shown to other users on a webpage without any html encoding. An example of this is an online discussion or message board that allows users to sign in to post messages for other users to read. Persistent XSS is one of the more prestigious types of vulnerabilities because the malicious scripts are capable of being provided and used more than once. This means an attacker can exploit this vulnerability and affect a large magnitude of users. In addition to the huge number of users already at risk, this web application can also be infected by a cross-site scripting virus or worm.
3.Document object model XSS:-
DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.
This is in contrast to other XSS attacks (stored or reflected), wherein the attack payload is placed in the response page (due to a server side flaw).
Reasons Why XSS Vulnerabilities are Exploited : –
· Account Hijacking for identity theft
· Cookie theft/poisoning to acquire sensitive information
· Conduct phishing attacks
· Gain free access to otherwise paid for content
· False advertising
Steps for XSS Attack
In order to execute a basic cross-site scripting attack, we must follow these four simple steps:
1. Select a target The first step is to select a target. This is done by searching for an XSS hole in a web-based application on a website.
2. Testing The next step is to decide what kind of XSS hole this website contains because all XSS holes are different in how they are exploited. We need to check for different attack vectors so as to pass the server filter.
3. XSS Execution
Insert malicious script ( ex : cookie stealing script ) into the webpage
4. Decide what to do with the data Once you get the user to execute the malicious script, their cookie will be sent to your CGI script. The last thing to do is to see if account hijacking is possible.
Steps to an XSS Attack
In order for a malicious attacker to execute a basic cross-site scripting attack, they must follow these four simple steps:
1. Select a target
The first step is to select a target. This is done by searching for an XSS hole in a web-based application on a website. Once you have discovered an XSS hole, you must look to see if that website contains any kind of cookies. If it does not, then you have failed and you must continue to look for another website. If it does, then you have succeeded and it is now possible for you to steal that cookie. You have finally selected a target.
2. Testing
The next step is to decide what kind of XSS hole this website contains because all XSS holes are different in how they are exploited. You must then run some tests to make sure the output is authentic looking. If the website appears to be broken, then you must modify your coding until it looks legitimate. When this is complete, you then plug in your JavaScript, or another kind of client-side scripting code, directing it towards the XSS vulnerability.
3. XSS Execution
You are finally ready to distribute your malicious URL in any way that might potentially help you launch it. However, you should make sure to Hex encode your URL to make it seem less obvious of its malicious intent. Now all you have to do is sit and wait. If you are a more experienced attacker, you could even do a few redirects and some XSS combo’s to steal a user’s cookie, and return the user to the website without them knowing their cookie was even stolen.
4. Decide what to do with the data .
Once you get the user to execute your XSS hole, their cookie will be sent to your CGI script. The last thing to do is to use a program like Websleuth to see if account hijacking is possible.
A Practical Example of XSS on a Test Site
1. Reflected Cross Site Scripting
Set security low
Explore localhost IP in browser; now login with admin: password and select the reflected cross site scripting vulnerability from given list of vulnerabilities.
Now have a look over a small script which would generate an alert window. So in the given text field for “name” I will inject the script in the server.
<script>alert(“helllooo”)</script>
Browser will execute our script which generates an alert prompt as showing following screenshot.
In low security it will easily bypass the injected script when an attacker injects it in the text field given for “name”which should be not left empty according developer.
2. Stored Cross Site Scripting
Set security low
Now have a look over a small script which would generate an alert window. So in the text area given for message I will inject the script which get store in the server.
<script>alert(“helllooo”)</script>
Now when user will visit this page to read our message his browser will execute our script which generates an alert prompt as showing following screenshot.
XSS FIREWALL BYPASSING
Firewalls, IDS and IPS are the most common security mechanisms that are often used to protect infrastructure from malicious attackers. Out of these, firewalls are the most commonly used, they are placed at the network layer and analyzes malicious packets as well as application layer, where their purpose is to monitor all HTTP and HTTPS traffic between clients and servers and based upon the pre-configured registered signatures in a data base.
1. Fingerprinting F5 BIG IP ASM
F5 is one of the world renowned Web application firewall’s with deep inspection capabilities, similar to citrixnetscaler F5 BiG IP ASM also adds certain cookies as a part of their HTTP communication. The following demonstrates a non-malicious GET request that was submitted to an application running behind an F5 BIG IP ASM firewall.
2. Fingerprinting Mod_Security
Mod_security is an open source WAF specifically designed for Apache server, due to it being open-source it has been bypassed many times and hence the detection rules have been significantly improved. A malicious request sent to an application running behind mod_security returns a “406 Not acceptable” error along with it inside the response body it also reveals that the error was generated by mod_security.
3.Fingerprinting WebKnight
Webknight is another very popular Web application firewall, it was specifically designed for IIS servers. The WAF works upon a blacklist and looks for common patterns for attacks such as SQL injection, Directory Traversal, XSS etc. Unlike, other WAF’s webknight is very easy to fingerprint a malicious request returns a “999 No Hacking” response.
4.Fingerprinting dotDefender
dotDefender is another well-known WAF that was specifically designed for protecting .net applications against well known attacks. Similar to Mod_security and WebknightdotDefender also reveals itself inside the response body when a malicious request is sent to a webapplication running dotDefender.
5. Fingerprinting With Wafw00f
Wafw00f is a small tool written in python and is specifically used tool for fingerprinting Web application firewalls, it conducts five different tests to detect the WAF, such as keeping track of the cookies inside the http request, by analyzing http response received from sending malicious requests, by using drop packets such as FIN and RST and looking at the response received, by server cloaking i.e. modifying URL and altering methods and by testing for pre-built negative signatures which vary from a WAF to a WAF.
XSS General Filter Evasion Cheat Sheet
All of us might have encountered one such end point that takes URL as parameter and redirects to it using javascript like :
location.href='URL'
window.location.href='URL'
window.location.replace('URL')
window.location='URL'
VARIOUS FORMATS:-
1. \x[HEX]
2.\u00[HEX] Format 1 : javascript: -- > \x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3a Format 2 : javascript: -- > \u006A\u0061\u0076\u0061\u0073\u0063\u0072\u0069\u007 0\u0074\u003a
BYPASSING THIS FORMAT:
\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3aalert(1)
\u006A\u0061\u0076\u0061\u0073\u0063\u0072\u0069\u0070\ u0074\u003aalert(1)
These are few alternatives to newline character which you can try if newline character is also blocked :
[0x09] <---- Horizontal Tab
[0x0d] <---- Carriage Return
\t <---- Horizontal Tab
\n <---- Newline
\r <---- Carriage Return
Now let's assume
'javascript:' and
'\x' and
'\u' and
[0x0a,0x09,0x0d]
and [\n,\t,\r] are blocked??
What happens if we try to escape any character that does not form a control char (\n,\t,\b,\v,\f,\r and of course \x,\u too) ?? The answer is NOTHING. So we can put escape char in front of any character except n,t,b,v,f,r,x,u and digits.
Bypass : \j\av\a\s\cr\i\pt\:\a\l\ert\(1\)
Conclusion
Cross-site scripting is one of the most dangerous and most common website vulnerability on the internet. An XSS attack comes in many forms that range from something as small as pop up in a window, to something as destructive as a virus or a worm, and even worse; XSS is capable of compromising a person’s identity. Nobody in this world is ever completely safe from it. As XSS vulnerabilities continue to grow, the best way to protect yourself against it is to always be on the alert, and be aware of what you should do when you come across it.
No comments
Post a Comment
Note: only a member of this blog may post a comment.