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

191–200 of 254 posts

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

#191

Post by roughly »

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.

Yes! Firesheep was the extension, and I think the combination of that and LetsEncrypt (which was in part a reaction to Firesheep) were the reason the web went from almost entirely decrypted by default to almost entirely encrypted by default in a matter of months. The capabilities had been there for years, but Firesheep made session hijacking a literal one-click affair and vividly highlighted the danger of unencrypted web traffic - it’s maybe the most impactful bit of white-hat hackery of all time.

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

#192

Post by d0gsg0w00f »

SoftTalker wrote: post #131
Falmarri wrote: post #120

Earlier quoted context omitted.

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

There is/was a school of thought that each user should have their own database account, and the application should connect to the database as that user. The advantage being you can use the database's built-in user and role management and privileges instead of having to invent your own. I have admittedly not seen this done much, but there is a certain appeal to it.

I work for a company that is trying to bolt this functionality onto all the AWS database products. At least at the IAM role level.

As it stands now, no human can write to a DB in prod-- only service accounts.

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

#193

Post by paledot »

crazygringo wrote: post #184
counterpartyrsk wrote: post #176

Earlier quoted context omitted.

Interesting, can you explain 'full control'?

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...

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

#194

Post by elevatedastalt »

turminal wrote: post #12

The funniest part of this is that they don't even check for all of the banned strings. Source: I'm a student there and tried it out of curiosity.

It's easy to ensure compliance when the risk of non-compliance is getting expelled.

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

#195

Post by jesprenj »

0x00_NULL wrote: post #187
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.

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.

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

#196

Post by jstarfish »

jchw wrote: post #129
civilized wrote: post #118

Earlier quoted context omitted.

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.

Correct, we should be legally enforcing that they do the right thing, with legislation that has actual fangs, for companies like Equifax. It should be a potential bankruptcy event when you leak most of America's social security numbers through sheer incompetence. The problem is that WAF-style security-theater is being enshrined as the industry standard instead, which means that we're just going to get more of these p…

> legislation that has actual fangs, for companies like Equifax. It should be a potential bankruptcy event when you leak most of America's social security numbers

Immutable identifiers should never have this much weight. When your encryption key is compromised, you roll it. When your SSN is leaked, you're doing damage control for the rest of your life. This problem did not begin with Equifax.

It's a 7-digit number that encoded most people's birth region in it until two decades ago and gets asked for by all sorts of randos having anything to do with finance. The problem here is that something so readily shared and easily compromised and impossible to change has this much weight in our identification protocols.

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

#197

Post by bruce511 »

jstarfish wrote: post #196
jchw wrote: post #129

Earlier quoted context omitted.

Correct, we should be legally enforcing that they do the right thing, with legislation that has actual fangs, for companies like Equifax. It should be a potential bankruptcy event when you leak most of America's social security numbers through sheer incompetence. The problem is that WAF-style security-theater is being enshrined as the industry standard instead, which means that we're just going to get more of these p…

> legislation that has actual fangs, for companies like Equifax. It should be a potential bankruptcy event when you leak most of America's social security numbers Immutable identifiers should never have this much weight. When your encryption key is compromised, you roll it. When your SSN is leaked, you're doing damage control for the rest of your life. This problem did not begin with Equifax. It's a 7-digit number th…

You are not wrong, but I'd argue that mutable ID methods would be worse.

Ok, context and perspective will matter a lot here. If you are wanting to hide from authority then mutable id sounds good. If you are wanting to "know the history" of a person then mutable is bad.

In our social contract the "inability" to change id is baked into the way be behave, and the consequences for bad behavior.

Equally there are lots of good reasons to be able to get a quick history of say a prospective employee, loan recipient, tennant, supplier, customer, and so on.

If I can apply for a new Social Security number every month/year then that number does become useless as a form of id.

But it would then just need to be replaced with something else. Too much of what we do is predicated on our historical behavior. Having a 12-month limit on identity would break, well, just about any kind of contract.

And in most contract situations uou most definitely want to know "who" you are contracting with.

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

#198

Post by iforgotpassword »

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.

"malicious" requests in this case. I actually dealt with a contact form of a health insurance company that had something like this going on, but there wasn't any error page showing up, you just got a blank page after submit if something resembled SQL. In my case it was the words "select" and "from" too close to each other in a sentence.

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

#199

Post by coolThingsFirst »

jcul wrote: post #182
coolThingsFirst wrote: post #177

Earlier quoted context omitted.

Eli5 this attack pla

I've no idea what nettby is. But ARP is how computers figure out what IP address is associated with a hardware / ethernet address, so they know what ethernet address to use for sending packets to a specific IP. ARP poisoning means you flood the network with fake ARP packets saying your ethernet address has the gateway IP or whatever IP. So then the other devices will forward packets to your machine instead of the int…

Yes but isnt this possible only on LANs?

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

#200

Post by mtlmtlmtlmtl »

coolThingsFirst wrote: post #199
jcul wrote: post #182

Earlier quoted context omitted.

I've no idea what nettby is. But ARP is how computers figure out what IP address is associated with a hardware / ethernet address, so they know what ethernet address to use for sending packets to a specific IP. ARP poisoning means you flood the network with fake ARP packets saying your ethernet address has the gateway IP or whatever IP. So then the other devices will forward packets to your machine instead of the int…

Yes but isnt this possible only on LANs?

Correct. I did this at school. It was early days of students being allowed laptops in class.

We weren't actually allowed internet, but the school had an extremely basic wifi network that was WEP encrypted... So naturally I broke out Aircrack-ng and ameliorated that situation. And suddenly everyone was procrastinating on nettby in class.

Post reply on HN