Use “Ethical Hacking” or penetration testing to find exploits in your web app before the bad guys do. Featuring @DevAcademyCom to go beyond 100 seconds to explain the purpose of CORS http://links.dev-academy.com/6aP

#hacking #webdev #100SecondsOfCode

🛡️ Web Security Course

40% Discount with code: FIRESHIP_40
http://links.dev-academy.com/6aP

🔗 Resources

OWASP Top 10 https://owasp.org/www-project-top-ten/
Burp Suite https://portswigger.net/burp
CORS in 100 Seconds https://youtu.be/4KHiSt0oLJ0

📚 Chapters

00:00 Ethical Hacking with Burp Suite
02:01 Why do we need CORS?
05:48 Same Origin Policy Example
2024-02-04T14:09:41.636Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
6506d5e5-7800-408e-95b7-8cdf7a2d2d96
a5eaa27447c6b96a5dd388459199fdf3b5ef99536d96db0c8d050d7bd1505f92
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
Ethical Hacking.
Find exploits in your web application before the bad guys do.
As a web developer, there are 10 common security risks that you'll want to be aware of.
Things like database injection, broken authentication, and cross site scripting.
Hackers have been exploiting these vulnerabilities from day 0.
Like back in 05, when cross site scripting was used to update your space page with Sammy is my hero, or just last year when the Chinese version of Twitter Weibo exposed over 500,000,000 user accounts because of a brute force attack on their authentication system.
You can reduce your chances of being a victim by running penetration tests on your web application.
I View to be a victim.
And a popular free tool for doing so is the Burp Suite.
Whenever you visit a website, the browser automatically makes requests to a bunch of servers for the HTML images and JavaScript that that site needs to run.
The Burp Suite is like a man in the middle that can eavesdrop on or intercept every single request.
On its dashboard, we can find the proxy tab, then open an instance of the Chromium browser, then visit a website that's given us permission to run testing.
The tool will intercept every request, allowing us to inspect it and optionally modify its values before it gets sent to the server.
This is kind of like casing the to find potential requests to exploit.
For example, you might submit a form to complete a shopping cart order.
If you change the order amount on the post request and their Riverside validation is weak, you may have just received a 5 finger discount.
But in real life, hacking is rarely that simple.
It takes a lot of tedious trial and error.
Luckily, You can automate your brute force attacks with the intruder tool.
You might have a bunch of username password combinations that get added to a request dynamically, then sent to the server with a variety of different attack types.
All you have to do is click the Start Attack button, then sit back and wait for a successful response.
Once you've gained access, You can use those same credentials to determine if you can maintain access to extract sensitive data from the target.
If you had permission to do this, you a white hat.
If you didn't have permission, but notified the target, you wear a gray hat.
And if you're selling the data for Dogecoin on the dark web, then you wear blackhat.
This has been ethical hacking on the web in 100 seconds, but stay tuned.
Because today, I've invited Bartos from the web Academy to take us beyond 100 seconds and level up our skills on web security.
Hello, Internet.
Bartos from web security academy here, and I'm We're happy that we partner with Fireship again.
Several days ago, Jeff posted a video about course, cross origin resource sharing.
And in today's video, I would like to give you an insight into why we need Cors in the first place.
We will take a look at same origin policy, which is the fundamental principle of Web security model.
We will start with the theory and explanation of important concepts, followed by coding labs, so that you can see the mechanics of this policy in practice.
Let's get started.
In order to understand same origin policy, let's first Understand the concept of origin.
When you take the triple of scheme domain port, this is what constitutes to origin.
First three examples when we have HTTPS, the domain Web Security Academy, and here the port is implicit because when you use HTTPS the default port for this is 4 43.
The default port for HTTP is port 80.
So when you have the same scheme, the same domain, and the same port, regardless of the path, It is considered to be the same origin.
If you have a different subdomain or a different port or a different scheme.
These are all different origins.
Why is this so important to differentiate those origins?
Let's jump to the next slide.
So the same origin policy creates some kind of secure context for your websites running in the browser.
So imagine that you have sitea.com, which will consider Our origin a and the browser fetches this website from the server.
And then we have origin b That is hosted on siteb.com.
So imagine that you fetch index HTML, image JPEG, Script.
Js.
And inside of single tap, we have this secure context with JavaScript running, DOM, document object model, cookies and web storage.
And if the second origin It's loaded in the different tab.
They cannot communicate each other.
They are isolated, but You can still fetch resources from the different origin.
For example, you would be able to load images, CSS styles or scripts to enrich your website with resources from the different origin.
And here is very important to note that This is the browser which enforces same origin policy.
And as I told you, there's going to be some kind of secure context That is going to bind this origin and the execution of this website and scripts and everything related to this website In your browser and this single website would not be allowed to communicate with different origins.
So imagine that you load some website and you would like to communicate with site b.
By default, Same origin policy restrict this kind of communication.
Because who said that they can trust each other?
Maybe one website is evil and We would like to prevent this kind of communication.
In order for this kind of communication, origin b Must whitelist origin a explicitly saying that origin a is trustworthy.
Let's look at this example.
We have a simple website which displays hello world, some image, it links to some style sheets and scripts.
And also it has some simple inline scripts implemented to call APIs on different URLs.
So to serve this application, we have a simple server which is written in Node.
Js and utilizes Express JS library to serve our application.
If we look here, we see that whenever there is a request To this URL, we are going to serve index HTML whenever there is a request to This URL, we are going to execute some simulated logic.
In this case, just a console log.
And also, we have a second Application.
Before we jump into the second application, let's note that this application is going to be served At port 8080.
And the second application, which is called external because it's going to simulate our External origin is going to be served on the different port, and here it's going to serve some static resources in the folder Public.
So we see it serves some image, script, and some style sheet and also exposes API method for HTTP get to also simulate some logic, in this case, console log.
So let's Also, look how we can run those 2 applications.
Npm run policies would start our first application.
Npm policies external would Start our second application.
As you remember, we are trying to see same origin policy in practice.
We know that we can fetch external CSSs and scripts like this.
So here you see that we are requesting our external Origin, which we know by the port number here, they were successfully applied.
Image was successfully loaded.
Uh, if we go to style, we see that the port It's different, and everything actually works fine.
We also know that same origin policy Prevents some API executions.
So here we have 2 buttons, call API And call external API.
Let's look at the console to see that we have some message here.
It says I was faxed from external origin.
This is a script that we can see here.
There was no problem in importing a Script from a different origin, our external origin, uh, that we see the port is 8081.
So let's try to execute API method on our first origin.
So looking back on our index HTML, We see whenever we click button call API, it's going to call our server Then get the response and display it in the console.
So whenever I click here, console log Success and also our server says that API was called.
But different situation would b, when we would try to call external API because now our API endpoint Is living on the different origin.
So if we click here, we see 2 things that happened.
First of all, The request actually hit the server because we see console log from the server that external API was called, but actual response Was blocked on the browser because we know that same origin policy is enforced on the browser level.
So now because we didn't actually allow this origin to communicate with our website, the result Is blocked.
To recap, we were able to get style sheets, images, and scripts to be executed on our website, but Calling external API was prevented from reading the result, but internal API call was successful.
If you liked How it was explained to you that we start with the theory and follow with Coding Labs, I encourage you to check out my Web security fundamental scores that you can get right now with a 40% discount using the code that you see on the screen right now.
During this concise one hour course, I will teach you the most important aspects of web security model from the theoretical and practical perspective So that you will never ever end up with course error again and you would know how to efficiently prevent cross site scripting or at least Minimize the risk of cross site scripting to a negligible degree.
See you in the course.
Thanks for watching, and I will see you in the next one.

