Thank you all so much for coming to DjangoCon Story Hour. I'm really happy you could all join me today.

Today's story is Frog and Toad learn Django security. Frog and Toad are friends. One day, Frog came up to Toad and said, I have this great idea for a startup. I'll do all the businessy work, and you, Toad, can code all of it.

Doesn't that sound great? The startup is going to be called Bezos Books. It'll be a site for selling books. Authors can have a form where they put in book information. The book information will get put on a page, and people can come to our site and buy books that authors put up. I'm sure it'll be easy. I'm sure we'll make lots of money.

Now, Toad is a Django Toad, not a flask frog, and so he decides that he's going to make Bezos Books in Django, and he goes back to Toad and tells him this, and Toad says, that's great, but all of the other startup friends

that I have in the lily pond keep losing customers because of security exploits. Is Django secure? So Toad thinks about it, and he goes and does some reading, and he discovers that yes, within reason, Django is secure, and he goes to tell his friend Frog about it. The first thing he tells Frog about

is XXS, or cross-site scripting vulnerabilities. Now, Frog asks, what's a cross-site scripting vulnerability? And Toad says, I'm glad you asked, Frog. A cross-site scripting vulnerability is when someone who can put information into our site that we render to a page

puts in things to be rendered that are supposed to harm or affect the user in a way we don't want. So because we have a form where authors can put in book information, if they put in some nasty JavaScript, our users could lose their credit card information or have all sorts of secrets stolen, and that would be very bad.

Frog says, yes, that would be very bad, Toad. Does Django protect this from this? And Toad says, yes, Django does. If a user puts in something like a script tag, Django, when we render that to HTML, is going to escape the nasty characters in that script tag, or in that script tag.

And because Toad is a very clever Toad, he dug into the Django source code and saw exactly the function that is doing this. And Toad was surprised that it's actually a very simple function, a function that basically hasn't been changed since Simon Willison wrote it like a decade ago. What the very simple escaping function does

is look for characters that could be harmful and replace them with safe HTML entities. Toad is a very clever Toad, and so he found out where that function lives. And because he wanted a complete picture of how Django handles this rendering system, he learned that where escape is called is in nodes.

When the context is used to render a template, a tree of nodes is created to represent the HTML in that template. If a template should have something change about it because a variable has been put in, a aptly named variable node is created.

That variable node has a render method like all nodes in the Django DOM representation. It has a method called a conditional escape, which checks if it should escape the string, and if it does, it calls that escape function that Toad discovered earlier. Frog is very happy about this, and asks his friend Toad, but Toad, what if there are cases where we really

don't want things escaped? For some reason, we actually do want HTML on the page. Toad isn't sure about this. He thinks that's a bad idea for security, but he tells his friend Frog, well, we have these helpers called mark-safe and pipe-in and pipe-safe that will let us put HTML right into the page and have it rendered the way we expect, but we should be very careful

about using these, Frog. Frog nods sagely and says, yes, of course, we should be very careful about using these. The next thing that Toad tells Frog about is CSRF, or cross-site request forgeries, and the way he tells it is, Frog asks, what else does Django protect us from?

And Toad replies, well, Django tries to protect us from CSRF attacks. CSRF stands for cross-site request forgery, and it could cause our site to do things against the user's wishes. Here's an example. Say our site had a delete button for authors to delete their books. If that button was just a simple request against our site, and we didn't have CSRF configured correctly, some other site

could link to our site and trick authors into leading their books through that link. Frog says, whoo, that sounds bad, we don't wanna do that. Toad agrees, we don't wanna do that. And luckily, out of the box, Django tries to protect us from that by using CSRF view middleware.

Toad is a very clever Toad, so he digs into the source code and finds exactly where the CSRF view middleware is defined. Toad digs even deeper because he wants to have a whole picture of how the system works, and comes up with some clever pseudo code to explain to Frog what the CSRF system is doing. If the middleware detects that our request

is a post, it gets the CSRF token from the cookie that's on the request. It gets the CSRF middleware token from the request post data. And if they both match, then the request is accepted, and everything moves on. If they don't match, then the request is rejected, and the user gets an error.

Frog thinks this is amazing. He likes that their site is protected because he heard about some weird thing years ago where Google tried to helpfully preload links and ended up deleting a lot of blog posts. So he asks, this is great, Toad, but is there a way to get around it?

