Part 5 Stored Demo
Video Activity
This lesson offers a demonstration of cross site scripting. Looking at standard web logs, the Burp Suite Interceptor is used to create a JavaScript to replace usernames to discover accounts and capture data to see what has been discovered in a session.
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
This lesson offers a demonstration of cross site scripting. Looking at standard web logs, the Burp Suite Interceptor is used to create a JavaScript to replace usernames to discover accounts and capture data to see what has been discovered in a session.
Video Transcription
00:04
Hello and welcome to the side Berry secure coding course.
00:09
My name is anywhere and this is the AWAS top 10 for 2013
00:15
a three cross site scripting demo.
00:18
This is stored cross site scripting via a weblog attack.
00:24
This is the demo for stored cross site scripting.
00:28
Now, what we're looking at here is a table that is in the database. So my SQL database and this table will show us Weblog Standard weblogs.
00:40
So let's take an example
00:45
at the log in page. I'm going to try to log in with an account that doesn't exist,
00:52
and it tells me that it doesn't exist. Now if I go to my Web logs,
01:00
I see that there are logs showing me that a user visited log in.
01:07
But notice here log in. Failed account test does not exist. I might be able to use this to my advantage if the Web
01:19
server is displaying exactly what is received and there's no sanitation and there's no more importantly output in coding.
01:30
If that's the case, then I can actually plant a
01:34
cross site scripting attack into the database. It will be shown to every single victim that then lands on this page.
01:46
So let's see how we can do this. I'm gonna go ahead and to lead these logs.
01:51
I'm gonna go back to the log in page.
01:56
I'm going to tie it the same information again, but I'm gonna go ahead and turn on our burb Sweet interceptor,
02:07
and we can see here that we have our tests. Now we know that the user name is what was displayed back in the browser. So that's the area that we're going to attack
02:21
now. What I've done is I've created some JavaScript that will be used to replace this user name.
02:30
If we take a look at that, it starts. Of course, with our script,
02:35
we've got to change the document location. So this is the DOM. Reference is document. We're going to change the location to point back to our page that actually has a back door script called capture Data. PHP.
02:53
Now, this is a script that
02:55
allows an attacker to capture information and then log it in a database.
03:04
And so we're actually going to poison
03:07
the my SQL Weblog
03:10
Ah, database table with our own malicious code instead.
03:16
And now then the final
03:21
in the final parameter that's being added here after the after the ampersand is just a variable called C. Doesn't really matter what you call it
03:30
than an equal sign. Then you see, we have
03:34
the ending
03:36
for our http
03:38
uh,
03:39
portion of the string.
03:42
Then we have literally a plus sign because we want to capture
03:49
the cookie
03:51
that is stored in the dom. And then, of course, we end our JavaScript tag.
03:58
Now, in order for all of this,
04:00
to be understood properly by the Web server,
04:05
we need to go ahead and in code that as you are, well,
04:11
and so that's what we have here.
04:14
So I'm gonna go ahead and take this string
04:18
this you Earl encoded string.
04:23
I'm going to replace my user name
04:27
with my payload.
04:30
And I'm gonna go ahead and forward that.
04:35
Now what we see here on the web pages we get another account does not exist.
04:43
Okay,
04:44
but if we go back to our web log
04:49
so fair
04:51
we were about to see our web log. But what we did instead is we infected. Are we poisoned this page by having it revert instead
05:03
to go to our capture data? PHP script. If you want to actually see what was captured in the hacker database, you can click this view, capture data,
05:16
and you can actually see that the session i d. Has been captured.
05:23
So these are all of the components in the cookie, but you can see the session I d. There.
05:29
So
05:30
I thought that this was a really good example. Because not only does it show how a stored cross site scripting can be inserted into a database table,
05:42
but then actually change the behavior of the Web page completely
05:47
and also realized that the
05:50
the point of entry of the point of attack was through a reflected cross site scripting vulnerability originally,
06:00
which actually led to our stored cross site scripting attack for the permanency of the page.
06:10
So now whenever I try to view my
06:14
Weblogs
06:16
immediately, it goes back to the capture data PHP script because the database table has been poisoned with the malicious script
Up Next
Instructed By
Similar Content
