Web App Security Best Practices | Hacker News Reader

Web App Security Best Practices

coffeeonthekeyboard.com

88 pointsjamessocol32 comments

Posts like this are awesome at raising awareness, but it seems difficult to find guidance on what to secure, whether to secure or not, and what to secure against. I'm not talking about SQL injection or XSS - both of which are hugely relevant for web apps, but rather a broader approach, like threat modelling.

The idea (for any system) is to start with understanding an adversary's perspective by:

- Listing application entry points (where does data enter into the application?)

- Cataloguing assets (what's being protected?)

- Identifying trust levels (who needs access to what?)

Then defining the security of the app/system by:

- Defining use scenarios

- Identifying implementation assumptions (parameter-based SQL?) and external dependencies (payment system?)

- Modelling the application/solution (data flow diagram that shows interactions with external entities, and machine and process boundaries)

The final stage is identifying threats, analysing them, and determining vulnerabilities. Threats typically fall into one of 6 categories:

- Spoofing

- Tampering

- Repudiation

- Information disclosure

- Denial of service

- Elevation of privilege

That stuff I've just written doesn't begin to do threat modelling justice, but it's enough to start some research.

And before anyone starts suggesting that it's not important/requires big design up front/we need to pivot/etc consider that exactly those arguments are what landed the likes of LinkedIn, Sony, etc. in hot water.

I would love if every web app went through proper threat modeling periodically. But we're in a fast-moving industry, and that takes time. Sometimes people need to ship and do it now, or yesterday. I'm aiming to help by helping people cover the basics and reduce the surface area of attack.

Maybe it's worth adding that the basics are just the basics, not a substitute for real threat modeling and analysis. But there's always a real-world cost/benefit factor.

The broader approach matters if you already have got the basics covered, but sadly it seems that most people don't have the basics covered at all. Most of the hacks I read about are impressive not because of their ingenuity, but because of how depressingly mundane they are. SQL injection hacks are still commonplace.

So, no, let's keep raising awareness of the basics until finally everyone gets it. Then, once the OWASP top ten is filled with MITM, timing and social engineering attacks, that's when we can move on to the broader approach.

This is true, however with creating applications with Django you are protected against most basic attacks. The ORM uses parameterized queries, all unsafe output is automatically escaped, Protection against CRLF injection within the framework and protection against HTTP response splitting.

The framework isn't fool proof (no one can protect developers from themselves). But I feel that Django does what it needs to do when it comes to protecting its users.

As long as you're using the tools provided, you're doing your due diligence. The framework provides a lot, and the ecosystem usually provides the rest.

The "last mile" is just making sure your code is using all those tools correctly.

Tools won't help when an integer overflow causes (for example) stock to be sold rather than bought.

And yet that example may only be the last item in a threat tree, which may have a zero-day vulnerability at its root.

Relying on tools or, in fact, any code you've not written yourself makes your system vulnerable. If you understand how an attacker might compromise a system (ref. STRIDE) you can mitigate.

> Relying on tools or, in fact, any code you've not written yourself makes your system vulnerable.

Writing everything yourself, as opposed to widely, community tested open-source alternatives, makes your system vulnerable.

Your example seems to be at the farthest possible end of the spectrum from what I'm talking about.

Not suggesting writing everything yourself. I'm suggesting that the use of third party applications, services, frameworks or components will increase the attack surface. Because you've not written that code yourself, there's value in understanding the attack vectors these components etc. present. Knowing those allows you to mitigate threats.

Maybe we come from different backgrounds. Using open source code that's been subject to lots of eyes and lots of use, e.g. a framework like Django, reduces the surface area, to me, because of the shared best-interest of fixing security problems. The key is staying up-to-date.

Not that you shouldn't understand the potential vectors against your site, or shouldn't read how to use these tools correctly, but a widely tested and used tool or framework, just like a widely researched crytpo algorithm, is better than one with no other eyes on it.

People forget how quick it can be to get the tools to do simple things like SQL Injection and XSS without even trying. They are free and EXTREMELY easy to get. Not covering those basic security flaws will allow any "script kiddies" to get into all of your data. Even still though, some of the more sophisticated attacks, like Social engineering, are not being made into tools that anyone that can use a computer can use. Its not so easy to make secure things because the hackers only need to be right once, you need to be right every time. Also remember, you're only secure as your weakest link.

It is really hard to prevent advanced attacks. I actually think that two-factor auth is a very simple and powerful way to prevent all sorts of attacks, including social engineering. It's a shame that he dismisses it as too advanced right out of the gate.

I like 2-factor auth, but I'm not sure I see what it has to do with XSS and SQLI.

It doesn't have anything to do with XSS or SQLI, quite right. But in his intro he dismisses two-factor auth as some sort of advanced security technique when in reality I think two-factor auth is a quite simple way to dramatically improve security.

Like I said elsewhere, that's a major cost/benefit calculation in terms of both real cost and user experience/conversion rate cost. If it makes sense for your app, do it, but it's not part of the basics, at least not yet.

I don't completely dismiss it, but it's a huge burden for users, especially those who aren't very tech savvy. I'd love non-optional 2-factor auth for my bank account, maybe that would really introduce it to non-geeks and start making it less of a burden.

Anything that makes engaging harder (2-factor auth, captchas, which I'll get to sometime next week) will cost conversions and engagement. You have to weigh those things realistically. Security doesn't exist in a vacuum where User Experience doesn't matter.

The thing that bothers me about semantics (do two-factor, or, use OAuth) is that so many people I've discussed security with can't tell me whether they should, and why they should.

Does the value of the asset merit the cost of the second factor (considering the 2factor is a per-user cost)?

While it's not as secure as an hardware token, you can get second-auth for free for any user with a more capable cellphone (e.g. a Nokia S60, iPhone, Android, BB, etc).

Google Authenticator is free for the user, and the algorithm used (TOTP/OATH - not to be confused with OAuth) is open and easy to implement: it's essentially just feeding the current unix time and a per-user secret to an HMAC-SHA1.

So the point was that two factors may not be required (security for security's sake is a waste of resource). But let's go with the cellphone thing for a minute. I'm assuming you'd use it to send some sort of OTP to the user.

Imagine the route that token takes - from your server across the internet to an SMS service (a channel you might secure using TLS/SSL).

From there to any one of an arbitrary number of network operators, again over the public internet. You've no control over this leg. From there the token travels through the network operator's network, to a switch, and then over the GSM network to the handset.

There are at least two places there where you can launch a man in the middle attack.

Which brings me back to the threat model - understanding the value of the asset you're protecting will tell you whether the cost [1] of such an authentication scheme is worth it. Oh, and the cellphone-based OTP is of course an additional asset this authentication scheme introduces.

[1] Cost is not just the cost/per SMS. It's also the cost of developing/aquiring the technology, and then maintaining it and the infrastructure that supports it.

Nope, the solution I posted doesn't use SMS - in fact, it's completely offline. You could have the phone in airplane mode.

It essentially generates a code based on a pre-shared secret and the current time.

As for the costs, as I said there's plenty of free client applications (Google Authenticator is just the most well known), and not only there are plenty of libraries that you can use on your server, as the RFC that details TOTP provides an implementation in less than 50 short lines of code (+ Java boilerplate); see http://tools.ietf.org/html/rfc6238

And you just need that, plus an extra field in your data store for each user (to store the secret) and a textbox in the login page.

I've not come across that one before, and... it looks really interesting. I'd argue that it's not completely offline because it requires time-sync, depending on the precision of the client. That assumes the validator is online and can re-sync at any time.

Using a phone is a great solution. Except when the app that requires TOTP authN is also on the phone. That's a shame.

Either way, thanks for positing the link, and clarifying. I learnt something today.

I'd argue that it's not completely offline because it requires time-sync, depending on the precision of the client. That assumes the validator is online and can re-sync at any time.

Well, it uses a 30 second window, so it can cope with small drifts; as long as the phone's RTC isn't broken, you should rarely need to re-sync.

I use it with a J2ME application on a Nokia S60 without an internet plan and it works fine.

That's why you make it optional for your users.

2-factor doesn't prevent your code from being swiss cheese, though. It helps prevent attacks on authentication. If you have a valid user, they can hammer on your swiss cheese code all day and eventually expose your database or worse.

Two-factor auth is like installing an electronic lock on your front door that uses voice recognition and a chipped key. It's only a good idea if the door itself isn't made out of cardboard.

what tool(s) can a web entrepreneur use to check if his site won't be hacked by script-kiddies?

Mastering the top 10 of the OWASP is important. Those are trivial but are important to keep in mind when working on the web. The next thing you can do is ensure that keep everything locked down and open up only what you need. This means that if you only need port 443 open on your server for people to access your API, thats the one you use. Multi Factor Auth is important for API's (I suggest OAuth). Other than that, keep your server monitored, and never EVER trust your users (in a security sense).

I'm going to assume you mean "What tools can a web entrepreneur use to check if his site can be hacked by script-kiddies". There are a multitude of static analysis and penetration testing tools out there, free and licensed. Fortify (Static analysis), HP Web Inspect and IBM AppScan (penetration testing) are just a couple easy(ish) to use tools. On the free side of things, BackTrack comes with a plethora of security tools one can use to assess your site.

Wow, they had to write their own code to do localization safely with regard to XSS. I'm surprised that's not already available off the shelf.

It's the weird combination of gettext, HTML, and user-supplied data that causes problems. But yeah, kind of surprising there isn't already something. That's why we moved the |fe filter up to jingo, as high and shared as we could.

CSRF seems to be missing from the "basics" section.

The CSRF section posts tomorrow morning. I wrote up the entire "Basics" section as a single post and it was of biblical proportions, so I broke it down to post over the next several days.

And now I put up the outline, at least, of what's coming over the next few days.

Reply on news.ycombinator.com