[bean-weevil]

I formerly worked in triage for a bug bounty program. We paid attention to these kinds of reports because it's often possible to bypass the WAF, or at least repurpose the vulnerability in a way the WAF wasn't designed to defend against.

[kstrauser]

Absolutely! If you have a known SQL injection behind a WAF, you better go fix it! It seems like these reports come down to the equivalent of “I pasted HTML into a form and you displayed the escaped version back to me, but maybe you forgot some tag.” No, I’m not going to turn off our WAF so you can test that hypothesis.

[Retr0id]

> No, I’m not going to turn off our WAF so you can test that hypothesis.

It would be worth your while to test it. You could run a dev/testing version of your app on a separate domain, without a WAF, and without any sensitive data held on it.

WAFs are a last resort to fix the bugs you didn't know about, and your application should still be safe without a WAF otherwise you're not actually getting the defense-in-depth you wanted. For an attacker that cares enough, WAF bypasses are a near inevitability.

[jerf]

It may be worthwhile to test, but the strength of "I see this field is correctly encoded but maybe hypothetically it could be your WAF protecting a vulnerable application. My sole supporting reason for this hypothesis is that if it is true, your bug bounty program will pay out for me" is, as vulnerability signals go, too uselessly weak to act on.

Bug bounty programs are nifty in that they give real researchers an effective outlet for the things they were quite possibly going to discover anyhow, but part of the price of that is you get a lot of submissions from people basically treating it as a system for spraying bug bounty programs with lottery tickets with low effort.

[resonious]

I'm kind of curious: do these bug bounty "spray and pray" tactics actually make money? I can't help but wonder if people are doing it because it works, or if it just looks like it should work and people are desperate.

[bombcar]

It’s incredibly low effort and for the people doing it even one hit in ten thousand could be multiple years’ wages.

[kstrauser]

Exactly. It's basically spam: there's nearly no cost to send it, so even an abysmal success rate is likely to return a fat profit.

I've heard that the average reward is about $500. You can afford a lot of rejections per success at that rate.

Never mind that you're destroying the effectiveness of those programs, driving staff nuts, and generally making the world less secure; that's their problem, right? (Sarcasm, obv.)

[kstrauser]

Nailed it. “Rationale: please pay me” is all too common.

[kstrauser]

Please give me the benefit of the doubt and assume that we actually do test things. As I assume you’re good at what you do, so am I. The WAF thing was an example of the sort of report we commonly get: “if you turn off all the mitigations, it may be possible to attack you!” Yes, but we use defense in depth so that the mitigations help cover any gaps we might’ve missed, and if the end result isn’t exploitable, it isn’t exploitable.

Just like in the original report here: “if you turn off those checks, it could be vulnerable!” “Yes, but we’re not about to do that because we’re not insane.”

[Retr0id]

I disagree that the WAF situation is comparable.

The curl report (incorrectly) describes missing bounds checks leading to buffer overflows.

If the curl project said "buffer overflows are ok because our code gets compiled with ASLR and NX", then that would be comparable to saying SQLi and XSS are non-issues due to a WAF. Fortunately, that's not what they said.

[kstrauser]

It was an example, an analogy, an illustration. We’re not dependent on our WAF any more than curl is dependent on ASLR and NX. We (and curl) use those things in addition to good coding practices so they all work together to create as secure of a product as our respective teams can manage.