Hello and welcome to the side Berry secure coding course.
My name is anywhere and this is the AWAS top 10 for 2013
a three cross site scripting demo.
This is stored cross site scripting via a weblog attack.
This is the demo for stored cross site scripting.
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.
So let's take an example
at the log in page. I'm going to try to log in with an account that doesn't exist,
and it tells me that it doesn't exist. Now if I go to my Web logs,
I see that there are logs showing me that a user visited log in.
But notice here log in. Failed account test does not exist. I might be able to use this to my advantage if the Web
server is displaying exactly what is received and there's no sanitation and there's no more importantly output in coding.
If that's the case, then I can actually plant a
cross site scripting attack into the database. It will be shown to every single victim that then lands on this page.
So let's see how we can do this. I'm gonna go ahead and to lead these logs.
I'm gonna go back to the log in page.
I'm going to tie it the same information again, but I'm gonna go ahead and turn on our burb Sweet interceptor,
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
If we take a look at that, it starts. Of course, with our script,
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.
Now, this is a script that
allows an attacker to capture information and then log it in a database.
And so we're actually going to poison
Ah, database table with our own malicious code instead.
And now then the final
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
than an equal sign. Then you see, we have
portion of the string.
Then we have literally a plus sign because we want to capture
Now, in order for all of this,
to be understood properly by the Web server,
we need to go ahead and in code that as you are, well,
and so that's what we have here.
So I'm gonna go ahead and take this string
this you Earl encoded string.
I'm going to replace my user name
And I'm gonna go ahead and forward that.
Now what we see here on the web pages we get another account does not exist.
but if we go back to our web log
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
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,
and you can actually see that the session i d. Has been captured.
So these are all of the components in the cookie, but you can see the session I d. There.
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,
but then actually change the behavior of the Web page completely
and also realized that the
the point of entry of the point of attack was through a reflected cross site scripting vulnerability originally,
which actually led to our stored cross site scripting attack for the permanency of the page.
So now whenever I try to view my
immediately, it goes back to the capture data PHP script because the database table has been poisoned with the malicious script