231–240 of 254 posts
Earlier quoted context omitted.
Session cookies are generally not available to javascript. The latter is true though.
Perhaps HttpOnly wasn't as prevalent back then?
My "hack" was mostly pretty harmless. Just did some layout changes to make my profile cooler. But the door was wide open for anything.
Earlier quoted context omitted.
I'm really trying to meet you halfway here but I can't imagine a scenario where I had such low confidence in a third party application that I'd wrap it in input-filtering cotton wool and feel like that was safe enough. A project that both stores plaintext passwords and fails to use parametrisation (something that's been standard practice for over two decades) is untrustable. It's an untenable liability. Maybe I'm wro…
It's not that I think it's acceptable. I'm thinking about how to reduce the harm of people doing unacceptable things that we can't stop them from doing. I would be very transparent about this. I would say this is harm reduction for people who are doing the wrong thing and is a waste of everyone else's time, but we have to do it anyway because software engineering has failed to govern itself as a profession and the go…
Imagining we're happy to sacrifice these words to the gods of security theatre, what layer are you suggesting this goes? Browser level just means hackers can make raw requests. HTTPDS could block it, like an overzealous WAF, but that still needs implementing. Service providers shouldn't be able to see this stuff because of transport layer security.
There's no sensible way to make this make sense.
I do agree that a lot of entities are not adequately prosecuted for their incompetent data handling but fixing that seems far more realistic than banning the word "drop", everywhere.
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.
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.
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.
Earlier quoted context omitted.
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!
Earlier quoted context omitted.
Cool - but neither of your comments addressed that I am still correct afaict, if you care about query plans and such parameterization is important, but not getting injected on is a different problem.
look, if you still want to live like it's 1999, then sure, go ahead and wrap your params in quotes like you think you can. just don't come crying to the rest of us that have more than once provided you with better solutions when you get attacked. i mean, even using the old style escape methods would be better than your appending of quotes idea.
Instead of making sure SQL injection is not possible at all by using proper stored procedures and other techniques, they just limit a few keywords and hope hackers don't come up with something that they haven't thought of like some escaping trick. Yeah that would probably work for a while. Until someone proves it doesn't :P It's not really rocket science anymore to make sure user input doesn't mix with your SQL. This…
> And really if this works in the first place you're storing the passwords unhashed Not really, your RDBMS probably supports some hash functions so you could be storing them hashed as "UPDATE USERS SET PASSWORD = SHA2($PASSWORD)" which would be vulnerable to SQL injection yet does not store unhashed passwords. There are good reasons I'd recommend to do the hashing in the application layer instead, but doing it in the…
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 That's misunderstanding the nature of the vulnerability. It's not about where the password is stored, but where it is entered. Before it…
It might be a method to avoid trigger an overenthusiastic WAF, but these are all SQL tokens and keywords. It seems far more likely that they've blocked them in a desperate effort to catch injection attacks. There might not be an actual attack vector, they might block these words in all inputs. It just smells like incompetence.
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…
I am receiving approximately one parcel per month informing me of a new data breach.
Earlier quoted context omitted.
> Stopping SQL keywords is a distraction dressed up like security. It's harmful. We are talking about how to mitigate harm from people who are already doing the wrong thing . Saying that this distracts from doing the right thing misses the point. They are already doing the wrong thing. You saying they should not do the wrong thing does not stop them from doing the wrong thing. Once again, your proposal is the failing…
I'm really trying to meet you halfway here but I can't imagine a scenario where I had such low confidence in a third party application that I'd wrap it in input-filtering cotton wool and feel like that was safe enough. A project that both stores plaintext passwords and fails to use parametrisation (something that's been standard practice for over two decades) is untrustable. It's an untenable liability. Maybe I'm wro…
Most software you use is untrustable. You get a binary and you pray the vendor isn't an idiot. Even if you watch all the SQL commands it does in normal operations, you can't be sure an attacker cannot send some operation you don't know about and do a regular SQL command.