Dude, Where’s My XSS Protection?

Web application security is a major concern nowadays. You have to make
sure your application is secure, especially if you have a lot of users.
There are many controls a developer can implement to attempt to make the
site safer. Or so they think. The fun of hacking is looking for a
different way to get things done. There are many reasons to why these
developers are mistaken, in this article we will be talking about a very
common XSS (Cross-Site Scripting) “solution” that all it really does is
make the game that much more interesting.

XSS is a technique or an attack used to exploit vulnerabilities in which
malicious scripts are injected or inserted into what is believed to be a
trusted web site. These attacks can occur when data enters a web
application through an untrusted source, most frequently a web request,
and that data is included in dynamic content that is sent to a web user
without being validated for malicious content. The malicious content
sent to the web browser is often JavaScript, but may also include
HTML, Flash, or any other type of code that the browser may execute.
XSS based attacks most commonly include transmitting private data,
like cookies or other session information, to the attacker, redirecting
the victim to web content controlled by the attacker, or performing
other malicious operations on the user’s machine under the guise of the
vulnerable site (OWASP, 2016).

To explain a specific XSS prevention method and one of the ways we can
bypass this control we will be looking at a really cool challenge from
our pals at Halls of
Valhalla.

Halls of Valhalla Challenge: XSS4

Our task here is to perform an XSS injection with alert(1). The
JavaScript alert(1) method generates a pop up alert window with 1 as a
the alert message.

In this challenge we are presented with an input in which we can submit
a message with a title, very much like a forum. The key is that we are
also given the source code for the function that displays my message.
This function is written in PHP. First we need to go through the source
code and understand what it is doing. Once we have done this we can look
for possible vulnerabilities.

From the code we see a conditional check. The if statement checks the
return value of the method ISSET(param) which determines if the param is
set and is not NULL. Inside the conditional check we see three very
similar instructions followed by an echo. The three similar instructions
all take one of the input fields from the form, pass it through the
strip_tags() method and assign the new value to a variable. The echo
message then echoes or prints on screen an HTML <div> tag. The tag
has some basic attributes and one of the attributes used is the title
variable with my input after strip_tags. So the echo instruction
displays the message along side the user name.

If we try the basic injection, “<script>alert(1)</script>”, we can
see that the strip_tags() method removes everything starting at “<”
and ending in “>”. The echoed message would then be “alert(1)” which is
useless without the correct script tags.

We said before that an XSS can occur when data enters a web application
through a web request, and that data is included in dynamic content that
is sent to a web user without being validated for malicious content.
That is pretty much exactly what we have here with one small exception.
Our input IS validated for malicious content, strip_tags() is applied
to all my input strings. So if we can find a way to bypass that
validation, we can then exploit the XSS vulnerability.

OWASP provides very helpful and complete documentation
on various security topics.
For attacks it provides great cheat sheets
that can guide you
in the Ethical Hacking process.
Here is TheirOfficial Homepage
for a look into the many topics and resources OWASP offers.

After further research on filter evasion, we can find that the
strip_tags() method has a common and well known vulnerability. Since
the method needs to identify the “<” and “>” symbols in order to know
what to delete, we need to inject our script without the use of these
symbols.

Note that in the echo message, one of the input strings, $title, is used
inside the actual HTML tag. This gives us a possible injection. We
know we can’t add any tags, but no one has said anything about adding
attributes. We can add an event as an attribute and in that event call
our JavaScript alert code. The best way to do this is through the
“onmouseover” event. This attribute sets of an event when the mouse
pointer is moved onto an element. So what we need to do is inject our
JavaScript alert as the event.

Note that the HTML tag puts single quotes ” ‘ ” before and after the
$title input. Hence we need to close the first ” ‘ ” in order to be able
to add an other attribute. We can’t forget about the closing single
quote, when adding the attribute we need to leave the quotes open in
order to use the single quote added by the HTML tag and therefore
maintain a valid syntax.

Know that we have successfully posted our message containing the
injection, all we need to do to test it out is trigger the onmouseover
event.

Once we place the mouse pointer over our message we can see we get the
alert 1 pop up.

There are many filters you can use to validate your website’s input and
reduce the chances of a successful XSS injection. If you only use one
filter there is a very high probability that an attacker will be able to
find a way around your control. There are many functions in different
programming languages which implement not only one but many different
filters to validate the user input. If you are passionate about
programming, you can easily do some basic research and find different
functions you can call in order to make one big and complete XSS filter.

References

1. OWASP. Cross-Site Scripting
   (XSS).

Challenge Link

Halls of Valhalla
XSS4

*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Juan Aguirre. Read the original post at: https://fluidattacks.com/blog/xss-protection/