SQL Injection

00:07

AB Sectorial Sze sequel injection

00:10

about this course.

00:12

Secret rejection is a technique by which a hacker can alter the logic of a sequel query before a descent to an interpreter.

00:19

To get the most out of this course, If you haven't already done so, we recommend that you take our introduction to Web applications Security Course First.

00:28

At the end of this course, you will understand the risks associated sequel injection and be able to defend against instances of this flaw.

00:36

Hello,

00:37

my name is Kevin Richard, and I'm a security researcher at Veracode.

00:41

I'm here to demonstrate for you how basic sequel injection flaw can be exploited.

00:45

We'll be using the very insecure Java Web application in order to show you this attack.

00:51

The first thing I'll do is to come in and try to find any potential injury points to use for a sequel injection.

00:57

Since this is a lab environment, I won't have to search very hard. How simply navigated a sequel injection lab.

01:03

Now, whenever I see an input field, the very first thing I want to do is familiarize myself. Would be inputs at the field, accepts and what it's supposed to be doing

01:11

so I'll begin by typing a common letter or number.

01:15

If I put in the number one, nothing is returned.

01:19

It doesn't seem to work so far, so I'll go ahead and type a letter.

01:22

With that input. The up returns the values that partially match the name or possibly the description.

01:29

At this point, I've learned that the application doesn't seem to be filtering out specific input types within the U. I.

01:34

In other words, it appears that the application is accepting values that I provide to submit field, even though they may not make logical sense for the query.

01:44

This gives me an indication that I may be able to provide special sequel characters to the search value as well.

01:49

Now I want to find out if I can actually execute a valid sequel Injection.

01:53

I'm going to start by putting a tick character in the search field.

01:57

If sequel injection is possible, the tick character will most likely result in an hour because it's a special sequel character.

02:05

When I cliques have been, nothing is returned.

02:07

So this information alone is not enough for me to know if injection it's possible

02:12

to explore a little more. I'm going to investigate my browser's network traffic to see if any ever messages were hidden from the user interface but returned by the server.

02:22

When I send the request well, viewing the network traffic, I now see that it never message returned.

02:27

You have a sequel ever message in your syntax.

02:30

This is exactly what I wanted to see.

02:32

I now know that I'm able to manipulate the query and its functionality by typing in sequel control characters because the characters that can manipulate the sequel are not filtered out, and the query is not parameter arised.

02:45

At this point, I'm going to attempt an actual sequel injection attack that will return all of the information contained within the table with which the queries interact.

02:53

By initially entering Miss Tech, I'm causing the sequel syntax to be altered.

02:58

Then I'm stating, or so I'm closing out the tickets in place.

03:02

I'm saying

03:04

tick or one equals one semi colon.

03:07

This tell sequel.

03:08

Please ignore the previous search right area and just give me anything or everything contained within the table being queried.

03:15

The reason this works is that or one equals one is always true.

03:21

So if we have an or true statement.

03:23

The criteria that we defined previously won't matter because the or true statement is always true.

03:29

And therefore we're just going to dump out everything that exists in the table that we're searching.

03:34

Finally, I'm adding a pound symbol.

03:36

This will quote out the rest of the sequel syntax so that any of the following sequel Syntax will be ignored

03:42

when I click Submit. What we see is that we have a valid sequel injection here, as all of the data is returned to the U. I.

03:50

We have successfully exploited this weakness in the application by entering a simple tick or true and then commenting out the rest of the line,

03:58

and now we get all of the data returned.

04:00

However, we would like to see a quick demonstration of how this could be used to do obtained, sensitive information.

04:05

So we're going to give him or interesting payload that retrieves user names and passwords ashes from an adjacent table and then returns that information to the product's name and description field.

04:15

Here we can see we have the user names and their password hash is now return to the user interface.

04:21

This was just a quick demonstration of what can be done left sequel injection

04:26

to learn more about advanced payloads and attacks. Police watch our events videos or participate in our training courses.

04:32

This has been Kevin Richard at Jericho.

04:34

Thank you very much for watching.

04:42

If a valid sequel injection flaw has been detected in your application, the next step is to update your code in order to remediated.

04:48

Click on any tab to see how to secure your code from the threat of a sequel. Injection Attack.

04:54

Hello and welcome back to APP SEC Tutorials.

04:58

In our last video, you witnessed an example of a sequel injection attack within the job application.

05:03

Now I'll provide a brief demonstration of how you can prevent this risk.

05:08

Once again, we'll be using the very insecure Web application in order to illustrate this fix.

05:15

To recap, let's navigate to the basic sequel Injection Lab and run through. The vulnerability contained there

05:21

with the help of a simple payload will prove that sequel injection. It's possible by retrieving all of the information within the table that is being queried

05:29

by typing tick or one equals one, a common stock payload.

05:33

We caused the application to dump all of this data, and now we can be sure that the sequel Injection Flaw Israel.

05:41

Next, we need to decide how we're going to fix the flaw.

05:45

First, we'll have to identify the query that actually contains the sequel injection flaw.

