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

Post by nicolas_t » Mon, Jan 22, 2024, 4:01 AM UTC

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.

Post by Aeolun » Mon, Jan 22, 2024, 4:56 AM UTC

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.

Post by Too » Mon, Jan 22, 2024, 7:19 AM UTC

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.

Post by singingfish » Mon, Jan 22, 2024, 7:48 AM UTC

nicolas_t wrote: post #222

cqqxo4zV46cp wrote: post #185

Earlier quoted context omitted.

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.

I remember back in that time that a lot of apps had convoluted code to do this https only at login dance. All in the name of performance (because https was slower despite it being a premature optimization really). Switching to https only actually mostly helped simplify codebases...

Post by vldr » Mon, Jan 22, 2024, 8:37 AM UTC