WEBVTT

0:00:09.380000 --> 0:00:13.360000
 Hunting for SQL injection
 vulnerabilities.

0:00:13.360000 --> 0:00:18.800000
 In this video and in this section specifically
 named or titled Finding

0:00:18.800000 --> 0:00:23.540000
 SQL injection vulnerabilities, we're
 going to be taking a look at how

0:00:23.540000 --> 0:00:28.880000
 to identify SQL injection vulnerabilities
 both manually and automatically.

0:00:28.880000 --> 0:00:32.440000
 However, in this video, what I'm going
 to be outlining is the process

0:00:32.440000 --> 0:00:34.820000
 or the methodology behind that.

0:00:34.820000 --> 0:00:40.200000
 So if you actually remember in the introductory
 section or the SQL injection

0:00:40.200000 --> 0:00:44.780000
 fundamental section of this course, where
 I introduce you to SQL injection

0:00:44.780000 --> 0:00:50.460000
 vulnerabilities, I sort of highlighted
 a few important aspects with regards

0:00:50.460000 --> 0:01:00.360000
 to the successful exploitation of parameters
 or requirements for successful

0:01:00.360000 --> 0:01:07.060000
 SQL injection is firstly the identification
 of an application input that

0:01:07.060000 --> 0:01:12.440000
 interacts with the database therefore
 allowing for some form of injection.

0:01:12.440000 --> 0:01:16.920000
 And the second parameter requirement
 is that the web application should

0:01:16.920000 --> 0:01:22.800000
 have no or very little input sanitization
 or user input validation.

0:01:22.800000 --> 0:01:26.440000
 And really that's what we're going
 to be focusing on primarily.

0:01:26.440000 --> 0:01:31.880000
 So sort of giving you an idea as to how
 you can go about finding SQL injection

0:01:31.880000 --> 0:01:36.740000
 vulnerabilities, what to look out for
 in terms of application inputs,

0:01:36.740000 --> 0:01:39.180000
 and the general methodology behind it.

0:01:39.180000 --> 0:01:45.140000
 I'll also be covering quite a lot of
 other helpful techniques and I'll

0:01:45.140000 --> 0:01:48.620000
 be providing you with very useful information
 that you can utilize when

0:01:48.620000 --> 0:01:53.880000
 performing your manual checks, which
 is what we'll be focusing on firstly.

0:01:53.880000 --> 0:01:58.360000
 So to begin with, it goes without saying
 that in order to exploit a SQL

0:01:58.360000 --> 0:02:03.100000
 injection vulnerability, you first
 have to identify an injection point

0:02:03.100000 --> 0:02:07.660000
 or an application input within the web
 application, after which you can

0:02:07.660000 --> 0:02:13.720000
 craft an SQL query or payload that can
 be injected in an injectable parameter.

0:02:13.720000 --> 0:02:17.940000
 And we'll talk, we'll explore a little
 bit more about parameters.

0:02:17.940000 --> 0:02:23.200000
 But for now, I've sort of highlighted
 that the three primary requirements

0:02:23.200000 --> 0:02:27.500000
 for successful SQL injection number
 one, you need to find an application

0:02:27.500000 --> 0:02:31.760000
 input number two or rather, yeah, number
 two, you need to find an application

0:02:31.760000 --> 0:02:35.700000
 input that does not have
 any input validation.

0:02:35.700000 --> 0:02:40.400000
 And one that is interacting with the database
 or rather one that is passing

0:02:40.400000 --> 0:02:49.080000
 data or is sending data
 is being updated, etc.

0:02:49.080000 --> 0:02:54.360000
 And a simple example of this is a login
 form where it's self-explanatory

0:02:54.360000 --> 0:03:02.060000
 with regards to why and how data is
 being sent into the web application.

0:03:02.060000 --> 0:03:05.500000
 And it makes sense that a username and
 password would be sent to the database

0:03:05.500000 --> 0:03:11.300000
 for verification, especially when you're
 talking about user accounts.

