Hi Andrew,
I was reminded of what you said in your post when I read the beginning of
this prezo description from HITB 2007:
"Using a lethal combination of various client side attacks we'll smash the
same origin policy, punch our way through your firewall, and dropkick an
Oracle database on your internal network (and we're NOT talking about SQL
Injection!)."
All good points you make that I'll keep in mind for my next attempt in SE
Asia.
Cheers,
Stephen
--------------------
> From: Andrew van der Stock <[EMAIL PROTECTED]>
> Date: Thu, Mar 27, 2008 at 6:02 AM
> Subject: Re: [SC-L] quick question - SXSW
> To: "Arian J. Evans" <[EMAIL PROTECTED]>
> Cc: Secure Coding Mailing List <SC-L@securecoding.org>
>
>
> 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
>
>
>
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L@securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com
> )
> as a free, non-commercial service to the software security community.
> _______________________________________________
>
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
