You know what I absolutely love? The sheer idea, that he can sit at home, with a shirt that wasn't ironed for the google video. I am not saying he didn't try - it's just the audience more focused on the content than the creator. I don't know how many will share the thought with me, but here it is. Good stuff.
I think a large part, if not the vast majority of the audience this video is intended for are likely sitting at home wearing a shirt that was not ironed.
This is the curse of being familiar with the content(aka being 1337 h4ck3r), you start to notice things that generaly you would and that would make the video a little bit better.
Finally some browser security; this is the stuff that really needs to be taught, it’s practical and real world content. Keep these kind of videos up man.
This seems to really boil down to: "if you can't accurately and specifically articulate how something can be exploited, it's likely not actually vulnerable"
@@LiveOverflow oh, no, thanks, but I only except payments in high quality cybersecurity videos, if that's cool.. so yea, I'm gonna be needing a couple of these instead, ty
@@TheJobCompany yeah apps these days are never getting it right. Same with speech recognition, its going to get me locked up one day for printing out the wrong words.
This is really crucial to understand that absence of a particular header doesn't mean the web application is vulnerable. Instead one should try to figure out how the absence of that header impacts the application in general or maybe chain that impact to find a realistic security flaw.
Thank you for sharing this informative content. It's interesting to note how the previous Systems Administrator at my workplace was strongly in favor of implementing HTTP Strict Transport Security (HSTS) and advocated for team members to obtain Security+ certification. Unfortunately, his misconfigured setup contributed to some security issues, highlighting that HSTS isn't always a critical requirement for website security. This situation underscores the impact of knowledge gaps and how they can lead to misplaced pressures within teams. Additionally, thank you for sharing the RUclips video-it provided valuable insights, even though it was originally shared on Google. We truly appreciate it.
I'm new to Cyber Security and have been denying third party application access based on bad results from HTTP header scans, this video has helped me so much thank you!!!
Honestly, in the stratus of people out there being "Security Content Creators" L.O. has always come across as a passionate hacker. Even when advertising something, not trying to sell it. I appreciate that you aren't a grifter man, because there are plenty in this field.
5:33 This is exactly what I was trying to explain to a client that if a 3rd party npm module is being used in a static client size electron app the vulnerabilities reported by npm have ZERO impact because those only apply if the module is being using to process a user provided input in a route handler in a server app.
Vulnerability scanners are brilliant at what they do and its just that, they give you a static output without providing any context, they cut out all the manual crap you have to go through to assess a web apps/infra vulnerabilities. But people seem to use them as gospel when in fact they should be used to determine the posture of that thing you are scanning. If the output you receive shows a bunch of critical and high ratings then it's probably best to either get an actual pen test conducted or you need to start looking at who is developing and either assess their capability at protecting your data or up-lifting sending them on training courses. Too many orgs I go to and consult for just blindly think because they have Qualys or a similar DAST tool that they have "really good security," when in fact they don't understand what the tool is actually trying to show
I never knew why i had hsts set up, just did it because it was good practice but never knew how it worked… very informational video, even if it was just for google!
Trust me nowadays people are more interested in this kind of videos I mean bug bounty niche, instead of Buffer Overflow or binary exploitation things. I mean this is what people can easily learn and earn through it. Your last Apisix video was amazing too. Keep it up, Great video. 👏🌟 Thank you!
Great video as always, but I think one thing could be slightly incorrect. Sometimes (at least the last time I checked) authorization headers are automatically submitted by the browser. HTTP Basic Authentication credentials are cached so you don't need to fill out the prompt every time you visit a new page. A CORS misconfiguration in this case could allow data from a user authenticated with basic with to have data stolen. I think the same also applies to client certificate based auth, but I've never tested this one myself.
I constantly have to deal with customer pentest reports stating I have a vulnerability because I don’t have HTTPOnly on cookies that are clearly non-sensitive.
While I do agree with most, I think with HSTS you missed some important points. You kinda made it look like HSTS is not really important and sites that use https are fine not setting it. But here I disagree. Setting HSTS is important. We can argue if it's bug bounty level important though... First of all, "Browsers do it anyways" is not correct. Browsers will access the site via http if you tell them to. Your experiment was kinda misleading. Your proxy log didn't show a second http request because the browser served the redirect from its cache, not because it prefers https in any way. (devtools will show you it still does an http request) The cache can simply be circumvented by adding query parameters or simply requesting an URL you didn't load before. HSTS works for the complete domain (and subdomains!) and is kept even if you clear the cache, while your example of "browser does it anyways" relies on the browser cache, caching headers, correct redirect type and only works for resources you already visited explicitly (exact URL). Also, as you stated, HSTS preload exists. While HSTS kinda requires TOFU (Trust on first use), HSTS preload does not. But even without preload, HSTS does a good job for sites that are frequently used by users (e.g. all sites with logins etc). Not setting HSTS leaves your site open to MITM attacks (which are not uncommon on open wifis etc), while setting it does a good job in preventing them. And in case someone tries to MITM an https request, it will also prevent the user from ignoring the warning and clicking "visit anyways" which probably some would do otherwise. So while some security headers really have no benefit at all in some cases, HSTS always increases security.
@@effsixteenblock50 you cannot. As long as the client accepts http a MITM can proxy http to https. Only the client can enforce https and that's why HSTS is important.
@@RoterFruchtZwerg You're talking about proxying with a tool such as Burp with an installed cert? I know some try to enforce SSL with javascript (a joke - I've had crappy shared hosting providers recommend it). Or are you saying even if SSL is enforced server-side, the client can force a downgrade to http?
Yep all good stuff. High-level application level stuff obviously. A ton of that (HSTS, OCSP stapling, HPKP) is largely kludge to mitigate SNI and (much later) ECH coming along far too late with far to much legacy baggage to fully deploy. So we pushed a bunch of workarounds up to the application layer and hope that all of them together are enough to cover our asses long enough for the legacy to become irrelevant. Yep this all requires context and it's always complicated context. CORS also makes a bit more sense if you know it historically came around in part as a means of permitting cross-site websocket access (it's a prerequisite really). Both partly a response to uglier "AJAX" type hacks that were required before there was any other means of "inter-tab" communication, that nobody needs to care about anymore.
i work in a mobile app (that doesnt use webview) and we had a dude reporting to us that we were missing the HSTS, x-frame-options, and others headers that we didnt need!!!! thanks to him we had to delay the production date and it endend ofc being a false positive -_-
We would love to have a more systematic video uploads like a series about CTF what you do how you studied ,good resources , just started with picoCTF but unable to solve many crypto , binary like things .... Reply much appreciated ❣️❣️ thanks
what would u recommend as the best resource for structured learning all the headers you mentioned, and in-depth http in general ? (something like your THE BEST ON THE INTERNET, HANDS DOWN binary playlist. (am aware of your web hacking playlist))
Once you try to deploy an API-Endpoint, you know to hate those headers... Wait, the frontend code that talks to my api works, bit only on Firefox? Because Chrome acts slightly differently with no CORS headers set? Just plain annoying.
Can you please talk about the Expect-CT security header and how it is set right! I cannot find any true worthy information of this header and how it is set right in apache servers!
a non related question buut you guys might be able to help me?? my mum in hospital post stroke has wrongly entered her pin to open her ipad so now it is so locked it doesnt even appear when I plug it into her pc. I get how it is supposed to protect a stolen ipad being accessed but I dont understand why her laptop cant talk to it. any ideas on how to get to the pin input stage again? at the moment its just an expensive coaster. oh I know the pin but theres no way to talk to the ipad, it turns on and thats it.
4 This strategy protects against passive eavesdropping by making it hard for an attacker to trick your user into using something other than SSL to access your site. It also probably ensures that any bookmarks users store will point to the https URLs, which is good. However, HSTS still offers advantages in the event of a man-in-the-middle attack. The core of the problem that HSTS tries to solve is that the browser doesn't know whether a given site should be using SSL or not. And most users don't explicitly try SSL first; if they type in a URL, they generally go to the non-SSL http site first, and usually they're just following links. If an attacker can trick your user into going to your site via an http URL and can sit in the middle of the user's traffic (by being their wireless AP, for example), that attacker can launch a man-in-the-middle attack against your site by proxying the user's traffic to your site and presenting the site to the user without SSL (this is a type of downgrade attack). Since the user won't see SSL, their browser won't recognize that the attacker doesn't have a valid certificate for your site and that they're not connecting to your site directly. (A more complicated approach would be to intercept the SSL traffic and present a self-signed or otherwise invalid certificate for your site, but this will normally result in browser warnings.) In this scenario, redirecting non-SSL users to SSL or setting the secure flag on cookies doesn't actually help you very much. The man-in-the-middle attacker will be connecting to your SSL site (and proxying the user's actions to it), and will just remove the secure flag from your cookies when passing them along to the user. The attacker can, of course, also remove the HSTS header. The point of the HSTS protocol, however, is that if the user had ever successfully gone directly to your site in the past, their browser will remember that your site sent HSTS. If they then later connect to your site and find that it's not using SSL or that the browser can't verify the certificate, the browser will throw an error and refuse to continue. This will prevent the attacker from downgrading your site to non-SSL if the browser supports HSTS and has your site recorded as requiring SSL.
Missing HTTP Security Headers is out of scope 99% of Bug Bounty Programs. It's more a thing about penetration testing reported as good practice information depending of the context. But yeah I agree that many HTTP headers are useless like the X-XSS-Protection (because not implemented in any browser) while some are useful like HSTS or CSP. Yeah if there is an XSS and there is HTTPOnly flag you can still then an XHR but you can't leak the cookie. So if the attacker has only a reflected XSS and not a stored one he will have a far less permanent access. PS: I know the title is just for clickbait
yeah it's out of scope, and still there are many reports about it. So this video hopefully helps those people understand why it's usually not rewarded ;) But what's clickbait about the title? The video is about HTTP Security Headers. That's literally the most accurate boring title lol
@@LiveOverflow I found the "Bug Bounty Tips" clickbaity. Lot of vloger use the word "bug bounty" as a shiny word when it's only general security not specific to bug bounty. The title could have been "HTTP Security Headers real impact" or "HTTP Security Headers - What not to report on Bug Bounty" if you really wanted to use the term "bug bounty". But as I said it is always out of scope of bug bounty so putting it in the title is weird, the title could have been "HTTP Security Headers - Pentest tips" and just saying a parenthesis : HTTP Security Headers are out of scope of BB programs 99% of the time so we'll focus on pentest. But nowaday "bug bounty" is such a trendy word where youg people think they can become rich with it that youtuber use it for every infosec video to get more clicks.
I really dislike the HSTS header, I mean why is it a header and not a DNS record, it would be so much simpler and we could disable http all together if it was simply a DNS record.
I'm going to post this in our Vulnerability Management Team group. I hate it when they make us report petty header issues without checking the context. I might get kicked for it. But fuck it. - _ -
All this information is mistaken and not technical gaps and for this reason, this is not considered within the bug buny HANTING system, which is presented by Google
![[TF2] The Russian Bear Trap](http://i.ytimg.com/vi/YFNSwz2_rOA/mqdefault.jpg)
You know what I absolutely love?
The sheer idea, that he can sit at home, with a shirt that wasn't ironed for the google video. I am not saying he didn't try - it's just the audience more focused on the content than the creator.
I don't know how many will share the thought with me, but here it is.
Good stuff.
True, we live in amazing times
I think a large part, if not the vast majority of the audience this video is intended for are likely sitting at home wearing a shirt that was not ironed.
@@Menaceirl ha!
I didn't even had one!
This is the curse of being familiar with the content(aka being 1337 h4ck3r), you start to notice things that generaly you would and that would make the video a little bit better.
didn't even notice wow
Nothing makes me more happier than seeing this guy.
same :D
@@JimTheScientist
Tô aqui na casa dele e vou ficar com o cara do carro e ele me disse que vai ser um
Finally some browser security; this is the stuff that really needs to be taught, it’s practical and real world content. Keep these kind of videos up man.
Totally agree bro Ahaha nice seeing you here
@@SirKrazzy This is epic, good to see you here too bro!!
This seems to really boil down to: "if you can't accurately and specifically articulate how something can be exploited, it's likely not actually vulnerable"
"POC or GTFO"
Missing security headers are usually out scope on bug bounties program. Nice presentation is worth demonstrating.
here's my typo bounty submission: at 5:55 in the English subtitles there's a typo - it says "doens't" instead of "doesn't"
what's your paypal so I can send you your bounty?
@@LiveOverflow oh, no, thanks, but I only except payments in high quality cybersecurity videos, if that's cool.. so yea, I'm gonna be needing a couple of these instead, ty
@@TheJobCompany yeah apps these days are never getting it right. Same with speech recognition, its going to get me locked up one day for printing out the wrong words.
This is really crucial to understand that absence of a particular header doesn't mean the web application is vulnerable. Instead one should try to figure out how the absence of that header impacts the application in general or maybe chain that impact to find a realistic security flaw.
Thank you for sharing this informative content. It's interesting to note how the previous Systems Administrator at my workplace was strongly in favor of implementing HTTP Strict Transport Security (HSTS) and advocated for team members to obtain Security+ certification. Unfortunately, his misconfigured setup contributed to some security issues, highlighting that HSTS isn't always a critical requirement for website security. This situation underscores the impact of knowledge gaps and how they can lead to misplaced pressures within teams. Additionally, thank you for sharing the RUclips video-it provided valuable insights, even though it was originally shared on Google. We truly appreciate it.
I'm new to Cyber Security and have been denying third party application access based on bad results from HTTP header scans, this video has helped me so much thank you!!!
Honestly, in the stratus of people out there being "Security Content Creators" L.O. has always come across as a passionate hacker. Even when advertising something, not trying to sell it.
I appreciate that you aren't a grifter man, because there are plenty in this field.
5:33 This is exactly what I was trying to explain to a client that if a 3rd party npm module is being used in a static client size electron app the vulnerabilities reported by npm have ZERO impact because those only apply if the module is being using to process a user provided input in a route handler in a server app.
Very thought-provoking video! No one else is talking about this.
Vulnerability scanners are brilliant at what they do and its just that, they give you a static output without providing any context, they cut out all the manual crap you have to go through to assess a web apps/infra vulnerabilities. But people seem to use them as gospel when in fact they should be used to determine the posture of that thing you are scanning. If the output you receive shows a bunch of critical and high ratings then it's probably best to either get an actual pen test conducted or you need to start looking at who is developing and either assess their capability at protecting your data or up-lifting sending them on training courses. Too many orgs I go to and consult for just blindly think because they have Qualys or a similar DAST tool that they have "really good security," when in fact they don't understand what the tool is actually trying to show
Amen
I never knew why i had hsts set up, just did it because it was good practice but never knew how it worked… very informational video, even if it was just for google!
This is surely one of my favorite Channel on youtube !!!!
Web dev here, i actually learned something, great content👌
Trust me nowadays people are more interested in this kind of videos I mean bug bounty niche, instead of Buffer Overflow or binary exploitation things. I mean this is what people can easily learn and earn through it.
Your last Apisix video was amazing too.
Keep it up, Great video. 👏🌟
Thank you!
I recommand subscribing to bug bounty reports explained for the best bug bounty knowledge
Great video as always, but I think one thing could be slightly incorrect. Sometimes (at least the last time I checked) authorization headers are automatically submitted by the browser. HTTP Basic Authentication credentials are cached so you don't need to fill out the prompt every time you visit a new page. A CORS misconfiguration in this case could allow data from a user authenticated with basic with to have data stolen. I think the same also applies to client certificate based auth, but I've never tested this one myself.
Amazing video. Please keep posting such real life examples of how to assess these reports generated by pen testing automation tools!!
Love your videos! So much informative!
ayyyy nice to see that you also still have the offcon covid wristband on your wrist :P
To be fair if we only applied CSP to sites with a known existing XSS, that would be a solid way to broadcast a known issue on your site :)
In other words "You don't have to lock your door if there's nothing valuable inside the house"
What an amazing explanation
As always the video is so Informative. I'm a beginner and I'm about to start my bug bounty journey. I must say it helped me a lot.
lookin more like John by the day my dood, keep it up
Great video!!
Atleast you said it!! So happy
Great insights. Thank you !
Great video! I'm going to watch it again, a lot of good information.
Very informational video, thank you as always for the nice content!!
love your videos
You need to proofread your captions. The tags got eaten, and at one point there's a todo note.
English CC @ 8:08 "[todo checj recording]", just FYI
Great video, i would have liked that the cache header was also explained
What an explanation 🙌
In order to make the transition truly seamless you should have also ripped off your festival wristband. What an oversight!
I constantly have to deal with customer pentest reports stating I have a vulnerability because I don’t have HTTPOnly on cookies that are clearly non-sensitive.
While I do agree with most, I think with HSTS you missed some important points.
You kinda made it look like HSTS is not really important and sites that use https are fine not setting it. But here I disagree. Setting HSTS is important. We can argue if it's bug bounty level important though...
First of all, "Browsers do it anyways" is not correct. Browsers will access the site via http if you tell them to. Your experiment was kinda misleading. Your proxy log didn't show a second http request because the browser served the redirect from its cache, not because it prefers https in any way. (devtools will show you it still does an http request)
The cache can simply be circumvented by adding query parameters or simply requesting an URL you didn't load before. HSTS works for the complete domain (and subdomains!) and is kept even if you clear the cache, while your example of "browser does it anyways" relies on the browser cache, caching headers, correct redirect type and only works for resources you already visited explicitly (exact URL).
Also, as you stated, HSTS preload exists. While HSTS kinda requires TOFU (Trust on first use), HSTS preload does not. But even without preload, HSTS does a good job for sites that are frequently used by users (e.g. all sites with logins etc).
Not setting HSTS leaves your site open to MITM attacks (which are not uncommon on open wifis etc), while setting it does a good job in preventing them.
And in case someone tries to MITM an https request, it will also prevent the user from ignoring the warning and clicking "visit anyways" which probably some would do otherwise.
So while some security headers really have no benefit at all in some cases, HSTS always increases security.
excellent points !
thanks! so much learning today :P
You can enforce HTTPS server-side.
@@effsixteenblock50 you cannot. As long as the client accepts http a MITM can proxy http to https. Only the client can enforce https and that's why HSTS is important.
@@RoterFruchtZwerg You're talking about proxying with a tool such as Burp with an installed cert? I know some try to enforce SSL with javascript (a joke - I've had crappy shared hosting providers recommend it). Or are you saying even if SSL is enforced server-side, the client can force a downgrade to http?
Just feeding the algorithm here.
Thank you for sharing your knowledge and clear explanations \o/
Thanks for the video =)
Yep all good stuff. High-level application level stuff obviously. A ton of that (HSTS, OCSP stapling, HPKP) is largely kludge to mitigate SNI and (much later) ECH coming along far too late with far to much legacy baggage to fully deploy. So we pushed a bunch of workarounds up to the application layer and hope that all of them together are enough to cover our asses long enough for the legacy to become irrelevant.
Yep this all requires context and it's always complicated context. CORS also makes a bit more sense if you know it historically came around in part as a means of permitting cross-site websocket access (it's a prerequisite really). Both partly a response to uglier "AJAX" type hacks that were required before there was any other means of "inter-tab" communication, that nobody needs to care about anymore.
i work in a mobile app (that doesnt use webview) and we had a dude reporting to us that we were missing the HSTS, x-frame-options, and others headers that we didnt need!!!! thanks to him we had to delay the production date and it endend ofc being a false positive -_-
Great ❤️❤️
one of the most under estimated security issues, which actually can help a lot
Woww!! Simply loved the quality of the content in this video! looking forward for much more quality content from you ..✌️✌️
excellent content. thank you.
Love it !
Very informative 😎
thank you this video
hope VA tool guys understand this, they should not be scaring people because of a VA results without understanding
I found a lack of X-Frame-Options tag and thought I conquered the world. It took tens of hours before I could turn it into anything usable...
Great video
Is there a reason not to set "Secure" and "HttpOnly" on all my cookies?
Are you going to make a video about the mc server research?
Yes, of course. But it will be a few weeks/months
I was also interested why a java object was logged while a normal leave message just logs the name.
Mh I don’t know what exactly you mean. If you send me an email with your question I will check it out :)
@@LiveOverflow I think he means the logj4 vulnerability
We would love to have a more systematic video uploads like a series about CTF what you do how you studied ,good resources , just started with picoCTF but unable to solve many crypto , binary like things ....
Reply much appreciated ❣️❣️ thanks
Is this your first time having glasses? I think the ones you chose are nice looking.
what would u recommend as the best resource for structured learning all the headers you mentioned, and in-depth http in general ? (something like your THE BEST ON THE INTERNET, HANDS DOWN binary playlist. (am aware of your web hacking playlist))
Is there any security vulnerability for server if it exposes the content disposition header?
lol the quality difference, its almost as you can tell it been filmed months before :)
img and form tags ignore CORS policy for backward compatibility I'm assuming ?
Nice
The thumbnail xD
Yay!
Once you try to deploy an API-Endpoint, you know to hate those headers... Wait, the frontend code that talks to my api works, bit only on Firefox? Because Chrome acts slightly differently with no CORS headers set? Just plain annoying.
its all about the context baybee
You have changed.
Can you please talk about the Expect-CT security header and how it is set right! I cannot find any true worthy information of this header and how it is set right in apache servers!
F for old MDN theme
Is password input vulnerable to clickjacking considered a vulnerability by Google.
1-2 year im, I am already hearing google's product mgmt opinion in the intro
Subtitle broke at 8:08 :
Also such headers can be per page, not site-wide 😉
a non related question buut you guys might be able to help me?? my mum in hospital post stroke has wrongly entered her pin to open her ipad so now it is so locked it doesnt even appear when I plug it into her pc. I get how it is supposed to protect a stolen ipad being accessed but I dont understand why her laptop cant talk to it. any ideas on how to get to the pin input stage again? at the moment its just an expensive coaster. oh I know the pin but theres no way to talk to the ipad, it turns on and thats it.
8:08 [todo checj recording]
Hello can you please do a video about http smuggling request 🙏🙏
I like your shirt, where did you buy it?
enough people do this that google paid to commission a video discouraging them
what is the exact difference between ( HSTS, secure attribute)?
4
This strategy protects against passive eavesdropping by making it hard for an attacker to trick your user into using something other than SSL to access your site. It also probably ensures that any bookmarks users store will point to the https URLs, which is good. However, HSTS still offers advantages in the event of a man-in-the-middle attack.
The core of the problem that HSTS tries to solve is that the browser doesn't know whether a given site should be using SSL or not. And most users don't explicitly try SSL first; if they type in a URL, they generally go to the non-SSL http site first, and usually they're just following links. If an attacker can trick your user into going to your site via an http URL and can sit in the middle of the user's traffic (by being their wireless AP, for example), that attacker can launch a man-in-the-middle attack against your site by proxying the user's traffic to your site and presenting the site to the user without SSL (this is a type of downgrade attack). Since the user won't see SSL, their browser won't recognize that the attacker doesn't have a valid certificate for your site and that they're not connecting to your site directly. (A more complicated approach would be to intercept the SSL traffic and present a self-signed or otherwise invalid certificate for your site, but this will normally result in browser warnings.)
In this scenario, redirecting non-SSL users to SSL or setting the secure flag on cookies doesn't actually help you very much. The man-in-the-middle attacker will be connecting to your SSL site (and proxying the user's actions to it), and will just remove the secure flag from your cookies when passing them along to the user.
The attacker can, of course, also remove the HSTS header. The point of the HSTS protocol, however, is that if the user had ever successfully gone directly to your site in the past, their browser will remember that your site sent HSTS. If they then later connect to your site and find that it's not using SSL or that the browser can't verify the certificate, the browser will throw an error and refuse to continue. This will prevent the attacker from downgrading your site to non-SSL if the browser supports HSTS and has your site recorded as requiring SSL.
Missing HTTP Security Headers is out of scope 99% of Bug Bounty Programs. It's more a thing about penetration testing reported as good practice information depending of the context. But yeah I agree that many HTTP headers are useless like the X-XSS-Protection (because not implemented in any browser) while some are useful like HSTS or CSP.
Yeah if there is an XSS and there is HTTPOnly flag you can still then an XHR but you can't leak the cookie. So if the attacker has only a reflected XSS and not a stored one he will have a far less permanent access.
PS: I know the title is just for clickbait
yeah it's out of scope, and still there are many reports about it. So this video hopefully helps those people understand why it's usually not rewarded ;)
But what's clickbait about the title? The video is about HTTP Security Headers. That's literally the most accurate boring title lol
@@LiveOverflow I found the "Bug Bounty Tips" clickbaity. Lot of vloger use the word "bug bounty" as a shiny word when it's only general security not specific to bug bounty. The title could have been "HTTP Security Headers real impact" or "HTTP Security Headers - What not to report on Bug Bounty" if you really wanted to use the term "bug bounty". But as I said it is always out of scope of bug bounty so putting it in the title is weird, the title could have been "HTTP Security Headers - Pentest tips" and just saying a parenthesis : HTTP Security Headers are out of scope of BB programs 99% of the time so we'll focus on pentest. But nowaday "bug bounty" is such a trendy word where youg people think they can become rich with it that youtuber use it for every infosec video to get more clicks.
bro the video was literally made for google to give tips to people using their bug bounty program, shut up lmaoo
The line is discussing n theory is a crime
First comment yes
where's the penguin?
2:36 wait....youtube isn't google's website?
good soup
Should've also changed shirt
They don't pay for intentional dev flaws
I really dislike the HSTS header, I mean why is it a header and not a DNS record, it would be so much simpler and we could disable http all together if it was simply a DNS record.
I'm going to post this in our Vulnerability Management Team group. I hate it when they make us report petty header issues without checking the context. I might get kicked for it. But fuck it. - _ -
Google has skilled hackers? This is a genuine surprise.
13:53 yeah then when should you use HttpOnly? You basically said that the flag is completely useless.
but of * cors *
All this information is mistaken and not technical gaps and for this reason, this is not considered within the bug buny HANTING system, which is presented by Google
🏈🏈🏈🏈🏈🏈
Cookie missing secure flag, server has only 443 open
MiTM.
@@nullvoidpointer is it possible mitm when you are in different network? I mean mitm to public ip
somebody is uploading buggy ubuntu 20.04 on my pc al the time, this comes from Ubuntu HQ.
kernel version 5.13.0-35-generic. very bad indeed.
Isai neshona
first