jamessocol

Honestly, "easy to overlook" is why I wrote a checklist for basics. CYA, then get to the advanced stuff.

We keep making more junior devs. It's important to drown out the w3schools and bad practices with good practices, so when they look up how to do it, they learn the right way.

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.

For click-jacking, the easiest thing to do is to set the X-Frame-Options header, but I'll get to that. And it doesn't help IE <= 7, so you need to weigh cost/benefit and your user base there.

And we'll get to session hijacking and why your session cookies in particular should always be HttpOnly and preferably secure.

I updated the post to point this out.

Hopefully you're taking steps to prevent both. But yes, closing the CSRF window and leaving the XSS door open would largely defeat the purpose of CSRF protections.

Ugh, I really need to create a lighter-weight theme. Sorry about that.

> In order to issue a POST request to siteA from the evil page, the attacker only has to submit a crafted POST form using an iframe.

Yes, but requiring POST for anything that changes anything (especially bank transfers) is a best practice anyway, for how all actors involved understand HTTP verbs, and reduces the surface area of attack.

You can create a POST with an iframe, but you can create a GET with an image tag: `<img src="http://mybank.com/transfer?...>`

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.

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

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.

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

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.

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.

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.

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.

I added that in because I thought about it and realized it was true, and it kind of surprised me, too. I get asked for the URL at the end sometimes, or to put that back up or email it out, but never the slides.

Which I personally take as evidence that I'm either a) writing slides the way I want to, or b) writing really bad slides.

If your slides are like this, sure, it'd need to be a multi-post series or an ebook (though, ebook might not be a bad option) or something like how Seth Godin presented his iconic "Really Bad Powerpoint": http://www.sethgodin.com/freeprize/reallybad-1.pdf

..edit: I like Markdown too much.

Speaker notes are definitely one option (as is the video mentioned in other comments) but I feel like they're a lazy/weak way of telling the story, compared to actually writing a blog post about the same topic.

That is an awesome idea, I had missed that post of Zach's--which I count as a personal failure.