Anatomy of Attack # 1 – Cross Site Scripting

Cross-Site Scripting (XSS) is one of the most popular attacks which uses the most popular vulnerabilities. It is considered one of the most risky attacks on internet applications. A Cross-Site Scripting attack is an injection of malicious code that will be executed in the victim’s browser. Malicious code is usually written in client-side programming languages ​​such as Javascript, HTML, VBScript, Flash, etc. However, Javascript and HTML are the most commonly used to carry out this attack.

The main purpose of this attack is to steal another user’s identity data – cookies, session tokens, and other information. In most cases, this attack is used to steal the other person’s cookies. As we know, cookies help us log in automatically. Therefore, with the help of stolen cookies, we can log in using other identities. This is one of the reasons why this attack is considered to be one of the riskiest attacks. Depending on the type of XSS attack, the malicious script might:

1. be reflected in the victim’s browser
2. stored in the database and executed each time the user calls the appropriate function.

The main reason for this attack is inadequate user input validation where malicious input can get into the output. A malicious user can enter a script that will be injected into the website’s code. Then the browser cannot tell if the code being executed is malicious or not. Therefore, a malicious script is run in the victim’s browser or a forged form is displayed. There are several forms in which XSS attacks can occur.

The main forms of Cross Site Scripting are as follows:

1. Reflected XSS – Malicious script is injected onto trusted or otherwise harmless websites. Typically, injection occurs when an unsuspecting user clicks on a link that is specifically designed to attack a visited website. Malicious results are returned when the malicious code is entered. The reflected XSS code is not saved permanently. In this case, the malicious code is reflected in any result of the website. The attack code may be contained in bogus URL or HTTP parameters.
   
   In a reflected XSS attack, a web application with an XSS vulnerability will allow potentially harmful data to enter a routine transaction. For example, when a user sends a network request to the server by submitting a form, the application responds with a page containing an echo of what the user submitted for confirmation. A malicious JavaScript snippet can replace or attach to a user entry that the user inadvertently executes. A reflected XSS attack can also trick a victim into launching an HTTP request by clicking on a malicious link in the email or a fake website that appears to be legitimate.

2. Stored XSS (Persistent XSS) – can be considered more risky and deals more damage. In this type of attack, the malicious code or script is saved on a web server (e.g. in a database) and executed each time the user calls the appropriate functionality. The XSS attacks stored in this way can affect many users. Also, since the script is stored on a web server, it will have an impact on your site for a long time. In order to perform a saved XSS attack, the malicious script should be sent via a vulnerable input form (for example, a comment field or a review field). In this way, the appropriate script will be saved in the database and executed when the page is loaded or the appropriate function is called.

3. DOM XSS (DOM-based/type-0 XSS) – Occurs when the DOM (Document Object Model) environment is changed, but the client-side code does not change. When the DOM environment is modified in the victim’s browser, the client-side code behaves differently. Example: Take into account that there is a website with the URL http://testing.com/book.html?default=1. As we know, “default” is a parameter and “1” is its value. Therefore, to perform an XSS DOM attack, we could pass a script as a parameter.

XSS is considered to be one of the most dangerous attacks because its main purpose is to steal the identity of website or system users. Moreover, XSS attacks can be carried out using various client-side languages ​​such as JavaScript, HTML, VBScript, Flash etc. And this makes them more harmful and widespread than other possible attacks. Another thing that makes it risky is the ability to save it on your website – this way, it can affect many users over a long period of time. XSS can sometimes be executed even on less vulnerable systems, and the vulnerabilities it exploits are often hard to find.

Ways to prevent XSS

Given that this type of attack is considered to be one of the most dangerous and risky, a prevention plan should be prepared. Due to the popularity of this attack, there are many ways to prevent it.

Commonly used methods of prevention include:

• Data Validation – The first step in preventing this attack is validating your input data. Anything the user enters should be carefully validated as user input may end up in exit. Data validation can be called the basis for ensuring system security. I would like to remind you that the idea of ​​validation is to prevent wrong input data. Another good prevention method is filtering user input. The idea behind filtering is to search for risky keywords in user input and remove or replace them with empty strings. These keywords can be:

• <script> </script> tags

• JavaScript commands

• HTML tags

• Static and software structure analysis services that scan binary files to find and fix bugs. This is most often combined with the vendor’s application security testing services to evaluate security risks in third-party applications.

• Web Application Firewall – A WAF firewall or web application helps protect web applications by filtering and monitoring HTTP traffic between the web application and the Internet. WAF is protocol layer 7 protection (in the OSI model) and is not intended to defend against all types of attacks. When deploying the WAF file in front of the web application, a shield is placed between the web application and the Internet. While the proxy server protects the identity of the client computer through an intermediary, WAF is a type of reverse-proxy that protects the server from attack by filtering client requests through WAF before reaching the server.

If we look at the growing standards for application security – WAF is the absolute minimum to be implemented before each web application, and is often offered as a service from your hosting provider. However, soon applications built accordingly to security by design principles – with built-in filters and validation mechanisms, data encryption, API control etc. – will become the majority.