[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[WEB SECURITY] Re: [Webappsec] [WEB SECURITY] xss filter to protect from xss attacks

[sorry for the double posting]

Again,

This is not a problem if you don't "strip" or "filter" input. Just do it
right on the way out. Now, I'd never recommend leaving out input
validation, but if you're just doing HTML output, then HTML entity
encoding will prevent XSS, and it's way easier than blacklist filtering,
which hoses the incoming data.

A simple proof:

<%
' stupid trivial asp example
dim strInput
strInput=server.htmlencode(trim(request.form("in")))
%>
<html>
<form name="f" action="" method="post">
Try to run script in this:<br> <textarea name="in"
rows="5"cols="80"><%=strInput%></textarea>
<br><input type="submit">
</form>
You entered: <%=strInput%>
</html>

The example above does not account for a bunch of stuff. It is only to
show that even fundamental, built in HTML encoding will go a long way.
And, no input validation is used whatsoever. Again, not safe for all
cases, just an example to illustrate a point that input "filtering" aka
"stripping characters" isn't the way to do output.

-c

anurag.agarwal@xxxxxxxxx wrote:
> Dinis -
>  
> Thanks for your input. I know i am applying a blacklist filter but in my
> experience i have seen many of the architects dont want to just look for
> the right characters. To them it limits their options. For example if
> & 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 either individually or in combination.
>  
> To reply to your code example -
>  
> 1. Normally in most of the sites you wouldnt allow an external 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
> website, just filter "http://"; and replace it with "/".
> 3. If you want the user to input an external url then filter for space
> in addition to the filter mentioned in the code(just a quick thought).
> 4. If you want spaces too in the url then you have to 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 which doesn't and the majority of the websites
> dont require these as an input
> 
> Cheers,
> 
>  
> 
> Anurag Agarwal
> 
>  
> 
> SEEC - An application security search engine <http://www.myappsecurity.com/>
> 
> Web: www.attacklabs.com <http://www.attacklabs.com/> ,
> www.myappsecurity.com <http://www.myappsecurity.com/>
> 
> Email : anurag.agarwal@xxxxxxxxx <mailto:anurag.agarwal@xxxxxxxxx>
> 
> Blog : http://myappsecurity.blogspot.com
> <http://myappsecurity.blogspot.com/>
> 
>  
> 
> 
> 
> ----- Original Message ----
> From: Dinis Cruz <dinis@xxxxxxxxxx>
> To: Anurag Agarwal <anurag.agarwal@xxxxxxxxx>
> Cc: WASC Forum <websecurity@xxxxxxxxxxxxx>; "webappsec @OWASP"
> <webappsec@xxxxxxxxxxxxxxx>; Andrew van der Stock <vanderaj@xxxxxxxxx>;
> Jeff Williams <jeff.williams@xxxxxxxxx>
> 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 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-examples/servlet/XSSFilter?url=nextServlet
> 
> 2) already a type of XSS since this type of redirection should not be
> allowed:
> http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=http://www.google.com
> <http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=http://www.google.com>
> 
> 3) and here is an XSS 101 payload:
> http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=nextPage'
> onmouseover='Javascript:alert(document.cookie)
> <http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=http://www.google.com%27%20onmouseover=%27Javascript:alert%28document.cookie%29>
> 4) or if you want to make sure the user cannot escape:
> http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=http://www.google.com'
> <http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=http://www.google.com%27>onmouseover='Javascript:alert(document.cookie)"
> style='display:block;position:absolute;left:0;right:0;width:100%25;height:100%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-examples/servlet/XSSFilter?url=nextPage";
> onmouseover="Javascript:alert(document.cookie)
> 
> <http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=http://www.google.com%27%20onmouseover=%27Javascript:alert%28document.cookie%29>6)
> of course that in this case you could always just do:
> http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=javascript:alert(document.cookie)
> <http://127.0.0.1:8080/servlets-examples/servlet/XSSFilter?url=javascript:alert%28document.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: String 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 <http://www.owasp.org/>
> 
> 
> On 1/23/07, *Anurag Agarwal* <anurag.agarwal@xxxxxxxxx
> <mailto:anurag.agarwal@xxxxxxxxx>> 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 any 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 <http://www.attacklabs.com/> ,
>     www.myappsecurity.com <http://www.myappsecurity.com/>
> 
>     Email : anurag.agarwal@xxxxxxxxx <mailto:anurag.agarwal@xxxxxxxxx>
> 
>     Blog : http://myappsecurity.blogspot.com
>     <http://myappsecurity.blogspot.com/>
> 
>      
> 
> 
> 
> 
> -- 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Webappsec mailing list
> Webappsec@xxxxxxxxxxxxxxx
> http://lists.owasp.org/mailman/listinfo/webappsec


----------------------------------------------------------------------------
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]
Brought to you by http://www.webappsec.org
Search this site