Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Developer Security Checklist

simplesecurity.sensedeep.com

Post reply on HN
Print view View original

121–130 of 249 posts

Re: Web Developer Security Checklist

#121

Post by bpicolo »

user15672 wrote: post #108
atemerev wrote: post #104

Earlier quoted context omitted.

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; credenti…

> 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

Re: Web Developer Security Checklist

#122

Post by LanceH »

sho wrote: post #25
aeronautic wrote: post #16

Earlier quoted context omitted.

The cost of full encryption is minimal on platforms like AWS Aurora. If the platform supports it - this is a good way to go. The incremental cost of encryption with Aurora is very low ( The 2nd layer is if the server-app is compromised. In this case, the data has already been decrypted by AWS. The 2nd layer means that credentials, emails etc are safe in the server-app tier. You can lookup tokens by decrypting first.…

> At rest, means that the data on disk is encrypted if the DB itself is compromised Right, so basically block-level encryption of the actual DB data file. While this would be much easier than encrypting the record data at the row level, it only protects against literal copying of the data file, which in my experience is not a common threat vector. You're right though, it is simple enough to do this with something lik…

Having a system encrypted at rest is a huge reduction in legal liability under HIPAA. It may be similar in other industries. On the other hand I might not care if someone stole my recipe collection.

Re: Web Developer Security Checklist

#123

Post by haburka »

ianamartin wrote: post #93
sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

I'm going to go the other way on the SQL advice, even though the author has clarified below that he was talking about prepared statements. It doesn't cost me much, if any, developer time to work with stored procedures. I realize most full stack devs don't have as much in-depth experience with SQL. That was literally all I did for the first several years of my career. Before it ever occurred to me to learn other progr…

Data, logic and presentation sounds a lot like model controller and view. I feel like you suggested most logic should be in how days is handled? But let's be serious here, there's no right way to make a web app. There are certainly wrong ways and inefficient ways. If we focus all our efforts on doing things perfectly well then we would miss the point. Essentially, you're just theory crafting how people should code while ignoring the practical issues of people and coding.

Re: Web Developer Security Checklist

#124

Post by swsieber »

aeronautic wrote: post #98
stephenr wrote: post #96

Earlier quoted context omitted.

So your solution to fixing a basic ops problem 'software package A was exposed to the internet with(out|effectively no) auth' is: encrypt shit in an ORM layer and destroy your ability to do anything beyond absolute string comparison queries. No thanks.

No, we don't encrypt indiscriminately. We selectively pick fields to encrypt - fields that are highly sensitive. And you are right, we do this because an ops error can easily make a mistake sometime in the future and probably will one day. We all make mistakes and defense in depth is all about that.

It does seem like emails are a good fit for encryption. I can't see wanting to do anything more than simple equality checks.

Re: Web Developer Security Checklist

#125

Post by _cereal »

aeronautic wrote: post #64
slackingoff2017 wrote: post #61

Besides the bad SQL tips most of it is okay. Sounds like the author has little experience with ORM's or SQL abstraction layers with parameterization like ADO.NET, SQLAlchemy, or JDBC. Besides the SQL stuff mentioned elsewhere, Regex is rarely a safe whitelist. It's better to use specific escapes for HTML or URI or whatever. Most of XSS is finding bad input that isn't filtered. Hardly anyone is stupid enough to not fi…

Thanks for the tips. Can you say which SQL tip is bad, someone has already picked up the Stored procedure comment -- really meant prepared statements. Regarding regexp. You can do very precise regexp for many patterns. I agree some are harder, but I wouldn't say "rarely" in our experience. The point about port 22 is that if you have it open, many people tend to use it more than they should. Effective automation shoul…

Hi, about port 22, you can use ssh keys and disable password access, see: https://aws.amazon.com/articles/1233/

Re: Web Developer Security Checklist

#126

Post by atemerev »

user15672 wrote: post #108
atemerev wrote: post #104

Earlier quoted context omitted.

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; credenti…

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

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.

Re: Web Developer Security Checklist

#127

Post by SimbaOnSteroids »

user15672 wrote: post #101
sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

Some this advice seems to come out of a cargo cult development handbook. That may sound a little harsh, but it's better to have a tendancy to take any article that states "Always do X" or "Never do Y" with a handful of salt. If you don't know enough about your own systems requirements, lists like this are going to have you doing work that you don't understand, doesn't need doing (or worse, is detrimental) and if you…

Thanks for this, I'm planning on developing a small web application over the summer for one of my gaming interests and as I was reading this I was wondering how practical any of it would be for my project. Don't get me wrong I plan on building in security but I'm planning on building a Rails app were the most sensitive data contained is an API key, it would hardly seem practical to build Fort Knox.

Re: Web Developer Security Checklist

#128

Post by atemerev »

DamonHD wrote: post #120
atemerev wrote: post #104

Earlier quoted context omitted.

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; credenti…

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 ju…

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

Re: Web Developer Security Checklist

#129

Post by aeronautic »

user15672 wrote: post #101
sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

Some this advice seems to come out of a cargo cult development handbook. That may sound a little harsh, but it's better to have a tendancy to take any article that states "Always do X" or "Never do Y" with a handful of salt. If you don't know enough about your own systems requirements, lists like this are going to have you doing work that you don't understand, doesn't need doing (or worse, is detrimental) and if you…

I'd recommend you start with the items at the very end of the check list. Make a list of the threats and plan who you need to defend against.

That will then allow you to cull the list down.

Re: Web Developer Security Checklist

#130

Post by EGreg »

aeronautic wrote: post #117
EGreg wrote: post #114

I would add one more regarding DOS protection: Sign the session tokens that you issue. This way you don't need to do any I/O to verify these tokens at the router level.

I'm not sure I fully understand what you are saying. Can you elaborate.

I came up with this technique when designing our platform (https://qbix.com/platform) so I don't know if it's widely used.

Many apps include session id tokens in requests, to identify the logged-in user. The session id is usually a bearer token (like in a cookie) which identifies the session on the server.

To mitigate against DDOS attacks, as you said, all publicly available resources can be cached on CloudFlare. (Personally I look forward to content-addressable protocols like IPFS supplanting HTTP.)

However, the non-public resources are usually dynamic and should not be cached. These resources are typically for users who have logged in, or at least have a session.

So our design basically encourages this:

1) if you want to serve non cacheable resources, require that the request included a session id

2) the session id is generated on our server and signed with an HMAC so the app can verify this signature without doing any I/O.

This is because I/O is expensive and hard to parallelize, whereas statelessly checking whether a session token has been issued by our app is easy to implement, even at the external router level. Simply examine the packets coming in, decrypt, look at the request, and verify the HMAC on the session id. If it is wrong then the session id is bogus so we don't expend any more resources within the network on this request.

You can make sessions expensive to start. For example, a user might have to log in with a valid account to get a session.

The big question is, how can we ensure that users don't get too many accounts? To prevent sybil attacks. Any ideas?

Post reply on HN