WEBVTT

0:00:10.800000 --> 0:00:13.580000
 Introduction to SQL injection.

0:00:13.580000 --> 0:00:17.780000
 So welcome everyone to the official
 kickoff point for this course.

0:00:17.780000 --> 0:00:21.780000
 And we're going to be starting off
 by getting a formal introduction as

0:00:21.780000 --> 0:00:23.640000
 to what SQL injection is.

0:00:23.640000 --> 0:00:25.660000
 It's a classification as a vulnerability.


0:00:25.660000 --> 0:00:29.960000
 What causes it as well as a brief history
 of the vulnerability so you

0:00:29.960000 --> 0:00:33.700000
 understand where it came from and what
 the prevalence of the vulnerability

0:00:33.700000 --> 0:00:36.680000
 or SQL injection attacks is today.

0:00:36.680000 --> 0:00:39.860000
 And that will lead us to the final
 section of this video where we will

0:00:39.860000 --> 0:00:44.040000
 be exploring the impacts of the vulnerability,
 the security consequences

0:00:44.040000 --> 0:00:49.520000
 as well as the risks posed by the vulnerability
 from a business or operational

0:00:49.520000 --> 0:00:55.060000
 perspective. So let's get started firstly
 by getting an introduction to

0:00:55.060000 --> 0:00:56.520000
 the vulnerability itself.

0:00:56.520000 --> 0:00:59.020000
 So what is SQL injection?

0:00:59.020000 --> 0:01:05.240000
 Well SQL injection also abbreviated as
 SQL I is a web application injection

0:01:05.240000 --> 0:01:10.660000
 vulnerability that occurs when an attacker
 injects malicious SQL statements

0:01:10.660000 --> 0:01:13.820000
 or queries into an applications
 input fields.

0:01:13.820000 --> 0:01:18.020000
 All right, so I really like that definition
 because it highlights two

0:01:18.020000 --> 0:01:21.400000
 key important keywords there.

0:01:21.400000 --> 0:01:24.500000
 The first being that this is
 an injection vulnerability.

0:01:24.500000 --> 0:01:28.540000
 Now if you have been performing web
 app pen testing before and if you

0:01:28.540000 --> 0:01:32.900000
 are familiar with the OS top 10 classification
 of vulnerabilities or the

0:01:32.900000 --> 0:01:38.020000
 classification types, you may have thought
 that SQL injection is an input

0:01:38.020000 --> 0:01:43.060000
 validation or a lack therein of input
 validation with regards to the type

0:01:43.060000 --> 0:01:43.960000
 of vulnerability.

0:01:43.960000 --> 0:01:49.120000
 However, SQL injection by nature and
 by virtue of its name is an injection

0:01:49.120000 --> 0:01:54.340000
 vulnerability in that it essentially
 allows for the injection of in this

0:01:54.340000 --> 0:01:59.460000
 case SQL queries into the back end of
 the web application to be therefore

0:01:59.460000 --> 0:02:04.000000
 or consequently executed by the database,
 therefore returning data from

0:02:04.000000 --> 0:02:07.660000
 the database that can then be consumed
 or used by the attacker for whatever

0:02:07.660000 --> 0:02:09.100000
 the objectives are.

0:02:09.100000 --> 0:02:11.960000
 Now, what causes the vulnerability?

0:02:11.960000 --> 0:02:14.400000
 This is very, very, very important.

0:02:14.400000 --> 0:02:19.400000
 So you may be thinking that this vulnerability
 is really caused by an

0:02:19.400000 --> 0:02:24.980000
 issue with the database or the DBMS,
 the database management system in

0:02:24.980000 --> 0:02:29.200000
 and of itself. However, that's not
 the case because the database will

0:02:29.200000 --> 0:02:33.980000
 execute anything or any SQL query that
 is sent over by the back end of

0:02:33.980000 --> 0:02:34.980000
 the web application.

0:02:34.980000 --> 0:02:36.340000
 So that's really not the issue.

0:02:36.340000 --> 0:02:39.620000
 The issue is at the point of injection.

0:02:39.620000 --> 0:02:44.040000
 So this vulnerability occurs when a
 web application does not properly

0:02:44.040000 --> 0:02:50.620000
 validate user input, therefore allowing
 an attacker to inject SQL SQL

0:02:50.620000 --> 0:02:55.860000
 or SQL code or queries that can manipulate
 the database or gain access

0:02:55.860000 --> 0:02:59.960000
 to the information contained within the
 database, which could be sensitive.

0:02:59.960000 --> 0:03:05.780000
 So the key thing there is that it's
 primarily caused by a lack of input

0:03:05.780000 --> 0:03:07.860000
 validation by the web application.

0:03:07.860000 --> 0:03:12.840000
 So many web applications leverage
 or utilize databases, right?

0:03:12.840000 --> 0:03:18.680000
 And the primary way that an attacker identifies
 and exploits an SQL injection

0:03:18.680000 --> 0:03:24.020000
 vulnerability is primarily through
 an application input, a point or an

0:03:24.020000 --> 0:03:28.040000
 area within the web application where
 the user can input data that is

0:03:28.040000 --> 0:03:33.000000
 then processed by the web application
 and consequently that where the

0:03:33.000000 --> 0:03:36.440000
 web application interacts with the
 database, a good example of that is

0:03:36.440000 --> 0:03:39.100000
 a login form. Why is that a good example?


0:03:39.100000 --> 0:03:42.920000
 Well, firstly, most web applications
 today have authentication set up

0:03:42.920000 --> 0:03:46.560000
 and the typical form of authentication
 is in the case is in the form of

0:03:46.560000 --> 0:03:49.600000
 username, password or email,
 password, right?

0:03:49.600000 --> 0:03:53.580000
 Now that website is obviously using some
 type of database and that database

0:03:53.580000 --> 0:03:56.280000
 is where the credentials are stored.

0:03:56.280000 --> 0:04:00.640000
 So an attacker finds the login form
 and they know that that login form

0:04:00.640000 --> 0:04:04.920000
 on the web application interacts with
 the database because of its nature,

0:04:04.920000 --> 0:04:10.020000
 because of the fact that it's requesting
 a user to put in their data,

0:04:10.020000 --> 0:04:13.840000
 their username or password that is then
 verified by the web application

0:04:13.840000 --> 0:04:15.800000
 by interacting with the database.

0:04:15.800000 --> 0:04:20.520000
 So the two requirements or parameters
 for a successful SQL injection attack