0:03:11.300000 --> 0:03:13.120000
 So yeah, so those are the
 three requirements.

0:03:13.120000 --> 0:03:17.900000
 Number one, an application input, number
 two, the application input needs

0:03:17.900000 --> 0:03:21.900000
 to be in some way or form, be
 interacting with the database.

0:03:21.900000 --> 0:03:26.180000
 And thirdly, a lack of proper
 input validation.

0:03:26.180000 --> 0:03:30.500000
 So with that being said, the most straightforward
 way to find SQL injection

0:03:30.500000 --> 0:03:35.000000
 vulnerabilities within web applications
 or websites is to probe its inputs

0:03:35.000000 --> 0:03:36.500000
 with special characters.

0:03:36.500000 --> 0:03:40.640000
 And I'll go over that even though I went
 through this in the introduction

0:03:40.640000 --> 0:03:45.440000
 to SQL or the structured query language
 video, I'll go over this again.

0:03:45.440000 --> 0:03:50.000000
 But we need to probe the application
 inputs with special characters that

0:03:50.000000 --> 0:03:55.020000
 are known to cause the SQL query to
 be syntactically invalid, therefore

0:03:55.020000 --> 0:03:58.000000
 forcing the web application
 to return an error.

0:03:58.000000 --> 0:04:02.700000
 So when we talk about identifying the
 vulnerabilities, so not really the

0:04:02.700000 --> 0:04:07.380000
 exploitation per se, even though the identification
 is part of the exploitation,

0:04:07.380000 --> 0:04:10.340000
 what we're trying to do is we're trying
 to validate whether injection

0:04:10.340000 --> 0:04:15.620000
 is possible. And the easiest way of
 doing that is through error-based

0:04:15.620000 --> 0:04:20.240000
 SQL injection. Now, we'll also be exploring,
 you know, what blind SQL

0:04:20.240000 --> 0:04:24.640000
 injection looks like from the perspective
 of validating that, you know,

0:04:24.640000 --> 0:04:26.480000
 a SQL injection vulnerability exists.

0:04:26.480000 --> 0:04:29.620000
 However, the most common type
 is obviously error-based.

0:04:29.620000 --> 0:04:32.520000
 And this is where you have the
 use of special characters.

0:04:32.520000 --> 0:04:36.040000
 It's the most straightforward and easiest
 way because it's an in-band

0:04:36.040000 --> 0:04:42.740000
 SQL injection attack in that the error
 is returned or is the error or

0:04:42.740000 --> 0:04:47.300000
 the results from the injection are communicated
 back via the same communication

0:04:47.300000 --> 0:04:51.860000
 channel or simply put the error is sent
 back via the web application and

0:04:51.860000 --> 0:04:57.360000
 is displayed usually on the web page
 or the page where you actually made

0:04:57.360000 --> 0:05:03.940000
 the injection. Now, one thing to note,
 and this comes to my first point

0:05:03.940000 --> 0:05:07.180000
 when I was talking about the three requirements
 for successful SQL injection

0:05:07.180000 --> 0:05:13.140000
 is that you must note that not all
 of the inputs in a web application

0:05:13.140000 --> 0:05:15.780000
 will interact with the database.

0:05:15.780000 --> 0:05:20.540000
 What I mean there is that it is always
 recommended to perform reconnaissance

0:05:20.540000 --> 0:05:25.760000
 on the web application firstly and categorize
 the different input parameters

0:05:25.760000 --> 0:05:30.480000
 before you actually begin performing
 SQL injection tests.

0:05:30.480000 --> 0:05:34.840000
 I've already gone over this or highlighted
 this process within this learning

0:05:34.840000 --> 0:05:40.200000
 path for the certification in a course
 on information or on web information

0:05:40.200000 --> 0:05:44.560000
 gathering and enumeration where I outlined
 the process of how, you know,

0:05:44.560000 --> 0:05:48.300000
 you go about mapping out the web application
 performing both passive and

0:05:48.300000 --> 0:05:50.220000
 active reconnaissance on it.

