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

61–70 of 71 posts

Re: A practical security guide for web developers

#61

Post by nommm-nommm »

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.

>>You normally remove all hints of HTML tags on input sanitation

Then what happens when you want to use that input in an excel export? PDF export? CSV file? Text file? How about if you want to use it in an HTML attribute? In a URL? Export the database elsewhere? (Such as a credit card company reporting to the CSAs). You can't assume that your data is going to be inside an HTML page between tags always because that mucks up your data. Data should be able to be used in many different ways because it will be and should not be tied to HTML.

Re: A practical security guide for web developers

#62

Post by ubernostrum »

niftich wrote: post #15

Efforts like this are very good. But one of the most serious problems with web development is how few frameworks ship with most of these sane answers out-of-the-box ( edit : or don't ship concepts at the right level of abstraction) When we all need to copy-paste some best-practice way of how to Argon2 a password and how to constant-time equality check a hash, we've already lost, in that we're reimplemeting these sane…

While I appreciate the kind words for Django, there are plenty of libraries and frameworks out there which are doing the basics of web app security out of the box these days, and my recommendation is to find one you like and use it.

The big obstacle there is people who insist on writing their own versions of everything rather than using off-the-shelf components. I know it's a point of pride for some folks not to "rely" on third-party code, or to post long rants from someone's experience with a late-90's-era framework as evidence that they're all awful, but getting a bunch of best practices done for you for free is the advantage they offer, and given how hard it is to cover even the basic security bases, that's an advantage I think people increasingly can't afford to give up.

Re: A practical security guide for web developers

#63

Post by ubernostrum »

zkhalique wrote: post #27
nmjenkins wrote: post #25

Earlier quoted context omitted.

The "Secure" flag has nothing to do with protecting against XSS. It protects against anyone who can proxy your requests (i.e. when you connect to dodgy wifi) being able to steal your session simply by injecting " rel="nofollow">http://yoursite.com"> into any non-secure web page your request . That is a massive security hole and not theatre in the slightest. The HTTP-only flag is less important but still useful. As I…

I'm talking only about the httpOnly flag. It's worse than useless because it makes you think that you dodged some kind of bullet, when in fact that same class of attack can still happen: the attacker needs to craft a script to send the cookie to their server, so they might as well have that script execute the actual requests in the context of your authorized session, the same way that they'd do it if they had your co…

For what it's worth, I agree with the criticisms of HttpOnly, but I still recommend people set it as one of several redundancy measures.

The approach I take these days (for example: when I gave a three-hour tutorial on web app security at DjangoCon this week) is basically to provide combinations of basic mitigations and then more complex/advanced ones, and push people do at least some combination of them, even if they can't do all of them. So to take XSS/CSRF, for example: Django's template system autoescapes variable output by default, and there's a CSRF protection mechanism on by default. Those are the basic easy things, because the advice is just "they're on already, don't turn them off", and just those simple measures will deal with a lot of nastiness for you.

From there I can talk about cookie options, or CSP, or that kinda-sorta-works header that turns on reflection detection in a few browsers, and the pros and cons of each, and recommend people use combinations of them. CSP is my gold-standard recommendation nowadays, and I downplay HttpOnly as not super great, but I'm not going to complain if somebody just watches my talk and does all the things mentioned.

Re: A practical security guide for web developers

#64

Post by ubernostrum »

jessaustin wrote: post #60
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"?

As a basic starting point OWASP's top-ten list is fine. I use it when doing intro web-security sessions as a structured way to start people thinking about the things that can go wrong, and I like it for that purpose because some of its items are vague enough to allow good open-ended discussions that take people out of the "just check these boxes" mindset and into full-blown paranoia.

I typically follow it up with a rundown of less-obvious things drawn from my experiences with Django, to point out that even when you cover the OWASP checklist-y stuff you still very easily have major issues.

Re: A practical security guide for web developers

#65

Post by vollmond »

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

Earlier quoted context omitted.

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.

>>You normally remove all hints of HTML tags on input sanitation Then what happens when you want to use that input in an excel export? PDF export? CSV file? Text file? How about if you want to use it in an HTML attribute? In a URL? Export the database elsewhere? (Such as a credit card company reporting to the CSAs). You can't assume that your data is going to be inside an HTML page between tags always because that mu…

Ok, this is the comment that best explained it to me -- you want to sanitize (escaped, etc, whatever) output because, even if you sanitize all HTML/CSS/JS on input, they might have inserted malicious Excel scripts or PDF exploits, etc, that eventually do get executed in an output context.

Re: A practical security guide for web developers

#66

Post by vollmond »

mryall wrote: post #47
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?

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

Right, but you seem to be talking about input -- the question was about output.

I did get my answer, though -- output matters because it might be a different medium than input. So even if you sanitize HTML input, malicious VBA code could make it through that eventually ends up in an Excel report and gets executed (for example).

Re: A practical security guide for web developers

#67

Post by ufmace »

DrJokepu wrote: post #7

* Don't let HTTP GET requests modify state, ever. It's very difficult to prevent CSRF via HTTP GET. * Session keys are password-equivalents. Hash them with bcrypt or something before you store them. * httponly is not incredibly useful. If the attacker can run JavaScript on your page, you're in trouble.

> httponly is not incredibly useful. If the attacker can run JavaScript on your page, you're in trouble.

Gotta disagree with that. Defense in depth is always a good idea. Don't ignore a simple security win just because it isn't necessary if all of your other security measures are working. Security is needed the most when some of your security measures have already failed.

Re: A practical security guide for web developers

#68

Post by lyonlim »

fmavituna wrote: post #28

Use static source code analysis and dynamic web app scanners. They are easy to integrate into your SDLC, they are not going to replace manual testing or secure development practices but they'll help a lot. They'll pick up tons of stuff for free, they'll remind you best practices. I have a startup (at least it still feels like a startup!) and we are developing a web application security scanner called Netsparker [0].…

How does this compare with Trend Micro Deep Security for Web Apps? We're using it now but it does not seem effective - not catching much in its scans. So we're looking at alternatives...

Re: A practical security guide for web developers

#69

Post by rahkiin »

k__ wrote: post #42
br3w5 wrote: 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.

You don't know who the user is until you verified the integrity of the JWT. Verifiying the integrity requires the secret. Your solution adds the dependency: the secret requires the user. It is cyclic, unsolvable without breaking a constraint.

You could assume the username is correct, then get the secret, validate. But that sounds like something breakable.

Re: A practical security guide for web developers

#70

Post by scooke »

These sorts of guides are much appreciated. I started out with a managed host, and learned a lot about web apps but not a lot about the backends like Apache, MySQL, etc. I hadn't bothered to try my own VPS because I assumed as soon as I spun up my own VPS I'd get attacked and hacked. But when that managed host had entire disks of customers' files wiped out due to a PHP malware, I decided it was time to jump ship and try to do it myself. Am I ever glad I did, and these sorts of guides (and what DO has put up) have been immensely helpful.
Post reply on HN