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

201–210 of 254 posts

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

#201

Post by nijave »

jesprenj wrote: post #195
0x00_NULL wrote: post #187

Earlier quoted context omitted.

On the contrary, make all of your passwords “DROP TABLE users;”. You’ll quickly sort out which passwords are being handled so insecurely by your vendors. This would mean they both don’t sanitize user input and don’t hash or otherwise obscure your password. They are a menace to society.

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

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

#202

Post by jamesfinlayson »

jesprenj wrote: post #195
0x00_NULL wrote: post #187

Earlier quoted context omitted.

On the contrary, make all of your passwords “DROP TABLE users;”. You’ll quickly sort out which passwords are being handled so insecurely by your vendors. This would mean they both don’t sanitize user input and don’t hash or otherwise obscure your password. They are a menace to society.

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.

Ah makes sense - someone in a business unit was having a weird failure updating something last week and I couldn't see any failures in the application logs. I looked on their computer and could say that Akamai was blocking the request, and after some trial and error I found that it was because a text field contained (* - which it thought looked like SQL.

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

#203

Post by nijave »

cqqxo4zV46cp wrote: post #185
coolThingsFirst wrote: post #177

Earlier quoted context omitted.

Eli5 this attack pla

It should also be said that HTTPS was seldom used outside of especially sensitive applications until ~2010 when someone packaged a HTTP MITM attack up into a handy Firefox extension. I think that Facebook used HTTPS for the actual login credential exchange, snd then bounced back to HTTP, which meant that the session cookie/s were still MITMable. It’s insane how long it took to see widespread HTTPS adoption.

Iirc Google said they'd start penalizing non https sites in search results and browser makers added much more aggressive warnings to http pages.

It caused quite a commotion among small site operators.

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

#204

Post by redeeman »

civilized wrote: post #118
jchw wrote: post #100

Earlier quoted context omitted.

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.

> I'm open to that, but what is the plan for forcing organizations that are doing the wrong thing to do the right thing?

i'd say figure out how bad what they did is. Not hashing and building sql strings like that: go to jail for a long time.

Gross carelessness with private data: go to jail for a very long time.

About the same time as if you purposely published the data, or purposely dropped a table, because thats about what you did. If you dont have the competence, you have no business writing such a system. If you dont know how to calculate a bridge that wont collapse, or dont know how to follow the plans and build it properly, you have no business being there.

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

#205

Post by selcuka »

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

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.

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

#206

Post by jknoepfler »

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…

An unhashed, unsalted password should literally never touch a database.

Which is to say this kind of sanitization on passwords is meaningless if the barest of security standards are in place.

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

#207

Post by paulmd »

petee wrote: post #91
ipython wrote: post #61

Earlier quoted context omitted.

But why would you ever send a plaintext password into a sql query?

Since being clever is often a footgun, I'll admit to one idea I had years ago; I never really gave it the smell test, and it only existed for a personal project. But if one person thought of it, others may have as well. I was learning to write sqlite C functions for fun, and thought since storing plain passwords has been such an issue, why not offload the responsibility from the programmer and let the db handle it fu…

one general problem with this (and also audit logging) is making sure that such changes can't be rolled back. I think the consensus the last time I looked at it was to do it in a separate connection or batched at the end of the main transaction. but audit logging is just such a tremendous pain in general and everyone's got their own specific requirements.

I think in general you would not want to do this in the database anyway (definitely not unless it's sharded and not really even then). You are taking that hashing load off your application servers and moving it inside the DB after all. When your DB is out of CPU, it's out, they're tough to scale. And in SQLite you are holding the DB write lock for longer, which serializes every other thread that needs to write. That's also true of holding connections/resources in traditional DBs. It's notionally fine for toy problems and you can probably do "clever" shit like sharding uuids across multiple files by hash to scale a bit further. But increasingly, even as someone who likes the idea of a "richer" interface to RDBMS, and doesn't mind writing SQL functions/triggers/views where it makes sense, I think the database really just not is the place for unnecessary gizmos on performance grounds either. Don't put hashing in your DB.

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

#208

Post by sillysaurusx »

paledot wrote: post #193
crazygringo wrote: post #184

Earlier quoted context omitted.

You can run any JavaScript. So you can show a popup saying the user needs to log in again, and then log their credentials on your own server instead.

Or exfiltrate their session cookie, or post spam/phishing links on their behalf...

Session cookies are generally not available to javascript. The latter is true though.

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

#209

Post by None4U »

sillysaurusx wrote: post #208
paledot wrote: post #193

Earlier quoted context omitted.

Or exfiltrate their session cookie, or post spam/phishing links on their behalf...

Session cookies are generally not available to javascript. The latter is true though.

Perhaps HttpOnly wasn't as prevalent back then?

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

#210

Post by 8note »

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…

> but where it is entered.

Hmm. This strongly reminds me of gpt promt injection. I guess why they're both called injection attacks

Post reply on HN