0:05:50.220000 --> 0:05:55.380000
 And part of that, which also leads
 into the web proxy's course, shows

0:05:55.380000 --> 0:06:00.740000
 you how to, you know, essentially
 find these application inputs.

0:06:00.740000 --> 0:06:04.000000
 And once you've identified them, you
 can perform a bit more reconnaissance

0:06:04.000000 --> 0:06:07.980000
 on them to sort of get an understanding
 of what they do and whether that

0:06:07.980000 --> 0:06:13.400000
 data is indeed, you know, passed into
 the database or are, you know, is

0:06:13.400000 --> 0:06:14.800000
 potentially injectable.

0:06:14.800000 --> 0:06:17.200000
 So it's very important
 to keep that in mind.

0:06:17.200000 --> 0:06:24.580000
 So the crescendo here of my point is
 that you need to have performed good

0:06:24.580000 --> 0:06:29.340000
 or successful enumeration or information
 gathering or reconnaissance on

0:06:29.340000 --> 0:06:35.760000
 the web application before you can start testing
 for SQL injection vulnerabilities.

0:06:35.760000 --> 0:06:41.260000
 That process will save you a lot of
 time, you know, in the actual, in

0:06:41.260000 --> 0:06:45.120000
 the overall process of finding vulnerabilities,
 regardless of whether

0:06:45.120000 --> 0:06:48.760000
 they're in the injection vulnerabilities
 or cross-site scripting vulnerabilities,

0:06:48.760000 --> 0:06:54.000000
 etc. So that brings us to the first
 point or the first requirement and

0:06:54.000000 --> 0:06:56.680000
 that is finding injectable fields.

0:06:56.680000 --> 0:07:00.540000
 So from my experience and the experience
 of web app investors and bug

0:07:00.540000 --> 0:07:04.880000
 bounty hunters, what are some of the
 most common injectable fields that

0:07:04.880000 --> 0:07:06.520000
 you should look out for?

0:07:06.520000 --> 0:07:10.660000
 Well, number one, you're obviously going
 to be dealing with login forms,

0:07:10.660000 --> 0:07:14.120000
 right? So the username and password
 fields in a login form are commonly

0:07:14.120000 --> 0:07:17.920000
 or are common targets for
 SQL injection attacks.

0:07:17.920000 --> 0:07:21.560000
 So if the application does not properly
 validate or sanitize the user

0:07:21.560000 --> 0:07:26.120000
 input, an attacker may be able to manipulate
 the SQL query that is used

0:07:26.120000 --> 0:07:32.000000
 for authentication and inject the SQL
 payload or query into one of the

0:07:32.000000 --> 0:07:36.160000
 parameters or rather the values for
 one of the parameters and then, you

0:07:36.160000 --> 0:07:42.140000
 know, utilize special characters if it's
 a string based injection to essentially,

0:07:42.140000 --> 0:07:46.700000
 you know, you use a, you know, for example,
 a single quote as a delimiter

0:07:46.700000 --> 0:07:49.420000
 and then you specify
 your SQL query after.

0:07:49.420000 --> 0:07:52.660000
 We'll take a look at this in the next
 video where we'll actually get started

0:07:52.660000 --> 0:07:57.640000
 with some labs. But yeah, it's very important
 that, you know, you obviously

0:07:57.640000 --> 0:08:00.360000
 take a close look at login forms.

0:08:00.360000 --> 0:08:05.140000
 The next injectable field that, you
 know, you typically want to test is

0:08:05.140000 --> 0:08:08.180000
 search boxes or are search boxes.

0:08:08.180000 --> 0:08:11.700000
 So input fields used for searching
 within an application are potential

0:08:11.700000 --> 0:08:16.180000
 targets for SQL injection, obviously
 because they allow you to input data.

0:08:16.180000 --> 0:08:21.980000
 And in certain cases, this search query
 is referenced by the web application.

0:08:21.980000 --> 0:08:27.680000
 And then in certain cases, the web application
 will make a query or we'll

