>> Hello everyone and welcome back to the course,
identifying web attacks through logs.
In the last video, we talked about brute force attacks.
This is Module 2, episode 4.
In this video, we'll start
talking about injection attacks.
The first injection attack will be SQL injections.
To start, let's check the video objectives.
First, a brief introduction of injection attacks.
After that, we'll review SQL attacks,
SQL injection attacks,
followed by performing web analysis to
identify SQL injection attacks.
Injection attacks are related to OWASP talk A1.
In 2007, it was a top vulnerability.
Injections are so common that OWASP classified it
>> as a top vulnerability in 2010 and 2013 as well.
>> Here's the definition from OWASP.
Injection attacks occur when
the central request contains some unexpected data,
and this data is executed by the web server.
Remember, the web server doesn't care
>> about the request.
>> If the request is malicious,
the web server will still process it.
SQL injection is one type of injection attack.
There are many other injection attacks.
Here's a list of some of them, SQL injection,
file injection, and others.
But in this video, we'll focus on SQL injection.
Because of the multi-layer
>> web application architecture,
>> the client should only access the web server.
In an SQL injection attack,
the client sends the request to the web server,
but the web server will send
the request to the database,
and the database will process it.
Depending on the request,
the database can execute unexpected commands.
These commands that come back to
the database server can impact the web application.
SQL injection is considered a critical vulnerability,
it directly affects the database server.
Here we have a comic strip joke about SQL injection.
Here the impact was losing
all the database of the students.
This could be fun,
but if this happens in a production environment,
the consequences could be tragic.
Let's talk about SQL injection.
Here are some considerations to keep in
mind with SQL injection attacks.
It needs to use SQL or the database won't process it.
Usually, it's caused by
incorrect user input validation
like allowing special characters in the form.
It's an old attack, we've known about it since 1998.
It's also more common on legacy applications.
It's a server-side attack,
and it has some types like blind,
classic, union-based, and error-based.
In our lab, there's a web application vulnerable
to SQL injection attacks.
It's simple, it's just a form with
only one text box to put the user ID.
If we try the number 1,
we have the admin user information.
Here you have the request made to the web server.
It's a simple request.
You can see that the ID has the number 1, the admin ID.
The information about the admin is shown.
But if we don't say a number, what happens?
This is an example of a malicious request.
To summarize this user ID request,
you say to the database,
I want all the user IDs that are
equal to a or 1 equals 1.
1 equals 1 is always true,
so the database will send all the usernames.
This is the result of the request,
all usernames and information about the usernames.
Now, maybe you're thinking,
can the web server logs identify SQL injection attacks?
Let's analyze both request web server logs.
The first is the ID number 1 request,
and the second logline is a malicious request.
Notice that whatever you put in the user ID,
you'll be sent to the web server
and to the database server.
Another important thing is
>> that this request is encoded.
>> After decoding,
>> we'll see the same request that we used.
>> Because of the SQL,
it's easy to see encoded requests
during SQL injection attacks.
It's important to notice that
the web server answered both requests,
and this includes the malicious request.
Depending on your web application,
this would mean that your application
is vulnerable to the SQL injection.
Now, let's analyze these three loglines.
These lines were generated by the SQL map tool.
SQL map is a well-known tool used to perform
vulnerability scans or to perform
>> SQL injection attacks.
>> Many of the vulnerability scans
can execute SQL injections.
So during the vulnerability scans,
it's possible to see SQL injections.
Depending on the policy of your company,
you can classify the attack as a vulnerability scan,
or as an SQL injection attack.
Again, the user agent
can help you in identifying the attack.
Analyzing the logs.
You should see SQL-related words or comments
>> like and, select, case, when, union, and others.
>> Always check the response of the web server.
On the previous slide, the answer was 200,
so the web server answered the request.
In the three loglines,
we have 302 to the right direction.
Sometimes you need to correlate
more than one logline to understand the entire attack.
For further information,
here are the same three loglines, but now decoded.
If you don't know about SQL comments,
you can ask your database admins if these comments
are malicious or could impact the database server.
In the next slide, we'll analyze
two more loglines. Here they are.
Again, we used the SQL map,
but we changed the user agent.
You can notice encoded requests send many SQL words.
In the second logline, you have the
where and the exec comments.
Taking a better look, you can find
more comments and words but related to
Linux operational system like cat and F password,
and in this slide, the decoded request.
One more question. What about POST requests?
To analyze POST requests,
you need more logs from other sources.
A good source is the back capture.
For example, this is
a web server log for a POST request.
The web server log only shows
the POST request to the login page,
there's no information about the request.
But in the package capture,
you see the HTTP request
and all the form data that was sent.
Notice that this request is similar to our examples,
although it's not that easy to get a package capture.
But if it's possible,
you should try and ask for them.
To summarize, how do you identify the SQL injection?
First, SQL commands like from,
select, where, and others.
Look for encoded requests.
Also, remember to look for user agents
and the operational system related comments or words.
Now, let's do
some post-assessment questions to practice.
In the first question, analyze the log below,
and identify the web application attack.
After, choose the option with the correct attack.
You can pause the video if you want.
It's easy to see that this log is big,
and it contains a lot of encoding.
In addition, it's easy to find
the SQL words like select,
and, count, and others.
So this is an SQL injection attack.
For further information,
here is the decoded request showing the SQL request.
Now, check this affirmation.
Web server logs will show
all information about user actions.
Is this affirmation true or false?
This affirmation is false.
If the web application uses POST or
if the web server log and configuration is wrong,
many of the logs can't help you.
If this happens, you
need to ask for the right configuration,
or for other logs. Video summary.
In this video, we talked about
the type of injection attacks,
SQL injection attacks,
some directions to identify
SQL injection attacks in the web server
logs like SQL comments,
encoded requests, user agent,
and operational system comments.
After, we showed the difference
between POST and GET requests,
showing an example of a package capture
with an SQL injection attack.
In the next video, we'll keep
talking about injection attacks.
We'll discuss file injection or file inclusion,
and the two types of inclusion:
local and remote file inclusion.