
Web App Security Best Practices - jamessocol
http://coffeeonthekeyboard.com/best-basic-security-practices-especially-with-django-697/
======
Spearchucker
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.

~~~
levigross
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.

~~~
jamessocol
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.

~~~
Spearchucker
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.

~~~
jamessocol
> 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.

~~~
Spearchucker
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.

~~~
jamessocol
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.

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

~~~
stanleydrew
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.

~~~
Spearchucker
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)?

~~~
icebraining
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.

~~~
Spearchucker
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.

~~~
icebraining
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.

~~~
Spearchucker
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.

~~~
icebraining
_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.

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

~~~
jamessocol
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.

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

~~~
jamessocol
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.

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