0:08:27.680000 --> 0:08:30.500000
 interact with the database to try and
 see whether, you know, for example,

0:08:30.500000 --> 0:08:33.920000
 in the case of content measurement systems
 or blogs, whether that search

0:08:33.920000 --> 0:08:38.520000
 query matches any particular blog or any
 string within a body of a particular

0:08:38.520000 --> 0:08:40.920000
 blog or the title of a particular blog.

0:08:40.920000 --> 0:08:42.500000
 So that's an example, right?

0:08:42.500000 --> 0:08:46.300000
 So if the search query is directly
 incorporated into an SQL statement

0:08:46.300000 --> 0:08:50.400000
 without proper validation, an attacker
 can inject malicious SQL code or

0:08:50.400000 --> 0:08:55.720000
 queries to manipulate the query and potentially
 access unauthorized data.

0:08:55.720000 --> 0:09:00.020000
 Some other injectable fields,
 obviously URL parameters.

0:09:00.020000 --> 0:09:02.240000
 This is not usually understood.

0:09:02.240000 --> 0:09:05.260000
 But as I said, in the next video and
 we'll be using a lab, I'll actually

0:09:05.260000 --> 0:09:07.720000
 show you this and what it looks like.

0:09:07.720000 --> 0:09:11.960000
 So web applications will often utilize
 URL parameters to pass data between

0:09:11.960000 --> 0:09:16.500000
 pages. If the application uses these
 parameters directly in constructing

0:09:16.500000 --> 0:09:21.200000
 SQL queries without proper validation and
 sanitization, it can be susceptible

0:09:21.200000 --> 0:09:23.460000
 to SQL injection attacks.

0:09:23.460000 --> 0:09:27.760000
 Now some of the other ones, and these are
 usually not a thought of, especially

0:09:27.760000 --> 0:09:31.000000
 by beginners, or, you know, if you're
 getting started with this, you'd

0:09:31.000000 --> 0:09:34.920000
 not really consider these injectable
 fields based on, you know, their

0:09:34.920000 --> 0:09:36.680000
 purpose and how they work.

0:09:36.680000 --> 0:09:39.260000
 So the other ones, of course,
 are form fields.

0:09:39.260000 --> 0:09:44.260000
 So any input fields in forms such as
 registration forms, contact forms,

0:09:44.260000 --> 0:09:45.180000
 or comment fields.

0:09:45.180000 --> 0:09:49.280000
 And the one that I'm that I've really
 seen quite a lot is comment fields.

0:09:49.280000 --> 0:09:53.040000
 So again, going back to the example
 of a content management system like

0:09:53.040000 --> 0:09:59.480000
 WordPress, on WordPress, blog posts,
 you typically have, by default, the

0:09:59.480000 --> 0:10:02.400000
 ability to write or post a comment.

0:10:02.400000 --> 0:10:07.380000
 Now the great thing with comments is
 comments are typically need to be

0:10:07.380000 --> 0:10:09.080000
 stored and referenced somewhere.

0:10:09.080000 --> 0:10:11.000000
 Now they can be linked
 to the page themselves.

0:10:11.000000 --> 0:10:14.760000
 However, in order to correctly reference,
 and this is where the whole

0:10:14.760000 --> 0:10:21.900000
 relational database methodology or functionality
 comes into play, a user

0:10:21.900000 --> 0:10:23.820000
 firstly needs to be logged in, right?

0:10:23.820000 --> 0:10:26.780000
 You need to have an account on the WordPress
 site in order to post a comment.

0:10:26.780000 --> 0:10:29.480000
 Now this can be changed, but that's
 typically how it works.

0:10:29.480000 --> 0:10:31.700000
 So you create an account,
 where does that data go?

0:10:31.700000 --> 0:10:33.580000
 It goes into the relational database.

0:10:33.580000 --> 0:10:35.420000
 So think of a MySQL database.

0:10:35.420000 --> 0:10:37.180000
 It's a relational database.

0:10:37.180000 --> 0:10:41.960000
 So you know that that data can be interpolated
 or used or linked or related

