Vector
Vector

Choose your topics

Blogs
The GRC Trends to Look Out for in 2024

Our GRC experts at SureCloud share their 2024 predictions for the world of governance, risk and compliance.

GRC
Blogs
The Top 5 Challenges of Third-Party Risk Management

With the supply chain now seen as a legitimate attack path, what can your organization do? Let’s explore 5 challenges of TPRM and how to overcome them.

Third-Party Risk Management GRC
Blogs
What is Third-Party Risk Management?

What is third-party risk management and how should you approach it? Find out in this post.

Third-Party Risk Management GRC
Blogs
The Top 4 Challenges of Risk Management

What are the top four challenges of risk management today and how can you overcome them? Find out in this post from SureCloud.

Third-Party Risk Management GRC
Blogs
Transform Compliance into Your Competitive Advantage

In GRC, compliance is often viewed as a cost that makes it harder to pursue growth. Here's how to make it your competitive advantage.

Compliance Management GRC
Blogs
Questions You Should Ask when Preparing For Your First Pen Test

Understand the processes that you and your chosen pentest provider will travel through for your first pen test, from the initial point to the day the test starts.

Penetration Testing
Blogs
TPRM Blog 6-Writing Clear Questions

Our GRC Practice Director explores the importance of clear communication and how to achieve it in your third party questionnaires. Read more here.

Third-Party Risk Management GRC
Blogs
The Simple Way to Combat Phishing

SureCloud Cybersecurity Practice Director Luke Potter shares his tip to stay ahead of attackers phishing for your downfall.

Penetration Testing
Blogs
See Yourself in Cyber With Janhavi Deshpande

See Yourself in Cyber With Janhavi Deshpande - SureCloud

Cyber Security
Vector (7)
Vector-1
Cyber Security

We need to talk about web flaws

We need to talk about web flaws
Written by

Admin

Published on

30 Oct 2017

We need to talk about web flaws

 
 

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.