4 ms·
How about no.
by upgrayedd 16y ago
How about no.
- dgavey 16y agoIf you vote no, you haven't looked hard enough.
- Skalman 16y agoNo, 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.
- jedsmith 16y agoYou trust the library doing that protection for you too?
- tptacek 16y agoYeah? 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.
- Devilboy 16y agoIt'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?
- tptacek 16y agoSo, 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?
- Devilboy 16y agoI've never used MySQL (and God willing I'll never have to) but in SQL Server you can limit rows by setting @@ROWCOUNT before your SELECT statement. SQL Server also allows CASE in your ORDER BY clause that can do pretty much anything you could want. 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.
- danparsonson 16y agoAll of those scenarios can be handled in such a way that you're only concatenating known strings rather than user input - e.g. 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?
- tptacek 16y agoOf course you can build these queries safely. Of course you should use prepared statements when possible. But web devs do have a bad habit of saying "we're safe, we used prepared statements", and then losing their app within 5 minutes because of the code than handles sortable columns in their table views.
- deleted 16y ago[deleted]
- deleted 16y ago[deleted]
- upgrayedd 16y agoI 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.
- uxp 16y agoI wrote an iPhone app with a sqlite backend that was vulnerable to SQLi. Don't think you aren't vulnerable even if your application doesn't touch the internet.
- upgrayedd 16y agoSorry, I just don't do any apps that touch the internet...just some programming for fun on the side. The only thing that I've written that could be applied to this is our POS system at the restaurant I work at as a dishwasher and cleaner for. It's in Django though, and the Django project takes care of most issues with that...not that they're really priority #1 security-wise...
- elliottcarlson 16y agoYou should never assume that your framework of choice does everything for you. This is by all means no shot at Django, but just in general, always assume what you are working with is insecure and full of bugs - and then account for that - if your framework/programming language of choice accounts for additional things - great.
- jarrett 16y agoBut does this mean, for example, that you should escape inputs yourself before passing them off to the framework, which is then ostensibly going to escape them again? I think a better approach is to verify that the framework is correct. You can do this experimentally, by writing unit tests, or by reading and running the unit tests of the framework itself.
- Devilboy 16y agoIf you use type-safe SQL parameters everywhere and no string concatenation you'll be fine. http://taylorza.blogspot.com/2009/04/sql-injection-are-parameterized-queries.html http://taylorza.blogspot.com/2009/04/sql-injection-are-param...