WEBVTT

0:00:03.660000 --> 0:00:05.860000
 Hello everyone and welcome.

0:00:05.860000 --> 0:00:09.580000
 In this video we're going to be
 taking a look at ORM injection.

0:00:09.580000 --> 0:00:12.740000
 However, before we do that we actually
 need to get an introduction to

0:00:12.740000 --> 0:00:19.500000
 ORM. So this particular vulnerability
 we're not going to cover practically.

0:00:19.500000 --> 0:00:31.180000
 And the reason for that will become
 apparent immediately after the SQL

0:00:31.180000 --> 0:00:33.480000
 injection section of this course.

0:00:33.480000 --> 0:00:38.000000
 But again, I thought it would be wise
 to cover it after we have taken

0:00:38.000000 --> 0:00:42.560000
 a look at the primary injection vulnerabilities
 or some of the more important

0:00:42.560000 --> 0:00:46.840000
 ones or the advanced techniques
 if you will.

0:00:46.840000 --> 0:00:52.620000
 And you may be asking, so what exactly how
 does this tie back to SQL injection?

0:00:52.620000 --> 0:00:57.340000
 Well, if you're familiar with
 ORMs then you know the answer.

0:00:57.340000 --> 0:01:01.940000
 Or if you're familiar with ORM I should
 say then you know the answer.

0:01:01.940000 --> 0:01:08.660000
 If you're not familiar with ORM and what
 this is pretty much as a technology,

0:01:08.660000 --> 0:01:10.920000
 as a concept, etc.

0:01:10.920000 --> 0:01:15.980000
 Then you might be asking yourself how
 does this link back to relational

0:01:15.980000 --> 0:01:21.300000
 databases? And one of the things that
 I want you to pay attention to is

0:01:21.300000 --> 0:01:22.340000
 the actual name.

0:01:22.340000 --> 0:01:28.420000
 So you know not ORM the abbreviation
 but object relational.

0:01:28.420000 --> 0:01:34.100000
 So let's get started by understanding
 what exactly ORM is.

0:01:34.100000 --> 0:01:40.200000
 So ORM stands for the object relational
 mapping or object relational mapping.

0:01:40.200000 --> 0:01:45.300000
 And it is a programming technique that is
 used to map objects in an application

0:01:45.300000 --> 0:01:46.840000
 to database tables.

0:01:46.840000 --> 0:01:50.120000
 So if you take a look at the name object
 relational what you're trying

0:01:50.120000 --> 0:01:58.340000
 to do is you're trying to create this
 bridge between objects and objects

0:01:58.340000 --> 0:02:01.240000
 or data in a relational database.

0:02:01.240000 --> 0:02:06.000000
 So what ORM does is it abstracts database
 operations allowing developers

0:02:06.000000 --> 0:02:10.060000
 to interact with the database using
 object-oriented programming concepts

0:02:10.060000 --> 0:02:12.760000
 instead of writing raw SQL queries.

0:02:12.760000 --> 0:02:18.060000
 So what you're doing and again there's
 many reasons why you do this as

0:02:18.060000 --> 0:02:21.800000
 a developer. We will get
 into them shortly.

0:02:21.800000 --> 0:02:25.180000
 But what you're doing is let's say you're
 developing a PHP web application

0:02:25.180000 --> 0:02:31.000000
 that utilizes a relational database
 like MySQL for whatever reason.

0:02:31.000000 --> 0:02:35.660000
 It could be storing user credentials,
 all of that good stuff.

0:02:35.660000 --> 0:02:40.740000
 And ORM comes between, I'm not saying
 it's a separate layer, it's sort

0:02:40.740000 --> 0:02:45.480000
 of built into the actual code of the
 web application but it acts as this

0:02:45.480000 --> 0:02:52.300000
 layer between the web application
 code and the actual database.

0:02:52.300000 --> 0:02:54.500000
 And you'll actually see
 how that plays out.

0:02:54.500000 --> 0:03:02.280000
 So instead of the web application making
 direct SQL queries to the database,

0:03:02.280000 --> 0:03:08.480000
 ORM essentially acts as an abstraction
 layer or a translation layer if

0:03:08.480000 --> 0:03:13.920000
 you will. So as I've just mentioned
 in this slide ORM bridges the gap

0:03:13.920000 --> 0:03:18.480000
 between object-oriented programming
 languages like Python, Java or Ruby

0:03:18.480000 --> 0:03:24.380000
 and relational databases like
 MySQL, PostgreSQL or SQLite.

0:03:24.380000 --> 0:03:29.780000
 And it automates the process of converting
 data between incompatible systems

0:03:29.780000 --> 0:03:35.160000
 by mapping classes to database tables
 and objects to rows within those

0:03:35.160000 --> 0:03:37.580000
 tables. That's typically how it's done.