0:10:41.960000 --> 0:10:43.500000
 to other tables.

0:10:43.500000 --> 0:10:48.580000
 Now, in the case of WordPress, what happens
 is for every post, or rather,

0:10:48.580000 --> 0:10:52.940000
 what will typically happen is you'll
 typically see a table for comments.

0:10:52.940000 --> 0:10:56.060000
 And this comment pulls data
 from the user's table.

0:10:56.060000 --> 0:11:01.040000
 So essentially tying a user account to
 a particular comment, that obviously

0:11:01.040000 --> 0:11:05.440000
 makes sense because you want to be able
 to identify who is typing in that

0:11:05.440000 --> 0:11:08.380000
 comment. And if they have a user account,
 you want to be able to open

0:11:08.380000 --> 0:11:10.940000
 up their user account and
 find out more about them.

0:11:10.940000 --> 0:11:17.820000
 And the second table that this third
 table will reference is going to

0:11:17.820000 --> 0:11:24.360000
 be the actual post, the blog post, or
 the WordPress post table, as it's

0:11:24.360000 --> 0:11:29.280000
 called, so that it links that comment
 to that particular blog post.

0:11:29.280000 --> 0:11:33.140000
 And then this information is referenced
 or is available or is accessible

0:11:33.140000 --> 0:11:36.560000
 via that WordPress comments table.

0:11:36.560000 --> 0:11:41.500000
 So as you can see, this is obviously
 one that you need to pay attention

0:11:41.500000 --> 0:11:46.260000
 to. So if the input is not properly
 validated and or sanitized before

0:11:46.260000 --> 0:11:52.800000
 being used or before being input,
 then SQL injection is possible.

0:11:52.800000 --> 0:11:55.840000
 Some other injectable fields
 are hidden fields.

0:11:55.840000 --> 0:12:01.600000
 So this is typically hidden
 fields in HTML forms.

0:12:01.600000 --> 0:12:05.180000
 And this is not that common,
 but it is possible.

0:12:05.180000 --> 0:12:09.040000
 So hidden fields in HTML forms can also
 be susceptible to SQL injection

0:12:09.040000 --> 0:12:13.060000
 attacks. If the data from these fields
 is again directly incorporated

0:12:13.060000 --> 0:12:16.520000
 into SQL queries without
 proper validation.

0:12:16.520000 --> 0:12:19.320000
 And I'll talk a little bit about parameters
 and the types of parameters

0:12:19.320000 --> 0:12:21.440000
 that you'll typically be dealing with.

0:12:21.440000 --> 0:12:25.840000
 And what I mean, and we've already seen
 this actually in the SQL fundamentals

0:12:25.840000 --> 0:12:31.480000
 video, what I mean when I say parameters,
 but now you'll get an actual

0:12:31.480000 --> 0:12:33.780000
 tacit sense of what I'm talking about.

0:12:33.780000 --> 0:12:37.940000
 And finally, and this is something that
 a lot of beginners sort of avoid

0:12:37.940000 --> 0:12:41.120000
 or ignore. And that is cookies, right?

0:12:41.120000 --> 0:12:46.640000
 Now this is not that common, but it
 is nonetheless an injectable field.

0:12:46.640000 --> 0:12:50.780000
 Cookies containing user data or session
 information may be used in SQL

0:12:50.780000 --> 0:12:54.740000
 queries. That's, you know, you can obviously
 tell why that would be important.

0:12:54.740000 --> 0:12:58.620000
 So if the application does not again
 validate or sanitize the cookie data

0:12:58.620000 --> 0:13:02.000000
 properly, it can lead to SQL
 injection vulnerabilities.

0:13:02.000000 --> 0:13:04.540000
 So these are the common
 injectable fields.

0:13:04.540000 --> 0:13:09.940000
 Now, you've identified or you're aware
 of the common injectable fields.

0:13:09.940000 --> 0:13:12.460000
 You have some that you want to test.

0:13:12.460000 --> 0:13:16.160000
 How do you go about finding or testing
 for SQL injection vulnerabilities