0:04:20.520000 --> 0:04:25.300000
 is that they needs to be an input point
 on the web application and we'll

0:04:25.300000 --> 0:04:26.840000
 get into input validation.

0:04:26.840000 --> 0:04:29.740000
 And secondly, that input point needs
 to have some form of interaction

0:04:29.740000 --> 0:04:35.100000
 with the database in that it needs to
 be checking for data in the database

0:04:35.100000 --> 0:04:36.620000
 or creating new data.

0:04:36.620000 --> 0:04:39.220000
 It really doesn't matter as long as
 it's interacting with the database

0:04:39.220000 --> 0:04:41.800000
 in some way of form.

0:04:41.800000 --> 0:04:44.200000
 That's the second prerequisite, right?

0:04:44.200000 --> 0:04:48.340000
 Now the first prerequisite, the point
 of injection or an input point,

0:04:48.340000 --> 0:04:52.160000
 the primary cause of the vulnerability
 is not really the database because

0:04:52.160000 --> 0:04:55.660000
 as I said, the database will execute
 whatever it's told to execute by

0:04:55.660000 --> 0:04:56.640000
 the web application.

0:04:56.640000 --> 0:05:01.200000
 It's really the input validation or
 the lack therein of input validation

0:05:01.200000 --> 0:05:03.000000
 on the web application itself.

0:05:03.000000 --> 0:05:06.420000
 So you can imagine if you're a web developer
 and you've not done any secure

0:05:06.420000 --> 0:05:10.300000
 coding and you're building a web application
 using the LAMP stack, so

0:05:10.300000 --> 0:05:12.500000
 MySQL, PHP, etc.

0:05:12.500000 --> 0:05:16.420000
 And you develop a PHP web application
 that has a form of authentication.

0:05:16.420000 --> 0:05:20.280000
 In this case, you use name and password.

0:05:20.280000 --> 0:05:24.560000
 Within the login.php page, you're going
 to be interacting with the database

0:05:24.560000 --> 0:05:28.260000
 in that you will take the data within
 the username and password and send

0:05:28.260000 --> 0:05:32.460000
 them to the database to verify whether
 that user exists, right?

0:05:32.460000 --> 0:05:36.060000
 Now if you don't validate or you don't
 perform any input validation where

0:05:36.060000 --> 0:05:41.900000
 you prevent the execution of certain
 keywords or SQL code natively, then

0:05:41.900000 --> 0:05:45.920000
 an attacker could potentially inject
 any legitimate or even dangerous

0:05:45.920000 --> 0:05:51.200000
 SQL queries into any of those input
 fields and have them injected.

0:05:51.200000 --> 0:05:54.200000
 The web application doesn't know that
 it's malicious unless you develop

0:05:54.200000 --> 0:05:59.300000
 the web application with that in mind
 or to block those types of inputs.

0:05:59.300000 --> 0:06:01.800000
 Web application doesn't know there's
 anything wrong with that.

0:06:01.800000 --> 0:06:05.500000
 It sends it to the database as a query
 to check whether that username

0:06:05.500000 --> 0:06:08.880000
 and password exists or whether
 that user exists.

0:06:08.880000 --> 0:06:12.860000
 Now remember the username parameter
 contains the SQL query.

0:06:12.860000 --> 0:06:16.040000
 So when passed into the database, the
 database is okay, you want me to

0:06:16.040000 --> 0:06:19.880000
 process this. It goes over to the value
 of the username parameter and

0:06:19.880000 --> 0:06:23.860000
 it says, okay, this is a SQL query
 that was injected by the attacker.

0:06:23.860000 --> 0:06:26.060000
 It doesn't know that it's been
 injected by the attacker.

0:06:26.060000 --> 0:06:30.180000
 It's expecting a username or a string,
 but it gets that data and a SQL

0:06:30.180000 --> 0:06:32.520000
 database doesn't know any better.

0:06:32.520000 --> 0:06:36.500000
 It knows how to execute SQL queries
 and it does exactly that and returns

0:06:36.500000 --> 0:06:41.620000
 back the data back to the web application,
 the back end of the web application,

0:06:41.620000 --> 0:06:45.400000
 the back end of the web application knows
 how to respond to that and then

0:06:45.400000 --> 0:06:49.860000
 sends back the data to the point of
 injection or the page where the user

0:06:49.860000 --> 0:06:54.660000
 had injected that information or any other
 page relevant to the functionality

0:06:54.660000 --> 0:06:56.080000
 of the web application.

0:06:56.080000 --> 0:07:00.920000
 So this is sort of the example that I've
 listed here where suppose a website

0:07:00.920000 --> 0:07:03.440000
 has a login form that accepts
 a username and password.

0:07:03.440000 --> 0:07:07.940000
 If the website does not properly validate
 the user's input, an attacker

0:07:07.940000 --> 0:07:12.580000
 could enter a malicious SQL statement
 into the username field that would

0:07:12.580000 --> 0:07:16.040000
 allow them to bypass the login process
 and gain access to the website's

0:07:16.040000 --> 0:07:20.740000
 database. So that's a very typical example
 of a SQL injection vulnerability

0:07:20.740000 --> 0:07:25.960000
 where the attacker leverages this vulnerability
 to bypass the login form

0:07:25.960000 --> 0:07:29.000000
 and to login is a particular user.

0:07:29.000000 --> 0:07:33.120000
 So essentially just bypassing the entire
 authentication process even though

0:07:33.120000 --> 0:07:40.180000
 or primarily in most cases the fact that
 they don't already have an account

0:07:40.180000 --> 0:07:43.820000
 on the website, that's really not an
 issue at that point, they're just

0:07:43.820000 --> 0:07:46.760000
 able to bypass that authentication
 process.

0:07:46.760000 --> 0:07:49.640000
 So that's sort of an intro
 to the vulnerability.

0:07:49.640000 --> 0:07:53.480000
 Now of course, moving on, breaking it
 down further, given what I've just

0:07:53.480000 --> 0:08:01.480000
 explained to the attacks can have serious
 consequences, including the

0:08:01.480000 --> 0:08:05.900000
 theft of sensitive data unauthorized
 access to sensitive systems and even

0:08:05.900000 --> 0:08:08.020000
 full system compromise.

0:08:08.020000 --> 0:08:11.720000
 Now you may be asking yourself, well,
 okay, this looks fairly simple to

0:08:11.720000 --> 0:08:15.440000
 understand. I just need to find a web
 application that has a database

0:08:15.440000 --> 0:08:19.200000
 by virtue of its functionality, the
 fact that it has authentication or

