CSRF Tutorial - A Guide to Better Understand and Defend Against Cross-Site Request Forgery (CSRF)

all right so today we're going to be talking about cross-site request forgery which is a security specific or security related topic oh and it's sometimes called by the way it goes by a lot of names so you'll see CSRF xsrf sometimes people put on sassy surf session writing there's a few others so just be aware but this is the kind of the official name for it so why should we learn this or be aware of it Oh wasp is a international organization which basically tries to provide security guidelines for developers around the world and every few years they publish basically like a top ten security concerns the 2017 one was actually supposed to be approved I think one month ago or so so and I think this is actually a draft but it should be approved very soon they had one in 2013 that was pretty similar a couple things shuffled around but for the most part you'll see that we have some pretty common security exploits or potential vectors that attackers can use against developers that have been with us for some time now so there's three that are pretty well-known which are sequel injection or injection generally which is actual number one on here cross-site scripting or XSS which is number three and then cross-site request forgery does come in at eight here so it's definitely not an important one but also it doesn't seem to be very well known or at least well understood by developers so most developers have maybe heard of it but they tend to be a little more familiar with the inner workings of cross-site scripting and injection but not as much about cross-site request forgery there seems to be a lot of confusion about it and then lastly it's has affected a lot of companies and applications it's actually also an interesting attack in the sense that it's very likely that it's highly highly underreported because the as we'll see when we get a little further in the discussion the attack looks very authentic and it really does look like it originates from the user so it has the users IP address as well as a lot of other information like their cookie and so it's it's pretty nuanced sometimes to distinguish between a legitimate request a false one or a forged one which is actually why this is security exploit to begin with but you can see on there it's affected Netflix YouTube Mew torrent ING Direct this is just to name a few even Google also has been a slightly different kind of specific version called log and CSRF we probably not have time to cover that today but certainly there have been many people impacted by it so quick example what exactly would this look like this is a very basic and simple example there's actually two quick versions here so the first one is a get request so we're going to send basically a get request to some banks website and you can see there's some query strings or parameters on the end of that you are elder and basically we are trying to fraudulently move some money from one person's account to another person's account and if this website was vulnerable to CSRF all that you would need to do is manage a site that you could get someone to visit some type of malicious web site that has this a tag or link on it that tag if the person were to click that link would then send that get request to the bank and because it's the user who's actually doing the clicking it's actually coming from their computer and their cookies also stored on their computer so the website actually gets confused and think this is legitimate claim from the user and then you're out ten thousand or how many dollars so pretty dangerous and then the second version is oh and in addition to an a check by the way you could use an image tag so either one of those would work for post it gets slightly more complicated but it's definitely still possible to do instead of an image or a tag you'd have to use something like a form but you could of course hide the form and put the action as the target URL and then again embed some of those parameters in the input and then also the user actually wouldn't even have to hit the submit on your kind of fake form on your website because you could on the loading of the website you may be able to run a script which submits the form as soon as the person comes to your what website so pretty pretty scary stuff a quick definition from a wasp again basically it's an attack that it makes an end-user execute some type of action that they didn't mean to do it wasn't supposed to be authenticated by them but because of some trickery that's going on maybe a help of a little social engineering like sending someone a message with like a link that goes to some malicious web site that's typically how something like this can happen so some more specific details the type of the attack is called the confused deputy deputy it's all that means is that's kind of a broad class of attacks where a confused deputy which in this case would be the browser mistakes someone for basically someone else or something else and grants them privileges that they shouldn't have so it's actually kind of a specific type of privilege escalation and the way the way this bug works you're the reason it exists that I should say is that it basically hijacks the inherent browser functionality of automatically sending cookies to any domain that you currently have an active cookie for and also some aspects of HTTP specification regarding cross-origin requests so here's a really quick diagram that I got from a great blog post I can provide that at the end as well but basically this is how it would look you go to an attackers website and they serve you up some type of HTML and then in that HTML in the background it's hidden from the user but it actually sends a request has your computer sent a request to some other site they think you might happen to be logged in at right now they'll just guess so maybe a bank or Facebook or whatever some some website and your cookie will your browser will just say ok we're sending requested this domain so send along our cookie as well and then this is how you kind of get this attack to work it should be pointed out and I think this is kind of a point of a confusion that the attacker doesn't see the response data so it's only used for state changing requests and not reading of your information so they might like update your mailing address or they may be able to like update your password or do all kinds of things but they can't just read the information typically from that's coming back but that being said and I'll touch on this again at the end that's actually not true if your site has any single vulnerability at that domain of an XSS type so yeah again very you got to be very careful to watch out for multiple security flaws and not just the srf so how do we get here of course we want users to be able to log in and to do that they provide a username and password typically they can also provide a token in some instances but let's say username and password we of course don't want the user to have to supplied it on every page we need to kind of remember for some amount of time let's say 10 15 minutes however long they're using our site that they're currently authenticated and logged in as the person who we just saw visit our site because HTTP works in a very stateless way so the the client and server don't have a consistent knowledge of what's going on it's kind of just like a pinging of messages back and forth so obviously many web sites want to use this type of login functionality so cookies were kind of invented or one of the reasons they're commonly used is for this functionalities to basically put like session information on a cookie another reason is relaxed origin policies so there is somewhat newer specification called cores or cross-origin resource sharing I believe it is but basically that helps govern XML HTTP requests which are across origin nature because traditionally those were governed by same origin meaning you weren't allowed to use an AJAX or fetch request to another origin if it wasn't your own so persistent authentication was a problem just referring to how kind of how do we go about solving that problem right so there's basically you have one of two options the first of which is kind of the classic or more traditional approach maybe which is you store some kind of and of course by the way a lot of these values are encrypted and hashed and so on so I'm not even covering that we don't have time to discuss all of that but the session ID that you create for this user can be stored on a server and so when the when a user comes to your website they send you their username and password you send them this session ID back and then and you tell their browser to set that in a cookie so now your browser has this cookie information with your session ID and now every time your browser goes to that site it's and if it has a cookie for it it will send a cookie along with all of its following or subsequent subsequent requests this is definitely one approach you can use you'll typically want to use a flag on the cookie called HTTP only that prevents the frontside code from reading or writing to that cookie header information so it's not able to access or kind of play with that session ID information and so it's not vulnerable to cross-site scripting attacks but it would still be vulnerable to cross-site request forgery which so we're discussing today the other option you have is to store session information on the client-side that has some pros and constitute as well that is actually no longer subject or acceptable to cross-site request forgery so I should clarify that CSRF is specific to cookies so if you're not using cookies to create a session or authenticate your user then actually you don't need as far as I'm aware to be concerned as much with CSRF but you the downside is you are so vulnerable now to XSS which means if you have any cross-site scripting vulnerabilities and attack or may be able to see a user session information in the browser so really quick some inadequate mitigation strategies that people have thought up in the past first one is referer header x' so sometimes people will think oh well this request is coming from the users computer but we can still see that it's this malicious website that's reaching out to us for this for requesting some source an image or a script or whatever it happens to be so let's check where this is being referred from the problem with that is there's actually not a very consistent implementation of refers a lot of browsers or proxies will just strip away refer information for privacy reasons so it's not something you can consistently rely upon that it will be there you're gonna get a lot of false positives in other words if you try to enforce that another one is HTTP verbs as we saw even though if your site allows get requests that are that are not idempotent that's obviously very bad design and makes you a little more vulnerable to this but even if you make sure all your requests that are item potent are posts you are still vulnerable to CSRF because again someone could use a form instead of an image resource to kind of attack the website and lastly URL rewriting would be putting the session ID in the URL that technically may be safe in certain situations but it's generally frowned upon because of course if that URL gets exposed in any way kind of in transit somehow or in some other manner their information would be compromised so what are actual legitimate mitigation strategies for CSRF one is real authentic ation so that one is basically just proved to me again that you're actually who you say you are we one of the early things I said was it would be annoying to user to have to submit user name and password at every single screen that's true but if they're doing something that's pretty dangerous or has a really big impact like I'm trying to transfer money out of my account or I'm trying to delete my account or something high level like that it wouldn't be as big of a nuisance on those types of requests to say you know what go ahead and enter your username and password again now or as long as it's when we again de nuff time to go into the details of this but if it's securely done you can do something like a CAPTCHA which is also a little bit harder for an attacker to request since they're not using that user's browser but probably the go-to method is actually to make unique form tokens so any form or link you have on your site you should have also these uniquely generated tokens that actually need to be sent it's maybe a little annoying to keep track of everything and implement but maybe sent on every post put or delete request and then you include that token in both the cookie header and the body of the message so that even if an attacker it can act as an imposter and has your cookie in the headers they will not be able to access the code that was running in the browser at the time so again unless you have an XSS vulnerability but assuming that's not the case they will not be able to read that secret token that was a value on some form let's say so they won't be able to impersonate you anymore and then you'll be able to get around CSRF lastly I would say just know your libraries so of course you know we're we're gonna use all kinds of libraries and frameworks as well to set websites up so there and Oh many of them we need to work with node Express and sessions and so on passport there's many of them out there but just definitely read the documentation and be aware of what the library is handling for you and what it's not because if it's not howling CSRF for you and you're not thinking about it then there's a very good chance that you could be vulnerable okay are there any questions awesome thanks so much for listening guys [Applause]

Channel: Fullstack Academy

Views: 75,551

Keywords: CSRF, CSRF attack, Cross-Site Request Forgery, defend against Cross-Site Request Forgery, cybersecurity

Id: 13QPmRuhbhU

Length: 14min 3sec (843 seconds)

Published: Fri Sep 29 2017