And Toad says, well, yes, again, we should be very careful about using these things, but there is CSRF exempt, which is a decorator that we can put around our views. And when we decorate our views this way, then we skip the CSRF protection in the middleware. Toad is a very clever Toad.

And he looks up exactly where that CSRF exempt decorator lives, and then plays around a bit with how he would use it for both function-based views and class-based views. He notices that for class-based views, he has to import a second method decorator, which strikes him as odd, but he moves on.

Appropriately, he now updates his pseudocode. If the request is a post and the view is not CSRF exempt, then we do everything else. Now, Frog and Toad were walking along as they said this, and they were ending their day enjoying some lovely,

lovely chocolate chip cookies back at Frog's house. And Toad said, you know, these cookies remind me, do you wanna know something interesting, Frog? And Frog said, yes, I would love to know something interesting, you are my friend. And Toad says, there's a special thing you can do with cookies where you can say

this cookie should be HTTP only, and therefore only be able to be read by the server. But the Django CSRF cookies aren't set that way. Isn't that interesting, Frog? Frog isn't exactly sure why that's interesting, but he nods along because he likes Toad, and Toad is doing all this work for him.

And Toad says, this is interesting because it means that JavaScript can read and affect the CSRF cookie that is set in the request, that is set in the browser. And Frog goes, well, that certainly is interesting. He's still not sure he gets it.

And Toad goes, and we asked some Django people why this might be, and the answer is for JavaScript forms, when you do that jquery.ajax, you need to set it up with the correct CSRF token, and you need to be able to read that CSRF token so it can't be set HTTP only.

Isn't that interesting, Frog? And Frog goes, yes, very interesting. What else do we need to be protected from? Next, Toad tells Frog about SQL I injections. And he says, these are really bad. These are so bad that if we're vulnerable to these,

we could lose everything. We could lose all our financial data, all of our user data. People could buy all the books they wanted. It would be horrible. Frog looks appropriately alarmed and says, are we protected from this? And Toad says, well, yes, yes, we are protected from this because Django does the right thing, which as it turns out is nothing.

All Django does is not screw up the barrier between code and data. When you make a query set, and you make a request against the database with the ORM, Django keeps the SQL logic separate from the data that is being collected with the SQL logic,

and passes them as two separate parts all the way to the database handler, and then the database handler does the escaping that is appropriate for that database. Django just has to not screw things up, and it doesn't. Frog goes, that's great. But I was talking to some analysts, and they said that sometimes they really need to get raw SQL into the database.

Toad isn't very certain about this, but he says, okay, if we actually need to do this, Django has some methods that can do this. There's the .extra method, there's the raw SQL, there's the .raw on managers, but we really shouldn't do this unless we're absolutely certain we want to be doing this. And Frog says, of course, Toad, we'll be perfectly safe.

The next thing that Toad tells Frog about is clickjacking. Clickjacking, Toad tells Frog, is particularly subtle. What people can do is wrap our entire page in an iframe on a different URL, and make it look like people are browsing our site

when really they're browsing somebody else's site. And if they're browsing somebody else's site with our site in an iframe, then when they enter their password into our site, that person could collect it. Isn't that awful? And Frog goes, yes, that's very awful. We can prevent that, right? And Toad says, yes. We can prevent that through the x-frame-options-middleware, which is also enabled by default on Django.

The x-frame-options-middleware, Toad learns, because he's a very clever Toad, lives in this particular location on GitHub, and makes sure that the browsers which respect it will only display the site if it's the same origin.

Of course, you can get around that with the x-frames-option-exempt decorator, and it only works in certain browsers, unfortunately. But it's a very good thing to do if you're worried about running an e-commerce site, like say, Bezos Books, where people could be trying to steal

your credit card information or passwords. Next, Toad tells Frog about host-header validation. Host-header validation works with click-jacking in a way to make sure that only the host that is supposed to be rendering the site can render this site.

Toad made the mistake very early on, as many Django developers do, of not setting the correct allowed hosts in his settings file before he deployed to production and got that lovely error that means that he spent 10 minutes Googling because he couldn't figure out why Django wasn't working. And the pseudocode looks something like this.

