Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Don't Dismiss the Small Vulnerabilities in Your Code

DZone's Guide to

Don't Dismiss the Small Vulnerabilities in Your Code

Never dismiss a small vulnerability because the impact on its own could be negligible.

· Security Zone ·
Free Resource

Do you know who is accessing your valuable data through your APIs? Discover how

The original article was published by security researcher Linus Särud on the Detectify blog.

Never dismiss a small vulnerability because the impact on its own could be negligible. Seemingly innocent vulnerabilities can be combined into something much more dangerous or, at the very least, be used to aid in an attack.

Sometimes, a small vulnerability is overlooked as the impact is not seen as dangerous. What is often missed in this type of scenario are the potential consequences of when vulnerabilities are combined. This is often called chain vulnerabilities.

This article serves as food for thought, to introduce the mindset and make you think a few steps ahead, as a hacker would. 

Combining vulnerabilities



How Vulnerabilities Can Be Combined

XSS and HTTPOnly

Imagine there is a developer page publicly accessible from the Internet. The only thing this page does is print the whole request onto the page. At first glance, this looks very innocent. How much does seeing their own request really help the attacker?

Now, imagine there is also an XSS on the same domain. All of a sudden, the printed request becomes very bad, as the hacker is able to steal all cookies with the XSS. An XSS can read the content of the webpage but not the sent headers when HTTPOnly is used. Such a debug page will, therefore, result in an HTTPOnly bypass.

Localhost and SSRF

Sometimes, you may neglect to update software that is only accessible locally. Vulnerable software that only allows requests from localhost/the same server seems a bit harmless, doesn't it? Well...

There is another vulnerability type called SSRF, Server Side Request Forgery. In short, it means that an attacker is able to force the web server to make custom requests to the internal network.

Now combine these two and an attacker is able to exploit the vulnerable software that was only running locally. Neither of those things sounds that dangerous, but combined, they can have a considerable impact!

CSRF and XSS

Log in/log out CSRF is another vulnerability we have written about before. It enables the attacker to forcefully log the victim into the attacker’s own account.

Once again, at first glance, this looks innocent enough. What good does it do the attacker that they can give away their own account? However, combine it with an XSS that previously only affected your own account and you now have an XSS affecting anyone.

How About Automation?

Many of these combinations are hard to automate. Some can, of course, be combined automatically, but others still require human creativity to fully understand the potential severity of the impact.

Because of this, minor issues reported by tools such as Detectify should not be ignored. Critical findings need to be prioritized, but it is also a good idea to evaluate how an attacker may chain and exploit minor issues. Even the most harmless ones can escalate into something critical.

Have you tried to chain vulnerabilities before? Leave your comments below. Thanks for reading!

Start a free self-guided trial to discover how API Security is done through a true Zero Trust approach.

Topics:
web vulnerabilities ,bug bounty ,xss ,csrf ,httponly ,ssrf ,web security ,cybersecuity ,security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}