0:08:19.200000 --> 0:08:24.280000
 that it's storing data and it has an
 application input that allows an

0:08:24.280000 --> 0:08:28.980000
 attacker to input SQL queries directly
 into it because of a lack of user

0:08:28.980000 --> 0:08:32.240000
 input validation.

0:08:32.240000 --> 0:08:37.360000
 What's the prevalence of websites that
 could potentially have or that

0:08:37.360000 --> 0:08:40.020000
 could potentially be affected
 by this vulnerability?

0:08:40.020000 --> 0:08:44.180000
 Well, going back to the previous slide
 where I highlighted the requirements

0:08:44.180000 --> 0:08:49.140000
 for the vulnerability to be executed
 successfully, one of them is the

0:08:49.140000 --> 0:08:53.300000
 fact that the website or web application
 needs to be utilizing a database.

0:08:53.300000 --> 0:08:56.640000
 Now, if you think about it, why
 would a web app need a database?

0:08:56.640000 --> 0:09:00.020000
 Web apps need databases because they
 need to store different types of

0:09:00.020000 --> 0:09:03.760000
 data. They need to store data like
 usename or user credentials.

0:09:03.760000 --> 0:09:07.500000
 They could be storing other data that is
 required like references to particular

0:09:07.500000 --> 0:09:13.140000
 pages or any other data or assets that
 they need stored somewhere, not

0:09:13.140000 --> 0:09:16.920000
 just so that they can be modified or
 changed, but also so that they can

0:09:16.920000 --> 0:09:21.560000
 be referenced. So, for example, when
 you log in to a web application that

0:09:21.560000 --> 0:09:27.140000
 is using a SQL database, more specifically
 a relational database, what

0:09:27.140000 --> 0:09:33.020000
 it does when you specify a username
 and password, the web application

0:09:33.020000 --> 0:09:36.740000
 takes that and sends it to the database
 and says, hey, can you please

0:09:36.740000 --> 0:09:43.280000
 check and see if this user exists within
 the user's table of the database.

0:09:43.280000 --> 0:09:47.320000
 If it doesn't exist, you know what
 to do or you just send me back the

0:09:47.320000 --> 0:09:51.280000
 result, I, as the web application,
 know how to respond to the user.

0:09:51.280000 --> 0:09:54.680000
 Web application typically tells you
 that either your username is false

0:09:54.680000 --> 0:09:58.960000
 or your password is false, therefore
 confirming that the user exists.

0:09:58.960000 --> 0:10:04.040000
 If you enter the correct password, the
 database says, okay, yes, typically

0:10:04.040000 --> 0:10:07.880000
 through a Boolean response, either true
 or false, as true, this user exists

0:10:07.880000 --> 0:10:10.080000
 and then it checks the password.

0:10:10.080000 --> 0:10:11.020000
 Is this the correct one?

0:10:11.020000 --> 0:10:12.160000
 Does it match? True.

0:10:12.160000 --> 0:10:15.680000
 The web application says, okay, this
 is a valid user account and they've

0:10:15.680000 --> 0:10:19.540000
 provided the valid password and it
 responds by logging you in and then

0:10:19.540000 --> 0:10:21.820000
 taking you to your dashboard
 or your profile page.

0:10:21.820000 --> 0:10:28.180000
 So, again, very, very simple to understand
 that many web applications

0:10:28.180000 --> 0:10:32.780000
 today use databases for storing different
 types of data of vast, you know,

0:10:32.780000 --> 0:10:36.000000
 vast types and quantities of data.

0:10:36.000000 --> 0:10:39.000000
 And as a result, these attacks
 are very prevalent.

0:10:39.000000 --> 0:10:42.280000
 Now, it doesn't matter what type of
 database they're using because that

0:10:42.280000 --> 0:10:45.300000
 will be a topic that we'll discuss,
 whether they're using a SQL database

0:10:45.300000 --> 0:10:47.100000
 or a NoSQL database.

0:10:47.100000 --> 0:10:50.960000
 It really doesn't matter as long as the
 using a database, it is a potential

0:10:50.960000 --> 0:10:55.600000
 target. The web application is a potential
 target, obviously, if it doesn't

0:10:55.600000 --> 0:10:58.380000
 have any proper input validation.

0:10:58.380000 --> 0:11:02.580000
 And content management systems or CMSs
 like WordPress, Drupal or Joomla

0:11:02.580000 --> 0:11:06.920000
 are very common examples of this because
 of the fact that they need the

0:11:06.920000 --> 0:11:10.300000
 database in order to work correctly
 for, you know, different reasons as

0:11:10.300000 --> 0:11:11.960000
 we'll obviously see.

0:11:11.960000 --> 0:11:16.780000
 And the content management systems will
 typically utilize relational databases.

0:11:16.780000 --> 0:11:21.060000
 And again, I'll explain what a relational
 database is as we progress.

0:11:21.060000 --> 0:11:25.420000
 But they utilize relational databases
 like MySQL, which is open source,

0:11:25.420000 --> 0:11:30.940000
 MSSQL, which is Microsoft SQL Server,
 Oracle, PostgreSQL and others.

0:11:30.940000 --> 0:11:36.540000
 Now, the key thing to note is that in
 order to interact with databases,

0:11:36.540000 --> 0:11:42.300000
 specifically SQL databases, entities
 such as system operators, programmers

0:11:42.300000 --> 0:11:47.780000
 or applications and web applications
 use a language to communicate with

0:11:47.780000 --> 0:11:53.160000
 SQL databases. And the language that
 they use is called SQL, also known

0:11:53.160000 --> 0:11:55.320000
 as the structured query language.

0:11:55.320000 --> 0:12:00.640000
 That's why databases, in this particular
 case, SQL databases have the

0:12:00.640000 --> 0:12:06.980000
 prefix or the word SQL as a prefix to
 their name or as a suffix, because

0:12:06.980000 --> 0:12:11.360000
 it's very important when choosing our
 database to use to know whether

0:12:11.360000 --> 0:12:16.140000
 you're using a SQL database or a NoSQL
 database, because that tells you

0:12:16.140000 --> 0:12:21.600000
 what language that database uses with
 regards to reading data, accessing

0:12:21.600000 --> 0:12:25.320000
 data, deleting data, modifying data, etc.


0:12:25.320000 --> 0:12:31.780000
 The point I'm trying to make here is
 that it's very important to interact

0:12:31.780000 --> 0:12:35.580000
 with the database so that they can send
 data to it for storage, they can