The request in the middleware, the middleware checks the request, checks the domain of the request, sees if it's an allowed host, and then proceeds. Otherwise, it raises an error. Finally, they get to passwords, and Toad is really excited about passwords, which is weird,

because nobody should be very excited about passwords. And Frog says, Toad, you're so excited about passwords. Why are you so excited about passwords? And Toad says, the reason I'm so excited about passwords is because what Django does is so cool. Django hashes passwords, which is common. All good web frameworks should hash passwords. But the way it hashes passwords and the way it does password upgrades is really nifty.

When it hashes your password on login, it checks this Django contrib auth hashes check password function. And if you have upgraded your hasher, it checks against the old hash, the password against the old hash to see if it should be a login. And if so, it automatically rehashes it

with the new algorithm. So you get automatic security upgrades as you're moving through the lifetime of your product. Isn't that amazing? Frog says, yes, that's amazing. That's so cool. And Toad smiles. So having gone through all that Frog, so all that Toad discovered, Frog asks Toad, that's all great,

really quite amazing, but what can we do to make this better? How can we improve the security of our Django site? Toad says, well, the first thing we can do is be constantly vigilant. All those things I talked about, all the ways to get around

the built-in Django security features, we should be doing everything we can to limit the use of those. One great way of doing this is having our code review tool automatically alert us when it detects things like CSRF exempt or pipe N or mark safe.

So that me especially as CTO, I am CTO, right? And Frog says, yes, yes, you're CTO. That me as CTO get alerted when somebody is using these very unsafe parts of Django. Additionally, we should be doing regular code reviews and we should be having tests to make sure that all of our security features are up to snuff.

We should also be doing regular security audits to make sure that our product can't be hacked into by people who aren't us. Frog says, that sounds like a lot of work. Are you sure we need to do all of that? And Toad says, yes, it's very important. If we don't do this and if we don't do this on a regular basis, we might be exposed and lose all of our customer's data. Frog looks suitably alarmed and says,

yes, that is very, very bad. The next thing that we could be doing, says Toad, is making sure our site is served over HTTPS. And luckily, Django makes this easier and easier all the time. You can serve cookies securely, you can set your settings to only allow secure URLs,

but it's very critical, especially since we're an e-commerce site, that we only use HTTPS on our site. So I know it's going to be a little bit more money to get the HTTPS certificate, Frog, but it is very worth it, I promise you. Do you want the government snooping in on what books our users are buying?

Frog thinks about it, thinks about the romances he's been buying recently and says, no, I don't want anybody knowing what I'm buying on our site. The next thing we could be doing, says Toad, is having a content security policy. A content security policy is another thing

that the browser respects that you set on your server and what it says is, hey, browser, please only allow content from these domains. And the browser says, well, you've told me to only allow content from these domains. I'm going to block hard anything that you tell me to block. But I will also, if you tell me to just log,

I will let you know when you are loading content from unauthorized domains, which is really great for Frog and Toad's site because it means they can allow certain HTML to be put in to load images from certain sites, but not allow images or links from other sites and block those at the CSP level

rather than having to write complicated rules for checking the HTML in the code. So Toad recommends to Frog, we must set a CSP policy. At the very least, we should set a logging policy so we know where our users are trying to access assets. But if we could, we should be trying to set a blocking policy so we don't allow anything

that we don't trust on our site. The next thing we could be doing, says Toad, is setting Django encrypted fields and using those to store confidential information like passwords or user credit card information or any other personally identifying information.

If we set this and set it with a key and come up with a good key management policy, which is unfortunately tricky all in its own right, then we can be reasonably certain that at least at rest, our users' data will be protected, which is very important. You understand it's important, right, Frog? And Frog says, yes, I understand it's important.

And Toad says, with Django encrypted fields protecting our data at rest and HTTPS protecting our data in transit, we now have a much tighter attack surface and it's much harder for our users' data to get leaked. The other thing we could do, which is fortunately now bundled

into a lot of later versions of Django, is use Django Secure and set some of the settings there to really tighten down any of the areas of Django that we haven't explicitly covered. And there's a great tool online, says Toad, called PonyCheckup, which will go over our entire site

and scan for common Django vulnerabilities. And I've heard, says Toad, that if we get 100% on our site on PonyCheckup, Eric will give us a sticker. Of course, there are lots of other resources in the community, one of which are talks

