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

A practical security guide for web developers

github.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: A practical security guide for web developers

#51

Post by nommm-nommm »

aruggirello wrote: post #37

> Store password hashes using Bcrypt (no salt necessary - Bcrypt does it for you). In PHP, I would rather recommend to use password_hash() with its own defaults since it's built-in and designed specifically for this purpose - and quite future-proof. But this is PHP specific. > [] Destroy all active sessions on reset password (or offer to). > ... > [] Destroy the logged in user's session everywhere after successful re…

I think the first one is saying "destroy active sessions when a user attempts to change their password" and the second one is saying "destroy active sessions when the user succeeds in changing their password."

Re: A practical security guide for web developers

#52

Post by bensummers »

danneu wrote: 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.

I've written an HTML templating system where the common security issues are simply not allowed: https://github.com/haplo-org/haplo-safe-view-templates

I'm pretty sure it covers all the HTML generation issues described in https://www.nostarch.com/tangledweb.htm

We're been using it very happily for a good six months, and it's worked out well.

Re: A practical security guide for web developers

#53

Post by glitcher »

vollmond wrote: post #44
danneu wrote: 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?

And the bigger issue with only sanitizing user inputs without also escaping output is that different escaping methods are required for different output contexts (HTML content, HTML attributes, URL params, JavaScript variables, etc).

Re: A practical security guide for web developers

#54

Post by tonyarkles »

nommm-nommm wrote: post #51
aruggirello wrote: post #37

> Store password hashes using Bcrypt (no salt necessary - Bcrypt does it for you). In PHP, I would rather recommend to use password_hash() with its own defaults since it's built-in and designed specifically for this purpose - and quite future-proof. But this is PHP specific. > [] Destroy all active sessions on reset password (or offer to). > ... > [] Destroy the logged in user's session everywhere after successful re…

I think the first one is saying "destroy active sessions when a user attempts to change their password" and the second one is saying "destroy active sessions when the user succeeds in changing their password."

My interpretation is: "when a user changes their password, offer to destroy all active sessions"

Re: A practical security guide for web developers

#55

Post by markc »

laurencei wrote: post #5

A great book is The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws, 2nd Edition [0] - by learning how hackers search for and exploit various web issues - you'll be naturally aware of them to defend against. i.e. start thinking like a hacker and you'll be amazed at the issues you discover in your applications. [0] http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118026470...

Agreed, still the best text out there for web application security.

Re: A practical security guide for web developers

#56

Post by nickpsecurity »

onion2k wrote: post #35
CiPHPerCoder wrote: post #12

Please excuse me if this comes across as anything other than constructive criticism, but I don't believe checklists should be used to guide web developers to build secure software. My reason for this belief is that, in my experience, it engenders tunnel vision and what I appropriately refer to as a "checklist mentality". There are developers who believe, "We're immune to the items on the OWASP Top 10, so we're secure…

What you're referring to is the difference between "quality checking", which is the act of checking a product meets acceptance criteria after you've finished building it, and "quality assurance", which is act of putting in processes to guarantee a product is of sufficient quality that you use throughout the build process. A lot of people believe they're doing QA when really they're only doing QC. Both are important.

Interesting point. We make the same in high-security INFOSEC where one must differentiate between adding security "features" and "assurance." The features are things like trusted boot, kernel/user separation, crypto protocols, and so on. The assurance... often missing... are activities that ensure those features are built securely & provide evidence of that to 3rd parties.

Common Criteria's EAL's provide an interesting set of assurance activities with descriptions of the increments:

https://web.archive.org/web/20130718103347/http://cygnacom.c...

Re: A practical security guide for web developers

#57

Post by Tehnix »

nommm-nommm wrote: post #48
vollmond wrote: post #44

Earlier quoted context omitted.

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

But that script tag would be taken care of in the input sanitation step. You normally remove all hints of HTML tags on input sanitation, which renders output sanitation a moot point.

Re: A practical security guide for web developers

#58

Post by tetrep »

Tehnix wrote: post #57
nommm-nommm wrote: post #48

Earlier quoted context omitted.

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

But that script tag would be taken care of in the input sanitation step. You normally remove all hints of HTML tags on input sanitation, which renders output sanitation a moot point.

Unless you application has a static mapping of input -> output that never changes, you can't properly sanitize input for all potential output contexts. The string ';alert(1) is perfectly safe to drop in between HTML tags, but can be very dangerous in JavaScript, but only if it's inside a single-quoted string.

You can try to filter for anything that may be potentially dangerous, but that's going to make a very long list of invalid inputs and once again you're playing whack-a-mole, hoping you correctly sanitize your input for all potential output contexts (unless you go through and re-sanitize all your user data whenever you add a new output context, which is a bit absurd).

From a programming perspective, it's akin to a function not checking that the input it has received is valid (because the caller is always going to do that...).

Re: A practical security guide for web developers

#60

Post by jessaustin »

lukiebriner wrote: post #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/ommissio…

ISTM I've seen some rather trenchant criticism of OWASP's lists in the past. Maybe they've improved, but are they really a "respected go-to"?
Post reply on HN