4 ms·

I think, the author is right, and you might be not. "Data at rest" means the data that you have no intention of querying soon. Which implies "hot" / "cold" dat

I think, the author is right, and you might be not. "Data at rest" means the data that you have no intention of querying soon. Which implies "hot" / "cold" data partitioning, which is usually a good idea. Can be complicated, but commonly encountered in financial backends. Two layers of encryption can be better than one (if logically and temporarily separated). Encryption algorithms are usually not a problem; credentials compromise or out-of-band vulnerabilities CAN be a problem. Finally, ANY type of input sanitization is wrong way to do security, and should be employed only as an absolute last resort. Prepared statements provide strong semantic separation guarantees, and you can use ';drop table users; _safely_ as your query parameters. Otherwise you'll be stuck between the requirements corner cases (do you know that legal names can include quotes and apostrophes?) and security requirements, and it is the war that is impossible to win.

user15672 9y ago
> Finally, ANY type of input sanitization is wrong way to do security, and should be employed only as an absolute last resort. Ok, that's just plain wrong and absolutely wreckless advice. Everything from software development 101 classes to OWASP data validation can call you on that. If you don't understand why you're wrong, please, please, please stop developing software now until you can understand it.
- bpicolo 9y ago
  He's correct in the sense of trying to catch SQL injection via input validation - that's a losing game. He isn't saying "don't validate your data at all", that's a different issue. Ultimately, your OWASP issues (XSS, SQL Injection) related to input are going to be prevented by appropriate escaping and data handling across your entire stack by default (key word is default, "trust the devs" is not the right answer). Input validation isn't the ticket. This is a prime example of the Robustness Principle. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
- atemerev 9y ago
  Would you be so kind to explain me the attack vector if the user input is never possibly treated as part of the code? What I came up with is this: user name is stored in the database, and some new junior developer in a large team reads it in the backend code, and immediately plugs into another SQL query using string concatenation. BOOM! But on the other hand, the very same junior developer can forget to sanitize the inputs before storing them (or do it incorrectly), so there.
DamonHD 9y ago
All significant modules, whether facing the Internet or internal to a large system, should validate their inputs to prevent propagation of BadThings(TM). You can choose how much to validate, which is probably more in the former case, but it should be done. I can't tell you the number of horrors I'm sure we've stopped in (for example) investment banking pricing by avoiding trying to do calculations on junk when the junk was easy to spot. (We also added one or two, eg when one set of interest rates went above 100%, but that's an after-dinner story!)
- atemerev 9y ago
  ...and this is why Gerard 't Hooft, the famed theoretical physicist, can't register with his real name nearly anywhere. :( https://en.wikipedia.org/wiki/Gerard_%27t_Hooft https://en.wikipedia.org/wiki/Gerard_%27t_Hooft
  - DamonHD 9y ago
    That sounds like BAD validation that needs fixing, not an excuse not to do any. Some US sites still won't let me in because (a) they insist that I must have a middle name or (b) screw up the hyphen in my surname. Many sites and payroll systems assume that everyone has a surname. Never mind its character set and ordering. Even if you don't make these assumptions you don't need to accept a binary gzipped GB of zeros or worse in a name input field.
    - atemerev 9y ago
      Designing a _good_ validation system (to reliably discriminate between "good" strings and "bad" strings, including all corner cases) is really hard, error-prone, not future-proof (standards change) and might be even theoretically impossible in some cases. Some basic sanity checks are useful, of course. But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks prevention.
      - DamonHD 9y ago
randallsquared 9y ago
I work in health care, where "data at rest" does not mean you won't query it soon, but instead that it isn't either in transit (datastore to app, app to app, app to customer, etc; all of these have transport encryption) or being worked with in memory currently. If the data is in a store, it's almost certainly "at rest".
- atemerev 9y ago
  OK, for anything that is queried on demand it is not a good idea, until we get homomorphic encryption.

user15672 9y ago

> Finally, ANY type of input sanitization is wrong way to do security, and should be employed only as an absolute last resort. Ok, that's just plain wrong and absolutely wreckless advice. Everything from software development 101 classes to OWASP data validation can call you on that. If you don't understand why you're wrong, please, please, please stop developing software now until you can understand it.

bpicolo 9y ago
He's correct in the sense of trying to catch SQL injection via input validation - that's a losing game. He isn't saying "don't validate your data at all", that's a different issue. Ultimately, your OWASP issues (XSS, SQL Injection) related to input are going to be prevented by appropriate escaping and data handling across your entire stack by default (key word is default, "trust the devs" is not the right answer). Input validation isn't the ticket. This is a prime example of the Robustness Principle. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
atemerev 9y ago
Would you be so kind to explain me the attack vector if the user input is never possibly treated as part of the code? What I came up with is this: user name is stored in the database, and some new junior developer in a large team reads it in the backend code, and immediately plugs into another SQL query using string concatenation. BOOM! But on the other hand, the very same junior developer can forget to sanitize the inputs before storing them (or do it incorrectly), so there.

DamonHD 9y ago

All significant modules, whether facing the Internet or internal to a large system, should validate their inputs to prevent propagation of BadThings(TM). You can choose how much to validate, which is probably more in the former case, but it should be done. I can't tell you the number of horrors I'm sure we've stopped in (for example) investment banking pricing by avoiding trying to do calculations on junk when the junk was easy to spot. (We also added one or two, eg when one set of interest rates went above 100%, but that's an after-dinner story!)

atemerev 9y ago
...and this is why Gerard 't Hooft, the famed theoretical physicist, can't register with his real name nearly anywhere. :( https://en.wikipedia.org/wiki/Gerard_%27t_Hooft https://en.wikipedia.org/wiki/Gerard_%27t_Hooft
- DamonHD 9y ago
  That sounds like BAD validation that needs fixing, not an excuse not to do any. Some US sites still won't let me in because (a) they insist that I must have a middle name or (b) screw up the hyphen in my surname. Many sites and payroll systems assume that everyone has a surname. Never mind its character set and ordering. Even if you don't make these assumptions you don't need to accept a binary gzipped GB of zeros or worse in a name input field.
  - atemerev 9y ago
    Designing a _good_ validation system (to reliably discriminate between "good" strings and "bad" strings, including all corner cases) is really hard, error-prone, not future-proof (standards change) and might be even theoretically impossible in some cases. Some basic sanity checks are useful, of course. But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks prevention.
    - DamonHD 9y ago

randallsquared 9y ago

I work in health care, where "data at rest" does not mean you won't query it soon, but instead that it isn't either in transit (datastore to app, app to app, app to customer, etc; all of these have transport encryption) or being worked with in memory currently. If the data is in a store, it's almost certainly "at rest".

atemerev 9y ago
OK, for anything that is queried on demand it is not a good idea, until we get homomorphic encryption.