When is a vulnerability not a vulnerability?
Recently, I was discussing the types of submissions that are often declined by bug bounty programs with Tomer Schwartz, who works as part of the Microsoft Security Response Center (MSRC). Unfortunately, sometimes he is the person who has to do the declining. He said, “Sometimes a vulnerability just isn’t a vulnerability”. You might think this sounds wrong, but let’s talk about what he meant.
The OWASP Top Ten is often quoted by those who make bug submissions, as though OWASP are the authority on all things web application security. While I do agree that we do seem to be the authority, I don’t agree that every person who reads the Top Ten document fully understands it. Which means sometimes people submit bugs that they think are part of the top ten, but they don’t *really* qualify.
Let’s talk about two examples.
First, Cross Site Request Forgery, or CSRF (Sea-Surf) for short.
The CSRF vulnerability is when an attacker gets a user to click on a malicious link (usually via phishing), and the link attempts to perform a transaction on the site. This attack assumes that the user is already logged in. You might think that this is far-fetched, but I will admit that I have found myself logged into Amazon for 4+ hours at a time, looking at dresses, on more than one occasion. If Amazon was vulnerable to this attack (it’s not), and if I clicked on a phishing link with a CSRF attack in it (we all make mistakes), then the attacker could potentially purchase something on my behalf, change my password, or even delete my account. This is why most sites re-authenticate the user when important things like this happen, usually by passing an anti-CSRF token, but also by asking for a captcha or for the user to re-enter their password. This is the reason why whenever you change your password that you also have to enter your old password.
The part that many people don’t seem to understand though, is that a CSRF attack only matters if something is at stake. A transaction of some sort needs to occur, otherwise it doesn’t matter if someone performs this attack against you.
Let me explain. If I am logged into Amazon and I search “dresses with pockets”, that’s not a transaction. I’m submitting a form, yes, but nothing important is happening. If someone sent me a phishing link that included that search criteria, what harm would it cause if it was executed? None. And therefore, no mitigation for the CSRF attack is required (passing a token or other re-authentication of the user).
In summary, if a form is being submitted, but there is no harm that can be done by someone else impersonating a user and submitting it for them, then it is not vulnerable to CSRF. Not on a technical level, but on a business logic level. This is why we don’t pass anti-CSRF tokens on search pages, navigation pages, and anything else that does not contain transaction functionality.
But this type of situation is reported to bug bounty programs all the time. And then they are rejected. Because although there is a technical issue (the app can be mis-used), there is no business risk. And therefore, no vulnerability.
Example 2, when SQL Injection does not cause a business risk.
WHAT? That’s unpossible! Injection is #1 on the Top Ten!
Hear me out. Imagine you have a web app with an SQL database. It contains only one table, and all of the data in that table is available via the search field on the website. None of it is sensitive data. The database user that the app uses is read-only. But the application is vulnerable SQL Injection (SQLi).
Where’s the business risk? How does this affect the Confidentiality, Integrity or the Availability (CIA) of the app? Since none of the data in the entire database is confidential, so the “C” does not apply. And since the database user is read-only, that means the data cannot be changed (update, create or delete) with this attack, only read (select). The read-only means it also cannot allow any sort of code execution on the database server, other than the select statement. That covers the “I”. And “A”, availability? I suppose there is the potential to do extremely large queries in attempts to perform a denial of service attack... But there are many ways to attempt a DOS attack, and I wouldn’t qualify this as a critical business risk by any means.
This is the type of thing that also gets rejected from a bug bounty program. Yes, you can perform SQLi on the app, but it isn’t a big scary problem. Yes, you can cause the application to misbehave, but it does not present a threat to the business.
If I found this problem in one of my apps would I put it in the bug tracker to be fixed? Absolutely. Would I make my dev team stay up all night fixing it or take the server offline? Nope. In fact, this exact situation happened to me while I was managing an incident, and the person who reported it was furious with me, claiming I didn’t take security seriously, I didn’t know what I was doing, etc. But I stand by the decision, and everything was fine (despite him complaining to my boss about me). We did fix it, but not that night.
For content like this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!