0:03:37.580000 --> 0:03:43.220000
 So that begs the question, why would
 anyone want to use ORM or object

0:03:43.220000 --> 0:03:45.180000
 relational mapping?

0:03:45.180000 --> 0:03:48.900000
 Well, there's a couple of reasons but
 let's start off with the fact that

0:03:48.900000 --> 0:03:55.180000
 it acts as a bridge between object-oriented
 code and relational databases.

0:03:55.180000 --> 0:04:00.820000
 So relational databases store data in tables
 while object-oriented programming

0:04:00.820000 --> 0:04:04.520000
 languages use objects and classes.

0:04:04.520000 --> 0:04:10.280000
 What happens or why ORM is used in this
 case because it translates object

0:04:10.280000 --> 0:04:14.560000
 structures into table structures and
 vice versa, essentially enabling

0:04:14.560000 --> 0:04:16.740000
 a seamless interaction.

0:04:16.740000 --> 0:04:19.680000
 Secondly, it simplifies
 database operations.

0:04:19.680000 --> 0:04:24.200000
 That's arguably one of the main reasons
 ORM's are used or ORM is used

0:04:24.200000 --> 0:04:28.300000
 as a practice when I refer
 to ORM's in plural.

0:04:28.300000 --> 0:04:32.900000
 I'm really referring to the actual
 frameworks that are used to do this

0:04:32.900000 --> 0:04:39.700000
 for different languages but ORM's provide
 a high level API for performing

0:04:39.700000 --> 0:04:42.420000
 common database operations like CRUD.

0:04:42.420000 --> 0:04:47.280000
 So create, read, update, delete
 without requiring SQL knowledge.

0:04:47.280000 --> 0:04:52.240000
 So I don't know if that's a good thing
 with an application developers

0:04:52.240000 --> 0:05:05.220000
 should not know SQL or outright SQL in
 the context or from the perspective

0:05:05.220000 --> 0:05:08.020000
 of a web application developer.

0:05:08.020000 --> 0:05:15.960000
 We also have the fact that it reduces boilerplate
 code, so reduce boilerplate

0:05:15.960000 --> 0:05:21.300000
 code. So ORM eliminates repetitive SQL
 code, essentially allowing developers

0:05:21.300000 --> 0:05:26.520000
 to focus on application logic rather than
 the database interaction details.

0:05:26.520000 --> 0:05:35.480000
 Another very good reason or another
 primary reason is to why ORM's are

0:05:35.480000 --> 0:05:40.040000
 used. Now you may still be confused
 because you may be asking, well, how

0:05:40.040000 --> 0:05:45.620000
 do you know if a web application
 is utilizing an ORM framework?

0:05:45.620000 --> 0:05:47.960000
 Well, don't worry, we'll actually
 get to that shortly.

0:05:47.960000 --> 0:05:52.760000
 So there's also a couple of other reasons
 that I wanted to highlight here

0:05:52.760000 --> 0:05:56.660000
 and that proceeding to the fourth one
 here, you know, ensure database

0:05:56.660000 --> 0:06:01.840000
 independence. ORM frameworks abstract
 database specific syntax, essentially

0:06:01.840000 --> 0:06:05.740000
 making applications more portable
 across different databases.

0:06:05.740000 --> 0:06:12.980000
 So, you know, it's sort of getting
 rid of the nuances of various types

0:06:12.980000 --> 0:06:19.920000
 of relational databases and the the differences
 between the two by providing

0:06:19.920000 --> 0:06:26.640000
 sort of, you know, by essentially abstracting
 database specific syntax.

0:06:26.640000 --> 0:06:30.280000
 So it's sort of a level playing field.

0:06:30.280000 --> 0:06:35.040000
 If you're using an ORM to, you know,
 interact with a database, it doesn't

0:06:35.040000 --> 0:06:39.980000
 matter what relational database is being
 used, whether it's MySQL, PostgreSQL,

0:06:39.980000 --> 0:06:46.360000
 SQLite, the ORM code or
 syntax remains the same.

0:06:46.360000 --> 0:06:49.800000
 You then have, you know, increased
 developer productivity.

0:06:49.800000 --> 0:06:54.200000
 So that's fairly obvious by reducing
 the complexity of database queries

0:06:54.200000 --> 0:06:58.780000
 and automating data transformations
 ORM speeds up development time.

0:06:58.780000 --> 0:07:02.660000
 And then of course, enhanced security,
 which I'm guessing you might have

0:07:02.660000 --> 0:07:09.980000
 been actually, you know, moving towards
 as I've been explaining this.

0:07:09.980000 --> 0:07:14.760000
 So ORM frameworks often include mechanisms
 like parameterized queries,

0:07:14.760000 --> 0:07:18.160000
 which help mitigate vulnerabilities
 like SQL injection.

