We Need To Talk About Web Flaws

Chris Cooper, Security Team Leader for SureCloud, examines three web application flaws that are still posing a risk to organisations

 Web application security is finally catching up with the threat landscape in which it is situated. Common vulnerabilities have been identified and are being fixed. The industry has generally adopted the Open Web Application Security Project (OWASP) Top 10, a list of the most critical web application security risks and the steps needed to mediate them. The most recognisable flaws at the highest rungs of this list are in decline, and when they are identified, developers fix them. Awareness is growing – but it is not equal everywhere.

In areas where awareness is poor, developers 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. Here are three of the major ones to consider.

CSRF

Cross-site request forgery (CSRF) is perhaps the most common high-severity flaw in web applications today, and the most poorly understood.

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 genuinely 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 recommended method is the use of a synchroniser 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 will fail as long as they don’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.

Flawed 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 behaviours. 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 only a minor subset of the major web application flaws that aren’t receiving enough airtime – there are plenty of others. While the industry continues to focus on the few, it will allow these outliers to slip into critical applications that power businesses, governments, and everyday Internet consumers. It is critical that the web application industry takes a closer look at the content covered by OWASP, considers in detail relevant research conducted by security firms, and gets talking about the wider web security landscape, sharing critical knowledge.