What is (Code) Injection?

According to OWASP, code injection is the most common vulnerability of web applications [1]. As a term, a code injection is a general approach for describing the attack types which are exploited by feeding the applications with invalid data [2]. More specifically, in these type of attacks, the attacker inserts malicious code in the application instead of valid data. After the code injection occurs, the software will execute the malicious code and will perform functionalities that are not supposed to achieve [2]. In most of the cases, a successful code injection can result with disastrous events [2]. Technical impacts of code injection can result in data loss or corruption, lack of accountability or denial of access [3]. As a worst case scenario, code injection can cause complete control takeover of the victim [3]. While, as a business impact of this attack is considered to be theft, modification, and removal of data [3]. Code injection can be applied in many different formats like SQL, Client-Side code (HTML/CSS and JavaScript), Shell, LDAP, File, Object etc. SQL injection will be discussed in more detail in the following subsections. [1] [4]

Cross-Site Scripting (XSS) 

As another form of code, injection is considered to be the injection of client-side (browser) code like HTML, CSS, and JavaScript. This type of injection is more known as Cross-Site Scripting and it is represented with the acronym of XSS. In OWASP Top 10 vulnerabilities list this vulnerability is listed separately from code injections by being in the third position. According to OWASP, XSS vulnerability is the most prevalent security flaw in web applications. [5] [6]

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. [7] [8]

Samy Kamkar

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. [5] [9]

Stored 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. [5] [9]

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>

The first two characters “> are used to break HTML input element, so the quotation mark (“) will close the value attribute, and the bigger than (>) character will close the input tag. The rest of HTML will print a text of “Heading 1” type, with the value of “TEXT XSS”. Moreover, to test the JavaScript functionality, the injected code will show an alert window with the message “123” when the user will move the mouse over the “TEXT XSS” text.

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

Instead of the first name, the Heading 1 text is shown, also the JavaScript alert window when moving the mouse over the text. This means, wherever this user’s first name is displayed the injected code will be executed. So now, making a public question by using this profile, anyone else who will see the question will be a victim of this injected code. Certainly, this attack can be sophisticated furthermore, depending on the attacker goals. Another approach of using this attack is to steal the other logged in users’ session information, or defacing the vulnerable pages to use them for Phishing attacks. A Phishing attack is the attempt to collect sensitive information by impersonating a trusted entity [10].

Reflected XSS

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. [5] [6]

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

After clicking on the Search button, the injected code will be reflected successfully in the page, as it is presented in figure 5. Rather than considering the injected code as text, the browser will execute it by displaying the Heading text of “TEXT XSS”, followed by the JavaScript alert window with the message of “123”. Surely, this attack can also be evolved in more advanced versions, thus having a bigger impact. In difference with Stored XSS injection, the other web visitors will not be affected directly, because the injected code is stored nowhere. In order for the attacker to affect the others with his code injection, it should share the link through other mediums or apply other attack methods. The link for this XSS injection would be the following:

http://www.somesite.com/other.php?Filter="><h1+onmouseover="alert(123)">TEXT+XSS</h1>

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

The attack shown on above figures was tested using Internet Explorer 11 browser. Nevertheless, if the same example will be tested with the latest version of Google Chrome browser, the JavaScript window alert will not get executed. That is because most of the modern browsers have started to implement security features against XSS injection for their users. Anyway, this will be explained in the next chapter as one of the protection mechanisms from code injections.

References