Live data from Hacker News

A practical security guide for web developers

github.com

41–50 of 71 posts

Re: A practical security guide for web developers

#41
Rather than just "JWT is awesome..." wouldn't it be more sensible and responsible to caveat this with some of the drawbacks?

I read this article recently (http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...) that proposes not to use it for sessions but instead for the use cases listed at the end of the article. Follow-up article here http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...

Also this https://auth0.com/blog/2015/03/31/critical-vulnerabilities-i...

Re: A practical security guide for web developers

#42
post #41

Rather than just "JWT is awesome..." wouldn't it be more sensible and responsible to caveat this with some of the drawbacks? I read this article recently ( http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo... ) that proposes not to use it for sessions but instead for the use cases listed at the end of the article. Follow-up article here http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... Also t…

Why not using one key per user? Then I would just have to invalidate this one user and not all of them.

Re: A practical security guide for web developers

#43

The problem with checklists, including this one, is that we tend to limit ourselves to what's in the list. Furthermore the list doesn't explain 'why' you should do things. They help, but nothing is a replacement for education. And when it comes to education, there's a decent write up I did and is still accessed in a daily basis [0]. I also recommend you to check OWASP [1] and read their "Testing Guide" to know many a…

Well, at least it's a good starting point.

Re: A practical security guide for web developers

#44
post #30

There's a whole section on input sanitization but nothing on escaping output. If you're on the hook to sanitize all inputs, doesn't that mean you're not escaping output? The biggest security mistake I've made so far in production was that one time I used an HTML templating library that didn't escape output by default.

Can you clarify? What exactly do you mean by escaping output, and how can forgetting that cause a security issue?

Re: A practical security guide for web developers

#46
post #2

Had this SO link saved since probably soon after it was asked 7 years ago. Still relevant and still being updated. http://stackoverflow.com/questions/549/the-definitive-guide-... Includes: - How to log in - How to remain logged in - Managing cookies (including recommended settings) - SSL/HTTPS encryption - How to store passwords - Using secret questions - Forgotten username/password functionality - Use of nonces to p…

HIPAA compliance is a good checklist even if you don't need the certification. It covers the administrative and physical safeguards in addition to the technical ones.

Check it out: http://www.hhs.gov/hipaa/for-professionals/security/laws-reg...

Re: A practical security guide for web developers

#47
post #30

There's a whole section on input sanitization but nothing on escaping output. If you're on the hook to sanitize all inputs, doesn't that mean you're not escaping output? The biggest security mistake I've made so far in production was that one time I used an HTML templating library that didn't escape output by default.

Can you clarify? What exactly do you mean by escaping output, and how can forgetting that cause a security issue?

User-provided data in any transport format (e.g. HTML) needs to be properly escaped so it can't use special characters to be processed as code or metadata rather than just plain data. Bugs in escaping cause pretty much every kind of injection attack, from SQL to XSS. The fundamental problem is not escaping data correctly for the context in which it is used.

If you want to see specific examples, search for how to avoid XSS attacks. Any decent guide will focus on escaping, not sanitisation.

Re: A practical security guide for web developers

#48
post #30

There's a whole section on input sanitization but nothing on escaping output. If you're on the hook to sanitize all inputs, doesn't that mean you're not escaping output? The biggest security mistake I've made so far in production was that one time I used an HTML templating library that didn't escape output by default.

Can you clarify? What exactly do you mean by escaping output, and how can forgetting that cause a security issue?

Example HTML output in a user's profile:

Would you like to contact ${NAME}?

Where ${NAME} is a user supplied parameter (you ask them what their name is)

Let's say I entered my name as: /evil code/

Now, if the output isn't escaped the page reads:

Would you like to contact /evil code/?

You've just injected evil code into the website that will be executed every time my user profile page is visited by another user.

EDIT: Hacker news doesn't properly render javascript comments.

Re: A practical security guide for web developers

#49
My problem with this is another howler for security:

Creating something that already exists.

Although OWASP are not legally mandated, they are the most respected go-to people for this kind of stuff and have much more exposure that your "guide" ever will, it also has a much greater level of review and scrutiny so instead to trying to help by increasing the web noise level and possibly making your own mistakes/ommissions (some of which are mentioned below), why not instead get engaged into the existing community and increase the quality of that if needed?

Re: A practical security guide for web developers

#50
This is one of the best examples of how Github nails collaborative document development I've seen.

It is striking how valuable much information is retained in negotiating the material here, vs email arguments with word documents and embedded content, where the app-seperation of submissions makes it too difficult to consume.

Post reply on HN