0:13:16.160000 --> 0:13:20.280000
 from a methodology perspective?

0:13:20.280000 --> 0:13:24.040000
 So identifying SQL injection vulnerabilities
 typically involves a combination

0:13:24.040000 --> 0:13:28.220000
 of both manual and automated testing,
 which is why I'm going to go through

0:13:28.220000 --> 0:13:30.280000
 this process sequentially.

0:13:30.280000 --> 0:13:34.820000
 So we'll start off in the next video
 with the practical lab by performing

0:13:34.820000 --> 0:13:38.700000
 manual testing, and then we'll move
 on and then utilize something like

0:13:38.700000 --> 0:13:41.000000
 OASP ZAP. And I'll show
 you how to do that.

0:13:41.000000 --> 0:13:45.760000
 That is sort of somewhat semi automated.

0:13:45.760000 --> 0:13:50.400000
 And then when we move on to the exploitation
 section of this course, I'll

0:13:50.400000 --> 0:13:52.280000
 be utilizing SQL map.

0:13:52.280000 --> 0:13:55.800000
 And the reason I'll be doing that is
 because that's the best way to learn

0:13:55.800000 --> 0:13:59.140000
 how to use SQL map is through practical
 examples and, you know, putting

0:13:59.140000 --> 0:14:00.780000
 it through different use cases.

0:14:00.780000 --> 0:14:04.960000
 So when you when it comes down to manual
 testing, the first thing you

0:14:04.960000 --> 0:14:08.860000
 typically want to do is perform manual
 testing with malicious input.

0:14:08.860000 --> 0:14:13.040000
 So try injecting SQL statements or
 special characters like the single

0:14:13.040000 --> 0:14:17.280000
 quote into input fields, such as login
 form search boxes or URL parameters.

0:14:17.280000 --> 0:14:22.700000
 And what you want to do is look for
 unexpected behavior error messages

0:14:22.700000 --> 0:14:27.700000
 or any indications that the input
 is being interpreted as SQL code.

0:14:27.700000 --> 0:14:33.220000
 So you're really looking for any sign
 that what you've just injected is

0:14:33.220000 --> 0:14:34.840000
 being sent to the database.

0:14:34.840000 --> 0:14:37.660000
 And this comes to the second requirement,
 which is the fact that the login

0:14:37.660000 --> 0:14:40.620000
 or application input needs to be
 interacting with the database.

0:14:40.620000 --> 0:14:42.440000
 So you're looking for any indication.

0:14:42.440000 --> 0:14:46.460000
 And again, this can also be blind where
 you use something like time based

0:14:46.460000 --> 0:14:50.580000
 injection. But you're just looking
 for anything, any indication at all

0:14:50.580000 --> 0:14:55.520000
 as to whether or not the query or the
 special character that you've just

0:14:55.520000 --> 0:15:04.120000
 injected is being executed or is being
 interpreted by the by the exploring

0:15:04.120000 --> 0:15:07.920000
 this now. This can obviously be broken
 down into error based testing where

0:15:07.920000 --> 0:15:12.340000
 you submit intentionally malformed input
 to trigger SQL queries that can

0:15:12.340000 --> 0:15:16.220000
 reveal underlying database errors
 or SQL statements being executed.

0:15:16.220000 --> 0:15:19.280000
 And of course, we'll also touch on this.

0:15:19.280000 --> 0:15:24.220000
 We then of course union based testing where
 we inject union select statements

0:15:24.220000 --> 0:15:29.480000
 into input fields that can that will allow
 us to determine if the application

0:15:29.480000 --> 0:15:33.740000
 is vulnerable to SQL injection by retrieving
 data from other tables or

0:15:33.740000 --> 0:15:36.740000
 databases. We obviously have
 Boolean based testing.

0:15:36.740000 --> 0:15:43.060000
 This is very, very popular, for example,
 in trying to bypass in trying

0:15:43.060000 --> 0:15:48.520000
 to bypass login, login screens or in trying
 to bypass authentication forms.

