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

211–220 of 254 posts

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

#211

Post by deathanatos »

cbsmith wrote: post #150
oliwarner wrote: post #71

Earlier quoted context omitted.

Your password should not go anywhere near a database. It should be salted and hashed a few hundred thousand times and that compared to the salted, hashed version stored on file. If you can't even manage that, you have no business writing software that can store credentials. And I mean that. Software security starts with acknowledging that data is toxic and will bankrupt you if you refuse to respect it.

>Your password should not go anywhere near a database. > > It should be salted and hashed a few hundred thousand times and that compared to the salted, hashed version stored on file. > > If you can't even manage that, you have no business writing software that can store credentials That's misunderstanding the nature of the vulnerability. It's not about where the password is stored, but where it is entered. Before it…

> That's misunderstanding the nature of the vulnerability.

No, they're 100% correct. If the password is properly stored, there's no possibility of injection, because what gets sent to the database is something like a hex string, or just a bytestring, depending on reprsentation.

> It's not about where the password is stored, but where it is entered. Before it can be salted & hashed, there's software that has to decide where the password input starts and ends. If it gets that wrong, that's how you get the vulnerability.

???

Where it is entered looks like this:
… the actual text of the password makes no appearances, ever.

Whatever code you're using to generate HTML/DOM nodes, or SQL queries, should be parameterized and automatically escaping all inputs. If it isn't, that's the security issue, and trying to kludge around it with idiotic restrictions won't work. (Other commenters have already alluded to the problems with the OP's attempt.)

But even then, a password should never hit either of those interfaces: there's no reason to render it into the DOM, or into SQL.

(There are some other comments about this might be to help users work around failures in a WAF. That could be, but it's orthogonal.)

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

#212

Post by aidenn0 »

matejn wrote: post #85

Oooh! I put that string there! It was a request by management, and I still don't know why. This site doesn't store any passwords, it's basically just a nice interface to external account management. I heard a rumour that some legacy apps have weird validation on their login fields, so students wouldn't be able to log in with passwords containing certain strings. But I don't actually know of any examples.

I had an issue with one site where the maximum length on the "create new password" field was longer than the "maxlength" property on the input field for the login form. I couldn't figure out why I could use my password manager's autofill to login (since it ignored the maxlength), but couldn't type or paste my password in.

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

#214

Post by aidenn0 »

alanfranz wrote: post #115
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 :-)

I actually think it's the second oldest, since the first would be just injecting the string itself.

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

#215

Post by jasonjayr »

selcuka wrote: post #205
nijave wrote: post #201

Earlier quoted context omitted.

Surely if you've resorted to blocking random SQL keywords you've already lost. SQL has a pretty big dialect not to mention arbitrary functions and procedures that might exist. For instance, TRUNCATE isn't even in the list

In real world, as a developer you can't control what IT uses for WAF, so you may have to work around it as much as you can. At a previous job the IT set up a spam filter which used a keyword list (dumb attempt anyway), but it also searched the email headers (not only the body). As a result, we weren't able to receive email if one of the SMTP hops was named, say, smtp.essex.company.com.

Ah, a clbuttic mistake!

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

#216

Post by aidenn0 »

d-z-m wrote: post #73
wongarsu wrote: post #63

Earlier quoted context omitted.

There are various schemes where the password is salted, hashed or prehashed on the client side, to various effectiveness. They have never been really popular and the advent of ubiquitous https probably made them even less common, but they do exist. They do help protect you from your own WAF though.

can you elaborate on this? Or link something that does? My intuition is that whatever gets sent over the wire is effectively the password. Not sure how the server could validate some rolling hash of the password (based on like a timestamp or something) without having to store the pre-image(i.e. the raw password).

If your password is 123456, then client-side hashing will make this less obvious. If the site is compromised in a way that reveals passwords, then it will not trivially work on other sites that use your password. In addition, stronger total hashing can be used, since if your server can do M hashes persecond and your client can do N hashes per second, the total number of hashes to allow a one second login are (M/$NUMBER_OF_CONCURRENT_LOGINS)+N which is strictly larger than (M/$NUMBER_OF_CONCURRENT_LOGINS).

SRP[1] is an even better improvement, where an eavesdropper cannot authenticate as you; there is a challenge-response to login.

1: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

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

#217

Post by matheusmoreira »

ht85 wrote: post #190
i_k_k wrote: post #123

Earlier quoted context omitted.

Well, duh: they needed to make sure to run the script twice.

Make it 3 times, you never know how clever those hackers folks could be!

Make it infinite times and stop after the output stabilizes to a constant string!

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

#218

Post by crumpled »

matejn wrote: post #85

Oooh! I put that string there! It was a request by management, and I still don't know why. This site doesn't store any passwords, it's basically just a nice interface to external account management. I heard a rumour that some legacy apps have weird validation on their login fields, so students wouldn't be able to log in with passwords containing certain strings. But I don't actually know of any examples.

It's just a string on a page? Or does validation actually prevent you?

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

#219

Post by crumpled »

crumpled wrote: post #218
matejn wrote: post #85

Oooh! I put that string there! It was a request by management, and I still don't know why. This site doesn't store any passwords, it's basically just a nice interface to external account management. I heard a rumour that some legacy apps have weird validation on their login fields, so students wouldn't be able to log in with passwords containing certain strings. But I don't actually know of any examples.

It's just a string on a page? Or does validation actually prevent you?

I think I figured it out. There is no validation. This is just a contact form and someone sees the plaintext password.

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

#220

Post by threeseed »

nijave wrote: post #201
jesprenj wrote: post #195

Earlier quoted context omitted.

AFAIUC, the reason for the word blacklist here lies in the fact that some applications have WAFs or similar software that detect malicious requests and since passwords are sent in plaintext to the WAF, they are detected as malicious exploitation attempts, if they imitate SQL injections, although your parent comment did not give any concrete examples.

Surely if you've resorted to blocking random SQL keywords you've already lost. SQL has a pretty big dialect not to mention arbitrary functions and procedures that might exist. For instance, TRUNCATE isn't even in the list

WAFs assume that they are protecting the worst type of systems.

And so they will block requests containing DROP etc even if the systems they are fronting are perfect.

Post reply on HN