I have created a xss filter to protect from xss attacks. Though i have filte
red only for 8 characters but i was able to test against all the attacks men
tioned in the RSnake's cheat sheet. Appscan was not able to detect any xss a
ttacks on it. I request the application security community to help test this
 filter. 90% i am sure that you wont be able to perform any xss attack on it
, the rest 10% i will find out after the feedback from the community. For th
e curious mind, it is written in java

In case if you are successful in performing xss attack, please do reply to t
his email with your name,browser and the xss attack string.

url - http://www.attacklabs.com/xssfilter/

I appreciate your time and effort. Thanks a lot in advance

Cheers,
 
Anurag Agarwal
 
SEEC - An application security search engine
Web: www.attacklabs.com , www.myappsecurity.com
Email : anurag..agarwal@yahoo.com
Blog : http://myappsecurity.blogspot.com

[ Post a follow-up to this message ]

Anurag,

I see that you are swallowing *potentially* malicious characters here. The
stress on the word potentially is because there might be occasions in a real
world web application where I might need to allow a user to enter characters
that your filter thinks are malicious but have a legitimate semantic in the
context of that web application.

For example, you filter out < and >. Great! But what if the user has to
express something like "I strongly believe that 10 < 11 and that ';' can be
a good terminator for statements." ?

What would make more sense is to echo these chars back with proper encoding?

Prasad.

On 1/23/07, Anurag Agarwal <anurag.agarwal@yahoo.com> wrote:
>
> I have created a xss filter to protect from xss attacks. Though i have
> filtered only for 8 characters but i was able to test against all the
> attacks mentioned in the RSnake's cheat sheet. Appscan was not able to
> detect any xss attacks on it. I request the application security community
> to help test this filter. 90% i am sure that you wont be able to perform a
ny
> xss attack on it, the rest 10% i will find out after the feedback from the
> community. For the curious mind, it is written in java
>
> In case if you are successful in performing xss attack, please do reply to
> this email with your name, browser and the xss attack string.
>
> url - http://www.attacklabs.com/xssfilter/
>
> I appreciate your time and effort. Thanks a lot in advance
>
>
> Cheers,
>
>
>
> Anurag Agarwal
>
>
>
> SEEC - An application security search engine<http://www.myappsecurity.com/
>
>
> Web: www.attacklabs.com , www.myappsecurity.com
>
> Email : anurag.agarwal@yahoo.com
>
> Blog : http://myappsecurity.blogspot.com
>
>
>
>

[ Post a follow-up to this message ]

This is a good but dangerous effort, the problem is in this example is
that Anurag
is applying a blackList filter and is only protecting against one case of
xss.

Here is the original code code:

String html = request.getParameter("html");
out.println("Here is the filtered output of the html you submitted.");
out.println(filterRequest(html));

And if I change it to:

String html = "<a href='" + filterRequest(request.getParameter("url")) +
"'>XSS link</a>";
out.println("Here is the filtered output of the html you submitted.");
out.println(html);

which is another example of using user input to create a link

the filter can be easily bypassed.

1) normal request:
http://127.0.0.1:8080/servlets-exam...url=nextServlet

2) already a type of XSS since this type of redirection should not be
allowed: http://127.0.0.1:8080/servlets-exam... />
google.com


3) and here is an XSS 101 payload:
http://127.0.0.1:8080/servlets-exam...er?url=nextPage'
onmouseover='java script:alert(document.cookie)
<http://127.0.0.1:8080/servlets-exam...ument.cookie%29>
4) or if you want to make sure the user cannot escape:
http://127.0.0.1:8080/servlets-exam...gle.co
m'
<http://127.0.0.1:8080/servlets-exam....c
om%27>onmouseover='java script:alert(
document.cookie)"
 style='display:block;position:absolute;l
eft:0;right:0;width:100%25;height:10
0%25
(thx pdp)

5) note that in example 4) above I could had used " in the payload since
your filter will convert " to '   :
http://127.0.0.1:8080/servlets-exam...er?url=nextPage"
onmouseover="java script:alert(document.cookie)

<http://127.0.0.1:8080/servlets-exam...ument.cookie%29>6)
of course that in this case you could always just do:
http://127.0.0.1:8080/servlets-exam...avascript:alert(document
.cookie)<http://127.0.0.1:8080/servlets-exam...ument.cookie%29>


