All examples below are demonstrated using the altoromutual.com
website, a purposely vulnerable application used for testing and training
Cross Site Scripting (XSS)
XSS is ranked as number 3 in the OWASP 2013 Top 10.
XSS is the injection of malicious scripts into a webpage causing
it to react in a way not intended by the developer. It is possible to carry out
an XSS attack against a site that uses input from a user in the output it
generates without validating or encoding it. By injecting a simple script like <script>alert(1)</script>
into the search box on the altoro site, the application responds with:-
As a test for XSS, this example is fine but if this result was
returned to an application owner it would not hold much weight. Returning a
session cookie is a far superior test. The application can be requested to
return the session cookie using <script>alert(document.cookie)</script>
The attacker can now use this to try and hijack the users
session.
This is a very basic XSS test that has been seen many times over.
By combining the old <script>alert(1)</script> with some of
the new functions in HTML5, a new version of the script can be created which
will generate the same results.
HTML5 has a form attribute called AutoFocus which will
automatically focus the cursor to a certain input point on the page. Using the
<input> tag in conjunction to the autofocus feature to create a script
like <input autofocus onfocus=alert(document.cookie)> can
cause the XSS to be triggered. This had also been proven to work with <select
autofocus onfocus=alert(1)>, <textarea autofocus onfocus=alert(1)>
and <keygen autofocus onfocus=alert(1)>
Another option is to create a form button, which when clicked will
trigger the XSS
<form><button
formaction="javascript:alert(1)">test
This script takes advantage of the form element ‘button’ and uses
the new attribute formaction to create the button and trigger the alert
when the button is clicked.
There are numerous other examples of how input type attributes and
form features can be used to construct new scripts to trigger an XSS attack.
Testers need to expand their tests to include the new <video> and <audio>
tags. If tags are being blocked there are new on* element attributes that can
be tried like onunload= or onforminput= or onfocus= . If
tests that include an on* are being blocked try the new formaction= as
demonstrated above.
HTML5 has given us more ways of creating scripts that currently
developers may not be validating or sanitizing. Where previously our attacks
may not have worked because the developer had implemented good input
sanitation, encoding and validation, the same applications may now be
susceptible to attack using some of the new functionality available.
LocalStorage
Previously part of the W3C HTML5 specification, WebStorage is a
form of client side storage and is now a specification in its own right.
LocalStorage is a part of WebStorage and is a persistent form of storage that
remains even after the user has closed the browser. It has a larger storage
capacity than cookies and is not sent to the server with every single HTTP
request. Web pages can store information in LocalStorage in String key/value
pair format. No longer are developers bound by the 4kb limit of a cookie nor
does any data need to be sent to the server every time a request is made, and
the data persists even after navigating away from the page or close the
browser.
LocalStorage does have its downfalls. For one, there is no
equivalent to the cookies HTTPOnly flag which prevents cookies from being
accessed by Javascript, there can’t be since the LocalStorage API is written in
Javascript. This means that Javascript can be used to access LocalStorage,
which could mean that we could write a script that will document the
LocalStorage. Since LocalStorage is part of the DOM, it is vulnerable to
exposure if an XSS vulnerability exists on a site.
Since the test site does not use LocalStorage, data had to be
inserted manually in order to demonstrate this.
Filling the storage was as easy as using the LocalStorage API
which includes a function to set an item in LocalStorage. The syntax of the
call is localStorage.setItem("Name: ",
"Attacker");
Many similar calls were made in order to insert data into the
LocalStorage. A simple javascript script was then used to read back the data
inserted as can be seen below through the FireFox FireBug window.
There are now 4 entries to view in LocalStorage. The keys in
the above example are Education:, Age:, Name:, Job:. We have to include the ‘:’
when referencing the key since we used it when we inserted the key. It was not
necessary to use the colon in the statement, it was used for purely esthetic
reasons. The = is inserted by the script used to display the details of
LocalStorage.
Injecting scripts that have been created using the LocalStorage
API into the vulnerable search box will yield the details of the data in
LocalStorage.
The alert box contains a 4, meaning that there are 4 entries in
LocalStorage.
Since
the key names are known, a script can be injected into the vulnerable search
box to get the value of the key <script>alert(localStorage.getItem(“Name:
“))</script>
It should be noted that the Key name is required to get the key
value using this method. If the key names are unknown to the tester, a simple
script that will loop around the storage and display each key and value can be
run in the console of Firebug. This will only return the key/value pairs of the
site currently visited.
Getting a complete list of all entries in LocalStorage is not an
easy task. In Firefox, an add-on by Foundstone called HTML5 LocalStorage
Explorer can be used to view the storage but the same cannot be said for IE or
Chrome.
No comments:
Post a Comment