4 ms·

I 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 a

I 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 ago
You should whenever you can always parametrized queries over sanitizing the input. Manually escaping or sanitizing should be the last resort.
- PavlovsCat 13y ago
  Manually 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 ago
    One 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 ago
  You'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 ago
    Bingo. 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 ago
    That'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.

jeltz 13y ago

You should whenever you can always parametrized queries over sanitizing the input. Manually escaping or sanitizing should be the last resort.

PavlovsCat 13y ago
Manually 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 ago
  One 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 ago
You'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 ago
  Bingo. 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 ago
  That'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.