from previous Django cons, like Making Django Ridiculously Secure by Kelsey Gilmore Indus last year, but also her security talk from PyCon this year, which Toad very much encourages Frog to go watch. Having done all of this and having tried to firmly explain to Frog

all the vagaries of securing a Django site and everything that Django does and digging deep into the code examples to prove to himself that the Django security works the way it should, Toad goes and asks Frog, Frog, do you have any other questions? And Frog thinks about it and thinks about it

and says, I'm not sure I wanna run a startup anymore, but I definitely know a lot more about security. Thank you very much. As Adrian mentioned, my name is Philip James.

I am a senior software engineer at Eventbrite. If you're interested in hearing more about that, come talk to me. These slides are online. I am deliberately leaving time for questions. This story is an overview of everything that Django security is doing and some suggestions for making it better. The reason there isn't a ton more content in this talk

is because Django does a pretty great job out of the box trying to secure it. Having, as part of my job, had to do audits of other web frameworks and other web security tools, Django does it right. Some things that I didn't mention that are also super important and part of the reason I didn't mention them is because of my lightning talk.

Django has a session cookie. Sorry, no session cookie. Django has a secret key that if you caught my lightning talk, you may have seen that that secret key does a lot for you that you may not realize under the hood, like doing signed cookies, secure sessions, and password reset tokens. In the list of ways to make Django better,

if you have at any time in the entire lifecycle of your code base pushed your secret key to a repo and you are still using that secret key, please, please, please change it now, put it in an environment variable and never think about it again. We have probably way more time than I was intending for questions.

Sorry about that. But send complaints to Russell Keith McGee, russell at keith-mcgee.com. And I will open it up for questions this time. Hi. Hey, what recommendations do you have around packages or things that help with Django for things like denial of service and more sort of behavioral analysis

about things that aren't strictly, strictly dangerous but can be dangerous? Yeah, that's a great question. So I'm going to answer this question from two approaches. One is the approach of a lot of users are just hitting my site in some way.

And one is a lot of semi-legitimate users are just kind of overloading my site, right? I'm going to argue that the hey, a lot of users are hitting my site is firmly in the realm of something that Django should not be handling. That is the web server's job. Either you figure out a way to throw more boxes in front of it

or you use Varnish to do good caching if you don't have a lot of content changing on your pages. But if you are trying to do DDoS mitigation at the Django level, feel free to disagree with me. I think you've already lost. If you are having a lot of legitimate actions come through your site where people are, you think somebody who has a real user account

might be trying to heavily spam your site or try to break it through repetition, I heavily recommend rate limiting both on web flows and especially on API flows. A lot of API packages will build in some form of rate limiting right now, but it's also not that difficult to add. I don't remember if REST framework has rate limiting built in.

Tom's nodding, so yeah, you can do rate limiting at the API level. Did that answer your question? Yeah, thank you. Thank you. We're gonna go this way. So when using encrypted fields, what, do you have any tips, I know it could probably be a talk on its own, but do you have any tips for the key management policies? Key management is really hard.

It's turtles all the way down. My advice is two fold. One, make sure that it's something that your entire team is aware of. As in like, key management is hard, but often the reason key management is hard is because there's like one flaw that turns out to be a human flaw

where there was this back door that nobody knew about to get to the place where you're storing your keys. But that's the human side. On the technical side, I have never seen a strong argument against Google KeysR, and especially because there's not really anything out on the market publicly available that's better. I know some companies that have rolled their own solutions on top of KeysR to make that better,

but dig deep into Google KeysR and see if that would work for you. If you don't have dedicated security people on your team, key management is the kind of thing where it's probably worth hiring a security consultant because you really want to get it right, and you really want to get it right the first time. But you probably already knew that because why are you asking the question?

So my TLDR is use Google KeysR. It solves most of the problem. Over here. Hello. I have very specific question I'll try to explain. So we have Django project behind some front-end server over HTTPS. And I would like to use all these

SSL-related Django settings to secure it. But behind front-end server, we have reverse proxy server, which is over HTTP. And if I will enable all these HTTPS-only features, I will break reverse proxy. So what to do?

That's a great question. I would say that I think in your heart of hearts, you might already know the answer. And the answer is wherever your HTTPS is terminating is the last place that your server is going to see HTTPS, right?