7) and even if you added ' to the filter (which might be a problem since in
some case you will need to accept it), it wouldn't cover for this case: Stri
ng
html = "<a href=" + filterRequest( request.getParameter("url")) + ">XSS
link</a>";

8) and lets not forget the XSS caused by double encoding or double decoding
in the code

I hope this shows how hard it is to properly mitigate against XSS and that
in most cases white listing is the only safe option (and even in those cases
XSS might occur).

Another solution that is very rarely talked is to by default encode
EVERYthing sent to out.println and force the developers to use strong-typed
html classes to create HTML tags.

In the above example your would change

String html = "<a href='" + filterRequest(request.getParameter("url")) +
"'>XSS link</a>";
out.println(html);
for

safeHtmlBuilder.a html = safeHtmlBuilder.a(request.getParameter("html"),
"XSS link")
safeHtml.out(html);

Assuming of course that safeHtmlBuilder.a(...) was built properly

Even better than encoding out.println would be to block the developer from
invoking out.println directly (which could be enforced via ('Shock
Horror!!!') the Java security manager (or in Partial Trust in .Net)).

We would have a nice solution for XSS (and this is a good example of what I
was talking about a while back on using Sandboxes to create environments
where these types of vulnerabilities are very hard to exists )

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org


On 1/23/07, Anurag Agarwal <anurag.agarwal@yahoo.com> wrote:
>
>  I have created a xss filter to protect from xss attacks. Though i have
> filtered only for 8 characters but i was able to test against all the
> attacks mentioned in the RSnake's cheat sheet. Appscan was not able to
> detect any xss attacks on it. I request the application security community
> to help test this filter. 90% i am sure that you wont be able to perform a
ny
> xss attack on it, the rest 10% i will find out after the feedback from the
> community. For the curious mind, it is written in java
>
> In case if you are successful in performing xss attack, please do reply to
> this email with your name, browser and the xss attack string.
>
> url - http://www.attacklabs.com/xssfilter/
>
> I appreciate your time and effort. Thanks a lot in advance
>
>
> Cheers,
>
>
>
> Anurag Agarwal
>
>
>
> SEEC - An application security search engine<http://www.myappsecurity.com/
>
>
> Web: www.attacklabs.com , www.myappsecurity.com
>
> Email : anurag.agarwal@yahoo.com
>
> Blog : http://myappsecurity.blogspot.com
>
>
>



--

[ Post a follow-up to this message ]

I have a php anti-XSS library in development which encodes all but the
characters A-Z, a-z, 0-9, and space. It is multi-byte aware. For
convenience, it uses the same API interfaces as Microsoft Anti-XSS 1.5
library (which I heartily recommend to all .NET developers). My version is
initially implemented in just PHP. I might have to make it into a PHP
extension to regain speed. But first and foremost, correct then fast. The
API is most likely going to be (statics may be lost in the long run):

class AntiXSS {     public function __construct()    {     }     p
ublic
static function HTMLEncode($o)
{     }        public static function HTMLDecode($i)    {         
   }
public static function HtmlAttributeEncode($o)
{            }        public static function UrlEncode($o)
{            }        public static function JavaScriptEncode($o)
{            }        public static function XmlEncode($o)
{            }        public static function XmlAttributeEncode($o)
{            } 
}

In addition, I have completed a basic anti-CSRF class, which will defeat
some but not all forced browsing attacks.

/*
* Usage: *  * require_once('owasp.csrfguard.php'); * $cg = new csrfGuard();
*  * In your HTML form, use this to get a hidden field: *  * echo $cg; *  *
If you want the two values as an array, say if you * want to put or store it
elsewhere, do this: *  * $myArray = $cg->getToken(csrfGuard::RAWFORM); *  *
Before processing the resulting submission, do this: *  * try * { *
$cg->isValid();
* ... Your appšs code goes here ... * } * catch (TokenException $e) * {
 *
// handle exception  * }
*/

These will be up on the OWASP web site soon; sooner with some help! 

Thanks,
Andrew

[ Post a follow-up to this message ]

Ok, I posted this on Dinis Cruz blog but I guess it might be useful
here as well.

XSS is an attack vector that is very hard to mitigate. Why? Well,
different applications have different requirements that involve
different problems. Some problems can be grouped and solved with a
single solution. Others can't! You need to write custom solutions for
them.

Also, be aware that the currently developed XSS filters protect the
client by sanitizing the input sent to the server. That's very good,
however, I've seen many applications that do pretty good job on the
server side but they fail to perform that well on the client side. I
am talking about DOM based XSS. If your JavaScript code makes use of
cookies, queries, fragment identifiers or other type of input without
sanitizing it, attackers can abuse it in order to execute malicious
code on the browser.

Althought that was not very popular in the past, today with the raise
of AJAX applications, it is normal. Serverside XSS filters don't work
here. This is the client side.

On 1/23/07, Andrew van der Stock <vanderaj@owasp.org> wrote:
>
>  I have a php anti-XSS library in development which encodes all but the
> characters A-Z, a-z, 0-9, and space. It is multi-byte aware. For
> convenience, it uses the same API interfaces as Microsoft Anti-XSS 1.5
> library (which I heartily recommend to all .NET developers). My version is
> initially implemented in just PHP. I might have to make it into a PHP
> extension to regain speed. But first and foremost, correct then fast. The
> API is most likely going to be (statics may be lost in the long run):
>
>  class AntiXSS {    public function __construct()    {    }    p
ublic static
> function HTMLEncode($o)
>     {    }        public static function HTMLDecode($i)    {    
        }
>     public static function HtmlAttributeEncode($o)
>     {            }        public static function UrlEncode($o)
>      {            }        public static function JavaScriptEncode($o
)
>     {            }        public static function XmlEncode($o)
>      {            }        public static function XmlAttributeEncode(
$o)
>      {            }
>  }
>
>  In addition, I have completed a basic anti-CSRF class, which will defeat
> some but not all forced browsing attacks.
>
>  /*
>   * Usage: * * require_once('owasp.csrfguard.php'); * $cg = new csrfGuard(
);
> * * In your HTML form, use this to get a hidden field: * * echo $cg; * * I
f
> you want the two values as an array, say if you * want to put or store it
> elsewhere, do this: * * $myArray =
> $cg->getToken(csrfGuard::RAWFORM); * * Before processing
> the resulting submission, do this: * * try * { *    $cg->isValid();
>   * ... Your app's code goes here ... * } * catch (TokenException $e) * &#
123; *
>     // handle exception * }
>   */
>
>  These will be up on the OWASP web site soon; sooner with some help! 
>
>  Thanks,
>  Andrew
>


--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

----------------------------------------------------------------------------
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

[ Post a follow-up to this message ]

Dinis -

Thanks for your input. I know i am applying a blacklist filterbut in my expe
rience i have seen many of the architects dont want to just look for the rig
ht characters. To them it limits their options. For exampleif & is not in my
 whitelist of characters then customer cannot enter his company name as A&A 
industries. So, as much as i favor not using blacklisting approach, industry
 still wants it. The characters i am filtering cover most of the basis eithe
r individually or in combination.

To reply to your code example -

1. Normally in most of the sites you wouldnt allow anexternal user to enter 
a url for your website.
2. Lets say if you allow the user to input a url, which is internal to a web
site, just filter "http://" and replace it with "/".
3. If you want the user to input an externalurl then filter for space in add
ition to the filter mentioned in the code(just a quick thought).
4. If you want spaces too in the url then you haveto develop your own filter
.

As i mentioned before, the code i demonstrated is not for the websites(blogs
, forums, etc) which require these special input characters but for those wh
ich doesn't and the majority of the websites dont require these as an input

Cheers,
 
Anurag Agarwal
 
SEEC - An application security search engine
Web: www.attacklabs.com ,www.myappsecurity.com
Email : anurag.agarwal@yahoo.com
Blog : http://myappsecurity.blogspot.com
 



----- Original Message ----
From: Dinis Cruz <dinis@ddplus.net>
To: Anurag Agarwal <anurag.agarwal@yahoo.com>
Cc: WASC Forum <websecurity@webappsec.org>; "webappsec @OWASP" <webappsec@li
sts.owasp.org>; Andrew van der Stock <vanderaj@owasp.org>; Jeff Williams <je
ff.williams@owasp.org>
Sent: Tuesday, January 23, 2007 7:46:33 AM
Subject: Re: [WEB SECURITY] xss filter to protect from xss attacks

This is a good but dangerous effort, the problem is in this example is that 
Anurag is applying a blackList filter and is only protecting against one cas
e of xss. 

Here is the original code code:

  String html =request.getParameter("html");
  out.println("Here is the filtered outputof the html you submitted.");
  out.println(filterRequest(html)); 

And if I change it to:

String html = "<a href='" + filterRequest(request.getParameter("url")) + "'>
XSS link</a>";
out.println("Here is the filtered output of the html you submitted.");
out.println(html);

which is another example of using user input to create a link

the filter can be easily bypassed.

1) normal request: http://127.0.0.1:8080/servlets-exam... />
extServlet 

2) already a type ofXSS since this type of redirection should not be allowed: http
://127.0.0.1:8080/servl...er?url=nextPage' onmouseover='java script:alert(document.cookie) 