0:07:18.160000 --> 0:07:21.460000
 So you may be asking yourself
 another question.

0:07:21.460000 --> 0:07:26.520000
 And that is, well, if ORMs are used
 specifically to mitigate, you know,

0:07:26.520000 --> 0:07:31.360000
 vulnerabilities like SQL injection,
 then, you know, where on earth does

0:07:31.360000 --> 0:07:34.340000
 ORM injection come from?

0:07:34.340000 --> 0:07:36.580000
 Well, we'll get to that shortly.

0:07:36.580000 --> 0:07:39.180000
 This is actually quite important.

0:07:39.180000 --> 0:07:44.420000
 Now I've not listed every ORM framework
 out there, but I think it's very

0:07:44.420000 --> 0:07:47.360000
 important that you're at least familiar
 with some of the most popular

0:07:47.360000 --> 0:07:51.880000
 ORM frameworks for each language.

0:07:51.880000 --> 0:07:57.100000
 And starting off with the first one,
 you know, we have SQL alchemy, which

0:07:57.100000 --> 0:08:02.660000
 is, you know, is essentially
 an ORM for Python.

0:08:02.660000 --> 0:08:07.120000
 As you can see in the description here,
 versatile and widely used ORM

0:08:07.120000 --> 0:08:12.260000
 supports advanced queries and raw SQL,
 you then have hibernate for Java.

0:08:12.260000 --> 0:08:17.680000
 So the most popular ORM for Java with extensive
 features and JPA integration,

0:08:17.680000 --> 0:08:21.080000
 you then have the entity framework,
 which is, you know, for dot nets or

0:08:21.080000 --> 0:08:25.820000
 Microsoft's official ORM that's fully
 integrated into the dot net ecosystem

0:08:25.820000 --> 0:08:30.800000
 for Python again, you
 have the Django ORM.

0:08:30.800000 --> 0:08:39.040000
 This is actually quite, you know, it's
 actually quite, it's actually one

0:08:39.040000 --> 0:08:42.960000
 of the more popular ones for Python,
 or, you know, if you're developing

0:08:42.960000 --> 0:08:44.940000
 a Django web application.

0:08:44.940000 --> 0:08:48.940000
 So it's essentially, you know, the
 built in ORM for Django focusing on

0:08:48.940000 --> 0:08:50.960000
 simplicity and ease of use.

0:08:50.960000 --> 0:08:55.340000
 And then for PHP, arguably the most
 popular would be eloquent ORM.

0:08:55.340000 --> 0:09:01.400000
 Now it's not, you know, the only one,
 but this is Laravel's intuitive

0:09:01.400000 --> 0:09:07.920000
 ORM, you know, emphasizing simplicity
 and productivity, very, very popular.

0:09:07.920000 --> 0:09:13.080000
 So the reason I'm sort of stating this
 is, the reason I've listed these

0:09:13.080000 --> 0:09:18.620000
 out is because identifying whether
 they're, you know, whether there is

0:09:18.620000 --> 0:09:23.980000
 an ORM present is sort of important now
 that you actually understand what

0:09:23.980000 --> 0:09:29.120000
 they do or what ORM's arm,
 what they used for, etc.

0:09:29.120000 --> 0:09:33.540000
 It might actually be an important factor
 in you actually identifying the

0:09:33.540000 --> 0:09:36.860000
 presence of a SQL injection
 vulnerability.

0:09:36.860000 --> 0:09:42.020000
 And the reason why I've just said that
 is because while they, while an

0:09:42.020000 --> 0:09:47.340000
 ORM, you know, sort of bridges the gap
 or access and, you know, essentially

0:09:47.340000 --> 0:09:56.620000
 abstracts the behold process of utilizing
 SQL queries, remember, it's

0:09:56.620000 --> 0:10:01.040000
 still making, it's still making
 queries to the actual database.

0:10:01.040000 --> 0:10:05.440000
 So let's actually proceed
 a little bit more.

0:10:05.440000 --> 0:10:07.380000
 And all of this will start
 to become clear.

0:10:07.380000 --> 0:10:11.240000
 So this may have raised another question.


0:10:11.240000 --> 0:10:15.380000
 And that is, you know, it may have
 raised another question for you.

0:10:15.380000 --> 0:10:21.820000
 And that is how, how, how are ORM's
 used in web applications?

0:10:21.820000 --> 0:10:36.720000
 So firstly, you know, you know, the,
 as I mentioned in the previous slide,

0:10:36.720000 --> 0:10:42.780000
 you know, why, why you choose to utilize
 an ORM when building a web application.

0:10:42.780000 --> 0:10:46.820000
 So ORM frameworks provide an API to interact
 with the database using methods

0:10:46.820000 --> 0:10:51.980000
 and objects, essentially reducing
 the need for manual SQL.

