PyCon 2014

Cómo mejorar fácilmente la seguridad de tu sitio web

Dan Callahan  · 




Extracto de la transcripción automática del vídeo realizada por YouTube.

hello everyone and welcome to the second session of the security track this afternoon it is my pleasure to introduce Dan Callahan from Mozilla we'll be talking to you about quick wins for better website security a big hand thank you so what I want to do

with this talk is give you a very broad overview of techniques some which are really rather underutilized that with minimal effort you can use to dramatically improve your site security I'm going to be talking about security in three domains when you're

transmitting content when you're rendering content and when you're storing content uploaded by users or generated otherwise the most important thing you can do to improve your website security when transmitting data is to use ssl this has been a pretty

rough year for SSL in 2014 Apple had the the double go to fail bug which wouldn't be possible in Python because we have significant white space but unfortunately have not yet taken over the world this short circuited certificate validation on iOS and OS

10 devices and then just last week a bug in openssl referred to as heartbleed was disclosed which leaked private key material for several million sites on the internet which is also not an ideal situation if you're running any sort of sight over SSL please

go update your cert and revoke the old one but seriously you need to use SSL because SSL is the only widely deployed technology the only tool we have to protect data in transit from eavesdroppers and when I say that what I mean is when you normally go to a

website say your bank calm when you type that into your browser's address bar and hit return the first thing your browser does is presume that you mean to it attempt to connect to the insecure the HTTP only version of that site the HTTP colon slash slash

bank com site and it sends a request that says hey bank give me your index page and the server will usually respond if it's a bank or some other secure institution like hacker news or github with a redirect that says actually please go and talk to me on

port 443 on my HTTPS my secure my ssl version of my sight so your browser will resubmit the same request over SSL get a response back and you'll actually have content you're off to the races of course with each request your browser is going to send

cookies as browsers do for that domain fortunately by using SSL you're protected in case sorry I messed up that transition imagine an attacker in between you and your bank if you're using SSL you're protected in case that attacker is listening

to your communication because everything over the SSL secured link is encrypted the attacker without knowledge of your servers keys which heartbleed I know has no idea what you're actually transmitting to that site or what the response is but that first

round trip that connection to the HTTP the insecure version of the site is still visible to anyone that's listening anyone that's on the same network or in between you and the site you're trying to reach and with that request came session cookies

normally when you log into a website looks like we'll set a cookie that identifies you be some sort of long may be assigned string and a cookie and if anyone can see that cookie and can copy it they can impersonate you on that site because that's what

the site is going to use to identify you for subsequent requests a little while ago someone actually weaponized this in Firefox and create an extension called firesheep that gave you a really beautiful sidebar with a big start capturing button when you click

that button it would listen on the local network and look for any insecure requests that had a cookie header with a session cookie and it would give you this wonderful really easy-to-use menu of all of the accounts that you could just hijack by cloning that

cookie and so with one click you could be logged the facebook or twitter or github as someone else if you had seen a request that they sent over HTTP before they got redirected to the ssl version of the site so using SSL alone isn't enough because there

is still that initial insecure request and the way you can mitigate that is by using secure cookies so normally the way a browser will will accept a cookie from a website is in the responses there will be a header called set cookie which has a key equals value

parameter and if you append to the end of that header semicolon space secure you can instruct the browser to only transmit that site or that cookie back to the site if it's communicating over a secure link so the attacker would still be able to see that

[ ... ]

Nota: se han omitido las otras 2.210 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.