4) or if you want to make sure the user cannot escape: http://127.0.0.1:8080/servl
../www.google.com' onmouseover='Javas
cript:alert(document.cookie)"  style='display:block;position:absolute;l
eft:0;
right:0;width:100%25;height:100%25   (thx pdp)

5) note that in example 4) above I could had used " in the payloadsince your filter wil
l convert " to '   : http://127.0.0.1:8080/servlets-exam...r />
=nextPage" onmouseover="java script:alert(document.cookie)

6) of course that in this case you could always just do: http://127.0.0.1:8080/ser
vl...avascript:alert(document.cookie)  

7) and even if you added ' to the filter(which might be a problem since in s
ome case you will need to accept it), it wouldn't cover for this case: Strin
g html = "<a href=" + filterRequest( request.getParameter("url")) + ">XSS li
nk</a>";

8) and lets not forget the XSS caused by double encoding or double decoding 
in the code

I hope this shows how hard it is to properly mitigate against XSS and that i
n most cases white listing is the only safe option (and even in those cases 
XSS might occur). 

Another solution that is very rarely talked is toby default encode EVERYthin
g sent to out.println and force the developers to use strong-typed html clas
ses to create HTML tags. 

In the above example your would change 

  String html = "<a href='" + filterRequest(request.getParameter("url")) + "
