We talked about many different kinds of attacks. All of them have the same strategy-direct targeting the server-side application. But, the attacks that we are going to describe now fall under the different category. Here, the primary attacker’s target is the application’s other users. Sound confusing, right? Well, it is. What does the attacker do? He leverages some aspects of the app’s behavior to carry out malicious actions against the another end user. Those actions can result in hijacking, unauthorized access, the disclosure of the personal data and many other examples we already talked about. I think now is the great time for you to remind yourself about the cyber security tips before we go further!
I hope you’ve learned them and explored them well. How do these attacks actually look? These attacks against the other application users come in various forms and manifest themselves as a variety of subtleties and nuances that are frequently overlooked. We may admit that these attacks are not easily understood even today. We will focus on cross-site scripting or XSS attacks here. Those attacks are the primary attacks against the other users. Don’t panic, check your knowledge about the internet security tips so we can go on and learn something new!
Varieties of XSS
They may be delivered in three varieties: the reflected ones, stored and DOM-based.
Reflected-This is sadly a very common of Cross Site Scripting Attacks (XSS). It occurs when the app employs a dynamic page for displaying the input messages back to the users. The page simply renders that message text back to the user within its response. The behavior of taking user-supplied input and inserting it into the HTML form of the server’s response is one of the signatures of XXS vulnerabilities. So, be aware
Stored. This is a different category of XSS vulnerabilities. It is often called stored cross-site scripting. It arises when the data which is submitted by one user becomes stored in the app and then displayed to the other users without being filtered or sanitized appropriately. They are most common in the apps that support the interaction between end users. Also, where the administrative staff access user records and data within that same app. These attacks typically involve two requests to the app. The attacker posts the data which are malicious, and then the user views it.
DOM-based. This category of XSS attacks isn’t like the previous two we talked about above. Here, the attacker’s JavaScript gets executed: the user requests a crafted URL which is supplied by the attacker and contains embedded JavaScript. Furthermore, the server’s response doesn’t contain the attacker’s script in any form and when the user’s browser processes that response, the script is executed nonetheless.
It is also important to mention that these attacks happen in the real world also, and they expect the payloads.
Delivery Mechanisms of XSS Attacks
An attacker needs to find some means to deliver the attack to the other users of the app. It can be done by the three categories we talked about above. A forged-email may be sent in a targetted attack to a single target user or a small number of the users. An app administrator could be sent an email which apparently originates from a known user, but complaining that the specific URL is causing an error. It is also known as ”spear phishing”. Also, there is in-band delivery applies, where in the most cases is used the data which is the subject of the vulnerability. It is supplied to the application through its main web interface. That may include personal information, names of the document or uploaded files, or even some messages or status updates.
Finding and Exploiting Reflected XSS Vulnerabilities
So, let’s see what is the most reliable approach to detect the reflected XSS vulnerabilities? It involves the systematic work through all the entry points for the users’ input that were identified during the app mapping. So, it is important to submit a benign alphabetical string at each entry point, to identify all of the locations where that string is reflected in the app’s response, to identify the syntactic context for each reflection attempting to introduce arbitrary script into the response. Besides that, it is a must to submit all modified data which are tailored to the reflection’s syntactic context, attempting to introduce the arbitrary script into the response. And there is one more thing. In the case that the reflected data is blocked or sanitized, preventing your script from executing you need to try to understand the circumvent the app’s defensive filters.
Beating Sanitization
Sanitizing filters are probably the most common of all the obstacles which you may encounter while attempting to exploit the potential XSS conditions. The app performs some kind of sanitization or encoding on your attack string that renders it harmless, preventing it from causing the execution of JavaScript.
What is the most prevalent manifestation of data sanitization? It occurs when the app HTML-encodes the certain key characters which are necessary for delivering the attack. There are also the other cases where the application may remove the certain characters or expressions in an attempt to cleanse your input of malicious content.
The first step is to determine the precisely everything and which characters and expressions are actually being sanitized.
Preventing XSS Attacks
Although we talked about various kinds of XSS attacks, preventing this terrible vulnerability itself is in fact conceptually straightforward. Yes, that sounds great. But, what makes it then problematic in practice? It is the difficulty of identifying every instance in which user-controllable data is handled in a potentially dangerous way. It is because the every page which is given of the application may process and display the dozens of items of the user data. Also, the vulnerabilities may arise in error messages and any other location. XSS flaws are so hugely prevalent and even in the most security-critical apps.
How to identify all the operations which are potentially at risk of XSS? How to defend them? We will explain you simply. You must follow a threefold approach to prevent any actual vulnerabilities from arising. So, what to do?
1.Validate input.
2.Validate output.
3.Eliminate dangerous insertion points.
Allowing limited HTML. There are some apps that need to let the users submit their data in the HTML format. That format will then be inserted into the app’s response. It is important for the application to support this functionality securely. It needs to be robust in allowing only a limited subset of HTML. And what does that mean? It is an HTML form which does not provide any means of introducing the script code.
Let’s take a look what we have learned today! I really hope you have enjoyed this article. In this chapter, we examined the various ways in which common filter-based defenses can be circumvented. We learned that the XSS vulnerabilities are so prevalent, and in that case, it is often the straightforward that is the best way to find several bugs within the app which are easy to exploit. We mentioned everything you need to know about the XSS, and we hope that you will implement this knowledge in your real life. We also hope that you will never need to fight against XSS attacks!