0:12:35.580000 --> 0:12:38.940000
 delete data, so on and so forth.

0:12:38.940000 --> 0:12:43.600000
 And again, as I said, we'll be exploring
 SQL as a language in its own

0:12:43.600000 --> 0:12:45.300000
 video or in its own section.

0:12:45.300000 --> 0:12:47.800000
 So don't worry about that if
 you're not familiar with it.

0:12:47.800000 --> 0:12:52.120000
 So we now have sort of a good understanding
 as to what a SQL injection

0:12:52.120000 --> 0:12:53.840000
 vulnerability is.

0:12:53.840000 --> 0:12:58.180000
 Let's take a little bit of a history
 lesson as to where SQL injection

0:12:58.180000 --> 0:13:01.920000
 came from as a vulnerability
 and obviously as an attack.

0:13:01.920000 --> 0:13:07.580000
 So the term SQL injection was coined by
 Jeff Forestor, also known as Rainforest

0:13:07.580000 --> 0:13:11.960000
 Poppy, in a paper that he presented
 at the DEFCON 8 conference in the

0:13:11.960000 --> 0:13:16.080000
 year 2000. So the vulnerability has
 been there since the advent of the

0:13:16.080000 --> 0:13:23.160000
 internet or the popularization of the
 internet, as well as the the inception

0:13:23.160000 --> 0:13:27.980000
 point at which we started seeing the
 invention and the use of database

0:13:27.980000 --> 0:13:29.820000
 driven websites.

0:13:29.820000 --> 0:13:33.860000
 So Jeff Forestor was one of the first
 security researchers to publicly

0:13:33.860000 --> 0:13:37.800000
 document the SQL injection vulnerability
 and explain how it could be exploited

0:13:37.800000 --> 0:13:43.040000
 in order to gain unauthorized access to
 databases and sensitive information.

0:13:43.040000 --> 0:13:47.180000
 SQL injection attacks have been around since
 the early days of web applications

0:13:47.180000 --> 0:13:49.720000
 and database driven websites.

0:13:49.720000 --> 0:13:52.360000
 The point I'm trying to make here is
 that it's been with us for a very

0:13:52.360000 --> 0:13:56.380000
 long time. It's still prevalent as
 long as there's a database using or

0:13:56.380000 --> 0:14:00.040000
 there's a website using a database,
 you're always going to have a form

0:14:00.040000 --> 0:14:04.440000
 of a database injection attack, regardless
 as to whether it is a SQL injection

0:14:04.440000 --> 0:14:07.420000
 attack or a NoSQL injection attack.

0:14:07.420000 --> 0:14:13.100000
 And that can be further explained or illustrated
 by taking a brief historical

0:14:13.100000 --> 0:14:18.300000
 view of some very popular or well-known
 data breaches or attacks that

0:14:18.300000 --> 0:14:22.220000
 were as a direct result of
 a SQL injection attack.

0:14:22.220000 --> 0:14:27.380000
 So in 1998, an attack known as rainforest
 poppy, also known as Jeff Forestor

0:14:27.380000 --> 0:14:31.920000
 used SQL injection to gain access to
 a US Department of Energy computer

0:14:31.920000 --> 0:14:37.320000
 network. In the year 2000, the first
 publicized SQL injection attack when

0:14:37.320000 --> 0:14:41.120000
 a hacker used SQL injection to steal
 credit card data from the website

0:14:41.120000 --> 0:14:43.820000
 of E-Taylor CD universe.

0:14:43.820000 --> 0:14:48.740000
 In 2002, a group of Russian hackers
 known as the Helldickers, which is

0:14:48.740000 --> 0:14:52.500000
 a pretty cool name, used SQL injection
 to gain access to the database

0:14:52.500000 --> 0:14:56.660000
 of the United Nations, resulting in
 the theft of sensitive information

0:14:56.660000 --> 0:15:01.740000
 and data. In 2012, this is a very popular
 one, the LinkedIn data breach

0:15:01.740000 --> 0:15:06.720000
 occurred in which attackers used SQL
 injection to steal 6.5 million user

0:15:06.720000 --> 0:15:08.580000
 passwords or user credentials.

0:15:08.580000 --> 0:15:12.880000
 And of course, another popular one in
 2015, the Ashley Madison data breach

0:15:12.880000 --> 0:15:17.220000
 occurred in which attackers used SQL
 injection to steal sensitive user

0:15:17.220000 --> 0:15:19.960000
 data from the infidelity dating site.

0:15:19.960000 --> 0:15:23.640000
 Now, why am I showing you this and why
 haven't I gone further historically

0:15:23.640000 --> 0:15:30.000000
 to cover some of the the latest SQL
 injection attacks or data breaches

0:15:30.000000 --> 0:15:32.900000
 that were a direct result
 of a SQL injection attack.

0:15:32.900000 --> 0:15:36.420000
 The reason I haven't gone further is
 because there's too many firstly

0:15:36.420000 --> 0:15:39.640000
 and secondly, each one of them is big.

0:15:39.640000 --> 0:15:43.300000
 And that's why I wanted to use this
 historical view or this histogram,

0:15:43.300000 --> 0:15:48.280000
 if you will, a very rough histogram
 to show you that whenever there's

0:15:48.280000 --> 0:15:54.420000
 a SQL injection attack of vulnerability,
 it always or mostly results in

0:15:54.420000 --> 0:15:57.740000
 a lot of data being stolen or leaked.

0:15:57.740000 --> 0:15:59.420000
 All right. So hopefully
 you're getting my point.

0:15:59.420000 --> 0:16:04.200000
 It's very, very, very severe for an
 organization regardless of whether

0:16:04.200000 --> 0:16:09.560000
 their website has a small amount of
 data or whether it has a huge amount

0:16:09.560000 --> 0:16:13.900000
 of sensitive information, it always results
 in a lot of data being leaked

0:16:13.900000 --> 0:16:17.300000
 or stolen and consequently
 sold by attackers.

0:16:17.300000 --> 0:16:23.280000
 As you can see, just from this historical
 view, dating to 2015 with one

0:16:23.280000 --> 0:16:28.840000
 of the most popular ones, one that
 grabbed the attention of the public

0:16:28.840000 --> 0:16:34.540000
 for different reasons, but that was
 caused by a SQL injection attack of

0:16:34.540000 --> 0:16:39.360000
 vulnerability, which brings me to the
 impact of the vulnerability from

0:16:39.360000 --> 0:16:41.440000
 a cybersecurity perspective.

