Web application security has, at long last, started catching up with the threat landscape in which it is situated. Common vulnerabilities have been identified, and are being fixed. The industry, as a collective, has generally adopted the OWASP Top 10. Vulnerabilities do still occasionally slip into production, but the industry as a whole knows how to deal with them and is getting better at responding to them.
However, there is still work to be done. When it comes to the likes of SQL injection, cross-site scripting, and password hashing, there are still providers who are failing to prepare well enough, and subsequently fall victim to major vulnerabilities in these areas.
By contrast, ‘common’ flaws, the most recognisable names at the highest rungs of the OWASP Top 10, are in decline. What’s more, when they are identified, developers fix them. Increased awareness means that the mistakes are less likely to be made in the first place, and that damage control when they do occur has also improved.
By contrast, in areas where awareness is poor, we are more likely to make mistakes and are weaker at responding to them. This means that rather than focusing all our attention on the weaknesses we already understand, we must start talking more about the ones we don’t. These flaws might be much more complex, much newer, or simply much harder to define.
CSRF
Cross-site request forgery (CSRF) can fall into the ‘much more complex’ category. In my personal experience, this is the most common high-severity flaw that I see in web applications today, as well as being the most poorly understood. It is not new, and is potentially a very severe and practical method of attack.
CSRF attacks work when a user is tricked into sending a request that makes a change on the vulnerable web application.
The server assumes that, because the request was received from the victim’s browser, that they actually initiated it. In actuality, it might have been initiated by a malicious website that they were lured onto, a crafted link that they followed, or an image they loaded in an email. When an application is vulnerable, it can often be leveraged to take any action on behalf of the user. This depends on the application in question, but it might include changing their login details or triggering a money transfer to the attacker.
The only way to prevent this is to allow the application to tell the difference between a genuine request initiated by the user, and a crafted request from an attacker. The most highly recommend method is the use of a synchronizer token.
The attacker can only craft an effective request if they know beforehand all the information that needs to be submitted. If every ‘action’ on the application requires a secret token to be submitted alongside it, one that is tied to the user’s session, any request crafted by an attacker would fail as long as they didn’t know the user’s token.
DOM-based XSS
DOM-Based XSS – cross-site scripting that occurs in the client-side document object model – is another issue that is becoming more frequent, yet doesn’t receive a great deal of press. The exploitability and impact of this issue is very similar to regular cross-site scripting, which is significant when you consider that the cause and resolution of the vulnerability occur in an entirely different place. In other words, an awareness of regular cross-site scripting does very little to help prevent or control this otherwise related issue.
DOM-based XSS occurs in the browser, rather than on the server. It originates within client-side Javascript code, where unsafe input is taken – input that could potentially be defined by an attacker – and outputted into the DOM in such a way that it can be processed as further script.
In effect, a vulnerable input could define an arbitrary block of Javascript code which will execute on the page. The source input could, for instance, be part of the URL, a cookie, or a value reflected by the server. The payload might be able to read data from the page and leak it to an attacker, modify the page to trick the user, or a host of other potential XSS outcomes.
One of the key challenges is that this type of XSS occurs in the front-end user interface, and this isn’t really where we are used to seeing it. This makes it more difficult to prevent, detect and resolve. Yet, all the while, it poses a very similar risk to the traditional XSS we know and love.
Business logic
Business logic flaws vary significantly, which makes them more difficult to define and understand. This type of issue generally permits an attacker to manipulate the logic of an application – using it in a way that was not intended by the developer. Preventing and testing for these kinds of flaws requires an in-depth exploration of the application’s processes, and what can happen if the workflow is subverted.
A business logic flaw might, for example, allow a user of an ecommerce site to begin transactions and earn loyalty points without ever actually completing a purchase, or to apply a 10% discount code to their order multiple times when it should only be allowed once.
Oversights like this are relatively common, and combating them is harder. Most other types of vulnerability are very closed, with a set of well-defined characteristics and behaviors. Business logic flaws are extremely open-ended by comparison. This makes discussion all the more important, since we all have to understand a very wide range of potential scenarios in order to build a better picture of what these issues might look like, and what we can do to prevent them.
Get talking
These are a few vulnerabilities that are commonly discovered during our penetration tests, but we don’t feel are being discussed often enough in the web development community. These are only a minor subset – there are plenty of others. While we continue to focus on the few, we will allow these outliers to slip past us into our critical applications that power businesses, governments, and every-day internet consumers.
We need a breadth of security knowledge throughout the industry, not just a convergence on the issues we hear about in the media. Take a closer look at the content covered by OWASP (The Open Web Application Security Project); consider the research being conducted by security firms who are invested in the industry; but most importantly, talk about the wider web security landscape and share knowledge.