Cross-site Scripting Attacks: Misunderstood and Dangerous
With Cross-site scripting (abbreviated XSS), most popular security mechanisms including firewalls and encryption become completely irrelevant. Also, due to the fact that the hijacking a session of a customer or an administrator of a web application — one of the results of an XSS attack — can have massive consequences on the business value of a service. Such a vulnerability can be much more devastating than most other attacks.
How misunderstood is it?
In a large number of situations, cross-site scripting is compared to SQL-injection due to similarities in their practice of injecting malicious code into legitimate and trusted code.
However, this is misguiding and demeaning to both attack categories.
They are two quite independent beasts that work in very different contexts and arise from different motivations. Unlike SQL-injection, cross-site scripting doesn’t inject malicious instructions into database-access processes at the hands of a malicious user, but rather work by manipulating an innocent end-user into executing code that will be seen by the server as legitimate user activities.
While the prevention of SQL-injection can be (arguably) easily achieved to a satisfying degree as consequence of techniques like intermediate query frameworks and ORM (especially in the .NET world), cross-site scripting (or XSS in street-talk) is not usually considered a threat due to the lack of understanding of its severity and state of reliable resolutions. Even the name “cross-site scripting” itself confuses most parties. While this name made sense with the scenarios in which it was discovered, it has long surpassed the security of same-origin policy , with the examples of stored XSS and second-order XSS.
Introduction to Cross-site scripting
The original idea of an XSS attack was that a website could cross a boundary and run arbitrary code inside another page; spy over sensitive data in forms, re-write page content and so on; hence the name cross-site scripting.
And this is why same-origin policy was introduced as a prevention form. But hackers perceived this only as a challenge and invented novel ways to circumvent the security by adapting the same concepts. Therefore, while the name “cross-site scripting” made sense with the scenarios in which it was discovered, cross-site scripting has long surpassed the security of such crude security mechanisms, with the examples of stored XSS and second-order XSS.
In simple terms, cross-site scripting as we know today, is an umbrella phrase covering a broad range of attacks that ultimately execute malicious JavaScript in the context of a website.
Persistent XSS (or stored XSS)
… stores strings containing the malicious code inside the web application’s database to be later inadvertently executed (on viewing) by a victim. These can be posts or comments in a forum, a user-to-user message or a HTML-customized page of a social profile.
Reflected XSS (or non-persistent XSS)
… embeds such malicious strings inside a request sent by the user (under manipulation) to the application, for example; as an AJAX GET request.
In addition to that, a DOM-based XSS attack is a situation where the whole attack takes place inside browser, without depending on the back-end to take any part . Such attacks rely on the existing, legitimate JavaScript of a page (even frameworks like AngularJS) to help execute the malicious instructions and generally originate from a URL.
Outcomes of an XSS attack
As in many vulnerabilities, the application of a well-planned cross-site would usually be simply a stepping stone in a much larger scheme. With XSS, the harvest of user credentials — or more commonly user sessions leading to exactly that — becomes trivial.
Hijacking the victim’s cookies containing the session ID can be as simple as accessing `document.cookie` and sending it as a simple GET request to the attacker’s server.
Phishing
Attacks where unsuspecting users are manipulated into clicking seemingly innocent links inside social networking sites (including but not limited to Facebook), simply viewing a certain social forum post or falling for a dynamically created page that is disguised as a privacy or security reminder are quite common.
Such phishing attacks have the potential to be extremely difficult to separate from legitimate content and are not identifiable through simple vigilance as in the case of traditional phishing attacks where a user is persuaded into visiting a fake login screen in an attacker-controlled domain.
Keylogging
Secretively registering a keyboard event-listener through `addEventListener(..)` is just a matter of coming up with a clever pattern for breaking through the encoding or sandboxing of any client-side framework.
The astounding and fearful nature of being able to track all keystrokes of a user in any web application requires no further explanation.
The potential scope of an attack
Prevention
The simplest and most common forms of attempts to prevent cross-site scripting is encoding and validation.
Encoding is used for escaping the user input and helping the browser interprets such strings only as data and not code.
Validation is used for filtering user input in cases where it is required to be executed, by helping the browser strip or block malicious instructions.
Such careful handling of user input must to be done differently depending on the context. In other words, where in a page user input is inserted.
This can be performed either at the reception of input or prior to the insertion of that input into a webpage. Sanitation or handling of input can be done on the side of the user-agent (browser) or on the side of the back-end, depending on the circumstance.
The same input may be required to be inserted or processed at different places and under different contexts. Such security measures need to be taken without limiting the user-experience and functionality.
Validation
Black-listing and white-listing are two methods used for validating, i.e. sanitizing or rejecting input.
Both have competing advantages as well as drawbacks. But generally, blacklisting, which is a method of preventing known patterns is deemed inferior to white-listing, which only allows extremely selective input patterns.
Still, secure input handling alone may not be a long-term solution in many cases, as oversight in a single place can render security in all other places worthless.
Content Security Policy
As a firm and reliable solution for such situations, CSP introduces policies for the browser to prevent ground for such vulnerabilities.
While parameters of CSP are well customizable , three main categories can be identified:
- No untrustworthy sources — Content can be loaded only from a set of clearly-defined external sources
- No inline resources — No inline Javascript and CSS will be executable
- No eval — The `eval()` function in the JavaScript API will be blocked.
Conclusion
Admitting the possibility of a problem is the key to finding a resolution for it. With familiarity and foresight, most unfortunate circumstances can be expected and avoided. Otherwise, every speck of effort in securing a product can be washed-away due to simple oversight.
Cross-site scripting is a very critical scenario for the existence of which every web-application developer should be constantly concerned about and implement the best of countermeasures.
The lack of clear understanding of the severity of the threat it poses and its attack vectors lead to the loss of motivation and knowledge required in developers for identifying related critical vulnerabilities in their applications, ultimately putting them on a false sense of security.
Thank you for reading! Feel free give me your feedback, opinions and advice or just stay connected!
Have a happy and secure Christmas!
This article was originally published in the TechDeep magazine (’17) produced by the Embla staff.
Read the below embedding of the magazine for more articles and sources for this article.
