I was looking through some feeds last week and saw a "Blind SSRF" vulnerability, and it got me thinking about a few vulnerability naming conventions that jostle my fur.
It spawned a tweet series that looked like this:
Thought: Does "blind" (in reference to vulnerabilities) actually mean the combination of out of band+ delayed? #infosec >
1/n
For SQLi, "blind", is in-band but not "visible", so the name makes sense.
But other kinds are out of band, e.g., making DNS requests.
2/n
But for XSS, "blind" means both persistent and out of band, where you create a long-term listener to see what comes back over time.
3/n
I wish there were a cleaner use of "blind" across these vulns and contexts. Maybe a clear distinction between blind and out of band.
4/4
And then I followed that up with:
While I’m on the topic, isn’t "Blind SSRF" redundant?
The core concept of SSRF is that it’s a secondary and proxied request, i.e., blind.
My buddy Jason Haddix > was one of the only people to reply, which didn’t surprise me.
@DanielMiessler > to me blind SQL injection makes sense. we should call blind xss, out of band. SSRF should just be implied.
So he and I are in agreement, as expected.
So just to clarify and summarize for myself, and outside of Twitter:
Blind to me means that either the request or the response are abstracted from you in some way that makes it non-trivial to create or interpret.
Out-of-band to me means that the response fails to return to you in a clear and obvious way, within the same interface that the attack was sent.
This means (like we’re saying above) Error-based SQL Injection would be "normal", or in-band. XSS would always be out-of-band, and SSRF would always be blind.
I hope others care about such things. I think arbitrary application of specific, but incorrect, naming causes a lot of confusion in the industry. This is true with testing types >, vulnerabilities, and many other things.
Don’t just assign names to things because you think they sound cool. And call it out when you see others doing it.