7 ms·
Nice article, but this is training wheels. Maybe it's inferred, but this article should be pointed at the rookie developer.
by jroseattle 13y ago
Nice article, but this is training wheels. Maybe it's inferred, but this article should be pointed at the rookie developer.
- magoon 13y agoWhich article is for intermediate and advanced?
- dmix 13y agohttp://www.amazon.com/SQL-Injection-Attacks-Defense-ebook/dp/B008PQESLI/ http://www.amazon.com/SQL-Injection-Attacks-Defense-ebook/dp...
- glhaynes 13y agoI learned long ago to sanitize my inputs/etc so I don't think I'll write more secure code for having read it, but I hadn't ever thought through exactly how an attacker might do things like time-based blind SQL injection. So I found it interesting.
- jeltz 13y agoYou should whenever you can always parametrized queries over sanitizing the input. Manually escaping or sanitizing should be the last resort.
- PavlovsCat 13y agoManually escaping or sanitizing should be the last resort. Why, other than "because one might forget it"? That is, what if bits of the query depend on various conditions and need to be constructed part by part? Keeping the placeholders and the actual values synced seems like a nightmare in those cases.. unless I am missing something.
- ygra 13y agoOne could imagine something like public static void AddParameterValue(this SqlCommand cmd, string paramName, object value) { if (cmd.CommandText.Contains("@" + paramName)) cmd.Parameters.AddWithValue(paramName, value); } to help set parameters only if they are referenced in the SQL statement.
- twistedpair 13y agoYou've got to do both chief. Sure, you won't get SQL Injected with your parameterized queries, but you'll persist content that is damaging to your users. XSS is the example case where malicious content is persisted to the database and returned to the UI as trusted content. That being said, this is not necessarily an issue with the DB tier as it is with the data input tier.
- jroseattle 13y agoBingo. A quick summary of the article would be "if you allow external input to pass through as executable values, this can happen". Really, the article is exploring different manners of executing SQL statements against a database, and really just looking at many possible SQL scenarios. The primary culprit in every scenario is the input tier.
- andyroid 13y agoThat's what output sanitizing is for. What's filtered for output may easily be changed over time whereas data that's been filtered when input could be enormously difficult to change once the application requirements changes.
- bigiain 13y agoTroy writes largely for a less-technical-than-HN-commenters audience. You're unlikely to see to many "Wow, there's something I didn't know" comments here in response to his articles – but I'll bet there's many many heads nodding and thinking "I wish I'd had this article to show a certain cow-orker before he did $newbie_mistake[0]"
- ams6110 13y agoOr, let's be honest: I wish I'd read this article before I learned this stuff the hard way.
- jroseattle 13y agoYep, certainly didn't mean to imply it wasn't useful, just where the focus should be.
- bcoates 13y ago"Don't be that guy who has SQL injection issues" is rookie advice but mistaken ideas about what SQL injections can do are widespread (probably #2 common security misconception after "hash your passwords"). The blind timing-based information leak is pretty clever and makes a nice counterexample to a lot of wrong common-knowledge.