XSS: Cross-Site Scripting
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
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 long analysis.
Now let's do a brief review of cross site scripting attacks and injection attacks.
It's also a client side attack
There are two types of cross site scripting
stored when the entrusted data is saved in the 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 entrusted data is sent and processed.
One of the causes of cross site scripting is incorrect user input validation, and this is on Topic a seven off the 2017 oh WASP 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 answer 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 are re directions to other sites, crypto mining credential theft or, in some cases, infecting the user's computer with malware or back doors.
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.
like this one?
In this picture, you can see the alert.
You'll notice that the same text we put into the text box is displayed in the alert.
together, let's analyze the logs from the two actions.
In the first, Nothing's wrong. Just hello log analysis.
Since the website used to get method, we can see the request, and here you have the log analysis strength.
Then you see that we have a lot of encoded characters.
Remember the Web server Onley except asking 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.
So how do you identify the reflected cross site scripting attacks?
since cross site scripting needs to using coded characters. If you see a lot of encoded characters in the same request,
it's better to take a closer look.
And since the attacker needs to craft the request.
Look for unexpected user agents.
The next type of cross site scripting is stored.
As I said before
stored cross site scripting attacks changed 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,
whenever we access the Web page, the alert message will show in the message board will show nothing in the message part.
This happens because our message contains the script text in the script. Text doesn't show as text they're executed by the browser.
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 relearn the Web page,
the next two lines of 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 on the Web server lock.
If you analyze the to post logs, you can see that the two lines are almost the same
Now. Maybe you're thinking how can identify the attack if I don't see the Web server law?
As I said before, there are other log sources that could help us.
The i PS or IEDs is one of them.
They analyzed the full packet
with the full packet. It can see the malicious request 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 I PS is in the block mood,
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 users device run slower.
You can check this website to Seymour about crypto mining. Cross site scripting attacks
store 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 militia code is this year.
There are many payloads that are used to perform cross side scripted.
This website contains some examples of cross site scripting payloads.
The way toe identified stored cross site scripting is almost a statement with reflected,
although since it commonly uses the Post request,
it's better to have more log sources like the I PS and, 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 clients I p address, followed by the date and time
after we have the get method and the requested file.
After we have a 200 status code, that means okay,
we don't have the refer, 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 and 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 the decoded request
so you have the malicious parts of the log
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 Doe identify both types of cross site scripting.
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 toe identify cross site request, forgery attacks.
CSRF: Cross Site Request Forgery
Other Log Sources Part 1
Other Log Sources Part 2