And so if you have an HTTP remote proxy in the middle, does it really need to be HTTP or can you make it HTTPS? Yeah.

Okay, so unfortunately it's not so easy to use HTTPS for reverse proxy because we generate dev domain for it, which includes version and hash and stuff. Gotcha. So it's complex. It looks like that guy might have a solution.

I think I'm gonna encourage you to talk to him afterwards. It's not an area that I am an expert in, but it probably is possible. It's also, there's probably a hole in it somewhere if you try to configure it that way. Looks like you should talk to that guy. Okay, thanks. Hey, yeah, over there.

Hi. So you mentioned the use of Django encrypted fields and I was just wondering if you had any experience or opinion about doing the field level encryption in the application layer versus the database layer using something like MySQL has AES encrypt, Postgres has a PG encrypt, I think.

Aside from the concern about portability, do you have any experience or opinion on that? I don't have any experience doing things that way. My guess is if you can, my general philosophy would be that if you can get it working locally and you can specifically write tests that prove that it works locally,

then you're probably fine. I'm willing to bet there's probably someone in this room who may have done that, but I don't have any direct experience with it. Hi. Looks like that Micah's dead, but she's got one for you. Okay, so it's very nice that I can encrypt fields

in the database and I should do that probably in more cases than I do. Even emails are PII at some low level, anyway. But I'm also supposed to encrypt database passwords on the file system. I don't want to put them in settings, but I also don't want to use environment variables

because then it's clear text somewhere. This is a standard problem. Wish I could use Keyzar, but for government reasons, our development environment is Windows desktop and PyCrypto was hard enough. I don't want to compile Keyzar. So is there a way that I can use the Django secret key

that will be an environment variable anyway to decrypt other things that are in settings? Does your secret key need to be consistent? Are you still reliant on sessions and the normal authentication methods?

Does my secret key need to be consistent from server to server or over time? From server to server. Yes, I said CAS is less secure than using mod auth CAS and it really is. Sure, and the reason I ask is because the,

most of the things that secret key does in Django are things that are incredibly helpful and incredibly necessary if you are buying into the standard way that Django auth works. If you are using a completely different authentication method, then you're not as reliant on the secret key and you can just set the secret key to call out to random every time you load up a server.

If it doesn't need to be consistent, then you don't need to even set it in an environment variable. It's just there to run over time. But if you need consistency and you can't use PyCrypto and you can't use Keyzar. I can use PyCrypto. Oh, you can use PyCrypto, but it's a pain to recompile, right?

Right, that's it. Okay, but Keyzar is the one that I would recommend, and so man, that is a great question. And you don't want it in any sort of source control because you don't want it in plain text at all. I mean it. I mean what, I guess what I'm asking is what in the innards of Django, which I don't know as well as you do, would I call to encrypt, decrypt things

using the secret key or using any key? Oh, I see what you're saying. So in the innards of Django, the secret key is used basically in two functions. It's used to create salted hmax for things like the password reset token.

So that's not necessarily an encryption, that's just like creating a hash. And it is used for the secure cookie signer. Okay, so if you're not using secure cookies. So it's not there, yeah. Then you might be fine. It is a key that should be secure, so I could use it with pycrypto and that's my way forward probably.

So. Possibly. But maybe I should try and compile Keyzar. Maybe you should try and compile Keyzar. I recommend you talking to Marcus. Yeah, Marcus down here at the front. Y'all should connect. All right, question over here. Hi. Hi. Your talk covered a lot of things we should do to protect against known threats. Sure. What kind of defensive programming things

should we be doing to protect us against the unknown threats, the ones that may appear at some point but we would rather be safe when they come out rather than find them and have to hurry to fix our sites? That's a great question. I'm gonna cover the mic a bit because I'm gonna yell. Constant vigilance!

Seriously, if you're in a large enough company to have a group of coders who care about security, making sure that they are trying to review as much code as possible, there's no such thing as perfect security. You can't predict the threats that are going to come.

What you can do is make sure that you are following good security practices like sanitizing data when it comes in, thinking about how it renders when it goes out, and making sure that that is probably still going to be sane no matter what the exploit is. Because I think we're reaching a point where the exploits are in, we're finding more exploits in the browsers, we're finding some exploits in the servers.

