Top 7 security concepts 🛡️ and hacking stories 🎭 that every JavaScript developer should know about. Master these concepts in the Enterprise Security course: https://bit.ly/2wrUqAB (use FIRESHIP50 at checkout). 

Full Security Article https://fireship.io/lessons/7-security-concepts-hacks-web-developers/
OWASP Top 10 https://owasp.org/www-project-top-ten/

Concepts: 

1. Zero-day 0:47
2. Vulnerable packages 1:22
3. XSS 2:24
4. SQL Injection 3:42
5. Credential Leaks 4:48
6. Principle of Least Privilege 6:11
7. DDoS 7:43

#security #web #javascript

My VS Code Theme

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T06:23:04.997Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
4728057a-8c52-48d8-8465-21efa113c62b
2fc8c8eb6d6e35d978361bdb184dca2cf2d947b3fb1a80d2a79b886560762f05
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
In most cases, the bugs we introduce are harmless, But sometimes, they can cause us to lose 100 of 1,000,000 of dollars in a few minutes, crash airplanes and spaceships, and kill people.
Today, I want to tell you some stories about the most damaging hacks and bugs throughout history, tree, and explains 7 software security concepts that every developer should know.
If you're new here, like and subscribe, and check out the full write up on FireShip.
Io.
There are billions upon billions of lines of code in production today, around 50,000,000 lines for Microsoft Windows, and over 2,000,000,000 lines across all Google services.
And within all this code, we have vulnerabilities that have either not yet been discovered or not yet been fixed.
These are known as 0 day vulnerabilities because as a developer, you have 0 days to get it fixed.
When a hacker decides to attack this vulnerability, it's known as a 0 day exploit.
Remember that one time Equifax had exposed the credit reports of a 150 people.
That wasn't the result of a 0 day exploit.
It was the result of a known bug in Apache Struts that had already been fixed weeks ago.
What?
I'm sorry.
I fudged up, guys.
Hackers, apparently from China, had been scanning the web for servers with this vulnerability.
They hit the mother lode with Equifax and extracted sensitive information over the next 76 days.
This breach has cost the company over a $1,000,000,000 and could have been prevented by installing a simple security patch.
Being hacked by a known vulnerability is not uncommon at all.
In fact, you're likely shipping code with a lot of known vulnerabilities right now.
If you're a JS developer, go into your project and hit npm audit.
It will give you a breakdown of all the different ways you can be hacked via your open source dependencies.
Now, there's no reason to panic.
If you have hundreds of high severity alerts, The best way to avoid being hacked is to simply update your packages.
But if you truly want to understand the flaws that are compromising these packages, You should enroll in the Enterprise Security course from Angular Academy.
It's a 10 week long program that will teach you how to confidently build secure web applications.
You'll find the link in the description, and you can use this code to take $50 off the enrollment price.
Using components with known vulnerabilities is one of the most common ways that web applications get hacked, But it's also very preventable, because as you can see here, most of the issues have already been patched.
And keep in mind, this issue isn't unique to JavaScript or NPM.
All package managers that rely on Open source code face similar issues, so trust nobody and keep your packages updated.
But most of all, Sammy is my hero.
Wait a second.
I didn't mean to say that last part.
It was somehow injected into this video.
Back in 2005, a guy named Sammy used an exploit known as cross site Scripting to update a user's MySpace profile with this text.
Within a day, it had spread to over a 1000000 users.
It was mostly harmless, but they did arrest Sammy, convict him of a felony, And worst of all, took away his Internet for a year.
A cross site scripting exploit occurs when the attacker manages to run some JavaScript code on a different user's browser.
There are a few different ways to achieve this, but the most common way is for the attacker to save the script in a web application's database.
The malicious script will then accessed by a different user that will execute the JavaScript on the client side device.
And at that point, the JavaScript code can submit forms, click on buttons on behalf of the logged in user.
So how do you avoid cross site scripting attacks as a developer?
Well, the attacker first needs to save some malicious code on your server.
So Step 1 is to do some server side validation of incoming data.
If it's surrounded by script tags, you might not wanna save it.
But let's imagine you fail to sanitize the incoming data.
The attacker still needs a way to run that script on the client side device, so the attacker is counting on you to render out the raw HTML of the script.
Fortunately, modern front end frameworks make it really difficult to shoot yourself in the foot.
In React, for example, if you want to write unsafe code, you have to use this dangerously set inner HTML Prop just to do so.
So with cross site scripting, we have malicious code running on the browser, but it's also possible to run bad code directly on a database.
Let's go back to 2008 and look at a company named Heartland Payment Systems, a company with the highest standards and the most trusted transactions, and also a company that was the target of one of the most elaborate and interesting hacks of all time.
The attackers first gained access to the company's databases by using a technique known as QL injection.
Instead of sending the expected data to the database, they sent raw SQL statements.
And because the data was not validated, the database would run this code as if it came from the developers.
Now this particular database contained the information that you would find on the back of a magnetic strip on a credit card, and they used this stolen data to create counterfeit credit cards that actually worked.
It's estimated that over a 100,000,000 cards were compromised, and the main hacker, Albert Gonzalez, was sentenced to 20 years in prison.
Injection attacks similar to this affect many different types of databases.
If you use an ORM or object relational mapping tool for your database, you should be safe from attacks like this.
But of course, it's always a good idea to validate your input before it's sent to your database.
Another very easy way to create a big problem as a developer is to expose, or leak a sensitive API key.
You can think of a private API key as a username and password all bundled up into a single string, and it allows your servers to securely communicate with paid services like AWS, Google Cloud, and so on.
A few years ago, I Incidentally leaked my AWS API key, and it was almost really bad.
I was using the Node SDK for a service that required the API key.
I hard coded the API key directly in the source code instead of setting it as an environment variable.
I then proceeded to push the source code to a public GitHub repo.
Whoopsies.
A few weeks went by, and then all of a sudden, I get a notification from AWS that I've maxed out my budget.
When I logged into my AWS account, I had racked up charges around $5,000 for EC 2 instances running all over the world.
Luckily, Amazon was nice enough to refund those charges, but it definitely made me feel like an idiot.
Nowadays, automatic scanners can often detect if you have an exposed API key and email you a notification.
But GitHub isn't the only place that you might leak an API key.
When you include a private key in a client side web or mobile app, a hacker might be able to find it directly in your source code.
Now if you do end up with an exposed API key, you can fix the problem by simply rolling it to a new value, and of course removing it from any public repos or source code.
Many good APIs will help you minimize the damage by allowing you to assign privileges to a specific API key.
This allows you to follow the principle of least privilege, and only give API keys access to the resources that they actually need.
That will mitigate the amount of damage that can be done if that key does end up being leaked.
If we look at a major cloud provider like AWS, we'll see that they offer hundreds of different services, and they might be used by a company with thousands of employees working on different projects.
Sharing a single API key that has access to everything would be a very bad idea.
Instead, the major cloud providers have a system called I'm which allows you to create groups or roles for your organization.
Once you've created a role, you can then attach a policy to that role to give it access to a service that it needs.
Implementing fine grained access control over your data is more important than ever.
In 2016, an employee of Morrison Supermarkets in the UK stole the private data of over 100,000 employees.
This rogue employee did it by simply copying the data onto a USB stick.
Now this is obviously unethical and illegal on the employee's part, but the company itself is facing a huge lawsuit, and the penalties for data breaches are becoming larger with laws like GDPR and the EU.
So the bottom line here is to always follow the principle of least privilege when it comes to accessing your customer or employee data.
And speaking of data, you might come across something called the CIA triad.
It's a model for data security that stands for confidentiality, integrity, and availability.
Generally speaking, you make data confidential by implementing user authentication so only authorized users can access the data.
Integrity means the data can't be simply modified or deleted without the user's authorization.
But I think the most interesting question is how do you make your data highly available?
In 2018, GitHub survived the biggest DDoS attack or distributed denial of service attack in history.
It took GitHub down for less than 10 minutes, but that's Still a pretty big deal considering how many people around the world depend on GitHub at any given moment.
A DDoS attack works by flooding a service with so much Traffic that it just fails to scale and completely stops working.
You can see in this chart how the inbound traffic suddenly spiked, but the servers treated these as legitimate requests and responded with a normal response.
GitHub is big enough to handle attacks like this, but smaller sites might not be so lucky.
In some cases, DDoS attacks have been used to shut down service, and then request a ransom from the owner.
So how do you protect yourself?
Well, the simple answer is to be ready to scale, and that likely means using a big cloud provider.
A service like Google Cloud Armor has the bandwidth to handle attacks like this and it can also prevent many other attacks that we talked about earlier in the video.
But at the end of the day, nobody's application is 100% safe.
There are likely hackers out there right now using 0 day exploits that we don't know about yet.
And it's only a matter of time before the next major data breach is in the headlines.
If this video helped you, please like and subscribe, and make sure to check out the Enterprise Security course if you really want to master these concepts.
Thanks for watching, and I will talk to you soon.

Speaker 0: If debugging is the process of removing software bugs, then programming must be the process of putting them in. In most cases, the bugs we introduce are harmless, But sometimes, they can cause us to lose 100 of 1,000,000 of dollars in a few minutes, crash airplanes and spaceships, and kill people. Today, I want to tell you some stories about the most damaging hacks and bugs throughout history, tree, and explains 7 software security concepts that every developer should know. If you're new here, like and subscribe, and check out the full write up on FireShip. Io.

