Missing HTTP Security Headers - Bug Bounty Tips

Key Takeaways

i cannot believe that i would ever say this but the internet is full of hacking tutorials really nowadays it's not difficult to find some article tutorial or tool that tells you about possible security issues but this also somewhat has created a problem where we feel like any small thing can be a serious security vulnerability but of course not everything can be critical and serious so where is the line and where's the educational content that tells you chill it doesn't actually matter that much where is the balance in case you didn't know me and some other creators have been partnered with google to create video content for the google vulnerability rewards program so the google bugbounty program but we didn't make just more of the same hacking tutorials that you can find everywhere online we try to explain why google does not accept certain kind of reports simply speaking at google there were tons of skilled hackers who understand the impact of certain vulnerabilities and they always have a good reason why they decided they won't reward certain kind of reports but it's a very fine line between what is a vulnerability and what is not a vulnerability this is a difficult topic and you can argue about it a lot so we made videos where we try to explain google's position and in the video i'm going to share today i talk about various http security headers including cookie flags and coarse misconfiguration and i'm going to be a bit more critical about them as i said there's tons of content telling you about why they met up for security and of course that material is not wrong of course they exist for good reason but there's basically no content that tries to balance the sides a bit and so in this video i try to be like calm down chill the world is not gonna end if a site didn't use certain security headers also i believe when you consider at least for a moment that maybe they are not so serious it really helps to develop a deeper technical understanding about this topic and even if you watch the video and in the end you say i still believe this should be reported at least you have actually thought about the other side anyway two more things i wanted to mention about this video first of all this video was not meant to be an advertisement for google but of course it kinda is that's why i labeled it this way google paid for this video but not to be shown on here i know it sounds weird but it's important for me to mention this this video was produced for google to be embedded on their site it was not produced as an advertisement to be shown on this channel but i thought my video is a very good educational video i really like it myself and that's why i wanted to share it with my audience on here as well so i'm very curious if any of your opinions about http security headers has changed after watching this video so make sure to leave some angry comments at the end and second this video was made before i got my glasses so i guess i take them off now to make the transition into the main video less awkward [Music] when you are hunting for bugs you probably look at all the http requests and responses and they contain a lot of http headers the response headers are especially interesting as they can contain interesting information from the target for example it might tell you which web server is running other response headers are important for the functionality of a web page such as the content type telling the browser how to interpret the response or the content disposition header which tells the browser if a returned response should be just shown or be downloaded as a file but also some of these headers are so called http security headers and they can be important for security generally http response headers can be placed in two categories headers that can weaken the security if they are added and headers that strengthen security when they are added so the big question is now if a site does not set certain security headers is that a vulnerability online you find many guides on best practices on what headers to set or not set so if you identify such a header could this be reported to a bugbounty program let's learn more about http response headers for bugbounty to figure this out we have to look at a few security headers in detail to understand what exactly they are doing and only then we will be able to assess if it's a vulnerability when they are not set example 1 x-frame options the x-frame options http response header can be used to indicate whether or not a browser should be allowed to render the page in an iframe with the iframe html tag you can embed another website into your website and this could allow an attacker to perform a so-called click checking attack if you don't know what click checking is check out this article which also has a great video from recon less explaining it but they also explain why click checking is not a very serious vulnerability and why often it is not accepted for a bug bounty reward the thing is yes setting the xframe options header in the response to same origin or deny would prevent such an attack but that's not the only way you can protect your website from click checking maybe sounds dumb but when you simply have a website where there is no actual impact with click checking click checking makes no sense in that case it's safe as well does that make sense generally speaking very critical functionality on a site plus click checking can be a vulnerability then setting the xframe options header makes sense boring and less critical actions available on a website plus click checking doesn't matter that much setting the header in many cases doesn't hurt it probably adds a bit of protection but the missing header doesn't necessarily open you up to a text you have to understand that and then of course there are cases where the website wants to allow others to embed it for example on youtube when you click on share you copy an html snippet for embedding the video and it has an iframe tag so youtube wants you to be able to embed the content it's a feature and of course in that case they won't ever set the xframe options header so you can see it depends on the context of the website if it's important for this header to be set or not which means you shouldn't blindly follow best practice guides or scanners that tell you that the header is missing you need to understand if there is actual impact example two another important security header is the content security policy csp and csp is awesome because theoretically it can protect your website pretty much from any cross-site scripting attack and it even has more features beyond xss with csp you can also set the frame answers to none which kind of acts like setting the xframe options header so if csp could block xss wouldn't it be a very important header to set let's do an example let's go into the google backhunter site and have a look at their csp huh there is no csb there's this awesome tool from google engineers called csp evaluator and it can help you to assess a given policy in this case there's literally no policy so let's submit an empty text and the tool reports a high severity finding script source missing so is this a vulnerability in itself well as i said csp can protect websites from exercise attacks or other kind of attacks but because csp just protects it doesn't make it a fix for an issue if there is an xss csp doesn't fix it it could just block exploitation it's a defense in depth strategy so setting scripts or csp only matters in the context of an xss issue existing in the first place and that means missing csp header in itself is not really a vulnerability again it depends on how critical the website is if this protection is really important or doesn't matter example three let's have a look at another header hsts http strict transport security this really sounds like an important header to set but what exactly does it do it lets website tell browsers that it should only be accessed using https instead of using http for example the visitor types www.com or even justfu.com this creates an opportunity for a man-in-the-middle attack the http strict transport security header informs the browser that it should never load a site using http and should automatically convert all attempts to access the site using http to https requests instead this sounds very useful but then why is it considered an invalid report if a site from google is missing it well right below there is also this node the strict transport security header is ignored by the browser when your site is accessed using http this is because an attacker may intercept http connections and inject the header or remove it only when your site is accessed over https with no certificate errors the browser knows your site is https capable and will honor the strict transport security header so we already have this weird situation where the header is supposed to prevent users from loading the site with http but if the site hasn't been loaded yet the browser doesn't know about it and only honors it once the site was loaded securely once which of course is better than nothing but modern browsers do the same anyway for example when i visit liveoflow.com with an http url you can see that it tries to go to the http version but it was redirected to https now let me try to go to the http version again there is no http request going on we directly go to the https version all of that without an hsts header so as you can see hsts is not a silver bullet protection and browsers kind of mitigate it anyway but it's still generally recommended and especially together with the hsts preload list by the way a project by google it's good but you also see that it's a very known and popular header google knows about it which you can also see here in the article internally we are already well aware of our hsts posture and are actively working on adding hsts support to additional endpoints so it's a known issue to them next example course now we just talked about headers that add security to a site but there are also headers that could weaken the security of a site and a very typical report is course misconfiguration generally websites are protected by the same origin policy this means javascript code on for example liveoverflow.com can not send http requests to gmail and leak your emails the browser says no i won't allow liveoflow.com to access your gmail but a web server can use course headers cross-origin resource sharing to actually allow another website to send requests to itself and at first sight the seems to weaken the same origin policy which it does so why would anybody do that is there any negative security impact it of course depends let's imagine two websites one website uses cookie authentication there is a session cookie and the other website has token authentication for each request the code on the side adds an authentication header with a token both websites have very permissive course settings allowing arbitrary origins to make requests and even allow setting credentials is this a security issue in both cases only for one of them this course setting is actually an issue setting access control allow credentials tells the browser that it can add the session cook to the request so in this case the request would be authenticated as the current user and the security impact of this is similar to cross site request forgery csrf or even xss in this case you can perform authenticated requests as the current users and even read the response this is really bad and definitely a security issue but for the other website with token authentication there is no session cookie the browser doesn't set the authorization header for you so this request would not be authenticated as the user thus there is no csrf like attack possible as you can see context matters and you have to understand if there really is any impact and you cannot blindly report an open misconfigured course so keep in mind that course exists for good reasons many websites from google allow course requests because it's meant as an open api that is intended to be accessed from other origins so you always need to be sure that there is really security impact and the last example cookie http only before we have a summary of this video i briefly wanted to mention the http only cookie flag as well cookies are technically part of the headers so it fits into this video and the setting causes cookies to only be transmitted in http request and cannot be read from javascript it often is considered a defense against xss attacks stealing cookies but it's rather ineffective yes the cookie cannot be stolen so you as the attacker cannot perform request as a user directly but when you have xss the xss can just send the requests you want for you and those requests will be authenticated so it's really not that big of a deal and on top of that not every cookie is really used for authentication cookies are a great way to store a bit of information about a user and the app they don't really have any security relevance so if they are missing the http only flag or even the secure flag it doesn't matter so as always you have to really understand what a cookie is for and if there is really any impact so let's summarize what we learned there's a reason these security headers exist they do really good things and can protect an application from exploiting other vulnerabilities but they're missing doesn't necessarily create a vulnerability most websites probably could benefit from setting some of them but it depends a lot on the context you have to understand the functionality of a website to judge if there is a significant risk and if it even makes sense to set them because maybe there is an intended feature why they don't want it for example youtube embedded videos that deliberately don't want to set the xframe options you cannot blindly copy and paste the result of a scanner reporting that headers are missing so make sure to read and understand what certain headers do and make sure you understand if it makes sense for an app to add it or not does it really do much for security or are maybe developer resources better invested into working on other things when it comes to bug bounty always think about the realistic impact [Music] you