XSS Protection in DevOps Platform

Introduction to Cross-site scripting (XSS)

Cross-site scripting (XSS) has been an ongoing issue in the security world. It's part of OWASP Top 10 list since its inception. Attacker tricks an application to send malicious script through the browser, which believes the script is coming from the trusted source. Now, whenever user accesses the affected page, their browser will download and run the malicious script. In the majority of XSS attacks, the attacker will try to hijack the user's session by stealing their cookies and session tokens or will use the opportunity to spread malware and malicious JavaScript.

Prevention of XSS

XSS vulnerabilities are difficult to prevent simply because there are so many vectors where an XSS attack can be used in most applications. In addition, whereas other vulnerabilities, such as SQL injection or OS command injection, XSS only affects the user of the website, making them more difficult to catch and even harder to fix. Also, unlike SQL injection, which can be eliminated with the proper use of prepared statements, there's no single standard or strategy to preventing XSS attacks.

XSS attacks can occur on any site in any place that accepts user input by incorrectly or without validating it. XSS is an attack method of having a legitimate website echo malicious, executable code, which is then loaded into a user's browser. Malicious sites can load a legitimate site into a window or frame and then, primarily using JavaScript, read and modify the data from the legitimate site.

XSS attacks can generally be categorized into two categories: Stored (or persistent) XSS, which is when malicious script is injected directly into the vulnerable application, and reflected XSS, which involves 'reflecting' malicious script into a link on a page, which will activate the attack once the link has been clicked. There is a third, much less well-known type of XSS attack called DOM Based XSS (or type-0 XSS), wherein the attack payload is executed as a result of modifying the DOM 'environment' in the victim's browser used by the original client-side script, so that the client-side code runs in an 'unexpected' manner.

DevOps Platform application preventive measures

Input Validation

"The theory goes like this: expect any untrusted data to be malicious. What's untrusted data? Anything that originates from outside the system and you don't have absolute control over so that includes form data, query strings, cookies, other request headers, data from other systems (i.e. from web services) and basically anything that you can't be 100% confident doesn't contain evil things." - Troy Hunt

Input validation is especially helpful and good at preventing XSS in forms, as it prevents a user from adding special characters into the fields, instead refusing the request. However, as OWASP maintains, input validation is not a primary prevention method for vulnerabilities such as XSS and SQL injection, but instead helps to reduce the effects should an attacker discover such a vulnerability.

For our platform, all data is untrusted by default. Our platform validates all inputs and ensures that platform is rendering the correct data and preventing malicious data from doing harm to the site, database, and users.

Sanitizing

Another way to prevent XSS attacks is to sanitize user input. Sanitizing data is a strong defense. DevOps Platform does input sanitizing to ensure data received can do no harm to users as well as database by scrubbing the data clean of potentially harmful markup, changing unacceptable user input to an acceptable format.

Use HTTPOnly cookie flag

To help mitigate the impact of an XSS flaw on any site, OWASP also recommends to set the HTTPOnly flag on session cookie and any custom cookies to restrict access from JavaScript. DevOps Platform uses HTTPOnly cookie flag for all session cookies.

Use the X-XSS-Protection Response Header

This HTTP response header enables the Cross-site scripting (XSS) filter built into some modern web browsers.

DevOps Platform process preventive measures

Apart from all these application controls, we have a nightly build setup for our platform. We run unit test cases, integration test cases, performance test cases etc. We also check code quality using Sonarqube in this setup. We run Open Source Component Analysis, Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) to ensure secure development in this nightly build setup. We do penetration testing for all our Long Term Supported (LTS) releases.

Help us to improve our platform. Contact Digital.ai technical support to report any vulnerability.