41–50 of 125 posts
Earlier quoted context omitted.
If you vote no, you haven't looked hard enough.
I don't do webapps, but I'm sure everyone's vulnerable somewhere, if they do. 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.
Earlier 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…
Earlier quoted context omitted.
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)
This is the second time in a few days someone has made the point that web stacks make it hard to use prepared statements†. This is a one-liner in Rails. Does it not work in Python? How hard is it in PHP? † Which are not a cure-all for SQLI .
Side note: We're jumping to conclusions by thinking that the javascript is the entire implementation. It's perfectly possible that the server is already safe against SQL injection and the javascript is just an extra line of defense. Maybe the client and server were done by separate programmers and the client programmer wanted to make sure he wouldn't get blamed. It's a government website: nobody in government ever got fired for being too careful. Or maybe the programmer had to do it to satisfy some non-technical bureaucrat who wanted to think that hacking attempts couldn't even reach his server.
Earlier quoted context omitted.
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?
window.pageBirthday =
Upvote here if you too have discovered sql injection vulnerabilities in your own web apps.
Earlier 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?
A moderately large amount of this information is available on the Internet, start at http://www.cabinetoffice.gov.uk/resource-library/security-po... if you want a look. A brief look through the sitemap suggests they are holding or processing Personally Identifiable Information (PII) which puts them under the Data Protection Act. Again, the presence of the javascript doesn't imply actual SQL injection, but it definitely doesn't imply a measure against it.
In this instance, the compliance requirements are fairly low. I guess the exam question is, can they pass the bar, or do they limbo under it?
Earlier quoted context omitted.
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 bui…
I've never had a situation where the client enters the column names to return in the UI. I mean the users should not have to know the column names in your database so surely you'll do that some other way instead? It's pretty rare (and probably wrong) to have hundreds of columns being returned, so we'd just return them all and show/hide the relevant ones on the application-side.
Same for table names. Why would you need to have a parameterized table name? This has never come up in all my years of SQL Server. Sounds like bad DB design or something exotic that I've never had to do. I mean how would you index queries like that anyway?
For your 'Advanced Search' I'd probably use a temp table or table variable and do the query in multiple steps using 'IF' switches depending on the flags or setting passed to it.
Earlier quoted context omitted.
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 bui…
stmt = "SELECT col1 FROM table ORDER BY col2 " + (isDescendingSort ? "DESC" : "ASC")
As long as all your user input has been filtered through type checking, enumerations, etc. (aside from parameters), is that not a safe approach?