0:16:41.440000 --> 0:16:46.720000
 So if you're aware with cybersecurity,
 cybersecurity utilizes a typical

0:16:46.720000 --> 0:16:53.000000
 of very well known, very, very powerful
 triad of pillars that sort of

0:16:53.000000 --> 0:16:59.760000
 outline the important aspects or factors
 to consider when securing any

0:16:59.760000 --> 0:17:05.140000
 asset regardless of whether it's digital
 or whether it is more ethereal

0:17:05.140000 --> 0:17:10.180000
 than that. And that, of course, is the
 CIA, the CIA triad, which stands

0:17:10.180000 --> 0:17:13.400000
 for confidentiality, integrity
 and availability.

0:17:13.400000 --> 0:17:18.280000
 So how does the SQL injection vulnerability
 affect the CIA triad?

0:17:18.280000 --> 0:17:22.740000
 Well, confidentiality or from the perspective
 of confidentiality, since

0:17:22.740000 --> 0:17:27.340000
 SQL databases generally hold sensitive
 data, a loss of confidentiality

0:17:27.340000 --> 0:17:30.840000
 is a frequent problem with SQL
 injection vulnerabilities.

0:17:30.840000 --> 0:17:34.740000
 So when you talk about confidentiality
 as a pill of the CIA triad, what

0:17:34.740000 --> 0:17:39.160000
 you're referring to is that access
 to data or access to a computer or

0:17:39.160000 --> 0:17:45.800000
 a system should be confidential in that
 only users or persons with access

0:17:45.800000 --> 0:17:51.340000
 or privileges or rights should be able
 to see or access that system and

0:17:51.340000 --> 0:17:59.980000
 no one obviously impacts confidentiality
 because attackers now gain access

0:17:59.980000 --> 0:18:03.800000
 to sensitive data that they should
 previously have never been able to

0:18:03.800000 --> 0:18:06.620000
 gain access to. Very, very
 simple to understand.

0:18:06.620000 --> 0:18:11.140000
 The second pillar, integrity, what is integrity
 in the context of cybersecurity

0:18:11.140000 --> 0:18:13.320000
 or the CIA triad?

0:18:13.320000 --> 0:18:18.140000
 Integrity refers to the fact that data
 or a system or the data contained

0:18:18.140000 --> 0:18:27.120000
 within a system data
 integrity maintained.

0:18:27.120000 --> 0:18:31.220000
 So specifically referring to the fact
 that data or information should

0:18:31.220000 --> 0:18:37.120000
 not be changed or modified without
 proper permission or privileges or

0:18:37.120000 --> 0:18:42.560000
 without being done by the individuals
 with the correct privileges or the

0:18:42.560000 --> 0:18:43.320000
 necessary privileges.

0:18:43.320000 --> 0:18:48.020000
 So that is fairly simple to understand
 with regards to the impact that

0:18:48.020000 --> 0:18:49.480000
 SQL injection has on integrity.

0:18:49.480000 --> 0:18:58.560000
 So just as we even delete this information
 with a SQL injection attack,

0:18:58.560000 --> 0:19:03.080000
 therefore, in therefore affecting
 the integrity of the data, right?

0:19:03.080000 --> 0:19:07.720000
 Because once a company has its website
 breached and it's a direct result

0:19:07.720000 --> 0:19:11.640000
 of a SQL injection attack and individuals
 find out that attackers have

0:19:11.640000 --> 0:19:16.220000
 gained access to the database, customers
 of that website will never trust

0:19:16.220000 --> 0:19:20.120000
 the database or the integrity of the
 database because no one knows what

0:19:20.120000 --> 0:19:24.080000
 the attackers did, whether they modified
 data, if they did modify it,

0:19:24.080000 --> 0:19:26.380000
 what was the extent of the modification.

0:19:26.380000 --> 0:19:30.480000
 The point I'm trying to pass along is that
 you can never trust that database.

0:19:30.480000 --> 0:19:35.060000
 If a computer is hacked or is targeted
 by an attacker or an APT group

0:19:35.060000 --> 0:19:40.200000
 and ransomware was deployed, you cannot
 clean it and fix it and decrypt

0:19:40.200000 --> 0:19:44.940000
 the files and perform an antivirus
 scan and then proceed on with your

0:19:44.940000 --> 0:19:46.640000
 life like nothing happened.

0:19:46.640000 --> 0:19:49.920000
 The integrity of the operating system
 has been affected and therefore

0:19:49.920000 --> 0:19:51.660000
 it needs to be reinstalled.

0:19:51.660000 --> 0:19:53.520000
 So that makes sense.

0:19:53.520000 --> 0:19:57.640000
 Now, of course, authentication is not
 really a pillar of the CIA tribe,

0:19:57.640000 --> 0:20:01.400000
 but I added it here with regards to
 it in a how SQL injection attacks

0:20:01.400000 --> 0:20:04.880000
 can affect authentication have already
 gone through that whole skip over

0:20:04.880000 --> 0:20:09.000000
 that. But with regards to availability,
 what is availability mean in the

0:20:09.000000 --> 0:20:10.220000
 context of the CIA tribe?

0:20:10.220000 --> 0:20:17.180000
 It essentially means that data or a system
 or an asset should be available

0:20:17.180000 --> 0:20:23.060000
 to the individuals that have access to
 it or that should have the it should

0:20:23.060000 --> 0:20:28.180000
 be available to users that should have access
 to it at almost 100% availability.

0:20:28.180000 --> 0:20:33.840000
 So in the case of SQL injection, SQL
 injection attacks can affect the

0:20:33.840000 --> 0:20:37.200000
 availability of a web application and
 the database and could take the

0:20:37.200000 --> 0:20:40.280000
 website down due to the loss
 or damage of the data.

0:20:40.280000 --> 0:20:44.280000
 So you think of a large company like
 LinkedIn or, you know, Ashley Madison

0:20:44.280000 --> 0:20:48.580000
 with the example I had given you, a
 breach of the database can lead to

0:20:48.580000 --> 0:20:51.900000
 issues with the functionality of the
 web application because certain data

0:20:51.900000 --> 0:20:55.040000
 that could be deleted that the web application
 needs to work correctly,

0:20:55.040000 --> 0:20:58.600000
 therefore leading to a loss of service
 and therefore customers cannot

0:20:58.600000 --> 0:21:03.140000
 use the service and availabilities impacted,
 which can lead to financial

