Innovative way to combat SQL injection | Hacker News Reader

Innovative way to combat SQL injection

homebank.sactocu.org

98 pointsyread16 comments

In case you have any confusion about this, please note that the term "Innovative" is used here to mean "likely to cause Hacker News readers to spew soda out their noses".

Hah, right, I came expecting some really innovative new way of handling SQL injection attacks.

Ooops - looks like somebody forgot to put "TRUNCATE" in the list!

Indeed! And "alter table", "create view", etc... I'm glad I didn't joint that credit union when I considered it a few years ago.

It is possible that they server is not given access to these functions, so they didn't need to be checked for, in the input.

This presents its own problems, if for some reason in the future they need to add one of these missing functions to the servers access, and don't recognise that they need to add the check as well.

But anyway, it is great to see the boss' nephew getting some work.

Come on. Typing "truncate" in a text field doesn't do anything to the database. Neither does "insert" or "update".

What it does is generate stupid alarms and break pageflows when you have an improperly configured web filter.

They aren't using instructions to users to block SQL Injection. They're using a web application firewall to block SQL Injection, and they have it configured to take a shotgun approach to filtering form fields.

You could do the same thing with any application, secure or not, by applying a naive mod_security configuration to your Apache server.

That's not a great practice, but it doesn't tell you anything about how susceptible they are to SQLI.

It does give some idea how susceptible they are to random web request rejections when people drop common words into their communications though.

It may not be a direct indicator of their vulnerability to SQL injection, but it is a pretty good indicator of their placement on the clulessness scale.

clueless<-------------------->cluefull

        ^
        |

Right about here I'd say.

Actually this is common old fashioned industry standard:

http://thedailywtf.com/Articles/Injection_Rejection.aspx

We where laughing our asses of. My name and the name of the other in-house guy, both contain an 'and'. Just our boss, could login and had no problem. :)

Except, the bad code as shown requires whitespace (\s) before and after the "bad" terms, so the names the Daily WTF post mentions should pass through it.

  if (preg_match('/\s['.implode('|',$badSqlCode).']+\s/i', $sqlcode))

They probably didn't realize this wouldn't catch any of the bad terms at the very start or end of their code, though :-)

According to their annual report they have 272 million dollars worth of member deposits. With that security practice that is very scary.

I'm guessing that they aren't using "honor-system SQL Injection protection", but they are hard-blocking all of that in the UI layer, which is not a terrible thing to do, but not the most sophisticated and user-friendly approach.

After they got a handful of calls about it, they had to put it in their FAQ.

Sorry, I just killed the joke.

My bank recently dumped their .NET online banking system for what appears to be a homebrew job in "classic" ASP. I'm sure they had a good reason, but from the outside it certainly seems like an odd decision.

And here I am thinking it was odd that my bank has a non-EV SSL cert.

Oh, and the time when my bank's netbank SSL certificate expired, and it took them 3 days to get it fixed because it seemed noone knew what was going on... that was great! lol.

Reply on news.ycombinator.com