What is (Code) Injection?
Cross-Site Scripting (XSS)
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].|
|||OWASP, “Code Injection,” 31 December 2013. [Online]. Available: https://www.owasp.org/index.php/Code_Injection.|
|||OWASP, “Top 10 -A1 Injection,” 23 June 2013. [Online].|
|||D. Ray and J. Ligatti, “Defining Code-injection Attacks,” Association for Computing Machinery, 2012.|
|||OWASP, “Cross-site Scripting (XSS),” 02 February 2016. [Online].|
|||OWASP, “Top 10 – A3 XSS,” 3 February 2014. [Online].|
|||S. Kamkar, “Technical explanation of The MySpace Worm,” [Online]. Available: http://samy.pl/popular/tech.html. [Accessed April 2016].|
|||M. R. Faghani and H. Saidi, “Social Networks’ XSS Worms,” APA Professional Center – Computer Security Incident Response Team, no. Social Networks’ XSS Worms .|
|||SANS Institute, “A Web Developer Guide to Cross-Site Scripting,” Information Security Reading Room, 2003.|
|||SANS Institute, “Phishing: An Analysis of a Growing Problem,” Information Security Reading Room, 2007.|