up SEC tutorials cross site scripting
Cross site scripting is a method by which an attacker can use a Web application to force a client side script to run in the browser of another user.
To get the most out of this course, we recommend that you take the introduction to Web Applications, Security Course and the secure coding with a WASP top 10 validation and encoding course for either Java or dot net.
Upon completion of this course, you will be able to describe how a hacker might perform a cross site scripting attack and be able to identify and remediate this weakness of the coat bubble.
my name is Kevin Richard, and I'm a security researcher with VERACODE.
Today, I'd like to demonstrate the steps that an attacker might take to perform a simple cross site scripting attack.
The application that will use in this example is a DOT net and VC app called Vera and secure dot net.
The HTML five code of its front end includes several pages that use the raw control to display and enable raw HTML to the end user.
Soon you'll see why this control belongs within a group that needs to be handled with care to prevent the threat of cross site scripting.
I'll show you how an attacker could find an ex SS flaw hidden within this application.
The attacker loves him and begins to search for so called threat factors or locations in the code that would process input data in a way that would trigger access s.
Their search leads them to the review page.
Pages like the's commonly contained a set of text fields that permit HTML for links are stylized input text.
The application expects to receive input that looks something like this,
a satisfied review that might contain bold or other HTML tags.
If we had it. The text to include some tanks once it submitted it appears that the HTML itself is displayed back to the user.
This is because the page has correctly encoded the HTML, preventing it from functioning his mark up.
You can see the HTML characters, but the markup itself will not be applied to the data.
Now let's navigate to the basic Crossette scripting page under security labs
here. If we include any HTML tags, we will actually see them rendered inside the view
for the attacker. This is great news.
Whenever they see that H female is rendered on a page, it means that it's a good place for them to begin testing for cross site scripting.
The attacker begins by typing a simple alert into the field
Justus we saw before. It is not rendered on this page,
however. Let's look back at the widget page, where scripts had not been properly encoded.
Now it is clear that the payload has been executed because the text honey appears on the page
The ability to pop a text message doesn't seem very troubling,
The language affords us control of a large number of things that we can manipulate in the browser,
so that alert box only reminds us that we haven't seen the worst of it
to prove it. Let's go ahead and direct this user to an external website
this time will be merciful and only direct them to Google.
But it's still enough to demonstrate the amount of control that we now wield over the user's browser experience.
We save our widget and return to the page that actually runs the Java script payload
were immediately redirected to an external sight.
Again, this site didn't have to be Google. It could have been a site owned by the attacker themselves.
It could have also been a background request, since the attacker can collect information about the documents and cookie and send it to themselves. This way
cross site scripting is a technique that Attackers used to take control of a user's browser.
It can be used to direct users to external websites, share our steel session information
or descend background requests.
And since Web applications are often connected to backend systems, it could also be used to escalate privilege when attacking a network as a whole
to learn more about advanced payloads and attacks, as well as how to prevent cross and scripted police continue to watch our training videos or participate in their training courses.
This has been kept in Richard from Veracode. Thank you very much for watching.
It's a valid cross site scripting flaw has been detected in your application. The next step is to update your code in order to remediated
click on any tab to see how to secure your code from the threat of across that scripting attack.
Hello and welcome back.
This is Kevin Richard, security consultant at Jericho.
I'm here to give a brief demonstration of how to remediate an existing cross site scripting attack inside of a dot net and BC Application
will be using the very insecure dot net Web application in order to demonstrate both the current cross that scripting attack as well as an appropriate remediation forthis attack.
Once we get logged into the application, we need to get familiar with the attack itself and identify which user interface is not properly encoding. The up put and is therefore vulnerable to across that scripting attack.
It shouldn't take us long to see that the reviews displayed within the basic cross that scripting laboratory contain HTML markup that is actually displayed to the end user.
We want to go a step further and ensure that this could actually be exploited.
In order to do so, we changed the text that contains mark up that would be displayed to the end user to include script tags
when we include script shags and then return to the actual cross it scripting lab interface. Let's see if our payload was executed on the page or if it was properly encoded.
When we return to the page and we search for widgets, we do see that our payload is executed and weaken safely. Know that the text field of the review is not properly encoded.
Part of the reason this occurs is because we're using the HTML brought control inside of our CSH dream. L file.
Many of the Microsoft controls air going to actually contain within the control itself proper and coding.
However, we want to be able to display some HTML. But in a secure matter,
this presents a problem
in order to support some HD. No, but only the h e mail that we want to allow in the page. We're going to properly in code the property in its entirety.
So the first thing we'll do is completely encode the text property of the review.
Following that, we're going to selectively decode the specific tags that we want to allow.
So what you can see here is that we take server dot html in code on the entire text property.
Then we selectively take the tags that we want to support, and we decode them to the HTML
in the very first replace you can see we take the encoded each one html string, and we replace it with a coded or standard HTML or H one tag
effectively. This creates a white list in which we're only allowing selective tags
again. This is a very simplistic example of how to support specific tags,
but it does support the point that you want to encode or sanitize all of your output to your end user
and then only selectively allow specific characters that you wish to have the end user provide to you and then display and render to your end users.
When we navigate to the formerly vulnerable interface, we can see the script alert. Tag Payload is no longer executed but rather displayed in an HTML encoded fashion where the end user sees the original script. But the script itself is not actually executed on the page
to ensure the functionality is working as we designed. We're going to go back include the tags that we want to support
specifically bold italic tags and then return to our witch it Paige to see if it is rendered as we've designed
here. You can see this is working now as desired.
This was a brief demonstration of using a standard encoder inside a dot net NBC Web application.
For more information about advanced across that scripting exploits or other attacks,
please watch some of our other training videos or attend one of our instructor led training courses.
This has been Kevin Richard at Barricade. Thank you very much for watching
This is Kevin Richard, a security researcher with Erica.
I'm here to offer a quick demonstration of how to remediate a simple cross site scripting flaw.
We'll be using the very insecure Java Web application and Theo Awesome Java html sanitizer in order to address this issue.
Let's recap what we learned in the last video.
If we return to our fake store and bring up the existing reviews, we can already see the review that contains a cross site scripting payload inside of it.
This output is probably escaped on the page and therefore we see the script displayed on the page. But the actual script attack and payload are not executed.
Now. If we visit the basic Crossette scripting love,
we see that when we love the page, the page does not escape the script stags and the payload is executed, causing a pop up that reveals the attack with successful
Let's bring up the I D to view the code of this attack targeted.
I'm using Spring Tool Sweet A version of Eclipse.
As I mentioned, we're also going to use Theo Lost Job HTML Sanitizer project.
This open source library leverages a policy to define which HTML control should be a wound and which should not.
We're going to be using a slightly altered Slashdot policy altered to allow specific HTML elements that I choose.
I want to allow H one h two and H three.
So I added those to the list of allowed in a women's
notice how, after the policies air defined,
I can apply a policy to any given text in the text will be sanitized.
So if the text contains HTML, as our payload did, a policy sanitization method that has returned from the HTML will be appropriately defined or sanitized.
And then the only exception to that will be the list of allowed tags that we defined within the policy.
Now let's make sure the project runs as we're expecting.
Let's go ahead and go back to our review page and find the review that we're interested in.
We let it the review to include some of the elements that should be supported by the policy.
Here's our really bad stuff review
now that we have included some HTML which should be supported according to policy within the review.
Once we save the review and return to the page that is intended to display HTML contained within the review,
we would expect to see that the review itself will be displayed and rendered.
Here we can see that we have proper HTML support.
We want to be sure we're doing this in a secure manner and that the previous payload is no longer effective and rendered on the page.
We had our payload back in, and when we navigate to the cross that scripting laboratory page, which was previously rendering the attack and therefore executing the job of payload,
we announced that the attack has actually been removed for the policy that we defined within age female job sanitizer.
This was just a brief demonstration of how to remediate across that scripting exploit, using the Java HTML sanitizer.
For more information about advance, Crossette scripting exploits or other attacks. Police watch some of our other training videos or attend one of our instructor led training courses.
This has been Kevin Richard at Veracode. Thank you very much for watching.
The scope of this course was not intended to cover every possible circumstance in which across set scripting attack could arise. Rather, it was designed to convey the basic idea of this flaw.
Further information is available through the following legs.
Thank you for viewing this app. SEC tutorial on cross site scripting