0:10:51.980000 --> 0:10:55.700000
 And, you know, I just listed out some
 example frameworks on the previous

0:10:55.700000 --> 0:11:00.040000
 slide. But the one that I didn't mention
 there was, you know, active record,

0:11:00.040000 --> 0:11:06.180000
 which is for Ruby on Rails, you then
 have mapping objects to tables.

0:11:06.180000 --> 0:11:14.300000
 So objects represent rows in a table
 and attributes correspond to columns.

0:11:14.300000 --> 0:11:18.140000
 So I think you're starting to understand
 what's going on when you're developing

0:11:18.140000 --> 0:11:21.740000
 a web application, let's say in PHP,
 any, you know, you're developing

0:11:21.740000 --> 0:11:26.300000
 a login form that then makes a SQL query
 to the database, you're essentially

0:11:26.300000 --> 0:11:27.780000
 getting rid of that.

0:11:27.780000 --> 0:11:35.640000
 And you're now utilizing the ORM specific
 syntax, specifically in, you

0:11:35.640000 --> 0:11:39.540000
 know, when we're talking
 about objects, etc.

0:11:39.540000 --> 0:11:43.340000
 And then you can, you can sort of start
 to understand how this works.

0:11:43.340000 --> 0:11:47.020000
 So an example of this is a user
 class maps to a user's table.

0:11:47.020000 --> 0:11:51.920000
 So in, you know, you'd essentially
 use the user's class and then, you

0:11:51.920000 --> 0:11:55.980000
 know, the, in this case, it maps to the
 user's table in the database with

0:11:55.980000 --> 0:11:59.040000
 attributes like username and email, etc.

0:11:59.040000 --> 0:12:04.500000
 And that brings us to the final point
 here, the advantages of ORM in the

0:12:04.500000 --> 0:12:06.400000
 context of web apps.

0:12:06.400000 --> 0:12:11.100000
 As I mentioned previously, it reduces
 boilerplate code, provides database

0:12:11.100000 --> 0:12:15.980000
 agnostic query support, and it improves
 maintainability by centralizing

0:12:15.980000 --> 0:12:23.960000
 database logic. So that begs the question,
 how exactly, you know, ORM,

0:12:23.960000 --> 0:12:28.940000
 how exactly does ORM work or does
 an ORM work if that makes sense.

0:12:28.940000 --> 0:12:33.640000
 So these are sort of the
 key concepts behind ORM.

0:12:33.640000 --> 0:12:36.500000
 The first is entity to table mapping.

0:12:36.500000 --> 0:12:41.160000
 So each class in the application
 corresponds to a database table.

0:12:41.160000 --> 0:12:44.840000
 Each attribute of the class represents
 a column in the table.

0:12:44.840000 --> 0:12:49.020000
 And then of course for crowd operations,
 ORM provides methods to perform

0:12:49.020000 --> 0:12:52.580000
 database operations without writing
 SQL queries manually.

0:12:52.580000 --> 0:12:58.340000
 So, you know, if you were to write a
 SQL query to search for, you know,

0:12:58.340000 --> 0:13:01.680000
 specific information from the user's
 table, you know, you'd say select,

0:13:01.680000 --> 0:13:07.380000
 you know, from, etc., which would
 be read in terms of crowd.

0:13:07.380000 --> 0:13:13.560000
 What I'm trying to point out here is
 that ORM's essentially, so ORM's

0:13:13.560000 --> 0:13:20.860000
 provide methods to operations that you're
 likely to, again, that you would

0:13:20.860000 --> 0:13:22.700000
 have been likely to write manually.

0:13:22.700000 --> 0:13:24.500000
 So you don't need to worry about that.

0:13:24.500000 --> 0:13:27.760000
 And then of course, we have abstraction
 of database queries.

0:13:27.760000 --> 0:13:31.980000
 So developers interact with the database
 through high level APIs, which

0:13:31.980000 --> 0:13:35.420000
 the ORM translates into SQL queries.

0:13:35.420000 --> 0:13:40.220000
 So it's actually performing a translation,
 which is actually quite important.

0:13:40.220000 --> 0:13:49.780000
 So here, I looks like, so we're
 going to take a look firstly at.

0:13:49.780000 --> 0:13:53.640000
 So I'll just, I'll just brief
 you on the example here.

0:13:53.640000 --> 0:13:57.220000
 So the following example that we'll
 be looking at in the next couple of

0:13:57.220000 --> 0:14:03.120000
 slides, illustrates how an ORM framework
 simplifies database interactions

0:14:03.120000 --> 0:14:07.080000
 into in a typical web
 application scenario.

0:14:07.080000 --> 0:14:10.840000
 And this scenario revolves around managing
 user data in a database, including

0:14:10.840000 --> 0:14:14.100000
 creating, reading, updating,
 and deleting records.

