Earlier quoted context omitted.
How about no.
If you vote no, you haven't looked hard enough.
How not to protect against SQL injection (view source)
21–30 of 125 posts
Re: How not to protect against SQL injection (view source)
#22Funny is that I tried to warn them about that problem and their Feedback form doesn't work.
Re: How not to protect against SQL injection (view source)
#23The saddest part is that tons of people will be reading this thinking that they're way smarter than that guy, while in fact their sites are wide open to exploitation as well. That last statement probably applies to me too. Doing web security well is hard, too hard. Everyone gets caught with a security bug sooner or later, even google. It's easy to laugh with silly coding like this, but I blame the technology for allo…
I don't think SQL is a bad API - it's just that every language makes it so difficult to use prepared statements! It shouldn't be harder than: sql_query('SELECT * FROM mytable WHERE name = ?', name) (I'm aware that this defeats the purpose of prepared statements to be reusable - this is just an API that's better than the current methods)
Huh? Most web frameworks use ORMs and discourage you from touching SQL at all.
Re: How not to protect against SQL injection (view source)
#24Earlier quoted context omitted.
How about no.
If you vote no, you haven't looked hard enough.
I just dislike the whole "upvote for x" comment that dredges up from Reddit.
'Just lowers the signal-to-noise ratio, and I hate to see things like that creep up on HN.
Re: How not to protect against SQL injection (view source)
#25The saddest part is that tons of people will be reading this thinking that they're way smarter than that guy, while in fact their sites are wide open to exploitation as well. That last statement probably applies to me too. Doing web security well is hard, too hard. Everyone gets caught with a security bug sooner or later, even google. It's easy to laugh with silly coding like this, but I blame the technology for allo…
I don't think SQL is a bad API - it's just that every language makes it so difficult to use prepared statements! It shouldn't be harder than: sql_query('SELECT * FROM mytable WHERE name = ?', name) (I'm aware that this defeats the purpose of prepared statements to be reusable - this is just an API that's better than the current methods)
A password must:
be 6-8 characters in length.
contain a non-alphanumeric character such as ( ! ] & * , + =
A password cannot:... include a dollar sign ( $ ), a single quote ( ‘ ), a double quote ( “ ), a number sign ( # ), a less-than sign ( < ), a question mark ( ? ), a pipe ( | ), a back quote ( ` ), or a backslash ( \ ). ...
Re: How not to protect against SQL injection (view source)
#26I don't know why but I just don't trust them...
Re: How not to protect against SQL injection (view source)
#27Earlier quoted context omitted.
If you vote no, you haven't looked hard enough.
No, really - I'm certain there aren't any in my code. SQL injections are extremely easy to protect against if you know how it works. There might however be other vulnerabilities.
Re: How not to protect against SQL injection (view source)
#28Re: How not to protect against SQL injection (view source)
#29The saddest part is that tons of people will be reading this thinking that they're way smarter than that guy, while in fact their sites are wide open to exploitation as well. That last statement probably applies to me too. Doing web security well is hard, too hard. Everyone gets caught with a security bug sooner or later, even google. It's easy to laugh with silly coding like this, but I blame the technology for allo…
I don't think SQL is a bad API - it's just that every language makes it so difficult to use prepared statements! It shouldn't be harder than: sql_query('SELECT * FROM mytable WHERE name = ?', name) (I'm aware that this defeats the purpose of prepared statements to be reusable - this is just an API that's better than the current methods)
† Which are not a cure-all for SQLI.
Re: How not to protect against SQL injection (view source)
#30Since they're using SQL Server (hint is that they are checking for "xp_"), you can get a list of all of their databases with "SELECT name FROM sys.databases", then loop through and drop them. Hope the web login doesn't have drop permissions.