Frog and Toad Learn About Django Security

0 0

thank you all so much for coming to Jango Kahn's story our 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 business II work and you toad can code all of it doesn't that sound great the startup is going to be called besos books it'll be a site for selling books authors can have a forum 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 pesos 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 on to our 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 forum where authors can put in book information if they put it 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 us from this and toad says yes dango does if the user puts in something like a script tag Django when we render that to HTML is going to escape the nasty characters in that strip tag or in that script tag and because to--it 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 and 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 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 rip 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 toe it 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 n 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 knowledge say Julian 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 frogs ass what else is 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 users 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 until eating their books to that link frog says whoo that sounds bad we don't want to do that toad agrees we don't want to do that and luckily out of the box Django tries to protect us from that by using CR SCR CSRF view middleware toad is a very clever toad so he digs into the source code and finds exactly where the CSRF hew middleware is defined Toyota digs even deeper because he wants to have a whole picture of how the system works and comes up with some clever pseudocode to explain to frog what the CSRF system is doing if the middleware detects that a 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 and 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 so it 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 you notice is 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 pseudo code if the request is a post and the view is not CSRF exempt then we do everything else now they were 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 frogs house and toad said you know these cookies remind me do you want to know something interesting frog and frog said yes I would love to know something interesting you are my friend and tow it 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 knows along because he likes toad and toadette is doing all this work for him and toad says this is interesting because it means that javascript can read and effect 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 sequel 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 sequel logic separate from the data that is being collected with the sequel 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 like raw sequel 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 dot extra method there's the raw sequel there's the dot 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 will be perfectly safe the next thing that toad tells frog about is clickjacking clickjacking Toto strong 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 and 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 how we can prevent that right and so it says yes we can prevent that through the X frame options middleware which is also enabled by default on Django the X frames option the X frame options middleware tolerance because he's a very clever tone lives in this particular location on github and makes sure that the browser's would 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 howís header validation works with clickjacking 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 requests in in the middle where 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 two 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 pastors 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 Goodwyn 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 pardon 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 - it 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 and 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 your CTL 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 until it 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 customers 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 you to only allow secure URLs but it's very critical especially since we're an e-commerce site that we only use HTTP 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 are 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 load-count it allow a 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 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 - 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 l in its own right then we can be reasonably certain that at least at rest our data our user's 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 HTTP 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 pony check up which will go over our entire site and scan for common Django vulnerabilities and I've heard it says toad that if we get a hundred percent on our site on pony check up 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 in his last year but also her security talk from Pike on 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 things about it and says I'm not sure I want to run a startup anymore but I definitely know a lot more about security so thank you very much as AJ mentioned my name is Phillip 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 was supposed to be 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 kind of audits of other web frameworks and other web security tools yet Django does it right some things that I didn't mention that are also super important and far the reason I didn't mention them is because my lightning talk Django has a session cookie sorry no session cookie Django has a secret key that if you cut 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 assigned cookies secure sessions and password reset tokens so if you in the list of things of ways to make Django better if you have at any time in the entire lifecycle of your codebase push to our secret key to a repo and you are still using the secret key please please please change it now put in an environment variable and never think about it again I we have probably way more time than I was intending for questions sorry about that but you know send complaints to Russell Keith McGee at Russell at Keith - McGee calm and I will open it up for questions this time hi what recommendations do you have around packages or things that help with Jango 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 servers 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 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 like people are you think somebody who has a real user account might be trying to like heavily spam your site or try to break it through repetition i heavily recommend rate limiting both on like web flows and on 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 rest framework has rate limiting built in Tom's nodding so yeah you can do rate limiting at the API level but then that's your question yeah thank you thank you go this way so when using encrypted fields what do you have any tips I know it probably be a talk on its own but you have any tips for the key management policies key management is really hard it's Turtles all the way down my advice is twofold one make sure that it's something that your entire team is aware of isn't 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 backdoor 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 keys are 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 keys are to make that better but dig deep into Google keys are and should 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 I might eel the artists use Google keys are it solves most of the problem yeah over here hello I have a very specific question I'll try to explain so we have Django project behind some front-end server over HTTP and I'd like to use all this SS SSL rate related Django settings to secure it but behind front-end server we have a reverse proxy server which is over HTTP and if I will enable all these HTTP only features I will break reverse proxy so what to do that's a great question I would say that you I think in your heart of hearts you might already know the answer and the answer is wherever if you're wherever your HTTP 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 HTTP right yeah okay so unfortunately it's not so easy to use HTTP for reverse proxy because we generate they have domain for it which includes version and hash and stuff 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 my 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 hi so you mentioned the use of django encrypted fields and i was just wondering if you had any experience or opinion about doing a field level encryption in the application layer versus the database layer using something like my sequel has AES and crypt Postgres has a PG crib and I think aside from the concern about portability you know 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 mic is dead but she's got one for you okay so 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 our PII at some low level level right 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 keys are but for government reasons our development environment is Windows desktop and PI crypto was hard enough I don't want to compile cookies are so is there a way that I can use the Jango secret key that will be an environment variable any way to decrypt other things that are in settings does your in does your secret key need to be consistent or you still reliant on sessions and the normal authentication methods does my secret key need to be consistent from server to server or overtime from server to server yes I said Cass is less secure than using mod off-gas and it really is sure the most of the things secret key does and Django are things that are incredibly helpful and incredibly necessary if you are into the standard way that Django off works if you are using a completely different authentication method then you're not as relying on the secret key and you can just set the secret key to like you know call out to random every time you load up a server right if it doesn't need to be consistent then you don't need to even set it an environment variable it's just like there to run over time but if you need consistency and you can't use pi crypto and you can't use keys are I can use PI crypto you can't you - oh but it's a pain to recompile right right that's it okay but keys are is the one that I would recommend so man that is a great question and you don't want to in any sort of source control because you don't want to in plain text at all I mean I mean what what I guess what I'm asking is what in the innards of Django which I don't know as well as you do Oh 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 H max for things like the password reset token so it'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 not cookies so it's not there yeah then you might lion it is a key that should be secure so I could use it with PI crypto and that's my way forward probably so possibly but I think the API should try and compile keys are maybe you're talking about keys are I recommend you talking to Marcus yeah Marcus it's down here at the front y'all should connect all right question I rear I your talk covered a lot of things we should do to protect against known for its 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 may have to hurry to fix our science that's a great question I'm gonna cover the mic a bit because I'm gonna yell constant vigilance seriously you if you're an allergic accompany to have a like a group of coders who care about security making sure that they are trying to review as much code as possible you 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 like 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 termination has 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 Seavey's 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 you know the answer to your question is constant vigilance but B try to be aware of your attack surface and that's why I really recommend people going and watching Kelsey Gilmerton hisses 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 I 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 it was great I mean really I think you know expanding on all the other things that go with security rather than pretty protected here's this problem because people who think about security and say here's the five things I have to protect against now I'm done right the whole other side of the perspective which is there are any number of threats out there think about dinner this in a systemic way rather than just one two three four five and I'm a rip off what you said which is they 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 every name and then 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 vectors 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 are any tools out there to check that my website debit that I don't use like type safe in templates anywhere so like say that again other - it's out there out there to root for to try to prove almost my site in terms of making sure that I don't use pipe safe in templates where I should not CSF CSRF except 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 thought 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 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 anytime anybody is using anything that looks like that even like matches the characters safe or pipe n we make sure a security reviewer is right there looking at making sure that like this isn't vulnerable and the same for CSRF exempt right like 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 codebase has all right Philip if people will have further questions for you it sounds like tweeting at you as a good suggestion are you gonna be around during Sprint's are you open to folks just coming up to you in the hall and talking about this subject you're welcome there just come talk to me and I will be here with Sprint's 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 oh if you do have feedback you can like be 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 tell me right now I don't want you all like 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 for what if you would like more James family experiments Nicole James around the corner right after this is giving a talk on beginner workshops so you just can't get enough of the James family go see here workshop or her talk next