Speaker 0: Ethical Hacking. Find exploits in your web application before the bad guys do. As a web developer, there are 10 common security risks that you'll want to be aware of. Things like database injection, broken authentication, and cross site scripting. Hackers have been exploiting these vulnerabilities from day 0.

Like back in 05, when cross site scripting was used to update your space page with Sammy is my hero, or just last year when the Chinese version of Twitter Weibo exposed over 500,000,000 user accounts because of a brute force attack on their authentication system. You can reduce your chances of being a victim by running penetration tests on your web application.

Speaker 1: I View to be a victim.

Speaker 0: And a popular free tool for doing so is the Burp Suite. Whenever you visit a website, the browser automatically makes requests to a bunch of servers for the HTML images and JavaScript that that site needs to run. The Burp Suite is like a man in the middle that can eavesdrop on or intercept every single request. On its dashboard, we can find the proxy tab, then open an instance of the Chromium browser, then visit a website that's given us permission to run testing. The tool will intercept every request, allowing us to inspect it and optionally modify its values before it gets sent to the server.

This is kind of like casing the to find potential requests to exploit. For example, you might submit a form to complete a shopping cart order. If you change the order amount on the post request and their Riverside validation is weak, you may have just received a 5 finger discount. But in real life, hacking is rarely that simple. It takes a lot of tedious trial and error.

Luckily, You can automate your brute force attacks with the intruder tool. You might have a bunch of username password combinations that get added to a request dynamically, then sent to the server with a variety of different attack types. All you have to do is click the Start Attack button, then sit back and wait for a successful response. Once you've gained access, You can use those same credentials to determine if you can maintain access to extract sensitive data from the target. If you had permission to do this, you a white hat.

If you didn't have permission, but notified the target, you wear a gray hat. And if you're selling the data for Dogecoin on the dark web, then you wear blackhat. This has been ethical hacking on the web in 100 seconds, but stay tuned. Because today, I've invited Bartos from the web Academy to take us beyond 100 seconds and level up our skills on web security.

Speaker 1: Hello, Internet. Bartos from web security academy here, and I'm We're happy that we partner with Fireship again. Several days ago, Jeff posted a video about course, cross origin resource sharing. And in today's video, I would like to give you an insight into why we need Cors in the first place. We will take a look at same origin policy, which is the fundamental principle of Web security model.

We will start with the theory and explanation of important concepts, followed by coding labs, so that you can see the mechanics of this policy in practice. Let's get started. In order to understand same origin policy, let's first Understand the concept of origin. When you take the triple of scheme domain port, this is what constitutes to origin. First three examples when we have HTTPS, the domain Web Security Academy, and here the port is implicit because when you use HTTPS the default port for this is 4 43.

The default port for HTTP is port 80. So when you have the same scheme, the same domain, and the same port, regardless of the path, It is considered to be the same origin. If you have a different subdomain or a different port or a different scheme. These are all different origins. Why is this so important to differentiate those origins?

Let's jump to the next slide. So the same origin policy creates some kind of secure context for your websites running in the browser. So imagine that you have sitea.com, which will consider Our origin a and the browser fetches this website from the server. And then we have origin b That is hosted on siteb.com. So imagine that you fetch index HTML, image JPEG, Script.

Js. And inside of single tap, we have this secure context with JavaScript running, DOM, document object model, cookies and web storage. And if the second origin It's loaded in the different tab. They cannot communicate each other. They are isolated, but You can still fetch resources from the different origin.

For example, you would be able to load images, CSS styles or scripts to enrich your website with resources from the different origin. And here is very important to note that This is the browser which enforces same origin policy. And as I told you, there's going to be some kind of secure context That is going to bind this origin and the execution of this website and scripts and everything related to this website In your browser and this single website would not be allowed to communicate with different origins. So imagine that you load some website and you would like to communicate with site b. By default, Same origin policy restrict this kind of communication.

Because who said that they can trust each other? Maybe one website is evil and We would like to prevent this kind of communication. In order for this kind of communication, origin b Must whitelist origin a explicitly saying that origin a is trustworthy. Let's look at this example. We have a simple website which displays hello world, some image, it links to some style sheets and scripts.

And also it has some simple inline scripts implemented to call APIs on different URLs. So to serve this application, we have a simple server which is written in Node. Js and utilizes Express JS library to serve our application. If we look here, we see that whenever there is a request To this URL, we are going to serve index HTML whenever there is a request to This URL, we are going to execute some simulated logic. In this case, just a console log.

And also, we have a second Application. Before we jump into the second application, let's note that this application is going to be served At port 8080. And the second application, which is called external because it's going to simulate our External origin is going to be served on the different port, and here it's going to serve some static resources in the folder Public. So we see it serves some image, script, and some style sheet and also exposes API method for HTTP get to also simulate some logic, in this case, console log. So let's Also, look how we can run those 2 applications.

Npm run policies would start our first application. Npm policies external would Start our second application. As you remember, we are trying to see same origin policy in practice. We know that we can fetch external CSSs and scripts like this. So here you see that we are requesting our external Origin, which we know by the port number here, they were successfully applied.

Image was successfully loaded. Uh, if we go to style, we see that the port It's different, and everything actually works fine. We also know that same origin policy Prevents some API executions. So here we have 2 buttons, call API And call external API. Let's look at the console to see that we have some message here.

It says I was faxed from external origin. This is a script that we can see here. There was no problem in importing a Script from a different origin, our external origin, uh, that we see the port is 8081. So let's try to execute API method on our first origin. So looking back on our index HTML, We see whenever we click button call API, it's going to call our server Then get the response and display it in the console.

So whenever I click here, console log Success and also our server says that API was called. But different situation would b, when we would try to call external API because now our API endpoint Is living on the different origin. So if we click here, we see 2 things that happened. First of all, The request actually hit the server because we see console log from the server that external API was called, but actual response Was blocked on the browser because we know that same origin policy is enforced on the browser level. So now because we didn't actually allow this origin to communicate with our website, the result Is blocked.

To recap, we were able to get style sheets, images, and scripts to be executed on our website, but Calling external API was prevented from reading the result, but internal API call was successful. If you liked How it was explained to you that we start with the theory and follow with Coding Labs, I encourage you to check out my Web security fundamental scores that you can get right now with a 40% discount using the code that you see on the screen right now. During this concise one hour course, I will teach you the most important aspects of web security model from the theoretical and practical perspective So that you will never ever end up with course error again and you would know how to efficiently prevent cross site scripting or at least Minimize the risk of cross site scripting to a negligible degree. See you in the course.

