There are many ways to prove that XSS flaws exist, the most common (for me at least) are these 2:
a) Basic XSS (user-form reflect back XSS).
b) HTTP Response Splitting.
1. Basic XSS
a. This is something simple, like a search field that allows HTML input. When the user searches for something and the input is reflected on the following page, this may show signs of XSS possibilities. Now, when a user searches for something like < h1 >test< / h1 > , if the page returned contains a large heading that reads "test", the field is vulnerable to HTML injection.. If the user were to search for < script >alert(1)< /script >, and the returning page contained and alert box that read "1", the field is also vulnerable to XSS Injection.
2. HTTP Response Splitting
a. This has something to do with the headers that your browser uses to communicate to the server with. If the webpage allows you to modify them via post or get vars, and reflects the information back, you can easily modify these headers to your needs in order to cross-site script the page. Most commonly, the header's that are XSS'able are the User-Agent: headers. Most pages don't sanitize the user agent when reflecting back the user's browser properties (most commonly on a 404 page.)
Back to Main Content
