Comment by Spearchucker | Hacker News Reader

Comment by Spearchucker | Hacker News Reader

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.

Reply on news.ycombinator.com