0:14:14.100000 --> 0:14:18.880000
 The goal of this example is to highlight
 how ORM abstracts SQL queries

0:14:18.880000 --> 0:14:24.380000
 and allows developers to work with data
 using object-oriented principles.

0:14:24.380000 --> 0:14:29.540000
 So without an ORM, this is sort of a
 web application that has a raw SQL

0:14:29.540000 --> 0:14:34.080000
 query. You can see that this is Python.

0:14:34.080000 --> 0:14:40.240000
 So import SQLite 3, connect SQLite
 3, and then cursor execute, insert

0:14:40.240000 --> 0:14:42.980000
 into users, username, email.

0:14:42.980000 --> 0:14:47.640000
 Okay. And then in this case,
 this is a very basic code.

0:14:47.640000 --> 0:14:51.940000
 But the bottom line is this is typically
 how you would, you know, how

0:14:51.940000 --> 0:14:59.080000
 you would configure your web application
 to connect to ORM or interact

0:14:59.080000 --> 0:15:10.280000
 with a relational when we
 actually utilize an ORM.

0:15:10.280000 --> 0:15:16.260000
 In this case, SQL alchemy, which if
 you remember in the previous set of

0:15:16.260000 --> 0:15:20.040000
 slides, or a few slides back
 was for Python, right?

0:15:20.040000 --> 0:15:21.740000
 It's a Python ORM.

0:15:21.740000 --> 0:15:26.140000
 So what's happening here now, and I'll
 sort of explain it using the next

0:15:26.140000 --> 0:15:33.300000
 slide, is you can see that instead
 of what we just had, the user class

0:15:33.300000 --> 0:15:38.240000
 is mapped to a database table
 called or named users.

0:15:38.240000 --> 0:15:44.540000
 So you can see the class right over
 here, user, and this is mapped to

0:15:44.540000 --> 0:15:45.260000
 a database table.

0:15:45.260000 --> 0:15:48.920000
 So you need to say table
 name is equal to users.

0:15:48.920000 --> 0:15:50.920000
 And then this is where you
 perform the mapping.

0:15:50.920000 --> 0:15:56.740000
 So each attribute of the class, so,
 you know, ID, username, email, etc.

0:15:56.740000 --> 0:16:00.340000
 Maps to a column in the users table
 with the specified data type.

0:16:00.340000 --> 0:16:02.800000
 So is it an integer or a string?

0:16:02.800000 --> 0:16:07.020000
 From a security perspective, you can
 actually tell, you know, just how

0:16:07.020000 --> 0:16:13.600000
 useful this is, because you can actually
 now sort of enforce or ensure

0:16:13.600000 --> 0:16:19.720000
 that specific data that, you know,
 let's say you can actually enforce

0:16:19.720000 --> 0:16:25.980000
 the format of data that the web application
 uses or is expecting, let's

0:16:25.980000 --> 0:16:31.240000
 say, but you can see ID is equal to
 column, and then you specify the the

0:16:31.240000 --> 0:16:36.100000
 data type. So integer, and then, you
 know, primary key is equal to true.

0:16:36.100000 --> 0:16:41.500000
 Usename is equal to column string,
 email equals column string, etc.

0:16:41.500000 --> 0:16:43.860000
 So very, very simple to understand.

0:16:43.860000 --> 0:16:50.980000
 You're essentially just translating
 whatever is stored in the database,

0:16:50.980000 --> 0:16:56.860000
 a relational database, and the format
 it's stored as to, you know, the

0:16:56.860000 --> 0:17:05.360000
 way you actually configure the web
 application to use that data or to

0:17:05.360000 --> 0:17:07.880000
 query that data, if that makes sense.

0:17:07.880000 --> 0:17:13.160000
 So moving on, you can see right over here
 where we have, in this particular

0:17:13.160000 --> 0:17:24.860000
 case, this is used to be, is an instance
 of the user class representing

0:17:24.860000 --> 0:17:27.040000
 a single row in the user's table.

0:17:27.040000 --> 0:17:34.740000
 So a new user is equal to user, you
 know, which in this case, new user,

0:17:34.740000 --> 0:17:38.260000
 as you can see, there's an instance
 of the user class, which we created

0:17:38.260000 --> 0:17:44.060000
 here, essentially inferring that, you
 know, essentially representing a

0:17:44.060000 --> 0:17:45.540000
 single row in the user's table.

0:17:45.540000 --> 0:17:50.880000
 So you say user, username is equal,
 John Doe, and then, of course, the

0:17:50.880000 --> 0:17:59.600000
 ad operation, or session ad, I should say
 session ad new user method schedules

0:17:59.600000 --> 0:18:01.680000
 the object to be inserted
 into the database.

0:18:01.680000 --> 0:18:05.940000
 So instead of saying writing a SQL query
 that says, insert the following

