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

31–40 of 249 posts

Re: Web Developer Security Checklist

#31

Post by sho »

xupybd wrote: post #15
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…

Totally with you on the DB encryption but I'm not sure about your comments on prepared statements >That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries. I've always found using only prepared statements is feasible and justifiable. What is about using…

My apologies - my brain focussed on "stored procedures" and that's what my rant was addressing. Prepared statements are great and I'd use them whereever possible - totally agreed.

Re: Web Developer Security Checklist

#32

Post by sho »

aeronautic wrote: post #21
horsecaptin wrote: post #18

How much of this is built into various frameworks such as Rails, Django, EmberJS (for frontend) etc?

No much at all.

For RoR many of the app-level points are - CSRF, SQL escaping, bcrypt by default, etc. That's a big reason to use such a framework in the first place.

Re: Web Developer Security Checklist

#33

Post by badminton1 »

A largely incomplete list. One of the most important items would be: handle errors correctly and make sure errors do not result into any sort of resource leak or sensitive information disclosure.

For example, this code was from a guy in Stack Overflow:

    ... function (req, res, next) {
        if (err) return console.log(err)
What will that piece of code do? Leak the request object, the response object, including the underlying client connection... keep the connection open, leak memory... and at scale, make your server run out of sockets and memory. Then, when memory is low, swapping kicks in, overloading your CPU as well. In short, kills your machine with only a little 1 line of code mistake.

There are less trivial ways of running into the same situation, but the lesson is that node.js is not a babyproofed technology and needs to be used with care.

This piece of advice is one of the most important, and the most overlooked/ignored in the node community.

Re: Web Developer Security Checklist

#34

Post by sho »

aeronautic wrote: post #27
sho wrote: post #25

Earlier quoted context omitted.

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

Good point. I did say: "This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application." But I'll try to make that clearer. I'm limited by space and peoples attention span. Having links to implementation notes will address your concern I think.

> I'm limited by space and peoples attention span

Might I suggest a simple "tag" for each suggestion indicating the appropriate market for that point. Eg good - your basic SAAS/casual web app. Great - apps dealing with moderately sensitive data. Extreme - you're building a bank, seeking PCI compliance, storing medical data, etc.

You could break it out at the top, and then it doesn't take much space in the body of the post, but still provides some context for which projects should be adopting this level of paranoia?

Re: Web Developer Security Checklist

#35

Post by aeronautic »

badminton1 wrote: post #33

A largely incomplete list. One of the most important items would be: handle errors correctly and make sure errors do not result into any sort of resource leak or sensitive information disclosure. For example, this code was from a guy in Stack Overflow: ... function (req, res, next) { if (err) return console.log(err) What will that piece of code do? Leak the request object, the response object, including the underlyin…

Ah, node. That is a whole post for itself and a really good idea. Perhaps I'll tackle that next. Coupled with async wait issues -- there is plenty to talk about there.

But good point. How would you describe this item on error handling? How would you state it for the check list?

Re: Web Developer Security Checklist

#36

Post by badminton1 »

aeronautic wrote: post #35
badminton1 wrote: post #33

A largely incomplete list. One of the most important items would be: handle errors correctly and make sure errors do not result into any sort of resource leak or sensitive information disclosure. For example, this code was from a guy in Stack Overflow: ... function (req, res, next) { if (err) return console.log(err) What will that piece of code do? Leak the request object, the response object, including the underlyin…

Ah, node. That is a whole post for itself and a really good idea. Perhaps I'll tackle that next. Coupled with async wait issues -- there is plenty to talk about there. But good point. How would you describe this item on error handling? How would you state it for the check list?

Make sure error conditions are handled gracefully, without leaking resources, and producing errors that do not contain any sensitive information.

Re: Web Developer Security Checklist

#37

Post by aeronautic »

badminton1 wrote: post #36
aeronautic wrote: post #35

Earlier quoted context omitted.

Ah, node. That is a whole post for itself and a really good idea. Perhaps I'll tackle that next. Coupled with async wait issues -- there is plenty to talk about there. But good point. How would you describe this item on error handling? How would you state it for the check list?

Make sure error conditions are handled gracefully, without leaking resources, and producing errors that do not contain any sensitive information.

Thanks perfect.

Re: Web Developer Security Checklist

#39

Post by Kiro »

badminton1 wrote: post #33

A largely incomplete list. One of the most important items would be: handle errors correctly and make sure errors do not result into any sort of resource leak or sensitive information disclosure. For example, this code was from a guy in Stack Overflow: ... function (req, res, next) { if (err) return console.log(err) What will that piece of code do? Leak the request object, the response object, including the underlyin…

> make your server run out of sockets and memory

Do you mind explaining why the code causes this?

Post reply on HN