django-nyc-security - Coffee on the Keyboard

Mass Assignment - Security Part 10

NB: This is the tenth post in a series of posts on web application security. “Mass assignment”? That’s a Rails thing! GitHub was the recent, high-profile target of an “attack”—it wasn’t so much a vicious attack as a “hey you guys, this is serious” attack, really gray-hat

django-nyc-security

Intermission

I sincerely hope to start the Advanced section of the security series tomorrow or Wednesday, but it’s been a full and hectic weekend and I didn’t have as much time to write as I’d hoped. I still need to finish the first couple of posts and get

django

Stay Up to Date - Basic Security Part 9

NB: This is the ninth post in a series of posts on web application security. Rounding out this week is the last, but perhaps most important part of the basic security series: staying up to date. Keeping everything up-to-date is a pain. You have to follow the latest versions of

click-jacking

Click-Jacking and a little Phishing - Basic Security Part 8

NB: This is the eighth post in a series of posts on web application security. Click-jacking is a process of “stealing” clicks on your site, redirecting them to other places, either by using an XSS vector to replace the targets of links (or whole sections of the page) or by

django

Server Configuration - Basic Security Part 7

NB: This is the seventh post in a series of posts on web application security. Configuring a server correctly is both 1) hard and 2) critical. You’ve probably spent a bunch of time configuring Apache or nginx, or whatever your server of choice is, for performance. But have you

django

Session Fixation and Hijacking - Basic Security Part 6

NB: This is the sixth post in a series of posts on web application security. Don’t put session IDs in the URL. Django explicitly does not support this because it’s just dangerous. Use SSL and secure cookies. Use HttpOnly cookies. Is it really that easy? Yes and no.

access control

Access Control - Basic Security Part 5

NB: This is the fifth post in a series of posts on web application security. Proper access control is an absolutely key part of web app security and is easily overlooked—possibly because it’s so easy. In Django, to hide a link from someone, you just: 1. {% [if](http:

django

Injections, SQL and otherwise - Basic Security Part 4

NB: This is the fourth post in a series of posts on web application security. SQL Injection SQL injection is a vector that lets a user insert their own SQL into a statement sent to your database server. The typical example is: 1. "SELECT * FROM users WHERE username = ‘" + username + "’ AND

csrf

CSRF: Cross-Site Request Forgeries - Basic Security Part 3

NB: This is the third post in a series of posts on web application security. The quintessential example of a CSRF (sometimes pronounced “sea-surf”) is a bank that naively does transfers over a GET request without any other security: http://badbank.com/transfer?from=act1&to=act2&amt=

django

XSS: Cross-Site Scripting - Basic Security Part 2

NB: This is the second post in a series of posts on web application security. XSS covers a number of various attacks, but the common thread is that someone gets to execute code in the context of your web page and domain. Doing that, they can do all sorts of

django

Password Storage - Basic Security Part 1

NB-1: This is the first post in a series of posts on web application security. NB-2: Fred wrote a great post on password storage. You should read it. I’m assuming we’re talking about web apps, and most web apps have user accounts, and most of those have passwords.

django

Best Basic Security Practices (Especially with Django)

Or: Locking Your Doors This goes along with a talk I gave at Django-NYC in July 2012, but is meant to stand on its own. It is the first in a series of posts, because I realized it was too big for one. Security is proportional. Most apps don’t