Hacker News Reader

Comment by matejn | Hacker News Reader

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.

View on HN

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.

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!

If you work as a developer and can’t do your job because of a dumb pattern matching WAF out of your control, you should find yourself a new job or set up a parallel IT infrastructure.

The infamous Scunthorpe problem.

https://en.wikipedia.org/wiki/Scunthorpe_problem

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.

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.

Bingo... I hate WAF with a passion, wasted so many hours debugging weird issues when it turned out that they were blocked by some kind of black box WAF the client put in front of their systems.

Thanks,

I just implemented the subset of what we actually needed from a WAF with haproxy, and I'm delighted to say our stuff is extremely effective (as we got a nice flood attack the day after go live), and that it's 10% of the cost, and presumably 10% of the maintenance of the proprietary solution we evaluated.

Oh, yeah. My Infra As Code state was also blocked by the WAF because it looked too much like SQL injection apparently.

Someone said you couldn't put ../../../../etc/passwd here in hackernews due to cloudflare waf. Let's see...

Interesting that such situations occur even in academic circles. Especially on the scale of a whole university.

Oh, since it's University of Ljubljana, lepi pozdravi z Maribora! ^^

I guess one could also do "DROP TABLE *", should they want to experience what it means when Google removed "Don't be evil" from the preface of their Code of Conduct.

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.

I think I've run into this issue multiple times but in the context of web-based login vs. logging in from an app. The problem went away when I used a shorter password.

I love that you actually posted here.

That’s hilarious. And why I love HN.

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.

Reply on news.ycombinator.com