0:15:48.520000 --> 0:15:50.140000
 And again, I'll show you this.

0:15:50.140000 --> 0:15:53.820000
 So this involves manipulating the applications
 response based on Boolean

0:15:53.820000 --> 0:15:58.620000
 conditions. And this will help you determine
 if the application is vulnerable.

0:15:58.620000 --> 0:16:04.640000
 So for example, injecting single quote
 or one equals one in a login form

0:16:04.640000 --> 0:16:06.820000
 will help you bypass authentication.

0:16:06.820000 --> 0:16:10.560000
 The reason this works is we're using
 a string delimiter, which is the

0:16:10.560000 --> 0:16:12.300000
 the actual single quote.

0:16:12.300000 --> 0:16:17.500000
 And then we utilizing a logical operator
 to say that you can run the previous

0:16:17.500000 --> 0:16:20.500000
 SQL query that precedes this query.

0:16:20.500000 --> 0:16:24.760000
 And it doesn't matter what the
 result is of that query.

0:16:24.760000 --> 0:16:28.120000
 What you can do is you can
 also run this query.

0:16:28.120000 --> 0:16:31.420000
 And in this case, the query is always
 going to be true, because one is

0:16:31.420000 --> 0:16:33.120000
 always going to be equal to one.

0:16:33.120000 --> 0:16:38.480000
 Now the great thing with Boolean based
 payloads or SQL queries is this

0:16:38.480000 --> 0:16:40.340000
 doesn't have to be one equals one.

0:16:40.340000 --> 0:16:47.980000
 This can be, for example, a equals a 100
 equals 100 as long as that operation

0:16:47.980000 --> 0:16:50.780000
 is always true. It will work.

0:16:50.780000 --> 0:16:53.940000
 And in this case, this is a common
 way of bypassing authentication or

0:16:53.940000 --> 0:16:58.240000
 a login screen. You then have time based
 testing, which is also, you know,

0:16:58.240000 --> 0:17:02.620000
 very, very popular, because in most cases,
 you're on most modern websites,

0:17:02.620000 --> 0:17:06.980000
 you're typically going to see either
 mix of union based testing, Boolean

0:17:06.980000 --> 0:17:11.460000
 based testing, and time based testing,
 more so time based testing, you

0:17:11.460000 --> 0:17:14.140000
 know, even though you're not getting
 back the results, you can always

0:17:14.140000 --> 0:17:19.200000
 utilize a tool like SQL map, which
 has some out of band functionality

0:17:19.200000 --> 0:17:21.720000
 where data is returned back to you.

0:17:21.720000 --> 0:17:24.700000
 And that's typically why people
 or pen testers use it.

0:17:24.700000 --> 0:17:29.340000
 So with time based testing, as I mentioned,
 in the SQL fundamental section

0:17:29.340000 --> 0:17:35.100000
 of this course, involves injecting time
 based time delayed SQL queries.

0:17:35.100000 --> 0:17:39.040000
 In order to reveal if the application
 is vulnerable to time based blind

0:17:39.040000 --> 0:17:42.320000
 SQL injection by observing the
 delays in server response.

0:17:42.320000 --> 0:17:48.280000
 So you essentially use an SQL query that
 is designed to invoke or to tell

0:17:48.280000 --> 0:17:55.120000
 the database to delay the execution
 of the SQL query by a certain amount

0:17:55.120000 --> 0:17:59.100000
 of time. And then if it's successful,
 you're able to monitor the response

0:17:59.100000 --> 0:18:01.840000
 time and say, okay, yeah,
 so that took 30 seconds.

0:18:01.840000 --> 0:18:03.940000
 That means it is working.

0:18:03.940000 --> 0:18:09.760000
 And you can also utilize other, you
 know, SQL commands or SQL syntax to,

0:18:09.760000 --> 0:18:15.480000
 for example, sleep after execution
 before results are returned.

0:18:15.480000 --> 0:18:17.660000
 And again, this is something
 we'll be exploring as well.