Preventing SQL Injections When WAF’s Not Enough
cossacklabs.com
Preventing SQL Injections When WAF’s Not Enough
1–10 of 14 posts
Re: Preventing SQL Injections When WAF’s Not Enough
#2Umh, this article is dubious.
1. If your WAF can be fooled by adding a X-Forwarded-For header, trouble ahead.
2. If your security strategy is about mitigating attacks where the payload matches some regular expressions, trouble ahead. Machine learning? Double trouble ahead.
3. If you don't write only completely static queries[1] to then use as prepared statements or use a proper ORM[2] when using a SQL database, trouble ahead.
[1] https://www.akadia.com/services/dyn_modify_where_clause.html
[2] Like linq, jOOQ...
Re: Preventing SQL Injections When WAF’s Not Enough
#3WAF's are never good enough. They're a weak band-aid used by companies who lack the expertise to find and fix security bugs in their own code.
Re: Preventing SQL Injections When WAF’s Not Enough
#4WAF's are never good enough. They're a weak band-aid used by companies who lack the expertise to find and fix security bugs in their own code.
This is the correct answer. Unfortunately PCI dictates that you can use WAFs instead of real coding standards and testing.
For anyone curious why WAFs are so useless, there is a very beginner-accessible talk by Joe McCray here: https://www.youtube.com/watch?v=qBVThFwdYTc
Re: Preventing SQL Injections When WAF’s Not Enough
#5WAF's are never good enough. They're a weak band-aid used by companies who lack the expertise to find and fix security bugs in their own code.
This is the correct answer. Unfortunately PCI dictates that you can use WAFs instead of real coding standards and testing. For anyone curious why WAFs are so useless, there is a very beginner-accessible talk by Joe McCray here: https://www.youtube.com/watch?v=qBVThFwdYTc
The company I work at has many PCI compliant systems. I asked a security officer why they were still doing certain things the old way. He explained they very well know it’s the old way but in order to be compliant they must do it.
Re: Preventing SQL Injections When WAF’s Not Enough
#6Earlier quoted context omitted.
This is the correct answer. Unfortunately PCI dictates that you can use WAFs instead of real coding standards and testing. For anyone curious why WAFs are so useless, there is a very beginner-accessible talk by Joe McCray here: https://www.youtube.com/watch?v=qBVThFwdYTc
The company I work at has many PCI compliant systems. I asked a security officer why they were still doing certain things the old way. He explained they very well know it’s the old way but in order to be compliant they must do it.
It's not about old vs new, it's about strong vs weak. WAF was too weak to be your primary line of defense against SQL injection when it was first popularized and it's still too weak now.
Re: Preventing SQL Injections When WAF’s Not Enough
#7This is an advertisement.
Re: Preventing SQL Injections When WAF’s Not Enough
#8Earlier quoted context omitted.
This is the correct answer. Unfortunately PCI dictates that you can use WAFs instead of real coding standards and testing. For anyone curious why WAFs are so useless, there is a very beginner-accessible talk by Joe McCray here: https://www.youtube.com/watch?v=qBVThFwdYTc
The company I work at has many PCI compliant systems. I asked a security officer why they were still doing certain things the old way. He explained they very well know it’s the old way but in order to be compliant they must do it.
I'm curious by what do you mean 'old way' for the very reason exposed above.
Would you mind to give some examples?
Re: Preventing SQL Injections When WAF’s Not Enough
#9Earlier quoted context omitted.
This is the correct answer. Unfortunately PCI dictates that you can use WAFs instead of real coding standards and testing. For anyone curious why WAFs are so useless, there is a very beginner-accessible talk by Joe McCray here: https://www.youtube.com/watch?v=qBVThFwdYTc
The company I work at has many PCI compliant systems. I asked a security officer why they were still doing certain things the old way. He explained they very well know it’s the old way but in order to be compliant they must do it.
Where I work Compliance and Security are completely different departments. This is great because the Security department does whatever they think is best for security, regardless of compliance requirements.
The Compliance department has one job: passing audits. They never tell Security what to do; they document "compensating controls" and if that's not good enough for an Auditor the Compliance department will run whatever worthless compliance control themselves.
I'm not saying security compliance itself is a joke. It forces small businesses to at least try to get their shit together. But for big tech companies with real security programs, security compliance is a worthless tax.
Re: Preventing SQL Injections When WAF’s Not Enough
#10Umh, this article is dubious. 1. If your WAF can be fooled by adding a X-Forwarded-For header, trouble ahead. 2. If your security strategy is about mitigating attacks where the payload matches some regular expressions, trouble ahead. Machine learning? Double trouble ahead. 3. If you don't write only completely static queries[1] to then use as prepared statements or use a proper ORM[2] when using a SQL database, troub…
If your security strategy relies on one or two security controls, you're doomed most of the time.
We've added SQL filtering as a defense-in-depth measure, having a convenient seat in the architecture, complementing every other mitigation measure proper application developers and DBAs should be doing (and frequently get wrong).
Even ORMs get bypassed once in a while:
- https://github.com/mysqljs/mysql/issues/342 - https://github.com/sequelize/sequelize/issues/5671 - (okay, we can avoid this one by saying nothing "nothing proper exists in NodeJS world) https://bertwagner.com/2018/03/06/2-5-ways-your-orm-will-all...
Dumb concatenation can nullify the merit of quite advanced ORM: copybook example of misusing Ruby's ActiveRecord (is that proper enough) got as far as OWASP testing guide: https://www.owasp.org/index.php/Testing_for_ORM_Injection_(O...
Prepared statements are cooked wrong as well, but rarely, that's why they are viable line of defense, but not the sole one (as nothing should be):
https://www.reddit.com/r/netsec/comments/ww9qm/sqli_bypassin... https://stackoverflow.com/questions/134099/are-pdo-prepared-...
(in fact, I've seen with my eyes exactly what first comment in reddit postmentions).