Speaker 0: Thanks for watching, and I will see you in the next one.
Ethical Hacking. Find exploits in your web application before the bad guys do. As a web developer, there are 10 common security risks that you'll want to be aware of. Things like database injection, broken authentication, and cross site scripting. Hackers have been exploiting these vulnerabilities from day 0. Like back in 05, when cross site scripting was used to update your space page with Sammy is my hero, or just last year when the Chinese version of Twitter Weibo exposed over 500,000,000 user accounts because of a brute force attack on their authentication system.
security
ethics
You can reduce your chances of being a victim by running penetration tests on your web application. I View to be a victim. And a popular free tool for doing so is the Burp Suite. Whenever you visit a website, the browser automatically makes requests to a bunch of servers for the HTML images and JavaScript that that site needs to run. The Burp Suite is like a man in the middle that can eavesdrop on or intercept every single request. On its dashboard, we can find the proxy tab, then open an instance of the Chromium browser, then visit a website that's given us permission to run testing. The tool will intercept every request, allowing us to inspect it and optionally modify its values before it gets sent to the server. This is kind of like casing the to find potential requests to exploit.
For example, you might submit a form to complete a shopping cart order. If you change the order amount on the post request and their Riverside validation is weak, you may have just received a 5 finger discount. But in real life, hacking is rarely that simple. It takes a lot of tedious trial and error. Luckily, You can automate your brute force attacks with the intruder tool. You might have a bunch of username password combinations that get added to a request dynamically, then sent to the server with a variety of different attack types. All you have to do is click the Start Attack button, then sit back and wait for a successful response. Once you've gained access, You can use those same credentials to determine if you can maintain access to extract sensitive data from the target. If you had permission to do this, you a white hat. If you didn't have permission, but notified the target, you wear a gray hat. And if you're selling the data for Dogecoin on the dark web, then you wear blackhat. This has been ethical hacking on the web in 100 seconds, but stay tuned. Because today, I've invited Bartos from the web Academy to take us beyond 100 seconds and level up our skills on web security. Hello, Internet. Bartos from web security academy here, and I'm We're happy that we partner with Fireship again. Several days ago, Jeff posted a video about course, cross origin resource sharing. And in today's video, I would like to give you an insight into why we need Cors in the first place. We will take a look at same origin policy, which is the fundamental principle of Web security model. We will start with the theory and explanation of important concepts, followed by coding labs, so that you can see the mechanics of this policy in practice. Let's get started. In order to understand same origin policy, let's first Understand the concept of origin. When you take the triple of scheme domain port, this is what constitutes to origin.
security
copyright
copyright licenses
purchasing
policy
google
networking
First three examples when we have HTTPS, the domain Web Security Academy, and here the port is implicit because when you use HTTPS the default port for this is 4 43. The default port for HTTP is port 80. So when you have the same scheme, the same domain, and the same port, regardless of the path, It is considered to be the same origin. If you have a different subdomain or a different port or a different scheme. These are all different origins. Why is this so important to differentiate those origins?
Let's jump to the next slide. So the same origin policy creates some kind of secure context for your websites running in the browser. So imagine that you have sitea.com, which will consider Our origin a and the browser fetches this website from the server. And then we have origin b That is hosted on siteb.com.
internet
So imagine that you fetch index HTML, image JPEG, Script. Js. And inside of single tap, we have this secure context with JavaScript running, DOM, document object model, cookies and web storage. And if the second origin It's loaded in the different tab. They cannot communicate each other. They are isolated, but You can still fetch resources from the different origin.
For example, you would be able to load images, CSS styles or scripts to enrich your website with resources from the different origin. And here is very important to note that This is the browser which enforces same origin policy. And as I told you, there's going to be some kind of secure context That is going to bind this origin and the execution of this website and scripts and everything related to this website In your browser and this single website would not be allowed to communicate with different origins. So imagine that you load some website and you would like to communicate with site b. By default, Same origin policy restrict this kind of communication. Because who said that they can trust each other? Maybe one website is evil and We would like to prevent this kind of communication. In order for this kind of communication, origin b Must whitelist origin a explicitly saying that origin a is trustworthy. Let's look at this example. We have a simple website which displays hello world, some image, it links to some style sheets and scripts.
internet
copyright licenses
intellectual property
websites
security
copyright
And also it has some simple inline scripts implemented to call APIs on different URLs.
So to serve this application, we have a simple server which is written in Node. Js and utilizes Express JS library to serve our application. If we look here, we see that whenever there is a request To this URL, we are going to serve index HTML whenever there is a request to This URL, we are going to execute some simulated logic. In this case, just a console log. And also, we have a second Application.
programming
Before we jump into the second application, let's note that this application is going to be served At port 8080. And the second application, which is called external because it's going to simulate our External origin is going to be served on the different port, and here it's going to serve some static resources in the folder Public. So we see it serves some image, script, and some style sheet and also exposes API method for HTTP get to also simulate some logic, in this case, console log. So let's Also, look how we can run those 2 applications. Npm run policies would start our first application. Npm policies external would Start our second application. As you remember, we are trying to see same origin policy in practice. We know that we can fetch external CSSs and scripts like this. So here you see that we are requesting our external Origin, which we know by the port number here, they were successfully applied. Image was successfully loaded. Uh, if we go to style, we see that the port It's different, and everything actually works fine. We also know that same origin policy Prevents some API executions. So here we have 2 buttons, call API And call external API. Let's look at the console to see that we have some message here. It says I was faxed from external origin. This is a script that we can see here. There was no problem in importing a Script from a different origin, our external origin, uh, that we see the port is 8081. So let's try to execute API method on our first origin. So looking back on our index HTML, We see whenever we click button call API, it's going to call our server Then get the response and display it in the console. So whenever I click here, console log Success and also our server says that API was called. But different situation would b, when we would try to call external API because now our API endpoint Is living on the different origin. So if we click here, we see 2 things that happened. First of all, The request actually hit the server because we see console log from the server that external API was called, but actual response Was blocked on the browser because we know that same origin policy is enforced on the browser level. So now because we didn't actually allow this origin to communicate with our website, the result Is blocked. To recap, we were able to get style sheets, images, and scripts to be executed on our website, but Calling external API was prevented from reading the result, but internal API call was successful. If you liked How it was explained to you that we start with the theory and follow with Coding Labs, I encourage you to check out my Web security fundamental scores that you can get right now with a 40% discount using the code that you see on the screen right now.
During this concise one hour course, I will teach you the most important aspects of web security model from the theoretical and practical perspective So that you will never ever end up with course error again and you would know how to efficiently prevent cross site scripting or at least Minimize the risk of cross site scripting to a negligible degree.
security
See you in the course. Thanks for watching, and I will see you in the next one.
Ethical Hacking. Find exploits in your web application before the bad guys do. As a web developer, there are 10 common security risks that you'll want to be aware of. Things like database injection, broken authentication, and cross site scripting. Hackers have been exploiting these vulnerabilities from day 0. Like back in 05, when cross site scripting was used to update your space page with Sammy is my hero, or just last year when the Chinese version of Twitter Weibo exposed over 500,000,000 user accounts because of a brute force attack on their authentication system. You can reduce your chances of being a victim by running penetration tests on your web application. I View to be a victim. And a popular free tool for doing so is the Burp Suite. Whenever you visit a website, the browser automatically makes requests to a bunch of servers for the HTML images and JavaScript that that site needs to run. The Burp Suite is like a man in the middle that can eavesdrop on or intercept every single request. On its dashboard, we can find the proxy tab, then open an instance of the Chromium browser, then visit a website that's given us permission to run testing. The tool will intercept every request, allowing us to inspect it and optionally modify its values before it gets sent to the server. This is kind of like casing the to find potential requests to exploit. For example, you might submit a form to complete a shopping cart order. If you change the order amount on the post request and their Riverside validation is weak, you may have just received a 5 finger discount. But in real life, hacking is rarely that simple. It takes a lot of tedious trial and error. Luckily, You can automate your brute force attacks with the intruder tool. You might have a bunch of username password combinations that get added to a request dynamically, then sent to the server with a variety of different attack types. All you have to do is click the Start Attack button, then sit back and wait for a successful response. Once you've gained access, You can use those same credentials to determine if you can maintain access to extract sensitive data from the target. If you had permission to do this, you a white hat. If you didn't have permission, but notified the target, you wear a gray hat. And if you're selling the data for Dogecoin on the dark web, then you wear blackhat. This has been ethical hacking on the web in 100 seconds, but stay tuned. Because today, I've invited Bartos from the web Academy to take us beyond 100 seconds and level up our skills on web security. Hello, Internet. Bartos from web security academy here, and I'm We're happy that we partner with Fireship again. Several days ago, Jeff posted a video about course, cross origin resource sharing. And in today's video, I would like to give you an insight into why we need Cors in the first place. We will take a look at same origin policy, which is the fundamental principle of Web security model. We will start with the theory and explanation of important concepts, followed by coding labs, so that you can see the mechanics of this policy in practice. Let's get started. In order to understand same origin policy, let's first Understand the concept of origin. When you take the triple of scheme domain port, this is what constitutes to origin. First three examples when we have HTTPS, the domain Web Security Academy, and here the port is implicit because when you use HTTPS the default port for this is 4 43. The default port for HTTP is port 80. So when you have the same scheme, the same domain, and the same port, regardless of the path, It is considered to be the same origin. If you have a different subdomain or a different port or a different scheme. These are all different origins. Why is this so important to differentiate those origins? Let's jump to the next slide. So the same origin policy creates some kind of secure context for your websites running in the browser. So imagine that you have sitea.com, which will consider Our origin a and the browser fetches this website from the server. And then we have origin b That is hosted on siteb.com. So imagine that you fetch index HTML, image JPEG, Script. Js. And inside of single tap, we have this secure context with JavaScript running, DOM, document object model, cookies and web storage. And if the second origin It's loaded in the different tab. They cannot communicate each other. They are isolated, but You can still fetch resources from the different origin. For example, you would be able to load images, CSS styles or scripts to enrich your website with resources from the different origin. And here is very important to note that This is the browser which enforces same origin policy. And as I told you, there's going to be some kind of secure context That is going to bind this origin and the execution of this website and scripts and everything related to this website In your browser and this single website would not be allowed to communicate with different origins. So imagine that you load some website and you would like to communicate with site b. By default, Same origin policy restrict this kind of communication. Because who said that they can trust each other? Maybe one website is evil and We would like to prevent this kind of communication. In order for this kind of communication, origin b Must whitelist origin a explicitly saying that origin a is trustworthy. Let's look at this example. We have a simple website which displays hello world, some image, it links to some style sheets and scripts. And also it has some simple inline scripts implemented to call APIs on different URLs. So to serve this application, we have a simple server which is written in Node. Js and utilizes Express JS library to serve our application. If we look here, we see that whenever there is a request To this URL, we are going to serve index HTML whenever there is a request to This URL, we are going to execute some simulated logic. In this case, just a console log. And also, we have a second Application. Before we jump into the second application, let's note that this application is going to be served At port 8080. And the second application, which is called external because it's going to simulate our External origin is going to be served on the different port, and here it's going to serve some static resources in the folder Public. So we see it serves some image, script, and some style sheet and also exposes API method for HTTP get to also simulate some logic, in this case, console log. So let's Also, look how we can run those 2 applications. Npm run policies would start our first application. Npm policies external would Start our second application. As you remember, we are trying to see same origin policy in practice. We know that we can fetch external CSSs and scripts like this. So here you see that we are requesting our external Origin, which we know by the port number here, they were successfully applied. Image was successfully loaded. Uh, if we go to style, we see that the port It's different, and everything actually works fine. We also know that same origin policy Prevents some API executions. So here we have 2 buttons, call API And call external API. Let's look at the console to see that we have some message here. It says I was faxed from external origin. This is a script that we can see here. There was no problem in importing a Script from a different origin, our external origin, uh, that we see the port is 8081. So let's try to execute API method on our first origin. So looking back on our index HTML, We see whenever we click button call API, it's going to call our server Then get the response and display it in the console. So whenever I click here, console log Success and also our server says that API was called. But different situation would b, when we would try to call external API because now our API endpoint Is living on the different origin. So if we click here, we see 2 things that happened. First of all, The request actually hit the server because we see console log from the server that external API was called, but actual response Was blocked on the browser because we know that same origin policy is enforced on the browser level. So now because we didn't actually allow this origin to communicate with our website, the result Is blocked. To recap, we were able to get style sheets, images, and scripts to be executed on our website, but Calling external API was prevented from reading the result, but internal API call was successful. If you liked How it was explained to you that we start with the theory and follow with Coding Labs, I encourage you to check out my Web security fundamental scores that you can get right now with a 40% discount using the code that you see on the screen right now. During this concise one hour course, I will teach you the most important aspects of web security model from the theoretical and practical perspective So that you will never ever end up with course error again and you would know how to efficiently prevent cross site scripting or at least Minimize the risk of cross site scripting to a negligible degree. See you in the course. Thanks for watching, and I will see you in the next one.
Ethical
ethical
Hacking.
hacking
Find
find
exploits
exploits
in
in
your
your
web
web
application
application
before
before
the
the
bad
bad
guys
guys
do.
do
As
as
a
a
web
web
developer,
developer
there
there
are
are
10
10
common
common
security
security
risks
risks
that
that
you'll
you'll
want
want
to
to
be
be
aware
aware
of.
of
Things
things
like
like
database
database
injection,
injection
broken
broken
authentication,
authentication
and
and
cross
cross
site
site
scripting.
scripting
Hackers
hackers
have
have
been
been
exploiting
exploiting
these
these
vulnerabilities
vulnerabilities
from
from
day
day
0.
0
Like
like
back
back
in
in
05,
05
when
when
cross
cross
site
site
scripting
scripting
was
was
used
used
to
to
update
update
your
your
space
space
page
page
with
with
Sammy
sammy
is
is
my
my
hero,
hero
or
or
just
just
last
last
year
year
when
when
the
the
Chinese
chinese
version
version
of
of
Twitter
twitter
Weibo
weibo
exposed
exposed
over
over
500,000,000
500,000,000
user
user
accounts
accounts
because
because
of
of
a
a
brute
brute
force
force
attack
attack
on
on
their
their
authentication
authentication
system.
system
You
you
can
can
reduce
reduce
your
your
chances
chances
of
of
being
being
a
a
victim
victim
by
by
running
running
penetration
penetration
tests
tests
on
on
your
your
web
web
application.
application
I
i
View
view
to
to
be
be
a
a
victim.
victim
And
and
a
a
popular
popular
free
free
tool
tool
for
for
doing
doing
so
so
is
is
the
the
Burp
burp
Suite.
suite
Whenever
whenever
you
you
visit
visit
a
a
website,
website
the
the
browser
browser
automatically
automatically
makes
makes
requests
requests
to
to
a
a
bunch
bunch
of
of
servers
servers
for
for
the
the
HTML
html
images
images
and
and
JavaScript
javascript
that
that
that
that
site
site
needs
needs
to
to
run.
run
The
the
Burp
burp
Suite
suite
is
is
like
like
a
a
man
man
in
in
the
the
middle
middle
that
that
can
can
eavesdrop
eavesdrop
on
on
or
or
intercept
intercept
every
every
single
single
request.
request
On
on
its
its
dashboard,
dashboard
we
we
can
can
find
find
the
the
proxy
proxy
tab,
tab
then
then
open
open
an
an
instance
instance
of
of
the
the
Chromium
chromium
browser,
browser
then
then
visit
visit
a
a
website
website
that's
that's
given
given
us
us
permission
permission
to
to
run
run
testing.
testing
The
the
tool
tool
will
will
intercept
intercept
every
every
request,
request
allowing
allowing
us
us
to
to
inspect
inspect
it
it
and
and
optionally
optionally
modify
modify
its
its
values
values
before
before
it
it
gets
gets
sent
sent
to
to
the
the
server.
server
This
this
is
is
kind
kind
of
of
like
like
casing
casing
the
the
to
to
find
find
potential
potential
requests
requests
to
to
exploit.
exploit
For
for
example,
example
you
you
might
might
submit
submit
a
a
form
form
to
to
complete
complete
a
a
shopping
shopping
cart
cart
order.
order
If
if
you
you
change
change
the
the
order
order
amount
amount
on
on
the
the
post
post
request
request
and
and
their
their
Riverside
riverside
validation
validation
is
is
weak,
weak
you
you
may
may
have
have
just
just
received
received
a
a
5
5
finger
finger
discount.
discount
But
but
in
in
real
real
life,
life
hacking
hacking
is
is
rarely
rarely
that
that
simple.
simple
It
it
takes
takes
a
a
lot
lot
of
of
tedious
tedious
trial
trial
and
and
error.
error
Luckily,
luckily
You
you
can
can
automate
automate
your
your
brute
brute
force
force
attacks
attacks
with
with
the
the
intruder
intruder
tool.
tool
You
you
might
might
have
have
a
a
bunch
bunch
of
of
username
username
password
password
combinations
combinations
that
that
get
get
added
added
to
to
a
a
request
request
dynamically,
dynamically
then
then
sent
sent
to
to
the
the
server
server
with
with
a
a
variety
variety
of
of
different
different
attack
attack
types.
types
All
all
you
you
have
have
to
to
do
do
is
is
click
click
the
the
Start
start
Attack
attack
button,
button
then
then
sit
sit
back
back
and
and
wait
wait
for
for
a
a
successful
successful
response.
response
Once
once
you've
you've
gained
gained
access,
access
You
you
can
can
use
use
those
those
same
same
credentials
credentials
to
to
determine
determine
if
if
you
you
can
can
maintain
maintain
access
access
to
to
extract
extract
sensitive
sensitive
data
data
from
from
the
the
target.
target
If
if
you
you
had
had
permission
permission
to
to
do
do
this,
this
you
you
a
a
white
white
hat.
hat
If
if
you
you
didn't
didn't
have
have
permission,
permission
but
but
notified
notified
the
the
target,
target
you
you
wear
wear
a
a
gray
gray
hat.
hat
And
and
if
if
you're
you're
selling
selling
the
the
data
data
for
for
Dogecoin
dogecoin
on
on
the
the
dark
dark
web,
web
then
then
you
you
wear
wear
blackhat.
blackhat
This
this
has
has
been
been
ethical
ethical
hacking
hacking
on
on
the
the
web
web
in
in
100
100
seconds,
seconds
but
but
stay
stay
tuned.
tuned
Because
because
today,
today
I've
i've
invited
invited
Bartos
bartos
from
from
the
the
web
web
Academy
academy
to
to
take
take
us
us
beyond
beyond
100
100
seconds
seconds
and
and
level
level
up
up
our
our
skills
skills
on
on
web
web
security.
security
Hello,
hello
Internet.
internet
Bartos
bartos
from
from
web
web
security
security
academy
academy
here,
here
and
and
I'm
i'm
We're
we're
happy
happy
that
that
we
we
partner
partner
with
with
Fireship
fireship
again.
again
Several
several
days
days
ago,
ago
Jeff
jeff
posted
posted
a
a
video
video
about
about
course,
course
cross
cross
origin
origin
resource
resource
sharing.
sharing
And
and
in
in
today's
today's
video,
video
I
i
would
would
like
like
to
to
give
give
you
you
an
an
insight
insight
into
into
why
why
we
we
need
need
Cors
cors
in
in
the
the
first
first
place.
place
We
we
will
will
take
take
a
a
look
look
at
at
same
same
origin
origin
policy,
policy
which
which
is
is
the
the
fundamental
fundamental
principle
principle
of
of
Web
web
security
security
model.
model
We
we
will
will
start
start
with
with
the
the
theory
theory
and
and
explanation
explanation
of
of
important
important
concepts,
concepts
followed
followed
by
by
coding
coding
labs,
labs
so
so
that
that
you
you
can
can
see
see
the
the
mechanics
mechanics
of
of
this
this
policy
policy
in
in
practice.
practice
Let's
let's
get
get
started.
started
In
in
order
order
to
to
understand
understand
same
same
origin
origin
policy,
policy
let's
let's
first
first
Understand
understand
the
the
concept
concept
of
of
origin.
origin
When
when
you
you
take
take
the
the
triple
triple
of
of
scheme
scheme
domain
domain
port,
port
this
this
is
is
what
what
constitutes
constitutes
to
to
origin.
origin
First
first
three
three
examples
examples
when
when
we
we
have
have
HTTPS,
https
the
the
domain
domain
Web
web
Security
security
Academy,
academy
and
and
here
here
the
the
port
port
is
is
implicit
implicit
because
because
when
when
you
you
use
use
HTTPS
https
the
the
default
default
port
port
for
for
this
this
is
is
4
4
43.
43
The
the
default
default
port
port
for
for
HTTP
http
is
is
port
port
80.
80
So
so
when
when
you
you
have
have
the
the
same
same
scheme,
scheme
the
the
same
same
domain,
domain
and
and
the
the
same
same
port,
port
regardless
regardless
of
of
the
the
path,
path
It
it
is
is
considered
considered
to
to
be
be
the
the
same
same
origin.
origin
If
if
you
you
have
have
a
a
different
different
subdomain
subdomain
or
or
a
a
different
different
port
port
or
or
a
a
different
different
scheme.
scheme
These
these
are
are
all
all
different
different
origins.
origins
Why
why
is
is
this
this
so
so
important
important
to
to
differentiate
differentiate
those
those
origins?
origins
Let's
let's
jump
jump
to
to
the
the
next
next
slide.
slide
So
so
the
the
same
same
origin
origin
policy
policy
creates
creates
some
some
kind
kind
of
of
secure
secure
context
context
for
for
your
your
websites
websites
running
running
in
in
the
the
browser.
browser
So
so
imagine
imagine
that
that
you
you
have
have
sitea.com,
sitea.com
which
which
will
will
consider
consider
Our
our
origin
origin
a
a
and
and
the
the
browser
browser
fetches
fetches
this
this
website
website
from
from
the
the
server.
server
And
and
then
then
we
we
have
have
origin
origin
b
b
That
that
is
is
hosted
hosted
on
on
siteb.com.
siteb.com
So
so
imagine
imagine
that
that
you
you
fetch
fetch
index
index
HTML,
html
image
image
JPEG,
jpeg
Script.
script
Js.
js
And
and
inside
inside
of
of
single
single
tap,
tap
we
we
have
have
this
this
secure
secure
context
context
with
with
JavaScript
javascript
running,
running
DOM,
dom
document
document
object
object
model,
model
cookies
cookies
and
and
web
web
storage.
storage
And
and
if
if
the
the
second
second
origin
origin
It's
it's
loaded
loaded
in
in
the
the
different
different
tab.
tab
They
they
cannot
cannot
communicate
communicate
each
each
other.
other
They
they
are
are
isolated,
isolated
but
but
You
you
can
can
still
still
fetch
fetch
resources
resources
from
from
the
the
different
different
origin.
origin
For
for
example,
example
you
you
would
would
be
be
able
able
to
to
load
load
images,
images
CSS
css
styles
styles
or
or
scripts
scripts
to
to
enrich
enrich
your
your
website
website
with
with
resources
resources
from
from
the
the
different
different
origin.
origin
And
and
here
here
is
is
very
very
important
important
to
to
note
note
that
that
This
this
is
is
the
the
browser
browser
which
which
enforces
enforces
same
same
origin
origin
policy.
policy
And
and
as
as
I
i
told
told
you,
you
there's
there's
going
going
to
to
be
be
some
some
kind
kind
of
of
secure
secure
context
context
That
that
is
is
going
going
to
to
bind
bind
this
this
origin
origin
and
and
the
the
execution
execution
of
of
this
this
website
website
and
and
scripts
scripts
and
and
everything
everything
related
related
to
to
this
this
website
website
In
in
your
your
browser
browser
and
and
this
this
single
single
website
website
would
would
not
not
be
be
allowed
allowed
to
to
communicate
communicate
with
with
different
different
origins.
origins
So
so
imagine
imagine
that
that
you
you
load
load
some
some
website
website
and
and
you
you
would
would
like
like
to
to
communicate
communicate
with
with
site
site
b.
b
By
by
default,
default
Same
same
origin
origin
policy
policy
restrict
restrict
this
this
kind
kind
of
of
communication.
communication
Because
because
who
who
said
said
that
that
they
they
can
can
trust
trust
each
each
other?
other
Maybe
maybe
one
one
website
website
is
is
evil
evil
and
and
We
we
would
would
like
like
to
to
prevent
prevent
this
this
kind
kind
of
of
communication.
communication
In
in
order
order
for
for
this
this
kind
kind
of
of
communication,
communication
origin
origin
b
b
Must
must
whitelist
whitelist
origin
origin
a
a
explicitly
explicitly
saying
saying
that
that
origin
origin
a
a
is
is
trustworthy.
trustworthy
Let's
let's
look
look
at
at
this
this
example.
example
We
we
have
have
a
a
simple
simple
website
website
which
which
displays
displays
hello
hello
world,
world
some
some
image,
image
it
it
links
links
to
to
some
some
style
style
sheets
sheets
and
and
scripts.
scripts
And
and
also
also
it
it
has
has
some
some
simple
simple
inline
inline
scripts
scripts
implemented
implemented
to
to
call
call
APIs
apis
on
on
different
different
URLs.
urls
So
so
to
to
serve
serve
this
this
application,
application
we
we
have
have
a
a
simple
simple
server
server
which
which
is
is
written
written
in
in
Node.
node
Js
js
and
and
utilizes
utilizes
Express
express
JS
js
library
library
to
to
serve
serve
our
our
application.
application
If
if
we
we
look
look
here,
here
we
we
see
see
that
that
whenever
whenever
there
there
is
is
a
a
request
request
To
to
this
this
URL,
url
we
we
are
are
going
going
to
to
serve
serve
index
index
HTML
html
whenever
whenever
there
there
is
is
a
a
request
request
to
to
This
this
URL,
url
we
we
are
are
going
going
to
to
execute
execute
some
some
simulated
simulated
logic.
logic
In
in
this
this
case,
case
just
just
a
a
console
console
log.
log
And
and
also,
also
we
we
have
have
a
a
second
second
Application.
application
Before
before
we
we
jump
jump
into
into
the
the
second
second
application,
application
let's
let's
note
note
that
that
this
this
application
application
is
is
going
going
to
to
be
be
served
served
At
at
port
port
8080.
8080
And
and
the
the
second
second
application,
application
which
which
is
is
called
called
external
external
because
because
it's
it's
going
going
to
to
simulate
simulate
our
our
External
external
origin
origin
is
is
going
going
to
to
be
be
served
served
on
on
the
the
different
different
port,
port
and
and
here
here
it's
it's
going
going
to
to
serve
serve
some
some
static
static
resources
resources
in
in
the
the
folder
folder
Public.
public
So
so
we
we
see
see
it
it
serves
serves
some
some
image,
image
script,
script
and
and
some
some
style
style
sheet
sheet
and
and
also
also
exposes
exposes
API
api
method
method
for
for
HTTP
http
get
get
to
to
also
also
simulate
simulate
some
some
logic,
logic
in
in
this
this
case,
case
console
console
log.
log
So
so
let's
let's
Also,
also
look
look
how
how
we
we
can
can
run
run
those
those
2
2
applications.
applications
Npm
npm
run
run
policies
policies
would
would
start
start
our
our
first
first
application.
application
Npm
npm
policies
policies
external
external
would
would
Start
start
our
our
second
second
application.
application
As
as
you
you
remember,
remember
we
we
are
are
trying
trying
to
to
see
see
same
same
origin
origin
policy
policy
in
in
practice.
practice
We
we
know
know
that
that
we
we
can
can
fetch
fetch
external
external
CSSs
csss
and
and
scripts
scripts
like
like
this.
this
So
so
here
here
you
you
see
see
that
that
we
we
are
are
requesting
requesting
our
our
external
external
Origin,
origin
which
which
we
we
know
know
by
by
the
the
port
port
number
number
here,
here
they
they
were
were
successfully
successfully
applied.
applied
Image
image
was
was
successfully
successfully
loaded.
loaded
Uh,
uh
if
if
we
we
go
go
to
to
style,
style
we
we
see
see
that
that
the
the
port
port
It's
it's
different,
different
and
and
everything
everything
actually
actually
works
works
fine.
fine
We
we
also
also
know
know
that
that
same
same
origin
origin
policy
policy
Prevents
prevents
some
some
API
api
executions.
executions
So
so
here
here
we
we
have
have
2
2
buttons,
buttons
call
call
API
api
And
and
call
call
external
external
API.
api
Let's
let's
look
look
at
at
the
the
console
console
to
to
see
see
that
that
we
we
have
have
some
some
message
message
here.
here
It
it
says
says
I
i
was
was
faxed
faxed
from
from
external
external
origin.
origin
This
this
is
is
a
a
script
script
that
that
we
we
can
can
see
see
here.
here
There
there
was
was
no
no
problem
problem
in
in
importing
importing
a
a
Script
script
from
from
a
a
different
different
origin,
origin
our
our
external
external
origin,
origin
uh,
uh
that
that
we
we
see
see
the
the
port
port
is
is
8081.
8081
So
so
let's
let's
try
try
to
to
execute
execute
API
api
method
method
on
on
our
our
first
first
origin.
origin
So
so
looking
looking
back
back
on
on
our
our
index
index
HTML,
html
We
we
see
see
whenever
whenever
we
we
click
click
button
button
call
call
API,
api
it's
it's
going
going
to
to
call
call
our
our
server
server
Then
then
get
get
the
the
response
response
and
and
display
display
it
it
in
in
the
the
console.
console
So
so
whenever
whenever
I
i
click
click
here,
here
console
console
log
log
Success
success
and
and
also
also
our
our
server
server
says
says
that
that
API
api
was
was
called.
called
But
but
different
different
situation
situation
would
would
b,
b
when
when
we
we
would
would
try
try
to
to
call
call
external
external
API
api
because
because
now
now
our
our
API
api
endpoint
endpoint
Is
is
living
living
on
on
the
the
different
different
origin.
origin
So
so
if
if
we
we
click
click
here,
here
we
we
see
see
2
2
things
things
that
that
happened.
happened
First
first
of
of
all,
all
The
the
request
request
actually
actually
hit
hit
the
the
server
server
because
because
we
we
see
see
console
console
log
log
from
from
the
the
server
server
that
that
external
external
API
api
was
was
called,
called
but
but
actual
actual
response
response
Was
was
blocked
blocked
on
on
the
the
browser
browser
because
because
we
we
know
know
that
that
same
same
origin
origin
policy
policy
is
is
enforced
enforced
on
on
the
the
browser
browser
level.
level
So
so
now
now
because
because
we
we
didn't
didn't
actually
actually
allow
allow
this
this
origin
origin
to
to
communicate
communicate
with
with
our
our
website,
website
the
the
result
result
Is
is
blocked.
blocked
To
to
recap,
recap
we
we
were
were
able
able
to
to
get
get
style
style
sheets,
sheets
images,
images
and
and
scripts
scripts
to
to
be
be
executed
executed
on
on
our
our
website,
website
but
but
Calling
calling
external
external
API
api
was
was
prevented
prevented
from
from
reading
reading
the
the
result,
result
but
but
internal
internal
API
api
call
call
was
was
successful.
successful
If
if
you
you
liked
liked
How
how
it
it
was
was
explained
explained
to
to
you
you
that
that
we
we
start
start
with
with
the
the
theory
theory
and
and
follow
follow
with
with
Coding
coding
Labs,
labs
I
i
encourage
encourage
you
you
to
to
check
check
out
out
my
my
Web
web
security
security
fundamental
fundamental
scores
scores
that
that
you
you
can
can
get
get
right
right
now
now
with
with
a
a
40%
40%
discount
discount
using
using
the
the
code
code
that
that
you
you
see
see
on
on
the
the
screen
screen
right
right
now.
now
During
during
this
this
concise
concise
one
one
hour
hour
course,
course
I
i
will
will
teach
teach
you
you
the
the
most
most
important
important
aspects
aspects
of
of
web
web
security
security
model
model
from
from
the
the
theoretical
theoretical
and
and
practical
practical
perspective
perspective
So
so
that
that
you
you
will
will
never
never
ever
ever
end
end
up
up
with
with
course
course
error
error
again
again
and
and
you
you
would
would
know
know
how
how
to
to
efficiently
efficiently
prevent
prevent
cross
cross
site
site
scripting
scripting
or
or
at
at
least
least
Minimize
minimize
the
the
risk
risk
of
of
cross
cross
site
site
scripting
scripting
to
to
a
a
negligible
negligible
degree.
degree
See
see
you
you
in
in
the
the
course.
course
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The importance of secure context in web applications is discussed, including the Burp Suite and the need for same origin policies. The security of web applications is emphasized, with the importance of secure environments and trustworthiness being emphasized. The academy representative explains the importance of secure policies and provides an example of running two applications with the same origin policy. The course is one hour long and teaches the most important aspects of web security, with a discount code for a Web security fundamental score.
Ethical Hacking in 100 Seconds // And why do we need CORS?
Ethical Hacking. Find exploits in your web application before the bad guys do. As a web developer, there are 10 common security risks that you'll want to be aware of. Things like database injection, broken authentication, and cross site scripting. Hackers have been exploiting these vulnerabilities from day 0. Like back in 05, when cross site scripting was used to update your space page with Sammy is my hero, or just last year when the Chinese version of Twitter Weibo exposed over 500,000,000 user accounts because of a brute force attack on their authentication system. You can reduce your chances of being a victim by running penetration tests on your web application. I View to be a victim. And a popular free tool for doing so is the Burp Suite. Whenever you visit a website, the browser automatically makes requests to a bunch of servers for the HTML images and JavaScript that that site needs to run. The Burp Suite is like a man in the middle that can eavesdrop on or intercept every single request. On its dashboard, we can find the proxy tab, then open an instance of the Chromium browser, then visit a website that's given us permission to run testing. The tool will intercept every request, allowing us to inspect it and optionally modify its values before it gets sent to the server. This is kind of like casing the to find potential requests to exploit. For example, you might submit a form to complete a shopping cart order. If you change the order amount on the post request and their Riverside validation is weak, you may have just received a 5 finger discount. But in real life, hacking is rarely that simple. It takes a lot of tedious trial and error. Luckily, You can automate your brute force attacks with the intruder tool. You might have a bunch of username password combinations that get added to a request dynamically, then sent to the server with a variety of different attack types. All you have to do is click the Start Attack button, then sit back and wait for a successful response. Once you've gained access, You can use those same credentials to determine if you can maintain access to extract sensitive data from the target. If you had permission to do this, you a white hat. If you didn't have permission, but notified the target, you wear a gray hat. And if you're selling the data for Dogecoin on the dark web, then you wear blackhat. This has been ethical hacking on the web in 100 seconds, but stay tuned. Because today, I've invited Bartos from the web Academy to take us beyond 100 seconds and level up our skills on web security. Hello, Internet. Bartos from web security academy here, and I'm We're happy that we partner with Fireship again. Several days ago, Jeff posted a video about course, cross origin resource sharing. And in today's video, I would like to give you an insight into why we need Cors in the first place. We will take a look at same origin policy, which is the fundamental principle of Web security model. We will start with the theory and explanation of important concepts, followed by coding labs, so that you can see the mechanics of this policy in practice. Let's get started. In order to understand same origin policy, let's first Understand the concept of origin. When you take the triple of scheme domain port, this is what constitutes to origin. First three examples when we have HTTPS, the domain Web Security Academy, and here the port is implicit because when you use HTTPS the default port for this is 4 43. The default port for HTTP is port 80. So when you have the same scheme, the same domain, and the same port, regardless of the path, It is considered to be the same origin. If you have a different subdomain or a different port or a different scheme. These are all different origins. Why is this so important to differentiate those origins? Let's jump to the next slide. So the same origin policy creates some kind of secure context for your websites running in the browser. So imagine that you have sitea.com, which will consider Our origin a and the browser fetches this website from the server. And then we have origin b That is hosted on siteb.com. So imagine that you fetch index HTML, image JPEG, Script. Js. And inside of single tap, we have this secure context with JavaScript running, DOM, document object model, cookies and web storage. And if the second origin It's loaded in the different tab. They cannot communicate each other. They are isolated, but You can still fetch resources from the different origin. For example, you would be able to load images, CSS styles or scripts to enrich your website with resources from the different origin. And here is very important to note that This is the browser which enforces same origin policy. And as I told you, there's going to be some kind of secure context That is going to bind this origin and the execution of this website and scripts and everything related to this website In your browser and this single website would not be allowed to communicate with different origins. So imagine that you load some website and you would like to communicate with site b. By default, Same origin policy restrict this kind of communication. Because who said that they can trust each other? Maybe one website is evil and We would like to prevent this kind of communication. In order for this kind of communication, origin b Must whitelist origin a explicitly saying that origin a is trustworthy. Let's look at this example. We have a simple website which displays hello world, some image, it links to some style sheets and scripts. And also it has some simple inline scripts implemented to call APIs on different URLs. So to serve this application, we have a simple server which is written in Node. Js and utilizes Express JS library to serve our application. If we look here, we see that whenever there is a request To this URL, we are going to serve index HTML whenever there is a request to This URL, we are going to execute some simulated logic. In this case, just a console log. And also, we have a second Application. Before we jump into the second application, let's note that this application is going to be served At port 8080. And the second application, which is called external because it's going to simulate our External origin is going to be served on the different port, and here it's going to serve some static resources in the folder Public. So we see it serves some image, script, and some style sheet and also exposes API method for HTTP get to also simulate some logic, in this case, console log. So let's Also, look how we can run those 2 applications. Npm run policies would start our first application. Npm policies external would Start our second application. As you remember, we are trying to see same origin policy in practice. We know that we can fetch external CSSs and scripts like this. So here you see that we are requesting our external Origin, which we know by the port number here, they were successfully applied. Image was successfully loaded. Uh, if we go to style, we see that the port It's different, and everything actually works fine. We also know that same origin policy Prevents some API executions. So here we have 2 buttons, call API And call external API. Let's look at the console to see that we have some message here. It says I was faxed from external origin. This is a script that we can see here. There was no problem in importing a Script from a different origin, our external origin, uh, that we see the port is 8081. So let's try to execute API method on our first origin. So looking back on our index HTML, We see whenever we click button call API, it's going to call our server Then get the response and display it in the console. So whenever I click here, console log Success and also our server says that API was called. But different situation would b, when we would try to call external API because now our API endpoint Is living on the different origin. So if we click here, we see 2 things that happened. First of all, The request actually hit the server because we see console log from the server that external API was called, but actual response Was blocked on the browser because we know that same origin policy is enforced on the browser level. So now because we didn't actually allow this origin to communicate with our website, the result Is blocked. To recap, we were able to get style sheets, images, and scripts to be executed on our website, but Calling external API was prevented from reading the result, but internal API call was successful. If you liked How it was explained to you that we start with the theory and follow with Coding Labs, I encourage you to check out my Web security fundamental scores that you can get right now with a 40% discount using the code that you see on the screen right now. During this concise one hour course, I will teach you the most important aspects of web security model from the theoretical and practical perspective So that you will never ever end up with course error again and you would know how to efficiently prevent cross site scripting or at least Minimize the risk of cross site scripting to a negligible degree. See you in the course. Thanks for watching, and I will see you in the next one.
The importance of secure context in web applications is discussed, including the Burp Suite and the need for same origin policies. The security of web applications is emphasized, with the importance of secure environments and trustworthiness being emphasized. The academy representative explains the importance of secure policies and provides an example of running two applications with the same origin policy. The course is one hour long and teaches the most important aspects of web security, with a discount code for a Web security fundamental score.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Ethical Hacking in 100 Seconds // And why do we need CORS? 
        and a small summary : The importance of secure context in web applications is discussed, including the Burp Suite and the need for same origin policies. The security of web applications is emphasized, with the importance of secure environments and trustworthiness being emphasized. The academy representative explains the importance of secure policies and provides an example of running two applications with the same origin policy. The course is one hour long and teaches the most important aspects of web security, with a discount code for a Web security fundamental score.
        [/INST]
        
        Generate the video : Ethical Hacking. Find exploits in your web application before the bad guys do. As a web developer, there are 10 common security risks that you'll want to be aware of. Things like database injection, broken authentication, and cross site scripting. Hackers have been exploiting these vulnerabilities from day 0. Like back in 05, when cross site scripting was used to update your space page with Sammy is my hero, or just last year when the Chinese version of Twitter Weibo exposed over 500,000,000 user accounts because of a brute force attack on their authentication system. You can reduce your chances of being a victim by running penetration tests on your web application. I View to be a victim. And a popular free tool for doing so is the Burp Suite. Whenever you visit a website, the browser automatically makes requests to a bunch of servers for the HTML images and JavaScript that that site needs to run. The Burp Suite is like a man in the middle that can eavesdrop on or intercept every single request. On its dashboard, we can find the proxy tab, then open an instance of the Chromium browser, then visit a website that's given us permission to run testing. The tool will intercept every request, allowing us to inspect it and optionally modify its values before it gets sent to the server. This is kind of like casing the to find potential requests to exploit. For example, you might submit a form to complete a shopping cart order. If you change the order amount on the post request and their Riverside validation is weak, you may have just received a 5 finger discount. But in real life, hacking is rarely that simple. It takes a lot of tedious trial and error. Luckily, You can automate your brute force attacks with the intruder tool. You might have a bunch of username password combinations that get added to a request dynamically, then sent to the server with a variety of different attack types. All you have to do is click the Start Attack button, then sit back and wait for a successful response. Once you've gained access, You can use those same credentials to determine if you can maintain access to extract sensitive data from the target. If you had permission to do this, you a white hat. If you didn't have permission, but notified the target, you wear a gray hat. And if you're selling the data for Dogecoin on the dark web, then you wear blackhat. This has been ethical hacking on the web in 100 seconds, but stay tuned. Because today, I've invited Bartos from the web Academy to take us beyond 100 seconds and level up our skills on web security. Hello, Internet. Bartos from web security academy here, and I'm We're happy that we partner with Fireship again. Several days ago, Jeff posted a video about course, cross origin resource sharing. And in today's video, I would like to give you an insight into why we need Cors in the first place. We will take a look at same origin policy, which is the fundamental principle of Web security model. We will start with the theory and explanation of important concepts, followed by coding labs, so that you can see the mechanics of this policy in practice. Let's get started. In order to understand same origin policy, let's first Understand the concept of origin. When you take the triple of scheme domain port, this is what constitutes to origin. First three examples when we have HTTPS, the domain Web Security Academy, and here the port is implicit because when you use HTTPS the default port for this is 4 43. The default port for HTTP is port 80. So when you have the same scheme, the same domain, and the same port, regardless of the path, It is considered to be the same origin. If you have a different subdomain or a different port or a different scheme. These are all different origins. Why is this so important to differentiate those origins? Let's jump to the next slide. So the same origin policy creates some kind of secure context for your websites running in the browser. So imagine that you have sitea.com, which will consider Our origin a and the browser fetches this website from the server. And then we have origin b That is hosted on siteb.com. So imagine that you fetch index HTML, image JPEG, Script. Js. And inside of single tap, we have this secure context with JavaScript running, DOM, document object model, cookies and web storage. And if the second origin It's loaded in the different tab. They cannot communicate each other. They are isolated, but You can still fetch resources from the different origin. For example, you would be able to load images, CSS styles or scripts to enrich your website with resources from the different origin. And here is very important to note that This is the browser which enforces same origin policy. And as I told you, there's going to be some kind of secure context That is going to bind this origin and the execution of this website and scripts and everything related to this website In your browser and this single website would not be allowed to communicate with different origins. So imagine that you load some website and you would like to communicate with site b. By default, Same origin policy restrict this kind of communication. Because who said that they can trust each other? Maybe one website is evil and We would like to prevent this kind of communication. In order for this kind of communication, origin b Must whitelist origin a explicitly saying that origin a is trustworthy. Let's look at this example. We have a simple website which displays hello world, some image, it links to some style sheets and scripts. And also it has some simple inline scripts implemented to call APIs on different URLs. So to serve this application, we have a simple server which is written in Node. Js and utilizes Express JS library to serve our application. If we look here, we see that whenever there is a request To this URL, we are going to serve index HTML whenever there is a request to This URL, we are going to execute some simulated logic. In this case, just a console log. And also, we have a second Application. Before we jump into the second application, let's note that this application is going to be served At port 8080. And the second application, which is called external because it's going to simulate our External origin is going to be served on the different port, and here it's going to serve some static resources in the folder Public. So we see it serves some image, script, and some style sheet and also exposes API method for HTTP get to also simulate some logic, in this case, console log. So let's Also, look how we can run those 2 applications. Npm run policies would start our first application. Npm policies external would Start our second application. As you remember, we are trying to see same origin policy in practice. We know that we can fetch external CSSs and scripts like this. So here you see that we are requesting our external Origin, which we know by the port number here, they were successfully applied. Image was successfully loaded. Uh, if we go to style, we see that the port It's different, and everything actually works fine. We also know that same origin policy Prevents some API executions. So here we have 2 buttons, call API And call external API. Let's look at the console to see that we have some message here. It says I was faxed from external origin. This is a script that we can see here. There was no problem in importing a Script from a different origin, our external origin, uh, that we see the port is 8081. So let's try to execute API method on our first origin. So looking back on our index HTML, We see whenever we click button call API, it's going to call our server Then get the response and display it in the console. So whenever I click here, console log Success and also our server says that API was called. But different situation would b, when we would try to call external API because now our API endpoint Is living on the different origin. So if we click here, we see 2 things that happened. First of all, The request actually hit the server because we see console log from the server that external API was called, but actual response Was blocked on the browser because we know that same origin policy is enforced on the browser level. So now because we didn't actually allow this origin to communicate with our website, the result Is blocked. To recap, we were able to get style sheets, images, and scripts to be executed on our website, but Calling external API was prevented from reading the result, but internal API call was successful. If you liked How it was explained to you that we start with the theory and follow with Coding Labs, I encourage you to check out my Web security fundamental scores that you can get right now with a 40% discount using the code that you see on the screen right now. During this concise one hour course, I will teach you the most important aspects of web security model from the theoretical and practical perspective So that you will never ever end up with course error again and you would know how to efficiently prevent cross site scripting or at least Minimize the risk of cross site scripting to a negligible degree. See you in the course. Thanks for watching, and I will see you in the next one.
        