Cross-Site Scripting (XSS) in details – With examples
What is (Code) Injection?
Cross-Site Scripting (XSS)
Anyway, many times this vulnerability tends to be treated as not very critical from developers, especially by assuming that if the application is read-only it cannot be attacked. But, this is not true as it became very clear with the incident on MySpace.com (social media network). At 4th of October 2005, a hacker named Samy Kamkar, 19 years old at that time, discovered an XSS injection vulnerability at MySpace. He crafted an injection code which turned out to be the fastest spreading computer worm. The worm later named as “Samy Worm” or “JS.Spacehero worm”, once was posted in Samy’s profile page, whoever else will see his page it will automatically add Samy as a friend, by skipping the MySpace friendship protocol. Additionally, the same injected code will be posted on the victims profile page as well, so whoever will see his page will add Samy as a friend too.  
Moreover, the injected code will also change the victims’ page to say “Samy is my hero”. This was spread exponentially, so within 20 hours Samy had over one million friends at MySpace. Either that he was declared to be doing this not to harm anyone, but just to impress his friends, he was sentenced with three years of probation with no computer access.
XSS attack follows the same concept of code injection, with minor differences. The main difference is that the XSS attack specifically injects client-side (web browser) code. Another difference is that, in order for the attack to be successful, the application should necessarily display an output of the injected code in the browser. As it was mentioned in the previous chapter, this was not the case with SQL injections. In SQL injection, it was not mandatory for the data to be displayed in the user view. However, a similarity with SQL injection is the way of exploitation. XSS vulnerability is exploited when the application does not parse the input for escape characters. The technical impact of this vulnerability is allowing the attacker to execute scripts in victim browsers, hijack user sessions, deface web sites, insert adverse content, redirect pages etc. There are many ways to attack the XSS vulnerability, but primarily they are grouped in two categories as Stored XSS and Reflected XSS.  
In this XSS attack type, the attacker will inject code through any input form, in which the application will store in the database. After that, the application will display the stored values (injected code) in some other page/s, by treating it as a simple text value. When the victim will open the specific vulnerable page which contains the injected code, its browser cannot differentiate the malicious code from the actual page code. Therefore, the injected code will be executed as trustworthy. Hence, the vulnerability will be exploited by a stored injected code.  
As an example of a Stored XSS attack, I will show a vulnerability that I have found on the US Department of Defense (DoD) public website. This vulnerability was found through “Hack the Pentagon” bug bounty program, which was publicly released by U.S. Government. In their website there is a section that allows anyone to make public questions. However, to do that the users need to be registered first as illustrated in figure 1. The user registration page is vulnerable to stored XSS since it is not parsing the user information input.
Figure 1 – US Department of Defense website, the user registration form
To exploit this page, the following browser code can be used instead of users’ first name (figure 1).
"><h1 onmouseover="alert(123)">TEXT XSS</h1>
After submitting this form, the application will store the information in the database and will show a page to inform the user for successfully creating an account (figure 2).
Figure 2 – Account creation, confirmation page
Next, after clicking Login button, and actually logging in by using the email and password provided in the registration form, the injected XSS code is executed (image 3).
Figure 3 – Exploited vulnerability of Stored XSS on “Submit a question” page
Unlike Stored XSS, this attack works on applications that do not store the user input data, yet they only reflect the tainted input in the browser without parsing it. For that reason, this attack is called Reflected XSS.  
To demonstrate this attack, an existing web portal will be used as an example. The portal’s home page contain a search input which is vulnerable to Reflected XSS (figure 4). To exploit it, instead of a valid text, we will use the same code that we used on the Stored XSS example:
"><h1 onmouseover="alert(123)">TEXT XSS</h1>
Figure 4 – Home page of a Website Portal
Note that the “Filter” parameter handles the XSS injected code and reflects it back in the browser. The attacker can use and share similar links to try and deceive his victims.
Figure 5 – Exploited vulnerability of Reflected XSS on home page of a Website Portal
OWASP, “Top Ten Most Critical Web Application Security Risks,” 2013. [Online]. Available: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf.
OWASP, “Code Injection,” 31 December 2013. [Online]. Available: https://www.owasp.org/index.php/Code_Injection.