quick question - SXSW

[vanderaj at owasp.org (Andrew van der Stock)]

Hi all,

I have been specifically targeting developer conferences these last  
twelve months. I've had rejections from the likes of OSCON, and in  
fact, I was rejected from BlackHat, too. I have worked out the pattern  
to these conferences.

You gotta SEX IT UP.

Instead of submitting talks like "Safe Ajax Coding Techniques" or  
"Securely using mainframe transactions in your web app", submit talks  
that are titled:

"How we pillage your app, identity rape your users, steal all your  
money, and retire in the Caribbean with the loot"

Then when you get there, start with a demo or three to end all demos.  
Totally scare them witless. Followed by a picture of a girly drink  
with an umbrella in it with a beach in the background, and take the  
girly drink to the talk, too. Once you've put the fear of god (or at  
least malicious attackers) into them, then you can:

* Do the talk you had in mind all along ("Securely using  
mainframe ..."), and they'll learn what they needed to learn by  
attending your talk.

This is not to say you should be a boring presenter, but we shouldn't  
shy away from saying to developers that they MUST do this stuff, or  
they'll be pwned.

Just before the folks fill in their presenter feedback forms, do an  
ASTONISHING demo. Something they will remember when they're filling in  
the feedback. When you're at the top of the feedback pile, you'll get  
invited back.

The program committees for these trendy conferences - with some very  
notable exceptions - are for the most part just as hostile /  
apathetic / know little about security as the attendees. Sometimes  
worse - many are truly hostile to security as it gets in the way of  
their "fast and crappy beats correct every time" mindset. So make your  
submission interesting to the program committee, so much so that they  
want to come see it, too. Once they start accepting the talks, sooner  
or later, after 10 years or so, we'll be able to submit the useful  
talks without any such cover. See the design pattern folks for proof.

Arian - ARGH! Tell Anurag to check out ESAPI - it has already hard  
core white list encoding, direct object reference maps, easy user  
object manipulation (logout that actually does the right thing with  
one call, etc), safe system(), encrypted property files, integrity  
protection and encryption for hidden fields and cookies, and so on and  
on and on.

Encoder::
canonicalize()           Simplifies percent-encoded and entity-encoded  
characters to their simplest form so that they can be properly  
validated.
decodeFromBase64()       Decode data encoded with BASE-64 encoding.
decodeFromURL()          Decode from URL.
encodeForBase64()        Encode for base64.
encodeForDN()            Encode data for use in an LDAP distinguished  
name.
encodeForHTML()          Encode data for use in HTML content.
encodeForHTMLAttribute() Encode data for use in HTML attributes.
encodeForJavascript()    Encode for javascript.
encodeForLDAP()          Encode data for use in LDAP queries.
encodeForSQL()           This method is not recommended.
encodeForURL()           Encode for use in a URL.
encodeForVBScript()      Encode data for use in visual basic script.
encodeForXML()           Encode data for use in an XML element.
encodeForXMLAttribute()  Encode data for use in an XML attribute.
encodeForXPath()         This implementation encodes almost everything  
and may overencode.
normalize()              Normalizes special characters down to ASCII  
using the Normalizer built into Java.

It's already done! However, there's more to do - let's work together  
on those gaps (client AJAX ESAPI) instead of re-inventing the wheel.

thanks,
Andrew

On Mar 13, 2008, at 4:11 AM, Arian J. Evans wrote:
> and Anurag will be releasing some APIs
> for java developers to actually do things like output encoding,
> where Java/J2EE is about 4 years behind the rest of the world.


thanks,
Andrew van der Stock
Lead Author, OWASP Guide and OWASP Top 10