Ethical Hacking in 100 Seconds // And why do we need CORS?

[Music] 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 myspace page with sami is my hero or just last year when the chinese version of twitter weibo exposed over 500 million 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 refuse 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 in 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 penetration 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 joint 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 server side validation is weak you may have just received a five 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 bruteforce 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 wear 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 a black hat this has been ethical hacking on the web in 100 seconds but stay tuned because today i've invited bartos from the web security 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 super happy that we partnered with fireship again several days ago jeff posted a video about course cross origin risk of sharing and in today's video i would like to give you an insight into why we need course 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 four for free 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 site a.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 site b.com so imagine that you fetch index.html image jpg script.js and inside of single tab we have this secure context with javascript running dom document object model cookies and web storage and if this second origin is 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't 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 white list 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 88 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 an image script and some stylesheet 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 two 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 css 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 if we go to style we see that the port is different and everything actually works fine we also know that same origin policy prevents some api executions so here we have two 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 fetched 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 and 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 be 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 two things that happened first of all a 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 fundamentals course 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

Channel: Fireship

Views: 215,991

Keywords: webdev, app development, lesson, tutorial, hacking, 100 seconds of code, penetration testing, ethical hacking, cors, web security, data breach

Id: v969_M6cWk0

Length: 11min 5sec (665 seconds)

Published: Tue Apr 20 2021