0:21:03.140000 --> 0:21:05.940000
 loss, a loss of customers,
 so on and so forth.

0:21:05.940000 --> 0:21:08.740000
 So the point I'm trying to make here
 with regards to the cybersecurity

0:21:08.740000 --> 0:21:14.500000
 impact is that it's extremely severe
 because it affects the three primary

0:21:14.500000 --> 0:21:20.540000
 pillars of the CIA tribe that being confidentiality,
 integrity and availability.

0:21:20.540000 --> 0:21:23.940000
 Now, of course, with regards to its consequences,
 these are fairly simple

0:21:23.940000 --> 0:21:28.920000
 to understand, given that we've already
 taken a look at the vulnerabilities

0:21:28.920000 --> 0:21:31.140000
 impact on the CIA triad.

0:21:31.140000 --> 0:21:35.400000
 You know, SQL injection consequences
 are obviously sensitive data exposure

0:21:35.400000 --> 0:21:38.900000
 or data breaches, where SQL injection
 attacks can result in unauthorized

0:21:38.900000 --> 0:21:56.420000
 access to sensitive data that is stored
 in a data-based database, potentially

0:21:56.420000 --> 0:21:58.800000
 causing data loss or corruption.

0:21:58.800000 --> 0:22:04.040000
 Potential code execution if a database
 user has administrative privileges,

0:22:04.040000 --> 0:22:07.700000
 an attacker can gain access to the
 target system using malicious code,

0:22:07.700000 --> 0:22:11.920000
 that is specifically referring to database
 user accounts and their access

0:22:11.920000 --> 0:22:14.660000
 rights, because the database is not
 a database user, because you could

0:22:14.660000 --> 0:22:19.500000
 potentially, if you have access to the
 database as the root user account,

0:22:19.500000 --> 0:22:24.620000
 you could be able to break out of that
 and get the database management

0:22:24.620000 --> 0:22:28.480000
 system to execute system code on the
 underlying server, regardless of

0:22:28.480000 --> 0:22:33.660000
 whether it's Windows or Linux and gain
 a shell or remote code execution

0:22:33.660000 --> 0:22:36.440000
 on the actual underlying server.

0:22:36.440000 --> 0:22:39.960000
 And then of course, business disruption,
 which is fairly self-explanatory,

0:22:39.960000 --> 0:22:43.820000
 successful SQL injection attacks can
 lead to and usually lead to business

0:22:43.820000 --> 0:22:48.500000
 disruption, has organizations work
 to identify the cause of the breach

0:22:48.500000 --> 0:22:53.440000
 and then work on restoring services
 and preventing further attacks if

0:22:53.440000 --> 0:22:56.500000
 it is more of a targeted attack.

0:22:56.500000 --> 0:22:58.560000
 So you sort of get the idea.

0:22:58.560000 --> 0:23:04.160000
 It's SQL injection vulnerabilities, bad
 news, if you're running an organization,

0:23:04.160000 --> 0:23:08.120000
 and it should always be, you know, be
 up to date with regards to making

0:23:08.120000 --> 0:23:11.080000
 sure that your web applications
 are secure.

0:23:11.080000 --> 0:23:14.480000
 And the underlying infrastructure with
 regards to the database management

0:23:14.480000 --> 0:23:18.400000
 system is set up correctly
 with security in mind.

0:23:18.400000 --> 0:23:23.620000
 And that brings us to the risks of
 the SQL injection vulnerability or

0:23:23.620000 --> 0:23:25.740000
 injection vulnerabilities in general.

0:23:25.740000 --> 0:23:28.500000
 And this is where I'm going to be switching
 over to my browser and taking

0:23:28.500000 --> 0:23:34.200000
 a look at the OS top 10 to show you
 how the OS project classifies SQL

0:23:34.200000 --> 0:23:38.620000
 injection or injection vulnerabilities
 from the perspective of the risks

0:23:38.620000 --> 0:23:40.500000
 posed to an organization.

0:23:40.500000 --> 0:23:42.660000
 So I'll see you there.

0:23:42.660000 --> 0:23:47.180000
 All right, so I'm back within my browser
 here and you can perform a quick

0:23:47.180000 --> 0:23:49.440000
 Google search for the OS top 10.

0:23:49.440000 --> 0:23:53.480000
 If you're not familiar with it, let
 me introduce you to it very briefly.

0:23:53.480000 --> 0:23:57.880000
 OS top 10 is a standard awareness document
 for developers and web application

0:23:57.880000 --> 0:24:03.620000
 security. It represents a broad consensus
 about the most critical security

0:24:03.620000 --> 0:24:05.440000
 risks to web application.

0:24:05.440000 --> 0:24:09.980000
 So the OS foundation works to improve
 security of software through its

0:24:09.980000 --> 0:24:14.420000
 community led open source software projects
 hundreds of chapters worldwide,

0:24:14.420000 --> 0:24:17.820000
 tens of thousands of members and by hosting
 local and global conferences.

0:24:17.820000 --> 0:24:23.520000
 So it is a project that seems to classify
 security risks that affect web

0:24:23.520000 --> 0:24:27.620000
 applications worldwide each year.

0:24:27.620000 --> 0:24:31.660000
 And they usually have releases, a top
 10 list of vulnerabilities or web

0:24:31.660000 --> 0:24:35.180000
 application security risks,
 as it says here.

0:24:35.180000 --> 0:24:39.800000
 And the most recent release that is
 actually currently being developed

0:24:39.800000 --> 0:24:42.720000
 and worked on actively is 2021.

0:24:42.720000 --> 0:24:46.100000
 So you can see the assorted, we have
 10 security risks here classified

0:24:46.100000 --> 0:24:51.480000
 by their type. So at the top in 2017,
 we add injection, which is referring

0:24:51.480000 --> 0:24:55.580000
 to injection vulnerabilities and SQL injection
 falls under injection vulnerabilities.

0:24:55.580000 --> 0:24:59.940000
 We had broken authentication vulnerabilities,
 sensitive data exposure,

0:24:59.940000 --> 0:25:04.020000
 etc. And this diagram sort of shows
 us the change in 2021, or how the

0:25:04.020000 --> 0:25:08.380000
 threat surface or threat landscape changed,
 or has been changing whereby

0:25:08.380000 --> 0:25:13.660000
 you can see 2021 injection was a was
 number three in terms of severity

0:25:13.660000 --> 0:25:19.580000
 or risk. And you have a description of each
 of these, each of these vulnerabilities.

0:25:19.580000 --> 0:25:23.960000
 So you can take a look at the latest
 one, which is the OAS top 10 2021.