There's a whole category of certificate exploits that is kind of outside the scope of what Django can do. Django assumes that by the time a request gets to it, that a lot of the SSL and certificate terminations already happened. If you want to ask what we do specifically, we have a group of security reviewers,

we have a group of PCI reviewers that look at different things because PCI comes with its own bundle of tricks. And we also make sure that we are in our chat, which happens to be Slack, subscribing to a lot of security feeds so as soon as the CVEs get announced, we know and we can get on top of it. And a lot of times, we find that because we've been doing security review, thinking about what's going in and what's coming out,

that we don't need to do much. And we also don't, Django has been looked at by so many eyes and reviewed so many times, that oftentimes the new security bugs that are coming out are in semi-obscure parts of Django that we weren't using already. So the answer to your question is constant vigilance,

but try to be aware of your attack surface. And that's why I really recommend people going and watching Kelsey Gilmer Innes' talk from last year, because she describes, think about your attack surface. Think about if somebody wanted to attack me, who's the most likely person to attack me? And what is their motivation? Where are they going to be coming from?

At Eventbrite, our attack service is manifold, but to go with the obvious case, people might want free tickets, right? So let's make sure that the everything around orders and everything around registration is really tight, so that people can't just like willy-nilly get a free ticket. But there are some places where

we may not need to focus as much. It was a roundabout answer. Sorry, did I kind of answer your question? It was great. I mean, really, I think, you know, expanding on all the other things that go with security rather than protect against this problem, because people who think about security and say, here's the five things I have to protect against,

now I'm done, meets the whole other side of perspective, which is there are any number of threats out there, think about this in a systemic way, rather than just one, two, three, four, five. And I'm gonna riff off what you said, which is to say that there are kind of two ways to think about security. One is the descriptive nomenclature way, where you try to like name every possible attack out there

and then come out with mitigation steps for rename. And then there's like the holistic strategy where it's like, well, we know these are common attack patterns. We know where the attack factors could be. Let's focus on like building skills that are for these specific patterns. I'm not a fan of the nomenclature specific model

of looking at security. I don't care what you call this exploit. I want general practices that will help me in the future. Okay, one final question and then we'll wrap up. Thanks for the talk. Are there any tools out there to check that my website, that I don't use like pipe safe in templates anywhere? So like, say that again.

Are there tools out there to try to brute force my site in terms of making sure that I don't use pipe safe in templates where I should not? CSF, CSRF exam, that's where I should not. That is a great question.

I don't know if it was a leading question. Maybe you were trying to suggest a tool. There's one that I actually saw that just came out yesterday called Brute XSS that is going to try, you feed it a URL and it's gonna try to do a bunch of brute XSS attacks against your site. What we do at Eventbrite is we do have auditors that try to do some of that for us.

We don't have a ton of automated tools to try to check for XSS because our site is very large and very old. And so what we do do is any time anybody is using anything that looks like, that even matches the characters safe or pipe N, we make sure a security reviewer

is right there looking at making sure that this isn't vulnerable. And the same for CSRF exempt. If it has CSRF in the name of the review, a security reviewer is going to have eyes on it and is going to have to approve it before it goes out. I'm sure there are tools out there. Feel free to tweet them at that hashtag and I'll retweet them and people can find them.

But I keep harping on the same thing of constant vigilance just like try to be as aware as possible of what your code base has. All right, Philip, if people have further questions for you, it sounds like tweeting at you is a good suggestion. Are you gonna be around during sprints? Are you open to folks just coming up to you in the hall and talking about this subject?

You're welcome to just come talk to me. I will be here with the sprints. I will be sprinting with the beware folk. Come get a coin, come talk to me about security. And yeah, I'm always happy to talk about more security stuff or to talk about frog and toad. If you do have feedback, you can give me the feedback directly or you can use the guidebook feedback form.

This was a bit of an experiment being more story-driven with the talk. I'm curious if people liked it or not. You don't have to tell me right now. I don't want you all shouting at me. But do leave me feedback. Tweet at me, send me email. I don't have my email up there. But you can tweet at me. You can even send me a DM. If you're bad, I'll block you. And that's it.

Thank you all so much. All right, thanks so much, Philip. If you would like more James family experiments, Nicole James around the corner right after this is giving a talk on beginner workshops.

So if you just can't get enough of the James family, go see her talk next.