Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
ladies and gentlemen our next speaker is jacob kaplan moss koch btfl of Django previously worked at world online where Django was invented he's noted speaker on Django having keynoter Django con US and Europe and has presented at parson conferences around
the world today he's going to be talking about how to protect Python and web applications against the OWASP top 10 attacks please welcome Jacob Kaplan Moss all right hi everybody so just very briefly about me so you know who I am and that I'm at least
minimally qualified to talk about web security so I am the Coby DFL of Django I was one of the people who worked at the journal world where Django was invented and I've been involved in the project ever since and lately I've taken a new job as the
director of security at Heroku so if you are a Heroku user or want to talk about Heroku come come talk to me and that's pretty much the last I'm gonna say about my day job so let's talk about the web the web is is really really scary unfortunately
unfortunately when when you talk about security engineering the most basic mistakes can end up being catastrophic someone likened it to if you were building a bridge and the choice of a bolt if you used a bolt that was a few centimeters too short could cause
the entire bridge to collapse that's often what security engineering can feel like and and that's rather that's rather terrible it makes developing web applications scary as you learn more about just how insecure and just how terrible the web is
for keeping your stuff protected it it can be really it can be really frightening luckily we have Python and in particular we have some fantastic Python web frameworks I'm gonna talk about what I think of as sort of the primary Python web frameworks right
now pyramid flask and Django I think most people doing web development in Python are using one of these frameworks and if you're not I think you should obviously I know the most about Django because I'm deep most deeply involved in it I know the second
most about flask I use it fairly regularly I know the least about pyramid most of what I'm presenting about pyramid comes from reading documentation and trying things out although I've never built a through to production application and Pyramid only
toys so that'll give you an idea of where my where my knowledge holes might be I think I've gotten everything right and I've run it by a few people to check but if I am wrong please correct me okay so so what is this Oh wasp top-10 the title mentioned
so the OWASP is the open web application security program it's a consortium of security professionals of web security professionals who work to put together open free in both senses information about web security and they publish a number of documents
and resources from from penetration testing tutorial which is actually really fun and great to work through to methodologies and resources you can use to evaluate your own applications and and your own security issues to this which is what they call the top
ten they do a roughly bi-yearly survey every couple of years they do a survey of web vulnerabilities of reported vulnerabilities and web applications and try to look at what the most common issues are and and rank them now like every one of these sort of top
ten lists there are there are quibbles people who do this for a living might say oh I would really put CSRF a lot number eight or you know I'm not sure I would include insecure direct object references so hi that's that's fine that you know we
reasonable people can disagree about the top ten ah I find this as a good launching point for trying to evaluate where we are where our tools are so the goal of this talk is twofold for those who are new to web security I want to introduce briefly what each
of these points are explained in the broadest strokes what each of them is and and what a vulnerability looks like and what the results would be and explain to you how you can use one of these great frameworks to protect against this vulnerability for those
who are a little more experienced with Python or may be contributors to frameworks I want to kind of use this talk as a way of giving us collectively a scorecard not not Jango specifically not flask specifically but but the Python web world how do we the Python
community do against this top ten I'm gonna come back at the end and kind of look at everything we've seen and and give us a scorecard and I think it identifies some areas that we have to work so I'm speaking to two different audiences here if
you're new to this stuff I hope to give you some practical advice to make sure that the applications you develop are as secure as you can I hope to show you what will be easy and what will be hard and for those of you who actually work on these tools I
want you to pay a special attention where I talk about what's hard because that's where we should be focusing our effort and that's where we should be trying to do better so let's dive in so the top vulnerability and it has been every year
that a wasp has published their list is injection if you're an xkcd fan you're probably familiar with little Bobbie tables and what what sequel injection is so if you're if your last thing now you understand this bug but for those who don't
I'll try to explain it a little bit all of my slides all my examples use flasks because it's the smallest it's the easiest to to fit on the slide there's a very specific type of development slide driven development where you need to write code
that's small enough to fit on a conference slides flask is perfect for slide driven development so let's imagine we were writing a banking site and we want to display a list of transactions of your transaction so we might write a view like this we
get the we get the user name from a get variable we do a sequel statement and we render the transactions that we get from the sequel statement so let's think about what this might do let's walk through how how this this might work so I could I could
visit a URL in my browser life get transactions question mark user equals Jacob right and then we could imagine the application would generate this URL would just be like your transactions I'd click on it so if that happens it gets interpolated into the
string and so we get a nice sequel statement select from transactions where user equals Jacob no problem there are all my transactions okay but what if I pass in an argument like this and that's some gobbledygook there because of URL encoding but that's
basically the string quote or one equals one so if I pass that in when at once I do the string interpolation my sequel statement ends up like this select from transactions where user equals blank or one equals one and since one always equals one I get every
single transaction so now all of a sudden instead of logged in users just seeing their transactions now they see everyone's transaction so this is data leakage via sequel injection so that's that's bad right everyone's transactions everyone's
private data but it gets worse if I pass in a string like this and I'll let you figure out exactly how the encoding is going on there I end up with a sequel statement that looks like select star from actions where user equals empty string semicolon delete
from transactions that's really not good there's an interesting type of attack that that black hats have started doing lately well they will they will discover a data leakage vulnerability and they will download all of your data and then they will
use that same vulnerability to delete all your data and essentially hold your data hostage they'll ask you for $50,000 in return for returning your own data to you and if you didn't have good backups and let's face it if you are writing an application
that's vulnerable to sequel injection the chances that you also don't have good backups are reasonably high you end up having to shell out money to the very people who broke into your systems not not fun now this is sort of the most simple form of
sequel injection we're using it we're using a get header here it's clear that the data is coming from the user you know that this is the very basic in practice something like this wouldn't necessarily have to come necessarily from direct data
from the browser a lot of times sequel injection comes from what's called stored injection so when you signup for the bank and it asks for your user name that's where you might put quote or one equals one hence little Bobbie tables so we you might
think oh the user name is safe because it comes from my own database but you have to actually trace back through the string of where the data comes from so again broad strokes if you want to know more there's lots of resources out there starting with OWASP
about sequel injection but let's move on to what you can do about this because although this is the most dangerous vulnerability the one most likely to really really hurt if you've got it it's also the easiest to defend against in Python basically
if you're using Python and you're using web stuff please use an ORM I know that this is somewhat controversial there's this whole like what's what's the line oh RMS or the Vietnam of computer science and and there there are good reasons
to use Ross sequel but for most of your data work if you use an ORM you're among the other benefits you get you are completely protected against these problems so Django has the Django DB models the model backend and in both flask and pyramid the default
[ ... ]
Nota: se han omitido las otras 4.849 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.