Hacker News Reader

Comment by atemerev | Hacker News Reader

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.

View on HN

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!)

...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

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.

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.

I never said:

1) That it was easy to do right: that's why we get paid.

2) That it was an excuse not to do other checks elsewhere: defence in depth is key.

Anyhow, I hope that we're really furiously agreeing.

> But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks prevention

Can you define what you mean by "input sanitization"? Because in my mind, a prepared statement is doing just that. You say what part is your SQL, what part is your user input, and you let the DB adapter sanitize the input to build the final statement. You aren't writing sanitization code yourself, you're leaving it up to a library, but that's still what's happening. Or do you have a different term for what's going when a prepared statement routine converts user input into SQL-safe strings?

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".

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

> 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.

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

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.

Reply on news.ycombinator.com