>> Hello everyone and welcome back to the course,
Identifying Web Attacks Through Logs.
In the last video, we talked about
file inclusion in its types of attacks.
In this video, we'll talk
about cross-site scripting attacks.
Let's start by talking about the video objectives.
The video objectives are to
review cross-site scripting attacks
>> and identify cross-site scripting attacks
>> with log analysis.
>> Now, let's do a brief review of
cross-site scripting attacks and injection attacks.
It's also a client-side attack.
Pages with forms and forums are
the most common examples that
offer cross-site scripting attacks,
usually they use JavaScript
processed by the user browser.
There are two types of
cross-site scripting stored when the untrusted data
is saved in a web server and
reflected when no data is saved in the web server.
This means that in the store type,
the attacker needs to change
the web page while in the reflected one,
the untrusted data is sent and processed.
One of the causes of cross-site scripting
is incorrect user input validation,
and this is on topic A7 of the 2017 OWASP
>> top 10 project.
>> Check these two websites to get
more information about cross-site scripting.
Now, let's see together how cross-site scripting works.
The process is like this.
The user accesses the website.
The web server will then enter the request.
The user browser will process the web server answer,
and if the answer contains a malicious code,
it will be executed by the browser.
Some actions that are common on cross-site scripting
our redirections to other sites, crypto mining,
credential theft, or in some cases,
infecting the user's computer
>> with malware or backdoors.
>> Let's start analyzing the attack.
The first will be reflected.
Here we have a website that is
vulnerable to cross-site scripting.
Whatever we put inside this text box will be
displayed in the web page after this submission.
For example, if we put log analysis,
it will say, "Hello log analysis."
What do you think will happen
>> if we add in this text box
>> a JavaScript code like this one.
The JavaScript loads and alerting the user browser.
In this picture, you can see the alert.
You'll notice that the same text that we put into
the text box is displayed in the alert.
This means that the web server accepted
the JavaScript and send it to the client.
When the web server answer
is processed by the user browser,
it will load the JavaScript that
says, "There is an alert."
Now, together, let's
analyze the logs from the two actions.
In the first, nothing's wrong,
just hello log analysis.
Since the website use the getMethod,
we can see the request and here
you have the log analysis string.
The second log contains the JavaScript alert.
Then you see that we have a lot of encoded characters.
Remember, the web server only accepts ASCII characters.
Here you see that during the
>> cross-site scripting attack,
>> the attacker needs to use a lot of encoded characters.
This is one behavior of cross-site
>> scripting attack that you can see in the logs.
>> How do you identify the
reflected cross-site scripting attacks?
One of the ways is to look for script
HTML text in the request.
Also look for JavaScript code in the request.
Since cross-site scripting needs
to use encoded characters,
if you see a lot of encoded characters
>> in the same request,
>> it's better to take a closer look.
Since the attacker needs to craft their request,
look for unexpected user agents.
The next type of cross-site scripting is stored.
As I said before, stored cross-site scripting attacks
change the web page.
For example, here we have a message board.
Like a forum, you put in your name in a message,
and it will be stored in the web page.
Can you guess how the attack occurs?
You can see here that we have
two messages. Everything looks okay.
To perform the attack,
we need to send the server the malicious request,
like this alert message in JavaScript.
Now, whenever we access the web page,
the alert message will show,
and the message board will show
nothing in the message part.
This happens because our message
>> contains the script text
>> and the script text doesn't show as text.
>> They are executed by the browser.
Now, let's check the web server logs from this attack.
The first two lines of the logs for
a non-malicious use of the website.
We have the post, time that we sent some data
>> to the web server and after the get
>> to reload the web page.
>> The next two lines are the logs from the attack.
What's the problem here? Can you identify the attack?
Remember that on the post request,
the payload has the action,
and that's why we can't see
the request and the web server log.
If you analyze the two post logs,
you can see that the two lines are almost the same.
Now maybe you're thinking, well,
how can I identify the attack
if I don't see the web server log?
As I said before, there are
other log sources that can help us.
The IPS or IDS is one of them.
They analyze the full packet.
With the full packet,
it can see the malicious requests,
>> like in this picture.
>> In this case, the log is different,
but it can see the request.
Inside the request, you can see
the malicious code that was sent to the web server.
If your IPS is in the block mode, the attack will fail.
One example of cross-site scripting attacks
is crypto mining.
Since the attack can add some code on
the web page and whenever users access the web page,
the user browser processes the web page.
If the web page has a command on its code that
is asking the web server to
start the crypto mining process.
The web browser will do it.
This can make the user's device runs slower.
You can check this website to see more about
crypto mining cross-site scripting attacks.
Stored cross-site scripting changes the web page.
One of the ways to confirm
the attack is to check the web page code.
During your analysis, you can look for
script text in unexpected places.
Here's the code of our vulnerable web page.
Since this is a small page,
it will be easy to find the malicious code.
The malicious code is this here.
There are many payloads that are
used to perform cross-site scripting.
This website contains some examples
of cross-site scripting payloads.
The way to identify stored cross-site scripting
is almost the same as with reflected.
Although since it commonly uses the post request,
it's better to have more log sources like the IPS.
If possible, to check
the web page code and look for malicious commands.
Post assessment question.
There is no difference between stored and
reflected cross-site scripting attacks.
Is this affirmation true or false?
This affirmation is false.
Although the attacks are similar,
there are some differences between them.
The difference changes the way we identify them.
For the next question, analyze
the weblog below and identify which part is malicious?
You can pause the video if you'd like.
Let's analyze the log together.
First we have the client's IP address,
followed by the date and time.
After we have the getMethod and the requested file.
After it, we have a 200 status code.
That means, okay, besides,
we don't have the referrer, and in
the end we have the user agent.
As I said before, many of the attacks
can be identified in the requested file.
Do you think that we have a lot of encoded characters in
the requested file or does it look normal?
Even if you think that this request looks normal
and we do have a lot of encoded characters.
We can see the script word. Did you see it?
To make things more clear,
here, you can see that decoded request.
You have the malicious parts of the log. Video summary.
In today's lesson, we talked about the two types of
cross-site scripting reflected and
stored and their differences.
We also talked about how to
identify both types of cross-site scripting.
Look for scripts in the requests,
look for JavaScript code,
look many encoded characters and unexpected user agents.
For stored cross-site scripting,
you can check the web page code.
In the next video, we'll talk
about cross-site request forgery,
and we'll analyze web server logs to
identify cross-site request forgery attacks.