0:25:23.960000 --> 0:25:29.120000
 However, if we take a look at OAS
 top 10 2017, there's a PDF here.

0:25:29.120000 --> 0:25:33.360000
 So you can see OAS top 10 2017, the 10
 most critical web application security

0:25:33.360000 --> 0:25:38.100000
 risks. Why I'm going through this is
 to highlight a few things tied to

0:25:38.100000 --> 0:25:42.920000
 the risk of the vulnerability, the easiness
 of exploitation and identification,

0:25:42.920000 --> 0:25:47.760000
 etc. So within this document, what
 typically happens or what OAS pull

0:25:47.760000 --> 0:25:52.660000
 typically do is give you a risk matrix
 here that they utilize to identify

0:25:52.660000 --> 0:25:57.560000
 the exploitability of the vulnerability,
 the weakness prevalence, the

0:25:57.560000 --> 0:26:02.400000
 weakness detectability and the technical
 impacts, and as well as the business

0:26:02.400000 --> 0:26:06.620000
 impacts, right? So this matrix
 is fairly simple to understand.

0:26:06.620000 --> 0:26:07.900000
 It's color coded.

0:26:07.900000 --> 0:26:12.400000
 So we have difficult, average and easy,
 where difficult with a value of

0:26:12.400000 --> 0:26:21.480000
 one is yellow, average, or the actual
 value of two is is going to be orange.

0:26:21.480000 --> 0:26:25.380000
 And then the highest, which
 is three, is red.

0:26:25.380000 --> 0:26:29.980000
 And that represents easy, widespread, easy
 or severe with regards to exploitability,

0:26:29.980000 --> 0:26:34.240000
 weakness prevalence, weakness detectability,
 and technical impacts.

0:26:34.240000 --> 0:26:37.560000
 The way this works is that there's
 a score of one to three, one being

0:26:37.560000 --> 0:26:41.780000
 the lowest in terms of exploitability, weakness
 prevalence, weakness detectability,

0:26:41.780000 --> 0:26:45.660000
 and technical impacts, and three being
 the highest in the aforementioned,

0:26:45.660000 --> 0:26:49.420000
 that being these factors right away
 as well as business impacts.

0:26:49.420000 --> 0:26:50.980000
 But those are business specific.

0:26:50.980000 --> 0:26:54.660000
 So the point is that for all of the
 vulnerabilities listed in the top

0:26:54.660000 --> 0:26:58.720000
 10 list, there will be a matrix that sort
 of gives us the score with regards

0:26:58.720000 --> 0:27:03.840000
 to exploitability, weakness prevalence,
 weakness detectability, technical

0:27:03.840000 --> 0:27:06.620000
 impacts, as well as the business impact.

0:27:06.620000 --> 0:27:10.720000
 So that is something that needs to
 be calculated based on the specific

0:27:10.720000 --> 0:27:12.800000
 type of business in question.

0:27:12.800000 --> 0:27:16.240000
 So you can see the top 10 security risks
 are listed here, where we have

0:27:16.240000 --> 0:27:18.260000
 a one, which is injection.

0:27:18.260000 --> 0:27:22.440000
 And this refers to injection flows such
 as SQL, no SQL operating system

0:27:22.440000 --> 0:27:26.080000
 or OS command injection,
 and LDAP injection.

0:27:26.080000 --> 0:27:30.100000
 These types of vulnerabilities occur
 when untrusted data is sent to an

0:27:30.100000 --> 0:27:32.140000
 interpreter as part of
 a command or query.

0:27:32.140000 --> 0:27:35.980000
 In the case of SQL or no SQL injection,
 the interpreter is going to be

0:27:35.980000 --> 0:27:40.680000
 the database, or is going to be facilitated
 by the query language, in

0:27:40.680000 --> 0:27:42.520000
 this case, the structured query language.


0:27:42.520000 --> 0:27:46.520000
 So the crux of the vulnerability revolves
 around the fact that the attacker's

0:27:46.520000 --> 0:27:50.760000
 hostile data can trick the interpreter
 into executing unintended commands

0:27:50.760000 --> 0:27:54.080000
 or accessing data without
 proper authorization.

0:27:54.080000 --> 0:27:59.680000
 So if we go to injection right over here,
 you're going to see three columns.

0:27:59.680000 --> 0:28:05.460000
 You're going to have the exploitability
 of the vulnerability, the security

0:28:05.460000 --> 0:28:09.560000
 weaknesses, where you have the prevalence
 and detectability of the vulnerability,

0:28:09.560000 --> 0:28:13.000000
 and the impacts are only technical
 being displayed.

0:28:13.000000 --> 0:28:17.120000
 So with regards to the attack vectors
 and the exploitability, that has

0:28:17.120000 --> 0:28:18.700000
 a score of three.

0:28:18.700000 --> 0:28:23.040000
 And if we refer back here, you can
 see with regards to exploitability,

0:28:23.040000 --> 0:28:27.360000
 the value or the score of three refers
 to the fact that it's very easy

0:28:27.360000 --> 0:28:28.680000
 to exploit this vulnerability.

0:28:28.680000 --> 0:28:30.880000
 And that's what OASP is telling us here.

0:28:30.880000 --> 0:28:36.180000
 So almost any source of data can be an injection
 vector, environment variables,

0:28:36.180000 --> 0:28:40.960000
 parameters, external and internal web
 services, and all types of users.

0:28:40.960000 --> 0:28:45.380000
 Injection flows occur when an attacker can
 send hostile data into an interpreter.

0:28:45.380000 --> 0:28:47.860000
 So you can see that it's
 very easy to exploit.

0:28:47.860000 --> 0:28:49.100000
 And this is not me saying it.

0:28:49.100000 --> 0:28:50.240000
 This is OASP saying it.

0:28:50.240000 --> 0:28:52.700000
 And this is what the community says.

0:28:52.700000 --> 0:28:56.540000
 In terms of security weaknesses, the prevalence
 as a score of two referring

0:28:56.540000 --> 0:29:01.160000
 back, you can see the weakness prevalence
 is set at two, which means it's

0:29:01.160000 --> 0:29:06.880000
 very common, as well as the detectability,
 which is set to three, which

0:29:06.880000 --> 0:29:11.500000
 means with regards to the detectability
 of the vulnerability, it's very

0:29:11.500000 --> 0:29:14.900000
 easy to detect, as you
 already can see here.