05:48

Because this is a lab environment. I happen to know exactly where the query is located within the code, so I'll navigate directly to the corresponding sequel Injection Lamp Code

05:59

Sequel injection occurs when a user deliberately alters the query string that has passed into the database.

06:04

This is only possible when the query includes information on variables.

06:09

When we inspect the code, it quickly becomes clear that the variable search term is being contaminated into the query, which can then effect the query that is ultimately sent to the database.

06:19

Now that we know how not to query the database, let's examine a better way to perform this operation.

06:26

When developing and dot Net and V. C, you're most likely to be using the entity framework and link

06:30

Link stands for language. Integrated query.

06:34

A benefit of link is that it provides strong typing and poor amateur ization.

06:40

When we look at the query here, notice that we've taken the standard query and converted it to a lake query that queries against the edge of the frameworks database

06:48

products. Let us know the engine e source that were querying in produce of type product.

06:54

We're now going to query against the properties of Prod to see if they contain the search term.

06:59

This query will then be translated into a strongly typed query and ultimately return to strongly typed list of products

07:04

we can then return. That is our results, and we'll see the same information in the view as we had when we were leveraging a native sequel. Query.

07:13

So let's go back to the U I and see if these attacks they're still successful while also making sure that we still get our desired functionality.

07:20

Once we return to our sequel injection lab, we'll go ahead and immediately try to make sure that the functionality is working.

07:28

And now that we know that it's working well, go ahead and will provide the same attack us before.

07:33

As we can see here, what was once a viable attack has now been blocked

07:39

by leveraging. Entity and link were able to securely communicate with our data layer

07:43

and still retain the existing functionality that we desire.

07:47

This has been a brief demonstration of how to remediate sequel injection

07:51

to learn more about advanced payloads and attacks police watch our training videos or participate in our training courses.

07:59

This has been Kevin Richard if Eric Code Thank you very much for watching

08:03

Hello and welcome back to APP SEC Tutorials.

08:07

In our last video, you witnessed an example of a sequel injection attack within the Java application.

08:13

Now I'll provide a brief demonstration of how you can prevent this risk. Once again, we'll be using the very insecure Java Web application in order to illustrate this fix.

08:26

To recap, let's navigate to the basic sequel Injection Lab and run through. The vulnerability contained there

08:31

with the help of a simple payload will prove that sequel injection. It's possible by retrieving all of the information within the table that is being queried

08:39

by typing tick or one equals one, a common stock payload.

08:43

We caused the application to dump all of this data,

08:46

and now we can be sure that the secret injection flaw Israel

08:50

Next, we need to decide how we're going to text the flaw.

08:54

First, we'll have to identify the query that actually contains the sequel injection flaw.

09:00

Because this is a lab environment, I happen to know exactly where the query is located within the code, so I'll navigate directly to the corresponding sequel Injection Lamp Code

09:09

Sequel injection occurs when a user deliberately alters the query string that has passed into the database.

09:15

This is only possible when the query includes information on variables.

09:18

When we inspect the code, it quickly becomes clear that the variable search term is being contaminated into the query, which can then effects the query that is ultimately sent to the database.

09:30

Now that we know how not to query the database, let's examine a better way to perform this operation.

09:35

The most important thing is that the query itself a statically defined

09:41

by having a totally statically defined query. We can be sure that an attacker cannot alter our desired functionality.

09:46

Now that the query string has been rewritten, it will allow the sequel server to set up an execution flow. As we intend.

09:54

The perimeter that is provided search term will be past is a perimeter to the sequel database, but now it will not be allowed to edit the execution flow of the statically defined query that we've set.

10:05

Furthermore, we're now catching any errors that may occur were logging the ever message, and we're returning back to a statically to find our message to the end user.

10:15

This will make it much harder for any attacker to try to reverse engineer any issues that we do have within our database, their table structure.

10:22

So let's go ahead at this point in re compiler code

10:26

were debugging the code, and we're going to go back to the user interface to see if our mediation is indeed successful.

10:33

We'll be using the exact same attack strings that we used in the original exploit to see if we're able to pull off another attack. This time,

10:39

we'll never get back to the sequel lab, and we're going to provide a tick character the same way that we did in our original attack. We'll even provide the or one equals one.

10:48

Once we d'oh and we cook cement, you'll notice that we don't get any information returned.

11:03

There's no error, and the query is still working as it should when we provide valid data.

11:07

If we try to use a more sophisticated payload,

11:11

one that we know is successful in the past for retrieving e mails and passwords. We see that no information is returned.

11:18

We have successfully remediated the risk of our sequel injection by statically defining the sequel string itself and ensuring that when an attacker provides malicious data within the search term that this does not alter the functionality of static query we have to find

11:31

this was a brief demonstration of how to remediate sequel injection and jumbo

11:37

to learn more about advanced payloads and attacks. Please watch our training videos or participate in our training courses.

11:43

This has been Kevin Richard at veracode. Thank you very much for watching

11:48

further information is available through the following links.