0:18:05.940000 --> 0:18:10.600000
 or insert new user would be the parameter
 that you'd insert there into

0:18:10.600000 --> 0:18:15.580000
 the following table, you essentially
 just say session ad new user.

0:18:15.580000 --> 0:18:21.760000
 And you've already, the new user variable
 is equal to, you know, the actual

0:18:21.760000 --> 0:18:23.620000
 value of the new user.

0:18:23.620000 --> 0:18:25.640000
 And then, of course, we have
 the commit operation.

0:18:25.640000 --> 0:18:29.760000
 So session.commit method sends the SQL
 insert statement to the database

0:18:29.760000 --> 0:18:32.640000
 to persist the new record.

0:18:32.640000 --> 0:18:38.300000
 So what you're doing is just moving
 away from direct or raw SQL queries

0:18:38.300000 --> 0:18:44.880000
 to something a little bit more fitting,
 you know, in terms of object oriented

0:18:44.880000 --> 0:18:47.180000
 programming languages.

0:18:47.180000 --> 0:18:51.440000
 And from my perspective, I actually really
 like this goes when I'm developing

0:18:51.440000 --> 0:18:57.820000
 a web application, you know, using
 a SQL query can, I'm not saying is

0:18:57.820000 --> 0:19:01.980000
 the worst thing I've developed many
 web applications, again, that have,

0:19:01.980000 --> 0:19:04.560000
 that make direct calls to the database.

0:19:04.560000 --> 0:19:09.280000
 But this actually sort of makes much
 more sense, because again, it goes

0:19:09.280000 --> 0:19:13.160000
 back to the advantages that
 I listed out previously.

0:19:13.160000 --> 0:19:19.340000
 You don't need to get into, you know,
 designing the communication or how

0:19:19.340000 --> 0:19:23.640000
 the application communicates with the
 database and, and all of that stuff,

0:19:23.640000 --> 0:19:30.520000
 you can sort of use an ORM to let it
 do, or, you know, to essentially

0:19:30.520000 --> 0:19:32.760000
 handle the actual interaction.

0:19:32.760000 --> 0:19:37.160000
 And you just tell, or you configure
 the ORM to do whatever you wanted

0:19:37.160000 --> 0:19:42.460000
 to do, you know, in a format that is
 quite intuitive, especially if you're

0:19:42.460000 --> 0:19:47.580000
 a developer. So that brings
 us now to ORM injection.

0:19:47.580000 --> 0:19:52.440000
 So I've sort of explained, you know,
 what ORM is and all that good stuff.

0:19:52.440000 --> 0:19:57.720000
 And you're, you're, you've seen exactly
 how it works in terms of the changes

0:19:57.720000 --> 0:20:00.760000
 it affects to a web application.

0:20:00.760000 --> 0:20:05.640000
 But really the most important thing
 to understand is that fundamentally,

0:20:05.640000 --> 0:20:12.640000
 the web application is still through
 the ORM API making SQL queries to

0:20:12.640000 --> 0:20:14.540000
 the relational database.

0:20:14.540000 --> 0:20:17.500000
 That remains, you know, constant.

0:20:17.500000 --> 0:20:19.240000
 It's not changing anything else.

0:20:19.240000 --> 0:20:21.560000
 And the SQL queries are still being used.


0:20:21.560000 --> 0:20:25.660000
 It's just that the, the
 ORM is translating them.

0:20:25.660000 --> 0:20:30.540000
 So again, at the beginning of the video,
 this is why I sort of said that

0:20:30.540000 --> 0:20:33.740000
 this is very closely related
 to SQL injection.

0:20:33.740000 --> 0:20:40.140000
 And it is. So let's actually understand
 what ORM injection is.

0:20:40.140000 --> 0:20:45.680000
 So ORM injection is a type of injection
 vulnerability that targets applications

0:20:45.680000 --> 0:20:50.120000
 using an ORM framework to
 interact with a database.

0:20:50.120000 --> 0:20:54.140000
 So what is the vulnerability exactly?

0:20:54.140000 --> 0:20:58.880000
 So this vulnerability or injection
 occurs when untrusted user input is

0:20:58.880000 --> 0:21:05.900000
 again, as it always is, is improperly
 sanitized and passed to ORM query

0:21:05.900000 --> 0:21:09.880000
 methods, allowing an attacker to manipulate
 the underlying SQL query generated

0:21:09.880000 --> 0:21:15.360000
 by the ORM. So that might be a bit confusing,
 but don't worry, it'll actually

0:21:15.360000 --> 0:21:18.120000
 make sense. So how does
 ORM injection work?

0:21:18.120000 --> 0:21:23.660000
 So ORM injection exploits the abstraction
 provided by ORM frameworks to