0:29:14.900000 --> 0:29:19.220000
 And that takes us to the technical
 impacts, which is set to three and

0:29:19.220000 --> 0:29:21.100000
 if we refer back, that is severe.

0:29:21.100000 --> 0:29:24.700000
 So the technical impacts are
 obviously going to be severe.

0:29:24.700000 --> 0:29:28.580000
 And also, I would assume that the business
 impacts will also be severe.

0:29:28.580000 --> 0:29:34.360000
 So in terms of the prevalence and detectability,
 as it says here, injection

0:29:34.360000 --> 0:29:39.060000
 flows are very, very, very prevalent,
 particularly in legacy code.

0:29:39.060000 --> 0:29:43.200000
 Injection vulnerabilities are often
 found in SQL LDAP, X path or NoSQL

0:29:43.200000 --> 0:29:48.140000
 queries, operating system commands,
 XML passes, SMTP headers, expression

0:29:48.140000 --> 0:29:50.640000
 languages and ORM queries.

0:29:50.640000 --> 0:29:54.140000
 Injection flows are easy to discover
 when examining code.

0:29:54.140000 --> 0:29:57.380000
 Scanners and fuzzers can help attackers
 find injection flows and we'll

0:29:57.380000 --> 0:30:00.540000
 be taking a look at how to find injection
 vulnerabilities both manually

0:30:00.540000 --> 0:30:02.140000
 and automatically.

0:30:02.140000 --> 0:30:06.940000
 With regards to the technical impacts
 of the vulnerability injection can

0:30:06.940000 --> 0:30:11.440000
 result in data loss, corruption or
 disclosure to unauthorized parties,

0:30:11.440000 --> 0:30:12.180000
 loss of accountability.

0:30:12.180000 --> 0:30:17.460000
 Again, coming back to the confidentiality,
 integrity and availability

0:30:17.460000 --> 0:30:23.980000
 side of the CIA triad,
 denial of access, etc.

0:30:23.980000 --> 0:30:28.660000
 Injection can sometimes lead to almost
 complete host takeover and the

0:30:28.660000 --> 0:30:32.920000
 business impact depends on the needs
 of the application and data.

0:30:32.920000 --> 0:30:37.000000
 The OS top 10 document also goes over
 how you can perform checks to see

0:30:37.000000 --> 0:30:41.560000
 if an application is vulnerable and
 now you can go about preventing SQL

0:30:41.560000 --> 0:30:45.300000
 injection attacks or vulnerabilities and
 then some example attacks scenarios

0:30:45.300000 --> 0:30:51.300000
 where some SQL queries have been provided
 to extract a certain piece of

0:30:51.300000 --> 0:30:53.880000
 information or to bypass a login.

0:30:53.880000 --> 0:30:57.000000
 And you can take a look at their references
 here, as well as external

0:30:57.000000 --> 0:31:00.720000
 references to the vulnerability or
 various injection vulnerabilities.

0:31:00.720000 --> 0:31:04.080000
 The point I'm trying to make here or
 the reason I wanted to cover this

0:31:04.080000 --> 0:31:08.660000
 is to show you or to back up my claims that
 it's very easy or very straightforward

0:31:08.660000 --> 0:31:13.480000
 to exploit. They're very prevalent in
 the wild or they're actually quite

0:31:13.480000 --> 0:31:16.720000
 common and detecting them is very easy.

0:31:16.720000 --> 0:31:20.060000
 And of course, their technical and
 business impacts are severe or high

0:31:20.060000 --> 0:31:21.180000
 to say the least.

0:31:21.180000 --> 0:31:25.900000
 So this is a very, very, very big vulnerability
 from the perspective of

0:31:25.900000 --> 0:31:29.000000
 an attacker and even bigger from
 the perspective of a developer.

0:31:29.000000 --> 0:31:32.520000
 This is something that you really need
 to prevent against or that you

0:31:32.520000 --> 0:31:37.280000
 really need to work to or essentially
 work on if you are a web developer

0:31:37.280000 --> 0:31:42.380000
 or you need to study up on and hopefully
 this course will cover a lot

0:31:42.380000 --> 0:31:46.440000
 of that because we will be covering
 how we can detect this SQL injection

0:31:46.440000 --> 0:31:51.680000
 vulnerability in some PHP code towards
 the latter stage or phase of this

0:31:51.680000 --> 0:31:55.220000
 course. With that being said, that's
 going to be it for the practical

0:31:55.220000 --> 0:31:56.380000
 demonstration side.

0:31:56.380000 --> 0:31:59.080000
 I'm going to switch back
 over to the slides.

0:31:59.080000 --> 0:32:02.780000
 All right, so that brings us to the
 end of the introductory video where

0:32:02.780000 --> 0:32:08.180000
 we took a look or we formal introduction
 to SQL injection vulnerabilities.

0:32:08.180000 --> 0:32:12.020000
 What causes them a brief history of the
 vulnerability as well as the data

0:32:12.020000 --> 0:32:17.340000
 breaches that were that occurred as a direct
 result of SQL injection vulnerabilities

0:32:17.340000 --> 0:32:23.580000
 we also touched upon the potential impacts
 of the vulnerability, the consequences

0:32:23.580000 --> 0:32:26.880000
 and obviously the risks
 of the vulnerability.

0:32:26.880000 --> 0:32:28.000000
 So we've covered quite a lot.

0:32:28.000000 --> 0:32:32.440000
 We should now have a solid base, solid foundational
 knowledge of the vulnerability

0:32:32.440000 --> 0:32:36.080000
 that will set the stage for what we'll
 be doing next or what we'll be

0:32:36.080000 --> 0:32:39.740000
 covering next. So in the next video,
 we're going to be taking a look at

0:32:39.740000 --> 0:32:44.100000
 an anatomy of a SQL injection attack
 to sort of give you an idea as to

0:32:44.100000 --> 0:32:48.180000
 what happens in the background or what
 the attack flow is from the perspective

0:32:48.180000 --> 0:32:51.340000
 of an attack. And this will also be
 useful for defenders because you'll

0:32:51.340000 --> 0:32:54.140000
 be able to identify where
 you need to focus on.

0:32:54.140000 --> 0:32:58.440000
 And obviously that's fairly simple to
 understand mainly the web application

0:32:58.440000 --> 0:33:01.300000
 and input or sanitizing user input.

0:33:01.300000 --> 0:33:03.500000
 However, that's getting ahead of myself.

0:33:03.500000 --> 0:33:07.100000
 So that's going to be it for this video
 and I'll be seeing you in the