There are billions upon billions of lines of code in production today, around 50,000,000 lines for Microsoft Windows, and over 2,000,000,000 lines across all Google services. And within all this code, we have vulnerabilities that have either not yet been discovered or not yet been fixed. These are known as 0 day vulnerabilities because as a developer, you have 0 days to get it fixed. When a hacker decides to attack this vulnerability, it's known as a 0 day exploit. Remember that one time Equifax had exposed the credit reports of a 150 people.

That wasn't the result of a 0 day exploit. It was the result of a known bug in Apache Struts that had already been fixed weeks ago. What? I'm sorry. I fudged up, guys.

Hackers, apparently from China, had been scanning the web for servers with this vulnerability. They hit the mother lode with Equifax and extracted sensitive information over the next 76 days. This breach has cost the company over a $1,000,000,000 and could have been prevented by installing a simple security patch. Being hacked by a known vulnerability is not uncommon at all. In fact, you're likely shipping code with a lot of known vulnerabilities right now.

If you're a JS developer, go into your project and hit npm audit. It will give you a breakdown of all the different ways you can be hacked via your open source dependencies. Now, there's no reason to panic. If you have hundreds of high severity alerts, The best way to avoid being hacked is to simply update your packages. But if you truly want to understand the flaws that are compromising these packages, You should enroll in the Enterprise Security course from Angular Academy.

It's a 10 week long program that will teach you how to confidently build secure web applications. You'll find the link in the description, and you can use this code to take $50 off the enrollment price. Using components with known vulnerabilities is one of the most common ways that web applications get hacked, But it's also very preventable, because as you can see here, most of the issues have already been patched. And keep in mind, this issue isn't unique to JavaScript or NPM. All package managers that rely on Open source code face similar issues, so trust nobody and keep your packages updated.

But most of all, Sammy is my hero. Wait a second. I didn't mean to say that last part. It was somehow injected into this video. Back in 2005, a guy named Sammy used an exploit known as cross site Scripting to update a user's MySpace profile with this text.

Within a day, it had spread to over a 1000000 users. It was mostly harmless, but they did arrest Sammy, convict him of a felony, And worst of all, took away his Internet for a year. A cross site scripting exploit occurs when the attacker manages to run some JavaScript code on a different user's browser. There are a few different ways to achieve this, but the most common way is for the attacker to save the script in a web application's database. The malicious script will then accessed by a different user that will execute the JavaScript on the client side device.

And at that point, the JavaScript code can submit forms, click on buttons on behalf of the logged in user. So how do you avoid cross site scripting attacks as a developer? Well, the attacker first needs to save some malicious code on your server. So Step 1 is to do some server side validation of incoming data. If it's surrounded by script tags, you might not wanna save it.

But let's imagine you fail to sanitize the incoming data. The attacker still needs a way to run that script on the client side device, so the attacker is counting on you to render out the raw HTML of the script. Fortunately, modern front end frameworks make it really difficult to shoot yourself in the foot. In React, for example, if you want to write unsafe code, you have to use this dangerously set inner HTML Prop just to do so. So with cross site scripting, we have malicious code running on the browser, but it's also possible to run bad code directly on a database.

Let's go back to 2008 and look at a company named Heartland Payment Systems, a company with the highest standards and the most trusted transactions, and also a company that was the target of one of the most elaborate and interesting hacks of all time. The attackers first gained access to the company's databases by using a technique known as QL injection. Instead of sending the expected data to the database, they sent raw SQL statements. And because the data was not validated, the database would run this code as if it came from the developers. Now this particular database contained the information that you would find on the back of a magnetic strip on a credit card, and they used this stolen data to create counterfeit credit cards that actually worked.

It's estimated that over a 100,000,000 cards were compromised, and the main hacker, Albert Gonzalez, was sentenced to 20 years in prison. Injection attacks similar to this affect many different types of databases. If you use an ORM or object relational mapping tool for your database, you should be safe from attacks like this. But of course, it's always a good idea to validate your input before it's sent to your database. Another very easy way to create a big problem as a developer is to expose, or leak a sensitive API key.

You can think of a private API key as a username and password all bundled up into a single string, and it allows your servers to securely communicate with paid services like AWS, Google Cloud, and so on. A few years ago, I Incidentally leaked my AWS API key, and it was almost really bad. I was using the Node SDK for a service that required the API key. I hard coded the API key directly in the source code instead of setting it as an environment variable. I then proceeded to push the source code to a public GitHub repo.

Whoopsies. A few weeks went by, and then all of a sudden, I get a notification from AWS that I've maxed out my budget. When I logged into my AWS account, I had racked up charges around $5,000 for EC 2 instances running all over the world. Luckily, Amazon was nice enough to refund those charges, but it definitely made me feel like an idiot. Nowadays, automatic scanners can often detect if you have an exposed API key and email you a notification.

But GitHub isn't the only place that you might leak an API key. When you include a private key in a client side web or mobile app, a hacker might be able to find it directly in your source code. Now if you do end up with an exposed API key, you can fix the problem by simply rolling it to a new value, and of course removing it from any public repos or source code. Many good APIs will help you minimize the damage by allowing you to assign privileges to a specific API key. This allows you to follow the principle of least privilege, and only give API keys access to the resources that they actually need.

That will mitigate the amount of damage that can be done if that key does end up being leaked. If we look at a major cloud provider like AWS, we'll see that they offer hundreds of different services, and they might be used by a company with thousands of employees working on different projects. Sharing a single API key that has access to everything would be a very bad idea. Instead, the major cloud providers have a system called I'm which allows you to create groups or roles for your organization. Once you've created a role, you can then attach a policy to that role to give it access to a service that it needs.

Implementing fine grained access control over your data is more important than ever. In 2016, an employee of Morrison Supermarkets in the UK stole the private data of over 100,000 employees. This rogue employee did it by simply copying the data onto a USB stick. Now this is obviously unethical and illegal on the employee's part, but the company itself is facing a huge lawsuit, and the penalties for data breaches are becoming larger with laws like GDPR and the EU. So the bottom line here is to always follow the principle of least privilege when it comes to accessing your customer or employee data.

And speaking of data, you might come across something called the CIA triad. It's a model for data security that stands for confidentiality, integrity, and availability. Generally speaking, you make data confidential by implementing user authentication so only authorized users can access the data. Integrity means the data can't be simply modified or deleted without the user's authorization. But I think the most interesting question is how do you make your data highly available?

In 2018, GitHub survived the biggest DDoS attack or distributed denial of service attack in history. It took GitHub down for less than 10 minutes, but that's Still a pretty big deal considering how many people around the world depend on GitHub at any given moment. A DDoS attack works by flooding a service with so much Traffic that it just fails to scale and completely stops working. You can see in this chart how the inbound traffic suddenly spiked, but the servers treated these as legitimate requests and responded with a normal response. GitHub is big enough to handle attacks like this, but smaller sites might not be so lucky.

In some cases, DDoS attacks have been used to shut down service, and then request a ransom from the owner. So how do you protect yourself? Well, the simple answer is to be ready to scale, and that likely means using a big cloud provider. A service like Google Cloud Armor has the bandwidth to handle attacks like this and it can also prevent many other attacks that we talked about earlier in the video. But at the end of the day, nobody's application is 100% safe.