0:21:23.660000 --> 0:21:29.920000
 manipulate database queries indirectly, while
 ORM's aim to prevent vulnerabilities

0:21:29.920000 --> 0:21:34.440000
 like SQL injection in proper handling
 of user input can still expose,

0:21:34.440000 --> 0:21:37.720000
 you know, applications to attacks.

0:21:37.720000 --> 0:21:42.460000
 So what causes ORM injection
 vulnerabilities?

0:21:42.460000 --> 0:21:48.280000
 So obviously, number one, it's all, you
 know, these vulnerabilities always

0:21:48.280000 --> 0:21:51.080000
 stem from improper input validation.

0:21:51.080000 --> 0:21:55.540000
 So failure to validate or sanitize user
 input allows malicious payloads

0:21:55.540000 --> 0:21:58.620000
 to be passed into ORM methods.

0:21:58.620000 --> 0:22:01.200000
 And then of course, you have
 dynamic query construction.

0:22:01.200000 --> 0:22:06.680000
 So this is actually one of the reasons
 or one of the prime causes, I would

0:22:06.680000 --> 0:22:11.780000
 say, you know, and it
 sort of makes sense.

0:22:11.780000 --> 0:22:18.940000
 Whenever you're given a new layer of
 human beings, always resort to type

0:22:18.940000 --> 0:22:21.020000
 and sort of get carried away.

0:22:21.020000 --> 0:22:26.240000
 So building dynamic queries by concatenating
 strings with user input introduces

0:22:26.240000 --> 0:22:27.960000
 vulnerabilities.

0:22:27.960000 --> 0:22:32.620000
 So in this case, there's an example here
 where you have user query filter.

0:22:32.620000 --> 0:22:36.760000
 So F, you know, username
 is equal to username.

0:22:36.760000 --> 0:22:39.900000
 And in this case, and password
 equals password.

0:22:39.900000 --> 0:22:45.220000
 So you can see the concatenation
 there, not all.

0:22:45.220000 --> 0:22:50.820000
 So what are some of the other causes,
 you know, use of raw SQL in ORM?

0:22:50.820000 --> 0:22:55.360000
 So many ORM frameworks allow developers
 to write raw SQL for complex queries.

0:22:55.360000 --> 0:22:58.060000
 So you always have to go back to SQL.

0:22:58.060000 --> 0:23:03.480000
 Now, if the raw SQL includes unsanitized
 user input, it becomes vulnerable.

0:23:03.480000 --> 0:23:06.100000
 And then of course, we
 have developer misuse.

0:23:06.100000 --> 0:23:11.120000
 So developers may inadvertently, inadvertently
 bypass ORM safeguards or

0:23:11.120000 --> 0:23:15.200000
 misuse query building features
 leading to vulnerabilities.

0:23:15.200000 --> 0:23:18.020000
 And that is again, quite common.

0:23:18.020000 --> 0:23:21.840000
 So let's take a look at an
 example of ORM injection.

0:23:21.840000 --> 0:23:24.920000
 And you'll see just how similar
 it is to SQL injection.

0:23:24.920000 --> 0:23:29.360000
 The only thing you're doing is just
 modifying the logic of your payloads

0:23:29.360000 --> 0:23:30.660000
 ever so slightly.

0:23:30.660000 --> 0:23:35.580000
 So in this case, let's use a fictional
 scenario or an example, an application

0:23:35.580000 --> 0:23:41.080000
 uses an ORM to authenticate users by verifying
 their username and password.

0:23:41.080000 --> 0:23:48.100000
 So you can see instead of now, you
 know, using SQL queries, you know,

0:23:48.100000 --> 0:23:53.160000
 username is equal to request.ogs.get
 username, password, same thing, just

0:23:53.160000 --> 0:23:54.580000
 getting the password value.

0:23:54.580000 --> 0:23:56.240000
 And then the vulnerable queries here.

0:23:56.240000 --> 0:24:02.420000
 So a user is equal to user.query filter,
 username is equal to username,

0:24:02.420000 --> 0:24:07.320000
 pay attention here, and password is
 equal to password, and then dot all.

0:24:07.320000 --> 0:24:08.880000
 Okay, so what's the issue?

0:24:08.880000 --> 0:24:12.400000
 So let's start off with
 the attacker's payload.

0:24:12.400000 --> 0:24:19.980000
 So the, for the username, the attacker
 puts in admin and then uses a single

0:24:19.980000 --> 0:24:21.940000
 quote, or one is equal to one.

0:24:21.940000 --> 0:24:24.940000
 So very, very, very similar
 to SQL injection.

0:24:24.940000 --> 0:24:27.680000
 However, you may miss it.

0:24:27.680000 --> 0:24:32.360000
 If you, if you don't look closely,
 and then the password can be a, the

