How To Secure From XSS And It's Impact On Business?

Cross-site scripting(XSS)

Cross-site scripting(XSS) is a client-side code injection attack. The attackers aim to execute malicious scripts into a web browser of the victim by including a malicious code in a web application. The attack can occur when the victim visits the web page or web application that executes the malicious code. The web application or web page becomes a vehicle to deliver the malicious script to the victim’s browser. Vulnerable vehicles that are commonly used for cross-site scripting attacks are forums, message boards, and web pages that allow comment.
A web page or web application is vulnerable to XSS if it uses unsanitized user input in the output that it generates. This user input must then be parsed by the victim browser. XSS attacks are possible in VBScript, ActiveX, Flash, and even CSS. however, they are most common in javascript, primarily because javascript is fundamental to the most browsing experience.

What Can An Attacker Do With Javascript?

XSS vulnerabilities are perceived as less dangerous than for example, SQL Injection vulnerabilities. The consequences of the ability to execute javascript on a web page may not seem dire at first. Most web browsers run JavaScript in a very tightly controlled environment. JavaScript has limited access to the user’s operating system and the user’s files. However, JavaScript can still be dangerous if misused as part of malicious content:
• Malicious JavaScript has access to all the objects that the rest of the web page has access to. This includes access to the user’s cookies. Cookies are often used to store session tokens. If an attacker can obtain a user’s session cookie, they can impersonate that user, perform actions on behalf of the user, and gain access to the user’s sensitive data.
• JavaScript can read the browser DOM and make arbitrary modifications to it. Luckily, this is only possible within the page where JavaScript is running.
• JavaScript can use the XMLHttpRequest object to send HTTP requests with arbitrary content to arbitrary destinations.
• JavaScript in modern browsers can use HTML5 APIs. For example, it can gain access to the user’s geolocation, webcam, microphone, and even specific files from the user’s file system. Most of these APIs require user opt-in, but the attacker can use social engineering to go around that limitation.
The above, in combination with social engineering, allow criminals to pull off advanced attacks including cookie theft, planting trojans, keylogging, phishing, and identity theft. XSS vulnerabilities provide the perfect ground to escalate attacks to more serious ones. Cross-site Scripting can also be used in conjunction with other types of attacks, for example, Cross-Site Request Forgery (CSRF).

Types Of Cross-Site Scripting

Below are thorough explanations and detailed walkthroughs of the different types of XSS. A vulnerable web application was set up for these examples.
Reflected Cross-site Scripting Reflected Cross-site Scripting (Type-2) occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request. The data sent to the server is not stored and can only impact the individual that accessed it directly
Stored XSS Stored XSS (Type-1) generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field. A victim can retrieve the stored data from the web application without that data being made safe to render in the browser. The only difference between this and Reflected XSS is that the JavaScript will be triggered for every visitor to the site
DOM-Based XSS DOM-Based XSS (Type-0) is a form of XSS where the entire tainted data flow from source to sink takes place in the browser where the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document. write).

Impact and Risk

How To Prevent Cross-site Scripting (XSS)

Preventing Cross-site Scripting (XSS) is not easy. Specific prevention techniques depend on the subtype of XSS vulnerability, on user input usage context, and on the programming framework. However, there are certain general strategic principles that you should follow to keep your web application safe.
Step 1: Train and maintain awareness
To keep your web application safe, everyone involved in building the web application must be aware of the risks associated with XSS vulnerabilities. You should provide suitable security training to all your developers, QA staff, DevOps, and SysAdmins. You can start by referring them to this page.
Step 2: Don’t trust any user input
Treat all user input as untrusted. Any user input that is used as part of HTML output introduces a risk of an XSS. Treat input from authenticated and/or internal users the same way that you treat public input.
Step 3: Use escaping/encoding
Use an appropriate escaping/encoding technique depending on where user input is to be used: HTML escape, JavaScript escape, CSS escape, URL escape, etc. Use existing libraries for escaping, don’t write your own unless absolutely necessary.
Step 4: Sanitize HTML
If the user input needs to contain HTML, you can’t escape/encode it because it would break valid tags. In such cases, use a trusted and verified library to parse and clean HTML. Choose the library depending on your development language, for example, HtmlSanitizer for .NET or SanitizeHelper for Ruby on Rails.
Step 5: Set the HttpOnly flag
To mitigate the consequences of a possible XSS vulnerability, set the HttpOnly flag for cookies. If you do, such cookies will not be accessible via client-side JavaScript.
Step 6: Use a Content Security Policy
To mitigate the consequences of a possible XSS vulnerability, also use a Content Security Policy (CSP). CSP is an HTTP response header that lets you declare the dynamic resources that are allowed to load depending on the request source.
Step 7: Scan regularly (with Acunetix)
XSS vulnerabilities may be introduced by your developers or through external libraries/modules/software. You should regularly scan your web applications using a web vulnerability scanner such as Acunetix. If you use Jenkins, you should install the Acunetix plugin to automatically scan every build.

---