How Simple can it be.....XSS Prevention....

Cross Site Scripting is sill a very common web vulnerability.
Generally it is used to attack clients/users.

It can be used for malware upload, botnet hooking, keylogging, a payload delivery system for clickjacking and CSRF attacks and much much more, all for 6 easy payments of $9.99...sorry got carried away there :)

But is is easily preventable. You dont even have to know what XSS (type 0, type 1, type 2, DOM, Stored, Reflected) is to prevent it.

One pretty simple way to prevent XSS is to use the OWASP ESAPI (Enterprise Security API). A very easy tool to use/invoke.
It's also managed and attended to by Chris Schmidt....A great guy...

Regardless of what it does....if there was a mandate to use it on all redisplayed external input a site could become virtually XSS free!! (all for 6 easy payments of......).

It's easy to deploy....

1. Include in JSP (Java version)
2. Invoke in JSP
3. Job done!!!

We include it by

<%@ page import="org.owasp.esapi.ESAPI" %>

We invoke it by

<div><%=ESAPI.encoder().encodeForHTML(contentQuery)%></div>
.....here we are escaping HTML element content.

But here be Dragons........
Yes there is an exception to server-side escaping of input....DOM XSS.
Input rendered on the clients which does not touch the server is fair game for XSS'ers!!!
So data sent into the browser which is rendered via client side code. No server interaction needed.

An example of this are URI fragments or Anchors. These are not required for DOM XSS but demonstrate server side reflection is not required (and escaping for that matter on the server is ineffective).

Remember "Learn to code HTML for Food" (otherwise know as the W3C)...well anchors or URI fragmants do not get sent to the server.

Anchors (#) as opposed to query parameters (?) hang about the client (in small groups, causing trouble).
So for server side validation:

http://127.0.0.1:8080/vuln/XSS.jsp#q=<script>alert()</script>  ß This fragment is dangerous. Server does not see this. We need some client validation!!
http://127.0.0.1:8080/vuln/XSS.jsp?q=<script>alert()</script>  ß This is escaped on server. Need server (and client) validation (depending where the input emanates from).
So we need some additional client side controls. This is particularly relevent for RIA applications.

Bring forth ESAPI4JS!!

Simply put ESAPI4JS escapes client side input from external sources.

Again very easy to use:

Import into your page:


<!-- esapi4js dependencies -->
<script type="text/javascript" language="JavaScript" src="/esapi4js/lib/log4js.js"></script>
<!-- esapi4js core -->
<script type="text/javascript" language="JavaScript" src="/esapi4js/esapi.js"></script>
<!-- esapi4js i18n resources -->
<script type="text/javascript" language="JavaScript" src="/esapi4js/resources/i18n/ESAPI_Standard_en_US.properties.js"></script>
<!-- esapi4js configuration -->
<script type="text/javascript" language="JavaScript" src="/esapi4js/resources/Base.esapi.properties.js"></script>

 Use:
org.owasp.esapi.ESAPI.initialize();

document.write($ESAPI.encoder().encodeForHTML(queryparam));

Jim Manico and myself shall be covering this and lots of other security jiggery pokery @

Sec App Dev - Belgium March 7th
OWASP AppSec DC 2012

Comments

  1. Hey Eoin,

    V. Interesting post. One question I had on the Javascript side of things is, Is there any easy way for developers to integrate ESAPI4JS into existing Javascript toolkits (eg, Jquery, MooTools etc)?

    A lot of times I see that most of the JS used in a site isn't actually hand coded, it's calls to pre-packaged libraries which can make DomXSS mitigation trickier...

    Cheers

    Rory McCune

    ReplyDelete
    Replies
    1. Hi Rory,
      jquery has its own version of esapi. (Written by Chris Schmidt)
      https://github.com/chrisisbeef/jquery-encoder
      I'm not sure about MooTools :)

      Delete
  2. my js files are being injected with js code (iframes).

    I dont uderstand How do I protect the files using ESAPI

    ReplyDelete
    Replies
    1. How are they being injected?
      is the server hosting them compromised? local injection is not an issue.
      To prevent injection on js parameters one needs to jsencode all data.
      $ESAPI.encoder(). encodeForJavaScript()
      But it depends. Certain Javascript sinks should be avoided such as

      Direct execution
      eval()
      window.execScript()/function()/setInterval() /setTimeout(), requestAnimationFrame()
      script.src(), iframe.src()

      Build HTML/Javascript
      document.write(), document.writeln()
      elem.innerHTML = danger, elem.outerHTML = danger
      elem.setAttribute(“dangerous attribute”, danger) – attributes like: href, src, onclick, onload, onblur, etc.

      Within execution context
      onclick()
      onload()
      onblur(), etc.

      Delete

Post a Comment

Popular posts from this blog

Edgescan, why we do what we do.....

20 years of Vulnerability Managment - Why we've failed and continue to do so.

Edgescan and Huawei - Cybersecurity - Irish Times Article and Panel Discussion