0:24:32.360000 --> 0:24:36.340000
 password can be any value, because
 that's not what's being injected.

0:24:36.340000 --> 0:24:41.600000
 So the bottom line is that this
 is the resulting SQL query.

0:24:41.600000 --> 0:24:45.580000
 So forget about the ORM, because the
 ORM will be making this particular

0:24:45.580000 --> 0:24:47.780000
 query, we're not looking at that.

0:24:47.780000 --> 0:24:52.500000
 So this is what would end up being sent
 by the ORM after translation to

0:24:52.500000 --> 0:24:57.920000
 the database. So what you'd expect,
 select all from users where username

0:24:57.920000 --> 0:24:59.660000
 is equal to admin.

0:24:59.660000 --> 0:25:03.960000
 And remember what we injected because
 of the concatenation, it's expecting,

0:25:03.960000 --> 0:25:08.120000
 you know, the value to be inserted
 in here if you remember.

0:25:08.120000 --> 0:25:09.200000
 So this is the actual query.

0:25:09.200000 --> 0:25:13.260000
 So you can see between two single quotes,
 or, you know, it's actually

0:25:13.260000 --> 0:25:15.380000
 been concatenated there.

0:25:15.380000 --> 0:25:20.860000
 But what we're doing is we're changing
 the payload, and, you know, essentially

0:25:20.860000 --> 0:25:27.020000
 saying close that initial one, and
 then you specify, you know, a value

0:25:27.020000 --> 0:25:30.200000
 that will always equate to true.

0:25:30.200000 --> 0:25:34.860000
 And, you pretty much let
 that close itself.

0:25:34.860000 --> 0:25:41.560000
 So the second, the original single quote
 right over here is what you see

0:25:41.560000 --> 0:25:49.420000
 right over here that closes your final,
 you know, your final operation

0:25:49.420000 --> 0:25:50.640000
 or what you injected.

0:25:50.640000 --> 0:25:59.040000
 So remember, the value is the value
 of the username is expected to go

0:25:59.040000 --> 0:26:03.260000
 between, in between these
 two single quotes.

0:26:03.260000 --> 0:26:08.500000
 However, what you do is, you know,
 you say admin, and that's the first

0:26:08.500000 --> 0:26:10.820000
 one, but then you close that.

0:26:10.820000 --> 0:26:12.940000
 But remember, now there's
 going to be two.

0:26:12.940000 --> 0:26:15.760000
 So you've opened another one
 kind of, if that makes sense.

0:26:15.760000 --> 0:26:18.080000
 And then it's actually been closed here.

0:26:18.080000 --> 0:26:20.520000
 So that's pretty much how it works.

0:26:20.520000 --> 0:26:24.360000
 So in this case, the condition or one
 is equal to one always evaluates

0:26:24.360000 --> 0:26:29.080000
 to true, allowing the attacker to bypass
 authentication, and login as

0:26:29.080000 --> 0:26:32.360000
 the first user in the database.

0:26:32.360000 --> 0:26:37.480000
 All right, so that is pretty much,
 you know, that's pretty much it in

0:26:37.480000 --> 0:26:40.120000
 terms of ORM injection.

0:26:40.120000 --> 0:26:44.520000
 As I said, the main difference is in the
 payloads and the way you essentially

0:26:44.520000 --> 0:26:50.420000
 format them. And again, it's not really
 important that we take a look

0:26:50.420000 --> 0:26:55.020000
 at a practical example, because while
 I was going through some practical

0:26:55.020000 --> 0:27:02.100000
 examples that I could demonstrate, it
 became quite apparent that it, you

0:27:02.100000 --> 0:27:06.020000
 know, it was very easy to miss to miss
 comes true, you know, standard

0:27:06.020000 --> 0:27:09.020000
 SQL injection with ORM injection.

0:27:09.020000 --> 0:27:12.860000
 But this particular video, the objective
 of this video is to introduce

0:27:12.860000 --> 0:27:17.400000
 it to ORM's, because again, the likelihood
 that you'll come across one

0:27:17.400000 --> 0:27:22.280000
 of them, or, you know, that you'll
 come across an ORM being used in a

0:27:22.280000 --> 0:27:24.820000
 web application, your testing
 is quite common.

0:27:24.820000 --> 0:27:29.680000
 And I just wanted you to actually understand
 that while you may not see,

0:27:29.680000 --> 0:27:34.560000
 or you may think that the, that a payload
 is not working, you probably

0:27:34.560000 --> 0:27:39.740000
 want to adapt the payloads accordingly.

0:27:39.740000 --> 0:27:45.920000
 And there's, there's quite a few resources
 you can actually utilize online.

0:27:45.920000 --> 0:27:49.220000
 But with that being said, that's
 going to be it for this video.

0:27:49.220000 --> 0:27:51.300000
 And I'll be seeing you in the next video.