Javascript - It can be Disabled!
Every Web Dev needs to remember this and Yet people tend to forget
How not to protect against SQL injection (view source)
31–40 of 125 posts
Re: How not to protect against SQL injection (view source)
#32Earlier 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.
Yeah? What i your "extremely easy" mechanism for avoiding SQLI? Is it, as I surmise from your previous comment, "using prepared statements for everything"? Because that isn't bulletproof.
Re: How not to protect against SQL injection (view source)
#33Since 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.
Are they actually vulnerable? How do you know? People have gotten in serious trouble in the UK for "innocuously" testing web apps for SQL problems. Know that in both the UK and the US, you are taking a significant risk by prodding websites like this.
I have no idea if they are, hence "I hope their web login doesn't have drop permissions".
Re: How not to protect against SQL injection (view source)
#34Javascript - It can be Disabled! Every Web Dev needs to remember this and Yet people tend to forget
A better principle is that you can not trust the client. Not only can javascript be disabled, it can also be modified, a new web page can be created posting to this endpoint, or one can send raw HTTP requests without a browser at all.
Re: How not to protect against SQL injection (view source)
#35Javascript - It can be Disabled! Every Web Dev needs to remember this and Yet people tend to forget
They use javascript to submit the form, so that's not a vulnerability for them.
Re: How not to protect against SQL injection (view source)
#36Earlier quoted context omitted.
Are they actually vulnerable? How do you know? People have gotten in serious trouble in the UK for "innocuously" testing web apps for SQL problems. Know that in both the UK and the US, you are taking a significant risk by prodding websites like this.
I have no idea if they are, hence "I hope their web login doesn't have drop permissions".
Since people on Reddit are apparently actually poking this thing, I just want to get in the warning: DON'T DO THAT.
Re: How not to protect against SQL injection (view source)
#37Earlier quoted context omitted.
How about no.
If you vote no, you haven't looked hard enough.
If you use type-safe SQL parameters everywhere and no string concatenation you'll be fine.
http://taylorza.blogspot.com/2009/04/sql-injection-are-param...
Re: How not to protect against SQL injection (view source)
#38Earlier quoted context omitted.
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.
Yeah? What i your "extremely easy" mechanism for avoiding SQLI? Is it, as I surmise from your previous comment, "using prepared statements for everything"? Because that isn't bulletproof.
It's bulletproof if you don't use string concatenation in your prepared statements.
EDIT: No this doesn't limit you to 'simple queries'! How do you figure that? There are only a VERY small subset of problems you can't solve like this. So small that in 10 years I've only had to do it once and I write SQL Server 5 hours a day.
Want to give me an example please?
Re: How not to protect against SQL injection (view source)
#39Earlier quoted context omitted.
Yeah? What i your "extremely easy" mechanism for avoiding SQLI? Is it, as I surmise from your previous comment, "using prepared statements for everything"? Because that isn't bulletproof.
It's bulletproof if you don't use string concatenation in your prepared statements. EDIT: No this doesn't limit you to 'simple queries'! How do you figure that? There are only a VERY small subset of problems you can't solve like this. So small that in 10 years I've only had to do it once and I write SQL Server 5 hours a day. Want to give me an example please?
So, in other words, it's bulletproof if you only use simple queries.
In MySQL, for instance, LIMIT and OFFSET have to be integer constants; the wire protocol won't allow you to bind variables to them. Does your SQL engine allow you to parameterize a table name? Can you parameterize columns? What about ASC and DESC? And this is just simple stuff. What about pages with "Advanced Search" that have to implement query builders?
Re: How not to protect against SQL injection (view source)
#40Earlier quoted context omitted.
It would seem kind of stupid if they were smart enough to implement validation but not smart enough to limit user access to it. Of course there's no accounting for the depths of stupidity.
That would actually not surprise me at all. There are a lot of Web devs who can make a site that renders in the browser and mostly works, but can't wrap their minds around the difference between server-side code and client-side. Browse through the JavaScript tag on Stack Overflow and you'll come across more than you can shake a stick at. Many people (either due to willful ignorance or a sad gap in their education) wr…
There may actually be a good reason for writing code like that. The time the content was generated by the server, perhaps?