'>XSS link</a>";
  out.println(html);
for

  safeHtmlBuilder.a html = safeHtmlBuilder.a(request.getParameter("html"), "
XSS link")
  safeHtml.out(html);

Assuming of course that safeHtmlBuilder.a(...) was built properly

Even better than encoding out.println would be to block the developer from i
nvoking out.println directly (which could be enforced via ('Shock Horror!!!'
) the Java security manager (or in Partial Trust in .Net)). 

We would have a nice solution for XSS (and this is a good example of what I 
was talking about a while backon using Sandboxes to create environments wher
e these types of vulnerabilities are very hard to exists )

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org 



On 1/23/07, Anurag Agarwal <anurag.agarwal@yahoo.com > wrote:
I have created a xss filter to protect from xss attacks. Though i have filte
red only for 8 characters but i was able to test against all the attacks men
tioned in the RSnake's cheat sheet. Appscan was not able to detect any xss a
ttacks on it. I request the application security community to help test this
 filter. 90% i am sure that you wont be able to perform any xss attack on it
, the rest 10% i will find out after the feedbackfrom the community. For the
 curious mind, it is written in Java 
 
In case if you are successful in performing xss attack, please do reply to t
his email with your name, browser and the xss attack string.
 
url - http://www.attacklabs.com/xssfilter/
 
I appreciate your time and effort. Thanks a lot in advance
 
Cheers,
 
Anurag Agarwal
 
SEEC - An application security search engine
Web: www.attacklabs.com , www.myappsecurity.com
Email : anurag.agarwal@yahoo.com
Blog : http://myappsecurity.blogspot.com
 



--

[ Post a follow-up to this message ]

Hi All,

Can the XSS problem (both avoiding and filtering) be minimized if we
accept only XHTML from the user? I mean if we create a custom DTD and
then validate the user input against that.

For example
If we allow only <b> (bold) or <i> (italic) tag, we may validate the
input against that DTD.

Regards,
Lalit Patel
--
http://www.lalit.org

----------------------------------------------------------------------------
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

[ Post a follow-up to this message ]