Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password may not contain: select, insert, update, delete, drop

id.uni-lj.si

Post reply on HN
Print view View original

111–120 of 254 posts

Re: Password may not contain: select, insert, update, delete, drop

#111

Post by amluto »

Off the top of my head, they forgot MERGE INTO, which is supported by several major databases. Also ALTER, GRANT, SET, and probably many others.

This particular variant of defense in depth is also rather missing the point: this field is a password. The question isn’t “did everyone remember to properly escape the password or properly use parameter binding” — the question is “did everyone remember not to store the plaintext password?” By the time someone does:

    Execute(“UPDATE xyz SET abc = ?”, password)
Or however your database API spells it, you have already messed up massively.

Re: Password may not contain: select, insert, update, delete, drop

#112

Post by [deleted] »

oliwarner wrote: post #107
civilized wrote: post #98

Earlier quoted context omitted.

What you're recommending is the status quo. The status quo has led to me receiving regular letters informing of massive security breaches where all my PII is disclosed and I have no recourse of any kind, other than possibly spending my life fighting a giant company in a class action lawsuit when I have no time or skill set to do so.

What I'm recommending is just part of the bare minimum security requirement for an authentication system. SQL parameterisation, transport encryption, input validation (and more) are all as important. Stopping SQL keywords is a distraction dressed up like security. It's harmful.

[deleted]

Re: Password may not contain: select, insert, update, delete, drop

#113

Post by klyrs »

junon wrote: post #29
mikkom wrote: post #26

Earlier quoted context omitted.

And top of that, password should NEVER be stored to database

Well, not in plaintext.

That's why you hash the password with an SQL built-in hash function. For security! But the password is still in plaintext inside the query so you can retrieve it from the logs for... security?

(I joke, but 20 years younger me, self-teaching php and security etc? Who knows what she'd think of this)

Re: Password may not contain: select, insert, update, delete, drop

#114

Post by civilized »

oliwarner wrote: post #107
civilized wrote: post #98

Earlier quoted context omitted.

What you're recommending is the status quo. The status quo has led to me receiving regular letters informing of massive security breaches where all my PII is disclosed and I have no recourse of any kind, other than possibly spending my life fighting a giant company in a class action lawsuit when I have no time or skill set to do so.

What I'm recommending is just part of the bare minimum security requirement for an authentication system. SQL parameterisation, transport encryption, input validation (and more) are all as important. Stopping SQL keywords is a distraction dressed up like security. It's harmful.

> Stopping SQL keywords is a distraction dressed up like security. It's harmful.

We are talking about how to mitigate harm from people who are already doing the wrong thing. Saying that this distracts from doing the right thing misses the point. They are already doing the wrong thing. You saying they should not do the wrong thing does not stop them from doing the wrong thing. Once again, your proposal is the failing status quo.

Re: Password may not contain: select, insert, update, delete, drop

#115

Post by alanfranz »

matsemann wrote: post #56

Can not contain "script". I hacked a big social platform in my early teens (Nettby.no), since they just did a removal of all banned words, including . I instead wrote ipt> in my profile bio, and after their removal I had a valid html tag injected into the webpage and full control of anyone visiting my page..

oldest injection trick ever :-)

Re: Password may not contain: select, insert, update, delete, drop

#116

Post by hobs »

dylan604 wrote: post #57
hobs wrote: post #17

Earlier quoted context omitted.

You don't even have to do that, just escape single quotes and you've defeated everything but homomorphic attacks as far as I can tell.

That’s a comment that makes me think someone read a blog 15 years ago, and never kept up with modern ways of doing things.

Cool - but neither of your comments addressed that I am still correct afaict, if you care about query plans and such parameterization is important, but not getting injected on is a different problem.

Re: Password may not contain: select, insert, update, delete, drop

#117

Post by hobs »

tester756 wrote: post #25
hobs wrote: post #17

Earlier quoted context omitted.

You don't even have to do that, just escape single quotes and you've defeated everything but homomorphic attacks as far as I can tell.

Why use unreliable solutions that rely on various assumptions that may change in the future and rely on you not forgetting about even 1 case where it wouldnt work When you can use approach which fundamentally prevents SQL injection?

I didn't say you should, I am just noting that there's no complexity in the solution required, it's simple and yet still many people don't do it.

Re: Password may not contain: select, insert, update, delete, drop

#118

Post by civilized »

jchw wrote: post #100
civilized wrote: post #35

I expect this will attract a lot of criticism, but I actually think it's a good idea, at least in some cases. There are a lot of people writing bad code and bad system architectures for their organizations. There are not enough people with the competence, organizational power, and time to catch what's bad and force change in those organizations. In the US you are probably forced to do business via many such terribly…

I disagree. It may seem good on paper, but it gives you too much of a false sense of security. Security measures like this often seem to work, but they are papering over a deeper problem. Usually this is being done because user input is not being handled carefully, and if so, the assumption that blocking some keywords "defangs" potential exploits is usually easy to prove false. Consider the case of eBay and JSFuck[1]…

A lot of critical responses here are saying "this distracts from getting people to do the right thing". I'm open to that, but what is the plan for forcing organizations that are doing the wrong thing to do the right thing? We're talking about businesses that mismanage the sensitive data of millions of people. "They should be doing things right" doesn't seem like an adequate response to this situation.

Re: Password may not contain: select, insert, update, delete, drop

#119

Post by dylan604 »

hobs wrote: post #116
dylan604 wrote: post #57

Earlier quoted context omitted.

That’s a comment that makes me think someone read a blog 15 years ago, and never kept up with modern ways of doing things.

Cool - but neither of your comments addressed that I am still correct afaict, if you care about query plans and such parameterization is important, but not getting injected on is a different problem.

look, if you still want to live like it's 1999, then sure, go ahead and wrap your params in quotes like you think you can. just don't come crying to the rest of us that have more than once provided you with better solutions when you get attacked. i mean, even using the old style escape methods would be better than your appending of quotes idea.

Re: Password may not contain: select, insert, update, delete, drop

#120

Post by Falmarri »

chasil wrote: post #10

Did someone have a Bobby Tables moment? https://bobby-tables.com/ In Oracle, you can't use a bind variable in setting a password on an account, so SQL injection is a more significant risk. I wrote some JavaScript and pl/sql to address that.

Do you mean setting a database user account? As in the oracle user? Why is that exposed over the web?
Post reply on HN