There are likely hackers out there right now using 0 day exploits that we don't know about yet. And it's only a matter of time before the next major data breach is in the headlines. If this video helped you, please like and subscribe, and make sure to check out the Enterprise Security course if you really want to master these concepts. Thanks for watching, and I will talk to you soon.
If debugging is the process of removing software bugs, then programming must be the process of putting them in. In most cases, the bugs we introduce are harmless, But sometimes, they can cause us to lose 100 of 1,000,000 of dollars in a few minutes, crash airplanes and spaceships, and kill people.
bugs
Today, I want to tell you some stories about the most damaging hacks and bugs throughout history, tree, and explains 7 software security concepts that every developer should know. If you're new here, like and subscribe, and check out the full write up on FireShip. Io. There are billions upon billions of lines of code in production today, around 50,000,000 lines for Microsoft Windows, and over 2,000,000,000 lines across all Google services. And within all this code, we have vulnerabilities that have either not yet been discovered or not yet been fixed. These are known as 0 day vulnerabilities because as a developer, you have 0 days to get it fixed.
When a hacker decides to attack this vulnerability, it's known as a 0 day exploit. Remember that one time Equifax had exposed the credit reports of a 150 people. That wasn't the result of a 0 day exploit. It was the result of a known bug in Apache Struts that had already been fixed weeks ago.
security
What? I'm sorry. I fudged up, guys. Hackers, apparently from China, had been scanning the web for servers with this vulnerability. They hit the mother lode with Equifax and extracted sensitive information over the next 76 days. This breach has cost the company over a $1,000,000,000 and could have been prevented by installing a simple security patch. Being hacked by a known vulnerability is not uncommon at all. In fact, you're likely shipping code with a lot of known vulnerabilities right now. If you're a JS developer, go into your project and hit npm audit.
It will give you a breakdown of all the different ways you can be hacked via your open source dependencies. Now, there's no reason to panic. If you have hundreds of high severity alerts, The best way to avoid being hacked is to simply update your packages. But if you truly want to understand the flaws that are compromising these packages, You should enroll in the Enterprise Security course from Angular Academy. It's a 10 week long program that will teach you how to confidently build secure web applications. You'll find the link in the description, and you can use this code to take $50 off the enrollment price. Using components with known vulnerabilities is one of the most common ways that web applications get hacked, But it's also very preventable, because as you can see here, most of the issues have already been patched. And keep in mind, this issue isn't unique to JavaScript or NPM. All package managers that rely on Open source code face similar issues, so trust nobody and keep your packages updated.
security
But most of all, Sammy is my hero. Wait a second. I didn't mean to say that last part. It was somehow injected into this video. Back in 2005, a guy named Sammy used an exploit known as cross site Scripting to update a user's MySpace profile with this text. Within a day, it had spread to over a 1000000 users. It was mostly harmless, but they did arrest Sammy, convict him of a felony, And worst of all, took away his Internet for a year.
youtube
google
A cross site scripting exploit occurs when the attacker manages to run some JavaScript code on a different user's browser. There are a few different ways to achieve this, but the most common way is for the attacker to save the script in a web application's database. The malicious script will then accessed by a different user that will execute the JavaScript on the client side device. And at that point, the JavaScript code can submit forms, click on buttons on behalf of the logged in user. So how do you avoid cross site scripting attacks as a developer? Well, the attacker first needs to save some malicious code on your server. So Step 1 is to do some server side validation of incoming data. If it's surrounded by script tags, you might not wanna save it. But let's imagine you fail to sanitize the incoming data. The attacker still needs a way to run that script on the client side device, so the attacker is counting on you to render out the raw HTML of the script. Fortunately, modern front end frameworks make it really difficult to shoot yourself in the foot. In React, for example, if you want to write unsafe code, you have to use this dangerously set inner HTML Prop just to do so.
So with cross site scripting, we have malicious code running on the browser, but it's also possible to run bad code directly on a database. Let's go back to 2008 and look at a company named Heartland Payment Systems, a company with the highest standards and the most trusted transactions, and also a company that was the target of one of the most elaborate and interesting hacks of all time. The attackers first gained access to the company's databases by using a technique known as QL injection. Instead of sending the expected data to the database, they sent raw SQL statements. And because the data was not validated, the database would run this code as if it came from the developers. Now this particular database contained the information that you would find on the back of a magnetic strip on a credit card, and they used this stolen data to create counterfeit credit cards that actually worked. It's estimated that over a 100,000,000 cards were compromised, and the main hacker, Albert Gonzalez, was sentenced to 20 years in prison. Injection attacks similar to this affect many different types of databases. If you use an ORM or object relational mapping tool for your database, you should be safe from attacks like this. But of course, it's always a good idea to validate your input before it's sent to your database. Another very easy way to create a big problem as a developer is to expose, or leak a sensitive API key.
databases
security
cryptocurrency
banking
data
data management
You can think of a private API key as a username and password all bundled up into a single string, and it allows your servers to securely communicate with paid services like AWS, Google Cloud, and so on. A few years ago, I Incidentally leaked my AWS API key, and it was almost really bad. I was using the Node SDK for a service that required the API key.
I hard coded the API key directly in the source code instead of setting it as an environment variable. I then proceeded to push the source code to a public GitHub repo. Whoopsies. A few weeks went by, and then all of a sudden, I get a notification from AWS that I've maxed out my budget. When I logged into my AWS account, I had racked up charges around $5,000 for EC 2 instances running all over the world. Luckily, Amazon was nice enough to refund those charges, but it definitely made me feel like an idiot. Nowadays, automatic scanners can often detect if you have an exposed API key and email you a notification. But GitHub isn't the only place that you might leak an API key. When you include a private key in a client side web or mobile app, a hacker might be able to find it directly in your source code.
amazon
software
Now if you do end up with an exposed API key, you can fix the problem by simply rolling it to a new value, and of course removing it from any public repos or source code.
Many good APIs will help you minimize the damage by allowing you to assign privileges to a specific API key. This allows you to follow the principle of least privilege, and only give API keys access to the resources that they actually need. That will mitigate the amount of damage that can be done if that key does end up being leaked.
security
If we look at a major cloud provider like AWS, we'll see that they offer hundreds of different services, and they might be used by a company with thousands of employees working on different projects. Sharing a single API key that has access to everything would be a very bad idea. Instead, the major cloud providers have a system called I'm which allows you to create groups or roles for your organization.
Once you've created a role, you can then attach a policy to that role to give it access to a service that it needs. Implementing fine grained access control over your data is more important than ever. In 2016, an employee of Morrison Supermarkets in the UK stole the private data of over 100,000 employees. This rogue employee did it by simply copying the data onto a USB stick. Now this is obviously unethical and illegal on the employee's part, but the company itself is facing a huge lawsuit, and the penalties for data breaches are becoming larger with laws like GDPR and the EU. So the bottom line here is to always follow the principle of least privilege when it comes to accessing your customer or employee data. And speaking of data, you might come across something called the CIA triad. It's a model for data security that stands for confidentiality, integrity, and availability. Generally speaking, you make data confidential by implementing user authentication so only authorized users can access the data. Integrity means the data can't be simply modified or deleted without the user's authorization. But I think the most interesting question is how do you make your data highly available?
security
theft
data management
copyright licenses
data
databases
patents
law enforcement
intellectual property
litigation
In 2018, GitHub survived the biggest DDoS attack or distributed denial of service attack in history. It took GitHub down for less than 10 minutes, but that's Still a pretty big deal considering how many people around the world depend on GitHub at any given moment. A DDoS attack works by flooding a service with so much Traffic that it just fails to scale and completely stops working. You can see in this chart how the inbound traffic suddenly spiked, but the servers treated these as legitimate requests and responded with a normal response.
GitHub is big enough to handle attacks like this, but smaller sites might not be so lucky. In some cases, DDoS attacks have been used to shut down service, and then request a ransom from the owner. So how do you protect yourself? Well, the simple answer is to be ready to scale, and that likely means using a big cloud provider. A service like Google Cloud Armor has the bandwidth to handle attacks like this and it can also prevent many other attacks that we talked about earlier in the video. But at the end of the day, nobody's application is 100% safe. There are likely hackers out there right now using 0 day exploits that we don't know about yet. And it's only a matter of time before the next major data breach is in the headlines. If this video helped you, please like and subscribe, and make sure to check out the Enterprise Security course if you really want to master these concepts. Thanks for watching, and I will talk to you soon.
security
google
weapons
If debugging is the process of removing software bugs, then programming must be the process of putting them in. In most cases, the bugs we introduce are harmless, But sometimes, they can cause us to lose 100 of 1,000,000 of dollars in a few minutes, crash airplanes and spaceships, and kill people. Today, I want to tell you some stories about the most damaging hacks and bugs throughout history, tree, and explains 7 software security concepts that every developer should know. If you're new here, like and subscribe, and check out the full write up on FireShip. Io. There are billions upon billions of lines of code in production today, around 50,000,000 lines for Microsoft Windows, and over 2,000,000,000 lines across all Google services. And within all this code, we have vulnerabilities that have either not yet been discovered or not yet been fixed. These are known as 0 day vulnerabilities because as a developer, you have 0 days to get it fixed. When a hacker decides to attack this vulnerability, it's known as a 0 day exploit. Remember that one time Equifax had exposed the credit reports of a 150 people. That wasn't the result of a 0 day exploit. It was the result of a known bug in Apache Struts that had already been fixed weeks ago. What? I'm sorry. I fudged up, guys. Hackers, apparently from China, had been scanning the web for servers with this vulnerability. They hit the mother lode with Equifax and extracted sensitive information over the next 76 days. This breach has cost the company over a $1,000,000,000 and could have been prevented by installing a simple security patch. Being hacked by a known vulnerability is not uncommon at all. In fact, you're likely shipping code with a lot of known vulnerabilities right now. If you're a JS developer, go into your project and hit npm audit. It will give you a breakdown of all the different ways you can be hacked via your open source dependencies. Now, there's no reason to panic. If you have hundreds of high severity alerts, The best way to avoid being hacked is to simply update your packages. But if you truly want to understand the flaws that are compromising these packages, You should enroll in the Enterprise Security course from Angular Academy. It's a 10 week long program that will teach you how to confidently build secure web applications. You'll find the link in the description, and you can use this code to take $50 off the enrollment price. Using components with known vulnerabilities is one of the most common ways that web applications get hacked, But it's also very preventable, because as you can see here, most of the issues have already been patched. And keep in mind, this issue isn't unique to JavaScript or NPM. All package managers that rely on Open source code face similar issues, so trust nobody and keep your packages updated. But most of all, Sammy is my hero. Wait a second. I didn't mean to say that last part. It was somehow injected into this video. Back in 2005, a guy named Sammy used an exploit known as cross site Scripting to update a user's MySpace profile with this text. Within a day, it had spread to over a 1000000 users. It was mostly harmless, but they did arrest Sammy, convict him of a felony, And worst of all, took away his Internet for a year. A cross site scripting exploit occurs when the attacker manages to run some JavaScript code on a different user's browser. There are a few different ways to achieve this, but the most common way is for the attacker to save the script in a web application's database. The malicious script will then accessed by a different user that will execute the JavaScript on the client side device. And at that point, the JavaScript code can submit forms, click on buttons on behalf of the logged in user. So how do you avoid cross site scripting attacks as a developer? Well, the attacker first needs to save some malicious code on your server. So Step 1 is to do some server side validation of incoming data. If it's surrounded by script tags, you might not wanna save it. But let's imagine you fail to sanitize the incoming data. The attacker still needs a way to run that script on the client side device, so the attacker is counting on you to render out the raw HTML of the script. Fortunately, modern front end frameworks make it really difficult to shoot yourself in the foot. In React, for example, if you want to write unsafe code, you have to use this dangerously set inner HTML Prop just to do so. So with cross site scripting, we have malicious code running on the browser, but it's also possible to run bad code directly on a database. Let's go back to 2008 and look at a company named Heartland Payment Systems, a company with the highest standards and the most trusted transactions, and also a company that was the target of one of the most elaborate and interesting hacks of all time. The attackers first gained access to the company's databases by using a technique known as QL injection. Instead of sending the expected data to the database, they sent raw SQL statements. And because the data was not validated, the database would run this code as if it came from the developers. Now this particular database contained the information that you would find on the back of a magnetic strip on a credit card, and they used this stolen data to create counterfeit credit cards that actually worked. It's estimated that over a 100,000,000 cards were compromised, and the main hacker, Albert Gonzalez, was sentenced to 20 years in prison. Injection attacks similar to this affect many different types of databases. If you use an ORM or object relational mapping tool for your database, you should be safe from attacks like this. But of course, it's always a good idea to validate your input before it's sent to your database. Another very easy way to create a big problem as a developer is to expose, or leak a sensitive API key. You can think of a private API key as a username and password all bundled up into a single string, and it allows your servers to securely communicate with paid services like AWS, Google Cloud, and so on. A few years ago, I Incidentally leaked my AWS API key, and it was almost really bad. I was using the Node SDK for a service that required the API key. I hard coded the API key directly in the source code instead of setting it as an environment variable. I then proceeded to push the source code to a public GitHub repo. Whoopsies. A few weeks went by, and then all of a sudden, I get a notification from AWS that I've maxed out my budget. When I logged into my AWS account, I had racked up charges around $5,000 for EC 2 instances running all over the world. Luckily, Amazon was nice enough to refund those charges, but it definitely made me feel like an idiot. Nowadays, automatic scanners can often detect if you have an exposed API key and email you a notification. But GitHub isn't the only place that you might leak an API key. When you include a private key in a client side web or mobile app, a hacker might be able to find it directly in your source code. Now if you do end up with an exposed API key, you can fix the problem by simply rolling it to a new value, and of course removing it from any public repos or source code. Many good APIs will help you minimize the damage by allowing you to assign privileges to a specific API key. This allows you to follow the principle of least privilege, and only give API keys access to the resources that they actually need. That will mitigate the amount of damage that can be done if that key does end up being leaked. If we look at a major cloud provider like AWS, we'll see that they offer hundreds of different services, and they might be used by a company with thousands of employees working on different projects. Sharing a single API key that has access to everything would be a very bad idea. Instead, the major cloud providers have a system called I'm which allows you to create groups or roles for your organization. Once you've created a role, you can then attach a policy to that role to give it access to a service that it needs. Implementing fine grained access control over your data is more important than ever. In 2016, an employee of Morrison Supermarkets in the UK stole the private data of over 100,000 employees. This rogue employee did it by simply copying the data onto a USB stick. Now this is obviously unethical and illegal on the employee's part, but the company itself is facing a huge lawsuit, and the penalties for data breaches are becoming larger with laws like GDPR and the EU. So the bottom line here is to always follow the principle of least privilege when it comes to accessing your customer or employee data. And speaking of data, you might come across something called the CIA triad. It's a model for data security that stands for confidentiality, integrity, and availability. Generally speaking, you make data confidential by implementing user authentication so only authorized users can access the data. Integrity means the data can't be simply modified or deleted without the user's authorization. But I think the most interesting question is how do you make your data highly available? In 2018, GitHub survived the biggest DDoS attack or distributed denial of service attack in history. It took GitHub down for less than 10 minutes, but that's Still a pretty big deal considering how many people around the world depend on GitHub at any given moment. A DDoS attack works by flooding a service with so much Traffic that it just fails to scale and completely stops working. You can see in this chart how the inbound traffic suddenly spiked, but the servers treated these as legitimate requests and responded with a normal response. GitHub is big enough to handle attacks like this, but smaller sites might not be so lucky. In some cases, DDoS attacks have been used to shut down service, and then request a ransom from the owner. So how do you protect yourself? Well, the simple answer is to be ready to scale, and that likely means using a big cloud provider. A service like Google Cloud Armor has the bandwidth to handle attacks like this and it can also prevent many other attacks that we talked about earlier in the video. But at the end of the day, nobody's application is 100% safe. There are likely hackers out there right now using 0 day exploits that we don't know about yet. And it's only a matter of time before the next major data breach is in the headlines. If this video helped you, please like and subscribe, and make sure to check out the Enterprise Security course if you really want to master these concepts. Thanks for watching, and I will talk to you soon.
If
if
debugging
debugging
is
is
the
the
process
process
of
of
removing
removing
software
software
bugs,
bugs
then
then
programming
programming
must
must
be
be
the
the
process
process
of
of
putting
putting
them
them
in.
in
In
in
most
most
cases,
cases
the
the
bugs
bugs
we
we
introduce
introduce
are
are
harmless,
harmless
But
but
sometimes,
sometimes
they
they
can
can
cause
cause
us
us
to
to
lose
lose
100
100
of
of
1,000,000
1,000,000
of
of
dollars
dollars
in
in
a
a
few
few
minutes,
minutes
crash
crash
airplanes
airplanes
and
and
spaceships,
spaceships
and
and
kill
kill
people.
people
Today,
today
I
i
want
want
to
to
tell
tell
you
you
some
some
stories
stories
about
about
the
the
most
most
damaging
damaging
hacks
hacks
and
and
bugs
bugs
throughout
throughout
history,
history
tree,
tree
and
and
explains
explains
7
7
software
software
security
security
concepts
concepts
that
that
every
every
developer
developer
should
should
know.
know
If
if
you're
you're
new
new
here,
here
like
like
and
and
subscribe,
subscribe
and
and
check
check
out
out
the
the
full
full
write
write
up
up
on
on
FireShip.
fireship
Io.
io
There
there
are
are
billions
billions
upon
upon
billions
billions
of
of
lines
lines
of
of
code
code
in
in
production
production
today,
today
around
around
50,000,000
50,000,000
lines
lines
for
for
Microsoft
microsoft
Windows,
windows
and
and
over
over
2,000,000,000
2,000,000,000
lines
lines
across
across
all
all
Google
google
services.
services
And
and
within
within
all
all
this
this
code,
code
we
we
have
have
vulnerabilities
vulnerabilities
that
that
have
have
either
either
not
not
yet
yet
been
been
discovered
discovered
or
or
not
not
yet
yet
been
been
fixed.
fixed
These
these
are
are
known
known
as
as
0
0
day
day
vulnerabilities
vulnerabilities
because
because
as
as
a
a
developer,
developer
you
you
have
have
0
0
days
days
to
to
get
get
it
it
fixed.
fixed
When
when
a
a
hacker
hacker
decides
decides
to
to
attack
attack
this
this
vulnerability,
vulnerability
it's
it's
known
known
as
as
a
a
0
0
day
day
exploit.
exploit
Remember
remember
that
that
one
one
time
time
Equifax
equifax
had
had
exposed
exposed
the
the
credit
credit
reports
reports
of
of
a
a
150
150
people.
people
That
that
wasn't
wasn't
the
the
result
result
of
of
a
a
0
0
day
day
exploit.
exploit
It
it
was
was
the
the
result
result
of
of
a
a
known
known
bug
bug
in
in
Apache
apache
Struts
struts
that
that
had
had
already
already
been
been
fixed
fixed
weeks
weeks
ago.
ago
What?
what
I'm
i'm
sorry.
sorry
I
i
fudged
fudged
up,
up
guys.
guys
Hackers,
hackers
apparently
apparently
from
from
China,
china
had
had
been
been
scanning
scanning
the
the
web
web
for
for
servers
servers
with
with
this
this
vulnerability.
vulnerability
They
they
hit
hit
the
the
mother
mother
lode
lode
with
with
Equifax
equifax
and
and
extracted
extracted
sensitive
sensitive
information
information
over
over
the
the
next
next
76
76
days.
days
This
this
breach
breach
has
has
cost
cost
the
the
company
company
over
over
a
a
$1,000,000,000
$1,000,000,000
and
and
could
could
have
have
been
been
prevented
prevented
by
by
installing
installing
a
a
simple
simple
security
security
patch.
patch
Being
being
hacked
hacked
by
by
a
a
known
known
vulnerability
vulnerability
is
is
not
not
uncommon
uncommon
at
at
all.
all
In
in
fact,
fact
you're
you're
likely
likely
shipping
shipping
code
code
with
with
a
a
lot
lot
of
of
known
known
vulnerabilities
vulnerabilities
right
right
now.
now
If
if
you're
you're
a
a
JS
js
developer,
developer
go
go
into
into
your
your
project
project
and
and
hit
hit
npm
npm
audit.
audit
It
it
will
will
give
give
you
you
a
a
breakdown
breakdown
of
of
all
all
the
the
different
different
ways
ways
you
you
can
can
be
be
hacked
hacked
via
via
your
your
open
open
source
source
dependencies.
dependencies
Now,
now
there's
there's
no
no
reason
reason
to
to
panic.
panic
If
if
you
you
have
have
hundreds
hundreds
of
of
high
high
severity
severity
alerts,
alerts
The
the
best
best
way
way
to
to
avoid
avoid
being
being
hacked
hacked
is
is
to
to
simply
simply
update
update
your
your
packages.
packages
But
but
if
if
you
you
truly
truly
want
want
to
to
understand
understand
the
the
flaws
flaws
that
that
are
are
compromising
compromising
these
these
packages,
packages
You
you
should
should
enroll
enroll
in
in
the
the
Enterprise
enterprise
Security
security
course
course
from
from
Angular
angular
Academy.
academy
It's
it's
a
a
10
10
week
week
long
long
program
program
that
that
will
will
teach
teach
you
you
how
how
to
to
confidently
confidently
build
build
secure
secure
web
web
applications.
applications
You'll
you'll
find
find
the
the
link
link
in
in
the
the
description,
description
and
and
you
you
can
can
use
use
this
this
code
code
to
to
take
take
$50
$50
off
off
the
the
enrollment
enrollment
price.
price
Using
using
components
components
with
with
known
known
vulnerabilities
vulnerabilities
is
is
one
one
of
of
the
the
most
most
common
common
ways
ways
that
that
web
web
applications
applications
get
get
hacked,
hacked
But
but
it's
it's
also
also
very
very
preventable,
preventable
because
because
as
as
you
you
can
can
see
see
here,
here
most
most
of
of
the
the
issues
issues
have
have
already
already
been
been
patched.
patched
And
and
keep
keep
in
in
mind,
mind
this
this
issue
issue
isn't
isn't
unique
unique
to
to
JavaScript
javascript
or
or
NPM.
npm
All
all
package
package
managers
managers
that
that
rely
rely
on
on
Open
open
source
source
code
code
face
face
similar
similar
issues,
issues
so
so
trust
trust
nobody
nobody
and
and
keep
keep
your
your
packages
packages
updated.
updated
But
but
most
most
of
of
all,
all
Sammy
sammy
is
is
my
my
hero.
hero
Wait
wait
a
a
second.
second
I
i
didn't
didn't
mean
mean
to
to
say
say
that
that
last
last
part.
part
It
it
was
was
somehow
somehow
injected
injected
into
into
this
this
video.
video
Back
back
in
in
2005,
2005
a
a
guy
guy
named
named
Sammy
sammy
used
used
an
an
exploit
exploit
known
known
as
as
cross
cross
site
site
Scripting
scripting
to
to
update
update
a
a
user's
user's
MySpace
myspace
profile
profile
with
with
this
this
text.
text
Within
within
a
a
day,
day
it
it
had
had
spread
spread
to
to
over
over
a
a
1000000
1000000
users.
users
It
it
was
was
mostly
mostly
harmless,
harmless
but
but
they
they
did
did
arrest
arrest
Sammy,
sammy
convict
convict
him
him
of
of
a
a
felony,
felony
And
and
worst
worst
of
of
all,
all
took
took
away
away
his
his
Internet
internet
for
for
a
a
year.
year
A
a
cross
cross
site
site
scripting
scripting
exploit
exploit
occurs
occurs
when
when
the
the
attacker
attacker
manages
manages
to
to
run
run
some
some
JavaScript
javascript
code
code
on
on
a
a
different
different
user's
user's
browser.
browser
There
there
are
are
a
a
few
few
different
different
ways
ways
to
to
achieve
achieve
this,
this
but
but
the
the
most
most
common
common
way
way
is
is
for
for
the
the
attacker
attacker
to
to
save
save
the
the
script
script
in
in
a
a
web
web
application's
application's
database.
database
The
the
malicious
malicious
script
script
will
will
then
then
accessed
accessed
by
by
a
a
different
different
user
user
that
that
will
will
execute
execute
the
the
JavaScript
javascript
on
on
the
the
client
client
side
side
device.
device
And
and
at
at
that
that
point,
point
the
the
JavaScript
javascript
code
code
can
can
submit
submit
forms,
forms
click
click
on
on
buttons
buttons
on
on
behalf
behalf
of
of
the
the
logged
logged
in
in
user.
user
So
so
how
how
do
do
you
you
avoid
avoid
cross
cross
site
site
scripting
scripting
attacks
attacks
as
as
a
a
developer?
developer
Well,
well
the
the
attacker
attacker
first
first
needs
needs
to
to
save
save
some
some
malicious
malicious
code
code
on
on
your
your
server.
server
So
so
Step
step
1
1
is
is
to
to
do
do
some
some
server
server
side
side
validation
validation
of
of
incoming
incoming
data.
data
If
if
it's
it's
surrounded
surrounded
by
by
script
script
tags,
tags
you
you
might
might
not
not
wanna
wanna
save
save
it.
it
But
but
let's
let's
imagine
imagine
you
you
fail
fail
to
to
sanitize
sanitize
the
the
incoming
incoming
data.
data
The
the
attacker
attacker
still
still
needs
needs
a
a
way
way
to
to
run
run
that
that
script
script
on
on
the
the
client
client
side
side
device,
device
so
so
the
the
attacker
attacker
is
is
counting
counting
on
on
you
you
to
to
render
render
out
out
the
the
raw
raw
HTML
html
of
of
the
the
script.
script
Fortunately,
fortunately
modern
modern
front
front
end
end
frameworks
frameworks
make
make
it
it
really
really
difficult
difficult
to
to
shoot
shoot
yourself
yourself
in
in
the
the
foot.
foot
In
in
React,
react
for
for
example,
example
if
if
you
you
want
want
to
to
write
write
unsafe
unsafe
code,
code
you
you
have
have
to
to
use
use
this
this
dangerously
dangerously
set
set
inner
inner
HTML
html
Prop
prop
just
just
to
to
do
do
so.
so
So
so
with
with
cross
cross
site
site
scripting,
scripting
we
we
have
have
malicious
malicious
code
code
running
running
on
on
the
the
browser,
browser
but
but
it's
it's
also
also
possible
possible
to
to
run
run
bad
bad
code
code
directly
directly
on
on
a
a
database.
database
Let's
let's
go
go
back
back
to
to
2008
2008
and
and
look
look
at
at
a
a
company
company
named
named
Heartland
heartland
Payment
payment
Systems,
systems
a
a
company
company
with
with
the
the
highest
highest
standards
standards
and
and
the
the
most
most
trusted
trusted
transactions,
transactions
and
and
also
also
a
a
company
company
that
that
was
was
the
the
target
target
of
of
one
one
of
of
the
the
most
most
elaborate
elaborate
and
and
interesting
interesting
hacks
hacks
of
of
all
all
time.
time
The
the
attackers
attackers
first
first
gained
gained
access
access
to
to
the
the
company's
company's
databases
databases
by
by
using
using
a
a
technique
technique
known
known
as
as
QL
ql
injection.
injection
Instead
instead
of
of
sending
sending
the
the
expected
expected
data
data
to
to
the
the
database,
database
they
they
sent
sent
raw
raw
SQL
sql
statements.
statements
And
and
because
because
the
the
data
data
was
was
not
not
validated,
validated
the
the
database
database
would
would
run
run
this
this
code
code
as
as
if
if
it
it
came
came
from
from
the
the
developers.
developers
Now
now
this
this
particular
particular
database
database
contained
contained
the
the
information
information
that
that
you
you
would
would
find
find
on
on
the
the
back
back
of
of
a
a
magnetic
magnetic
strip
strip
on
on
a
a
credit
credit
card,
card
and
and
they
they
used
used
this
this
stolen
stolen
data
data
to
to
create
create
counterfeit
counterfeit
credit
credit
cards
cards
that
that
actually
actually
worked.
worked
It's
it's
estimated
estimated
that
that
over
over
a
a
100,000,000
100,000,000
cards
cards
were
were
compromised,
compromised
and
and
the
the
main
main
hacker,
hacker
Albert
albert
Gonzalez,
gonzalez
was
was
sentenced
sentenced
to
to
20
20
years
years
in
in
prison.
prison
Injection
injection
attacks
attacks
similar
similar
to
to
this
this
affect
affect
many
many
different
different
types
types
of
of
databases.
databases
If
if
you
you
use
use
an
an
ORM
orm
or
or
object
object
relational
relational
mapping
mapping
tool
tool
for
for
your
your
database,
database
you
you
should
should
be
be
safe
safe
from
from
attacks
attacks
like
like
this.
this
But
but
of
of
course,
course
it's
it's
always
always
a
a
good
good
idea
idea
to
to
validate
validate
your
your
input
input
before
before
it's
it's
sent
sent
to
to
your
your
database.
database
Another
another
very
very
easy
easy
way
way
to
to
create
create
a
a
big
big
problem
problem
as
as
a
a
developer
developer
is
is
to
to
expose,
expose
or
or
leak
leak
a
a
sensitive
sensitive
API
api
key.
key
You
you
can
can
think
think
of
of
a
a
private
private
API
api
key
key
as
as
a
a
username
username
and
and
password
password
all
all
bundled
bundled
up
up
into
into
a
a
single
single
string,
string
and
and
it
it
allows
allows
your
your
servers
servers
to
to
securely
securely
communicate
communicate
with
with
paid
paid
services
services
like
like
AWS,
aws
Google
google
Cloud,
cloud
and
and
so
so
on.
on
A
a
few
few
years
years
ago,
ago
I
i
Incidentally
incidentally
leaked
leaked
my
my
AWS
aws
API
api
key,
key
and
and
it
it
was
was
almost
almost
really
really
bad.
bad
I
i
was
was
using
using
the
the
Node
node
SDK
sdk
for
for
a
a
service
service
that
that
required
required
the
the
API
api
key.
key
I
i
hard
hard
coded
coded
the
the
API
api
key
key
directly
directly
in
in
the
the
source
source
code
code
instead
instead
of
of
setting
setting
it
it
as
as
an
an
environment
environment
variable.
variable
I
i
then
then
proceeded
proceeded
to
to
push
push
the
the
source
source
code
code
to
to
a
a
public
public
GitHub
github
repo.
repo
Whoopsies.
whoopsies
A
a
few
few
weeks
weeks
went
went
by,
by
and
and
then
then
all
all
of
of
a
a
sudden,
sudden
I
i
get
get
a
a
notification
notification
from
from
AWS
aws
that
that
I've
i've
maxed
maxed
out
out
my
my
budget.
budget
When
when
I
i
logged
logged
into
into
my
my
AWS
aws
account,
account
I
i
had
had
racked
racked
up
up
charges
charges
around
around
$5,000
$5,000
for
for
EC
ec
2
2
instances
instances
running
running
all
all
over
over
the
the
world.
world
Luckily,
luckily
Amazon
amazon
was
was
nice
nice
enough
enough
to
to
refund
refund
those
those
charges,
charges
but
but
it
it
definitely
definitely
made
made
me
me
feel
feel
like
like
an
an
idiot.
idiot
Nowadays,
nowadays
automatic
automatic
scanners
scanners
can
can
often
often
detect
detect
if
if
you
you
have
have
an
an
exposed
exposed
API
api
key
key
and
and
email
email
you
you
a
a
notification.
notification
But
but
GitHub
github
isn't
isn't
the
the
only
only
place
place
that
that
you
you
might
might
leak
leak
an
an
API
api
key.
key
When
when
you
you
include
include
a
a
private
private
key
key
in
in
a
a
client
client
side
side
web
web
or
or
mobile
mobile
app,
app
a
a
hacker
hacker
might
might
be
be
able
able
to
to
find
find
it
it
directly
directly
in
in
your
your
source
source
code.
code
Now
now
if
if
you
you
do
do
end
end
up
up
with
with
an
an
exposed
exposed
API
api
key,
key
you
you
can
can
fix
fix
the
the
problem
problem
by
by
simply
simply
rolling
rolling
it
it
to
to
a
a
new
new
value,
value
and
and
of
of
course
course
removing
removing
it
it
from
from
any
any
public
public
repos
repos
or
or
source
source
code.
code
Many
many
good
good
APIs
apis
will
will
help
help
you
you
minimize
minimize
the
the
damage
damage
by
by
allowing
allowing
you
you
to
to
assign
assign
privileges
privileges
to
to
a
a
specific
specific
API
api
key.
key
This
this
allows
allows
you
you
to
to
follow
follow
the
the
principle
principle
of
of
least
least
privilege,
privilege
and
and
only
only
give
give
API
api
keys
keys
access
access
to
to
the
the
resources
resources
that
that
they
they
actually
actually
need.
need
That
that
will
will
mitigate
mitigate
the
the
amount
amount
of
of
damage
damage
that
that
can
can
be
be
done
done
if
if
that
that
key
key
does
does
end
end
up
up
being
being
leaked.
leaked
If
if
we
we
look
look
at
at
a
a
major
major
cloud
cloud
provider
provider
like
like
AWS,
aws
we'll
we'll
see
see
that
that
they
they
offer
offer
hundreds
hundreds
of
of
different
different
services,
services
and
and
they
they
might
might
be
be
used
used
by
by
a
a
company
company
with
with
thousands
thousands
of
of
employees
employees
working
working
on
on
different
different
projects.
projects
Sharing
sharing
a
a
single
single
API
api
key
key
that
that
has
has
access
access
to
to
everything
everything
would
would
be
be
a
a
very
very
bad
bad
idea.
idea
Instead,
instead
the
the
major
major
cloud
cloud
providers
providers
have
have
a
a
system
system
called
called
I'm
i'm
which
which
allows
allows
you
you
to
to
create
create
groups
groups
or
or
roles
roles
for
for
your
your
organization.
organization
Once
once
you've
you've
created
created
a
a
role,
role
you
you
can
can
then
then
attach
attach
a
a
policy
policy
to
to
that
that
role
role
to
to
give
give
it
it
access
access
to
to
a
a
service
service
that
that
it
it
needs.
needs
Implementing
implementing
fine
fine
grained
grained
access
access
control
control
over
over
your
your
data
data
is
is
more
more
important
important
than
than
ever.
ever
In
in
2016,
2016
an
an
employee
employee
of
of
Morrison
morrison
Supermarkets
supermarkets
in
in
the
the
UK
uk
stole
stole
the
the
private
private
data
data
of
of
over
over
100,000
100,000
employees.
employees
This
this
rogue
rogue
employee
employee
did
did
it
it
by
by
simply
simply
copying
copying
the
the
data
data
onto
onto
a
a
USB
usb
stick.
stick
Now
now
this
this
is
is
obviously
obviously
unethical
unethical
and
and
illegal
illegal
on
on
the
the
employee's
employee's
part,
part
but
but
the
the
company
company
itself
itself
is
is
facing
facing
a
a
huge
huge
lawsuit,
lawsuit
and
and
the
the
penalties
penalties
for
for
data
data
breaches
breaches
are
are
becoming
becoming
larger
larger
with
with
laws
laws
like
like
GDPR
gdpr
and
and
the
the
EU.
eu
So
so
the
the
bottom
bottom
line
line
here
here
is
is
to
to
always
always
follow
follow
the
the
principle
principle
of
of
least
least
privilege
privilege
when
when
it
it
comes
comes
to
to
accessing
accessing
your
your
customer
customer
or
or
employee
employee
data.
data
And
and
speaking
speaking
of
of
data,
data
you
you
might
might
come
come
across
across
something
something
called
called
the
the
CIA
cia
triad.
triad
It's
it's
a
a
model
model
for
for
data
data
security
security
that
that
stands
stands
for
for
confidentiality,
confidentiality
integrity,
integrity
and
and
availability.
availability
Generally
generally
speaking,
speaking
you
you
make
make
data
data
confidential
confidential
by
by
implementing
implementing
user
user
authentication
authentication
so
so
only
only
authorized
authorized
users
users
can
can
access
access
the
the
data.
data
Integrity
integrity
means
means
the
the
data
data
can't
can't
be
be
simply
simply
modified
modified
or
or
deleted
deleted
without
without
the
the
user's
user's
authorization.
authorization
But
but
I
i
think
think
the
the
most
most
interesting
interesting
question
question
is
is
how
how
do
do
you
you
make
make
your
your
data
data
highly
highly
available?
available
In
in
2018,
2018
GitHub
github
survived
survived
the
the
biggest
biggest
DDoS
ddos
attack
attack
or
or
distributed
distributed
denial
denial
of
of
service
service
attack
attack
in
in
history.
history
It
it
took
took
GitHub
github
down
down
for
for
less
less
than
than
10
10
minutes,
minutes
but
but
that's
that's
Still
still
a
a
pretty
pretty
big
big
deal
deal
considering
considering
how
how
many
many
people
people
around
around
the
the
world
world
depend
depend
on
on
GitHub
github
at
at
any
any
given
given
moment.
moment
A
a
DDoS
ddos
attack
attack
works
works
by
by
flooding
flooding
a
a
service
service
with
with
so
so
much
much
Traffic
traffic
that
that
it
it
just
just
fails
fails
to
to
scale
scale
and
and
completely
completely
stops
stops
working.
working
You
you
can
can
see
see
in
in
this
this
chart
chart
how
how
the
the
inbound
inbound
traffic
traffic
suddenly
suddenly
spiked,
spiked
but
but
the
the
servers
servers
treated
treated
these
these
as
as
legitimate
legitimate
requests
requests
and
and
responded
responded
with
with
a
a
normal
normal
response.
response
GitHub
github
is
is
big
big
enough
enough
to
to
handle
handle
attacks
attacks
like
like
this,
this
but
but
smaller
smaller
sites
sites
might
might
not
not
be
be
so
so
lucky.
lucky
In
in
some
some
cases,
cases
DDoS
ddos
attacks
attacks
have
have
been
been
used
used
to
to
shut
shut
down
down
service,
service
and
and
then
then
request
request
a
a
ransom
ransom
from
from
the
the
owner.
owner
So
so
how
how
do
do
you
you
protect
protect
yourself?
yourself
Well,
well
the
the
simple
simple
answer
answer
is
is
to
to
be
be
ready
ready
to
to
scale,
scale
and
and
that
that
likely
likely
means
means
using
using
a
a
big
big
cloud
cloud
provider.
provider
A
a
service
service
like
like
Google
google
Cloud
cloud
Armor
armor
has
has
the
the
bandwidth
bandwidth
to
to
handle
handle
attacks
attacks
like
like
this
this
and
and
it
it
can
can
also
also
prevent
prevent
many
many
other
other
attacks
attacks
that
that
we
we
talked
talked
about
about
earlier
earlier
in
in
the
the
video.
video
But
but
at
at
the
the
end
end
of
of
the
the
day,
day
nobody's
nobody's
application
application
is
is
100%
100%
safe.
safe
There
there
are
are
likely
likely
hackers
hackers
out
out
there
there
right
right
now
now
using
using
0
0
day
day
exploits
exploits
that
that
we
we
don't
don't
know
know
about
about
yet.
yet
And
and
it's
it's
only
only
a
a
matter
matter
of
of
time
time
before
before
the
the
next
next
major
major
data
data
breach
breach
is
is
in
in
the
the
headlines.
headlines
If
if
this
this
video
video
helped
helped
you,
you
please
please
like
like
and
and
subscribe,
subscribe
and
and
make
make
sure
sure
to
to
check
check
out
out
the
the
Enterprise
enterprise
Security
security
course
course
if
if
you
you
really
really
want
want
to
to
master
master
these
these
concepts.
concepts
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
talk
talk
to
to
you
you
soon.
soon
success
The speaker expresses concern about potential risks of code vulnerabilities and recommends enrolling in a security course to avoid them. They also provide advice on avoiding cross site scripting attacks and recommend enrolling in a recommendation for Heartland Payment Systems. The speaker discusses issues with cross site scripting attacks and the potential for attacks on databases and systems, including a recent leaked API key causing thousands of cards to be compromised. They stress the importance of following principles of least privilege and protecting oneself from attacks, as well as the use of a CIA Triad model for data security and potential DDoS attacks.
7 Security Risks and Hacking Stories for Web Developers
If debugging is the process of removing software bugs, then programming must be the process of putting them in. In most cases, the bugs we introduce are harmless, But sometimes, they can cause us to lose 100 of 1,000,000 of dollars in a few minutes, crash airplanes and spaceships, and kill people. Today, I want to tell you some stories about the most damaging hacks and bugs throughout history, tree, and explains 7 software security concepts that every developer should know. If you're new here, like and subscribe, and check out the full write up on FireShip. Io. There are billions upon billions of lines of code in production today, around 50,000,000 lines for Microsoft Windows, and over 2,000,000,000 lines across all Google services. And within all this code, we have vulnerabilities that have either not yet been discovered or not yet been fixed. These are known as 0 day vulnerabilities because as a developer, you have 0 days to get it fixed. When a hacker decides to attack this vulnerability, it's known as a 0 day exploit. Remember that one time Equifax had exposed the credit reports of a 150 people. That wasn't the result of a 0 day exploit. It was the result of a known bug in Apache Struts that had already been fixed weeks ago. What? I'm sorry. I fudged up, guys. Hackers, apparently from China, had been scanning the web for servers with this vulnerability. They hit the mother lode with Equifax and extracted sensitive information over the next 76 days. This breach has cost the company over a $1,000,000,000 and could have been prevented by installing a simple security patch. Being hacked by a known vulnerability is not uncommon at all. In fact, you're likely shipping code with a lot of known vulnerabilities right now. If you're a JS developer, go into your project and hit npm audit. It will give you a breakdown of all the different ways you can be hacked via your open source dependencies. Now, there's no reason to panic. If you have hundreds of high severity alerts, The best way to avoid being hacked is to simply update your packages. But if you truly want to understand the flaws that are compromising these packages, You should enroll in the Enterprise Security course from Angular Academy. It's a 10 week long program that will teach you how to confidently build secure web applications. You'll find the link in the description, and you can use this code to take $50 off the enrollment price. Using components with known vulnerabilities is one of the most common ways that web applications get hacked, But it's also very preventable, because as you can see here, most of the issues have already been patched. And keep in mind, this issue isn't unique to JavaScript or NPM. All package managers that rely on Open source code face similar issues, so trust nobody and keep your packages updated. But most of all, Sammy is my hero. Wait a second. I didn't mean to say that last part. It was somehow injected into this video. Back in 2005, a guy named Sammy used an exploit known as cross site Scripting to update a user's MySpace profile with this text. Within a day, it had spread to over a 1000000 users. It was mostly harmless, but they did arrest Sammy, convict him of a felony, And worst of all, took away his Internet for a year. A cross site scripting exploit occurs when the attacker manages to run some JavaScript code on a different user's browser. There are a few different ways to achieve this, but the most common way is for the attacker to save the script in a web application's database. The malicious script will then accessed by a different user that will execute the JavaScript on the client side device. And at that point, the JavaScript code can submit forms, click on buttons on behalf of the logged in user. So how do you avoid cross site scripting attacks as a developer? Well, the attacker first needs to save some malicious code on your server. So Step 1 is to do some server side validation of incoming data. If it's surrounded by script tags, you might not wanna save it. But let's imagine you fail to sanitize the incoming data. The attacker still needs a way to run that script on the client side device, so the attacker is counting on you to render out the raw HTML of the script. Fortunately, modern front end frameworks make it really difficult to shoot yourself in the foot. In React, for example, if you want to write unsafe code, you have to use this dangerously set inner HTML Prop just to do so. So with cross site scripting, we have malicious code running on the browser, but it's also possible to run bad code directly on a database. Let's go back to 2008 and look at a company named Heartland Payment Systems, a company with the highest standards and the most trusted transactions, and also a company that was the target of one of the most elaborate and interesting hacks of all time. The attackers first gained access to the company's databases by using a technique known as QL injection. Instead of sending the expected data to the database, they sent raw SQL statements. And because the data was not validated, the database would run this code as if it came from the developers. Now this particular database contained the information that you would find on the back of a magnetic strip on a credit card, and they used this stolen data to create counterfeit credit cards that actually worked. It's estimated that over a 100,000,000 cards were compromised, and the main hacker, Albert Gonzalez, was sentenced to 20 years in prison. Injection attacks similar to this affect many different types of databases. If you use an ORM or object relational mapping tool for your database, you should be safe from attacks like this. But of course, it's always a good idea to validate your input before it's sent to your database. Another very easy way to create a big problem as a developer is to expose, or leak a sensitive API key. You can think of a private API key as a username and password all bundled up into a single string, and it allows your servers to securely communicate with paid services like AWS, Google Cloud, and so on. A few years ago, I Incidentally leaked my AWS API key, and it was almost really bad. I was using the Node SDK for a service that required the API key. I hard coded the API key directly in the source code instead of setting it as an environment variable. I then proceeded to push the source code to a public GitHub repo. Whoopsies. A few weeks went by, and then all of a sudden, I get a notification from AWS that I've maxed out my budget. When I logged into my AWS account, I had racked up charges around $5,000 for EC 2 instances running all over the world. Luckily, Amazon was nice enough to refund those charges, but it definitely made me feel like an idiot. Nowadays, automatic scanners can often detect if you have an exposed API key and email you a notification. But GitHub isn't the only place that you might leak an API key. When you include a private key in a client side web or mobile app, a hacker might be able to find it directly in your source code. Now if you do end up with an exposed API key, you can fix the problem by simply rolling it to a new value, and of course removing it from any public repos or source code. Many good APIs will help you minimize the damage by allowing you to assign privileges to a specific API key. This allows you to follow the principle of least privilege, and only give API keys access to the resources that they actually need. That will mitigate the amount of damage that can be done if that key does end up being leaked. If we look at a major cloud provider like AWS, we'll see that they offer hundreds of different services, and they might be used by a company with thousands of employees working on different projects. Sharing a single API key that has access to everything would be a very bad idea. Instead, the major cloud providers have a system called I'm which allows you to create groups or roles for your organization. Once you've created a role, you can then attach a policy to that role to give it access to a service that it needs. Implementing fine grained access control over your data is more important than ever. In 2016, an employee of Morrison Supermarkets in the UK stole the private data of over 100,000 employees. This rogue employee did it by simply copying the data onto a USB stick. Now this is obviously unethical and illegal on the employee's part, but the company itself is facing a huge lawsuit, and the penalties for data breaches are becoming larger with laws like GDPR and the EU. So the bottom line here is to always follow the principle of least privilege when it comes to accessing your customer or employee data. And speaking of data, you might come across something called the CIA triad. It's a model for data security that stands for confidentiality, integrity, and availability. Generally speaking, you make data confidential by implementing user authentication so only authorized users can access the data. Integrity means the data can't be simply modified or deleted without the user's authorization. But I think the most interesting question is how do you make your data highly available? In 2018, GitHub survived the biggest DDoS attack or distributed denial of service attack in history. It took GitHub down for less than 10 minutes, but that's Still a pretty big deal considering how many people around the world depend on GitHub at any given moment. A DDoS attack works by flooding a service with so much Traffic that it just fails to scale and completely stops working. You can see in this chart how the inbound traffic suddenly spiked, but the servers treated these as legitimate requests and responded with a normal response. GitHub is big enough to handle attacks like this, but smaller sites might not be so lucky. In some cases, DDoS attacks have been used to shut down service, and then request a ransom from the owner. So how do you protect yourself? Well, the simple answer is to be ready to scale, and that likely means using a big cloud provider. A service like Google Cloud Armor has the bandwidth to handle attacks like this and it can also prevent many other attacks that we talked about earlier in the video. But at the end of the day, nobody's application is 100% safe. There are likely hackers out there right now using 0 day exploits that we don't know about yet. And it's only a matter of time before the next major data breach is in the headlines. If this video helped you, please like and subscribe, and make sure to check out the Enterprise Security course if you really want to master these concepts. Thanks for watching, and I will talk to you soon.
The speaker expresses concern about potential risks of code vulnerabilities and recommends enrolling in a security course to avoid them. They also provide advice on avoiding cross site scripting attacks and recommend enrolling in a recommendation for Heartland Payment Systems. The speaker discusses issues with cross site scripting attacks and the potential for attacks on databases and systems, including a recent leaked API key causing thousands of cards to be compromised. They stress the importance of following principles of least privilege and protecting oneself from attacks, as well as the use of a CIA Triad model for data security and potential DDoS attacks.

        [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 : 7 Security Risks and Hacking Stories for Web Developers 
        and a small summary : The speaker expresses concern about potential risks of code vulnerabilities and recommends enrolling in a security course to avoid them. They also provide advice on avoiding cross site scripting attacks and recommend enrolling in a recommendation for Heartland Payment Systems. The speaker discusses issues with cross site scripting attacks and the potential for attacks on databases and systems, including a recent leaked API key causing thousands of cards to be compromised. They stress the importance of following principles of least privilege and protecting oneself from attacks, as well as the use of a CIA Triad model for data security and potential DDoS attacks.
        [/INST]
        
        Generate the video : If debugging is the process of removing software bugs, then programming must be the process of putting them in. In most cases, the bugs we introduce are harmless, But sometimes, they can cause us to lose 100 of 1,000,000 of dollars in a few minutes, crash airplanes and spaceships, and kill people. Today, I want to tell you some stories about the most damaging hacks and bugs throughout history, tree, and explains 7 software security concepts that every developer should know. If you're new here, like and subscribe, and check out the full write up on FireShip. Io. There are billions upon billions of lines of code in production today, around 50,000,000 lines for Microsoft Windows, and over 2,000,000,000 lines across all Google services. And within all this code, we have vulnerabilities that have either not yet been discovered or not yet been fixed. These are known as 0 day vulnerabilities because as a developer, you have 0 days to get it fixed. When a hacker decides to attack this vulnerability, it's known as a 0 day exploit. Remember that one time Equifax had exposed the credit reports of a 150 people. That wasn't the result of a 0 day exploit. It was the result of a known bug in Apache Struts that had already been fixed weeks ago. What? I'm sorry. I fudged up, guys. Hackers, apparently from China, had been scanning the web for servers with this vulnerability. They hit the mother lode with Equifax and extracted sensitive information over the next 76 days. This breach has cost the company over a $1,000,000,000 and could have been prevented by installing a simple security patch. Being hacked by a known vulnerability is not uncommon at all. In fact, you're likely shipping code with a lot of known vulnerabilities right now. If you're a JS developer, go into your project and hit npm audit. It will give you a breakdown of all the different ways you can be hacked via your open source dependencies. Now, there's no reason to panic. If you have hundreds of high severity alerts, The best way to avoid being hacked is to simply update your packages. But if you truly want to understand the flaws that are compromising these packages, You should enroll in the Enterprise Security course from Angular Academy. It's a 10 week long program that will teach you how to confidently build secure web applications. You'll find the link in the description, and you can use this code to take $50 off the enrollment price. Using components with known vulnerabilities is one of the most common ways that web applications get hacked, But it's also very preventable, because as you can see here, most of the issues have already been patched. And keep in mind, this issue isn't unique to JavaScript or NPM. All package managers that rely on Open source code face similar issues, so trust nobody and keep your packages updated. But most of all, Sammy is my hero. Wait a second. I didn't mean to say that last part. It was somehow injected into this video. Back in 2005, a guy named Sammy used an exploit known as cross site Scripting to update a user's MySpace profile with this text. Within a day, it had spread to over a 1000000 users. It was mostly harmless, but they did arrest Sammy, convict him of a felony, And worst of all, took away his Internet for a year. A cross site scripting exploit occurs when the attacker manages to run some JavaScript code on a different user's browser. There are a few different ways to achieve this, but the most common way is for the attacker to save the script in a web application's database. The malicious script will then accessed by a different user that will execute the JavaScript on the client side device. And at that point, the JavaScript code can submit forms, click on buttons on behalf of the logged in user. So how do you avoid cross site scripting attacks as a developer? Well, the attacker first needs to save some malicious code on your server. So Step 1 is to do some server side validation of incoming data. If it's surrounded by script tags, you might not wanna save it. But let's imagine you fail to sanitize the incoming data. The attacker still needs a way to run that script on the client side device, so the attacker is counting on you to render out the raw HTML of the script. Fortunately, modern front end frameworks make it really difficult to shoot yourself in the foot. In React, for example, if you want to write unsafe code, you have to use this dangerously set inner HTML Prop just to do so. So with cross site scripting, we have malicious code running on the browser, but it's also possible to run bad code directly on a database. Let's go back to 2008 and look at a company named Heartland Payment Systems, a company with the highest standards and the most trusted transactions, and also a company that was the target of one of the most elaborate and interesting hacks of all time. The attackers first gained access to the company's databases by using a technique known as QL injection. Instead of sending the expected data to the database, they sent raw SQL statements. And because the data was not validated, the database would run this code as if it came from the developers. Now this particular database contained the information that you would find on the back of a magnetic strip on a credit card, and they used this stolen data to create counterfeit credit cards that actually worked. It's estimated that over a 100,000,000 cards were compromised, and the main hacker, Albert Gonzalez, was sentenced to 20 years in prison. Injection attacks similar to this affect many different types of databases. If you use an ORM or object relational mapping tool for your database, you should be safe from attacks like this. But of course, it's always a good idea to validate your input before it's sent to your database. Another very easy way to create a big problem as a developer is to expose, or leak a sensitive API key. You can think of a private API key as a username and password all bundled up into a single string, and it allows your servers to securely communicate with paid services like AWS, Google Cloud, and so on. A few years ago, I Incidentally leaked my AWS API key, and it was almost really bad. I was using the Node SDK for a service that required the API key. I hard coded the API key directly in the source code instead of setting it as an environment variable. I then proceeded to push the source code to a public GitHub repo. Whoopsies. A few weeks went by, and then all of a sudden, I get a notification from AWS that I've maxed out my budget. When I logged into my AWS account, I had racked up charges around $5,000 for EC 2 instances running all over the world. Luckily, Amazon was nice enough to refund those charges, but it definitely made me feel like an idiot. Nowadays, automatic scanners can often detect if you have an exposed API key and email you a notification. But GitHub isn't the only place that you might leak an API key. When you include a private key in a client side web or mobile app, a hacker might be able to find it directly in your source code. Now if you do end up with an exposed API key, you can fix the problem by simply rolling it to a new value, and of course removing it from any public repos or source code. Many good APIs will help you minimize the damage by allowing you to assign privileges to a specific API key. This allows you to follow the principle of least privilege, and only give API keys access to the resources that they actually need. That will mitigate the amount of damage that can be done if that key does end up being leaked. If we look at a major cloud provider like AWS, we'll see that they offer hundreds of different services, and they might be used by a company with thousands of employees working on different projects. Sharing a single API key that has access to everything would be a very bad idea. Instead, the major cloud providers have a system called I'm which allows you to create groups or roles for your organization. Once you've created a role, you can then attach a policy to that role to give it access to a service that it needs. Implementing fine grained access control over your data is more important than ever. In 2016, an employee of Morrison Supermarkets in the UK stole the private data of over 100,000 employees. This rogue employee did it by simply copying the data onto a USB stick. Now this is obviously unethical and illegal on the employee's part, but the company itself is facing a huge lawsuit, and the penalties for data breaches are becoming larger with laws like GDPR and the EU. So the bottom line here is to always follow the principle of least privilege when it comes to accessing your customer or employee data. And speaking of data, you might come across something called the CIA triad. It's a model for data security that stands for confidentiality, integrity, and availability. Generally speaking, you make data confidential by implementing user authentication so only authorized users can access the data. Integrity means the data can't be simply modified or deleted without the user's authorization. But I think the most interesting question is how do you make your data highly available? In 2018, GitHub survived the biggest DDoS attack or distributed denial of service attack in history. It took GitHub down for less than 10 minutes, but that's Still a pretty big deal considering how many people around the world depend on GitHub at any given moment. A DDoS attack works by flooding a service with so much Traffic that it just fails to scale and completely stops working. You can see in this chart how the inbound traffic suddenly spiked, but the servers treated these as legitimate requests and responded with a normal response. GitHub is big enough to handle attacks like this, but smaller sites might not be so lucky. In some cases, DDoS attacks have been used to shut down service, and then request a ransom from the owner. So how do you protect yourself? Well, the simple answer is to be ready to scale, and that likely means using a big cloud provider. A service like Google Cloud Armor has the bandwidth to handle attacks like this and it can also prevent many other attacks that we talked about earlier in the video. But at the end of the day, nobody's application is 100% safe. There are likely hackers out there right now using 0 day exploits that we don't know about yet. And it's only a matter of time before the next major data breach is in the headlines. If this video helped you, please like and subscribe, and make sure to check out the Enterprise Security course if you really want to master these concepts. Thanks for watching, and I will talk to you soon.
        