Web App Security Best Practices (opens in new tab)

(coffeeonthekeyboard.com)

88 pointsjamessocol13y ago32 comments

32 comments

20 comments · 4 top-level

kirinan13y ago· 9 in thread

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.

stanleydrew13y ago

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.

tptacek13y ago

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

1 more reply

jamessocolOP13y ago

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.

Spearchucker13y ago

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

2 more replies

peterwwillis13y ago

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.

Joeri13y ago

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.

tucson13y ago

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

kirinan13y ago

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

woobles13y ago

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.

Spearchucker13y ago· 4 in thread

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.

jamessocolOP13y ago

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.

Joeri13y ago

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.

levigross13y ago

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.

jamessocolOP13y ago

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.

1 more reply

zeroonetwothree13y ago· 2 in thread

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

jamessocolOP13y ago

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.

jamessocolOP13y ago

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

bluesnowmonkey13y ago· 1 in thread

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.

jamessocolOP13y ago

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.

j / k navigate · click thread line to collapse

32 comments

20 comments · 4 top-level

kirinan13y ago· 9 in thread

stanleydrew13y ago

tptacek13y ago

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

1 more reply

jamessocolOP13y ago

Spearchucker13y ago

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

2 more replies

peterwwillis13y ago

Joeri13y ago

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.

tucson13y ago

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

kirinan13y ago

woobles13y ago

Spearchucker13y ago· 4 in thread

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.

jamessocolOP13y ago

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.

Joeri13y ago

levigross13y ago

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.

jamessocolOP13y ago

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.

1 more reply

zeroonetwothree13y ago· 2 in thread

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

jamessocolOP13y ago

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.

jamessocolOP13y ago

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

bluesnowmonkey13y ago· 1 in thread

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.

jamessocolOP13y ago

j / k navigate · click thread line to collapse