Re:Password may not contain: select, insert, update, delete,...
by skottk on Sunday January 21, 2024 @09:06AM
(#39078511)
Parameterized SQL is your friend here.
Re:Password may not contain: select, insert, update, delete,...
by mysterydip on Sunday January 21, 2024 @09:11AM
(#39078553)
Yeah, that's what's mapped in my head to "sanitizing input" in these cases, as it's the correct way to handle them. I should've unrolled my brain shortcut for the discussion.
Re:Password may not contain: select, insert, update, delete,...
by dylan604 on Sunday January 21, 2024 @09:30AM
(#39078732)
Before Parameterized SQL was a thing, sanitizing was the thing. There’s a lot of escape_string() type of methods out there.
Re:Password may not contain: select, insert, update, delete,...
by reeeeaway on Sunday January 21, 2024 @09:57AM
(#39078985)
Looking at the postgres JDBC source, it sanitizes parameters when prepared statements and parameterization is used. Different implementations may do different things here though
Re:Password may not contain: select, insert, update, delete,...
by tester756 on Sunday January 21, 2024 @10:14AM
(#39079161)
Could you describe it conceptually how they do it?
Re:Password may not contain: select, insert, update, delete,...
by reeeeaway on Sunday January 21, 2024 @11:04AM
(#39079652)
The method doAppendEscapeLiteral (Line 66) is a good example; https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main...
I didn’t take notes all the way down, but at the end of the day this method is invoked when a prepared statements’ parameters are being bound
Re:Password may not contain: select, insert, update, delete,...
by hobs on Sunday January 21, 2024 @09:15AM
(#39078590)
You don't even have to do that, just escape single quotes and you've defeated everything but homomorphic attacks as far as I can tell.
Re:Password may not contain: select, insert, update, delete,...
by tester756 on Sunday January 21, 2024 @09:17AM
(#39078609)
Why use unreliable solutions that rely on various assumptions that may change in the future and rely on you not forgetting about even 1 case where it wouldnt work
When you can use approach which fundamentally prevents SQL injection?
Re:Password may not contain: select, insert, update, delete,...
by hobs on Sunday January 21, 2024 @01:20PM
(#39081067)
I didn't say you should, I am just noting that there's no complexity in the solution required, it's simple and yet still many people don't do it.
Re:Password may not contain: select, insert, update, delete,...
by dylan604 on Sunday January 21, 2024 @09:32AM
(#39078756)
That’s a comment that makes me think someone read a blog 15 years ago, and never kept up with modern ways of doing things.
Re:Password may not contain: select, insert, update, delete,...
by hobs on Sunday January 21, 2024 @01:19PM
(#39081056)
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.
Re:Password may not contain: select, insert, update, delete,...
by dylan604 on Sunday January 21, 2024 @01:47PM
(#39081477)
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.
Re:Password may not contain: select, insert, update, delete,...
by hobs on Monday January 22, 2024 @09:12AM
(#39089701)
I didn't say I don't use parameterization, and I still haven't heard what the difference is between the old style escape methods and the quotes I mentioned, just you being salty :)
"Blacklist sanitizing cleans the input by removing unwelcomed characters such as line breaks, extra white spaces, tabs, &, and tags."
But still this is not a way, input sanitization is bullshit.
Using query parameters, thus inserting raw input into already built abstract syntax tree of SQL query
is the correct solution since SQL injection is about affecting tree composition