omg.wtf.bbq.

because arshan’s too cheap to license OneNote

What could be better than Google Code Search for finding vulnerabilities? Look at MAMA. I bet you never heard of it – I hadn’t, until my buddy .mario pointed it out to me. It’s (as of today) an internal tool that Opera uses to crawl the web and index the structure of the world’s web pages, which is very different from Google’s engine which is strictly interested in text content.

Brian Wilson of the Opera team has said on their forums that general public release is definitely the plan. What could you do with MAMA? Just off the top of my head, anything an appscanner could find without stateful context. Simple queries could produce a lot of noise, but could be optimized greatly with correlating conditions and keywords. Some quick thoughts, and who knows, maybe Johnny Long can do a few of these things already:

  • DOM-based XSS vulnerabilities
  • CSRF (forms without a token >20 bytes of seemingly random stuff)
  • CAPTCHA-less comment forms (hello targeted, optimized spam!)
  • hidden administration login pages (already kind of doable with Google)
  • clickjackable sites (absence of frame breaking code)
  • interesting HTML comments (HACK, FIXME, TODO are usually good ones)
  • insecurely implemented postMessage() senders or listeners
  • insecure password policies
  • suspiciously named hidden fields
  • meta tags with incorrectly spelled charsets (for followup exploitation with content sniffing and utf-7)

This would also be useful to security researchers who are asking browsers to kill off crazy API abuse. For example, my first question for MAMA is: does any legitimate site out there use <img src=”javascript:…>? This tool could provide assurance to browsers that any API cleanups don’t cause any back breakage significant.

I can’t wait to hear more about this project, which has not, as far as I can tell, been released to the public. In the meantime check out Brian’s list of articles that hint at the power this thing could give the unscrupulous. They should make you pass a breathalyzer before using that thing.

Unchecked redirect vulnerabilities are annoying to fix for our customers. Sometimes the developers need to link to a constantly changing selection of partners and they always have to support different redirect URLs for testing, integration, and production. Sometimes these redirect mechanisms span different applications even though they live on the same domain, too. Given the unstable nature of the “targets” and the cross-application centralization of these redirect mechanisms, we need some smarter alternatives.

What we’ve been recommending customers do to accommodate this target flux allows them to maintain a dynamic target without putting them at risk to phishing attacks. There are a number of creative solutions, and if you’ve got any more please comment:

  1. Change the functionality to use POST instead of GET, and require a POST before redirecting. The attacker can’t force your browser to issue a POST without bouncing you off an intermediary, evil site. And if they do that, they could just redirect you to the phishing page directly anyway.
  2. Set the target of the redirect in a cookie and let the “bounce” functionality read it from there. The attacker can’t force your browser to send arbitrary cookies with cross-site requests, so you’re safe with this technique.
  3. Symmetrically encrypt the contents of the redirect target. You can still have a constantly-in-flux list of redirect targets and still maintain assurance that attackers can’t abuse your functionality for phishing.
  4. Set the target of the redirect in a session variable and let the “bounce” functionality read it from there. The attacker can’t  populate a victim’s session variables without abusing another vulnerability. For some redirect scenarios this may simply shift the dynamic work somewhere else but at least at that point you have architectural enforcement of your security mechanism.

Hope that helps!

Jeremiah Grossman, who not many people know is actually the devil, smoked a bunch of crack and made the mistake of associating himself with me again with this virulently circulating “7 facts”. Before I got a chance to see his post, he sent me an e-mail saying he was sorry about the “7 facts” thing. I got all excited because I thought it had something to do with Miley “fuckmeboots” Cyrus who has a song by the same name. Now I am all pissed off because it has nothing to do with my dream girl (just playing, Anna Faris – what we have is srsly speshl).

The Rules:

  • 1. Link to your original tagger(s) and list these rules in your post.
  • 2. Share seven facts about yourself in the post.
  • 3. Tag seven people at the end of your post by leaving their names and the links to their blogs.
  • 4. Let them know they’ve been tagged.

0. I don’t think anyone cares about these facts, but I enjoyed writing them while stuck in a hotel outside Philly. By the way, I love It’s Always Sunny in Philadelphia. Great show. That technically will make this page contain 8 facts, but I figure I’m also 1/7 more important or better looking than everyone else, so that means I deserve another fact.

1. I grew up on something more than alert(document.cookie). I cut my teeth on auditing and exploiting C. My favorite hacking books are Hacking: The Art of Exploitation by Jon Erickson and The Shellcoder’s Handbook by Aitel, Kozoil, Litchfield, et. al. Despite some lies you might hear from samy, the structs in my DNS spoofers are not misaligned and I can smash some stacks. However, my skills in the world of how-the-hell-can-I-write32 and the like have atrophied during my past 3 years in Funhouse of Mirrors we call the webappsec world.

2.  My favorite hobbies are video games, soccer and table tennis. I’ve even gotten some recognition and money for the first 2! Watch your back, Chris Shiflett.

3. I am a social justice junkie and desperately want everyone to vote 3rd party in the next presidential election. Stay within the realm of sanity with choices like Ralph Nader, Cynthia McKinney and Ron Paul. The media and controlling parties simply aren’t capable or willing to affect change, although we all have high hopes for Obama. If you don’t do something to help change your country, even if it’s just helping spread awareness about how fundamentally broken our system is, you might as well buy a shotgun, hole up in your house, and wait for the zombies to come. And pray that when they do, they’re the slow-moving zombies that can only infect you with a bite. If they’re fast and can infect you with scratches, you my friend, can consider yourself as eaten as a delicious risotto in front of Reuben Studdard.

4. I hang out with mostly non-technical people, which is probably why I haven’t killed myself yet. Computers r dum.

5. I can’t fall asleep without reading. I usually stick with Stephen King (the Dark Tower series should be a legal requirement for young adults), Frank Herbert (Dune, duh), George R.R. Martin, and all kinds of non-fiction including modern science types (On Intelligence, Freakonomics), but mostly historical and political (All the Shah’s Men, The Story of World War II, Franklin and Winston, A People’s History of the United States, The Essential Chomsky).

6. I’m an avid fan of both types of football, and cheer on my hometown Baltimore Ravens and my never-been-there-but-home-away-from-home Liverpool Reds.

7.  I was almost an artificial intelligence academia dork. My master’s thesis got published and I had some cool opportunities, but security was more interesting. We’re a long way from the finish line in the world of AI, and I didn’t want to be a forgotten ant in the pile of failed researchers.

Ok, here are the people I’m picking out.

Ivan Ristic. A good friend; unique, and an expert.

Mario Heiderich. He’s a great mind, passionate, but most importantly because he will HATE me for it.

Billy Hoffman. Because he’s my hero.

Dre/Marcin: Marcin is one of my padawan and Dre is hilariously inflammatory. This counts as 2.

Rafal Los:  I’m calling on a preacher’s kid, I must be running out of people.

Coates: A co-worker who pwns.

What other way is there of finding 216 million flaws in sub-second scanning time? Google, of course. How about 160,000 strictly within .gov? These numbers are absurd, especially since I’m only searching for one type of URL rewriting for J2EE. This type of flaw usually rates to a medium – the result of the combination of high impact and low likelihood.

URL rewriting is really only a problem because people aren’t especially good at rotating the user’s session ID post-authentication, so if you can trick a user into clicking on a link that has the session ID in it, they will be using that session ID from that point forward. All you have to do is wait 5 minutes, then use the session ID you sent them and hijack their identity and, most likely, their Twitter account because apparently they take security lessons from Oracle, which, for the uninitiated, is like taking gun safety lessons from Plaxico Burress (my 2nd round pick in fantasy football, I am salty).

URL re-writing is bad for one-click session fixation, SEO (page 8), usability – it’s just a bad, bad idea. Why don’t you use some clever JavaScript for tracking cookieless user state instead?

Of course none of these Google hacking techniques are new, but neither is David Spade and he’s banging it out with all kinds of hotties (note to Nicollette Sheridan: you can invade my Gaza strip anytime – also do you have a son named Eric?). It’s just that the numbers for this particular area are so crazy I had to write something up. And when I brought this up to j-dubs he of course tried to outdo me (typical) by trying to conjure up huge numbers in Google’s Code Search looking for the most blatant reflected XSS and the most obviously exploitable SQL injection vulnerabilities. He couldn’t come close, but notes correctly that many of those could be in widely deployed software.

Can anyone beat that number? With a similar-or-higher-severity vulnerability?

Another great OWASP conference ended yesterday. Other than the terrible food and slightly jarring speaker shuffle, I had a great time. I met lots of interesting folks from lots of different places, including closet webappsec expert Chris Shiflett, the always-blogging Rafal Los, and seasoned veteran Gunter Ollman, among them. I gave a talk on Day 2 about organizing our thoughts on cross-site scripting worms and where worm authors can go in the future with smarter design choices and futureware from HTML5. The slides are here and the corresponding paper from last year’s Belgium conference is here. Let’s go through the highlights of the rest of the conference for those of you who weren’t there.

Clickjacking / UI Redress / iframe + CSS

There’s been some drama recently since Jeremiah Grossman and Robert Hansen abruptly cancelled their ‘clickjacking’ talk at the conference. Instead of giving the talk, the pair fielded questions about the vulnerability in general terms and deflected any detailed questions that might leak information to people attempting to reverse engineer it. This pattern of half-disclosure among security researchers is becoming more popular and I’m not personally sure if the vendors deserve any preferential treatment given their security track record.

Clickjacking, the term, is an attack whereby a victim on a malicious page is tricked into clicking ‘past’ a link or button and ends up clicking on something else. What is that “something else”? How bad can it be? Pretty bad, actually. After about 30 minutes of thinking I came up with 2 really dangerous vectors, one just a general attack framework idea, and another specific vector against Flash I’d rate as a 7/10. However, Jeremiah and RSnake are sitting on a vector that is definitely 10/10. To quote Ptacek, ‘they have the goods.’

Corruption

Dave Aitel’s talk on trends in public exploit development and future consequences was fascinating. Dealing with “alert(document.cookie)” 24/7/365 does make you itch for that time when you were staying up all night trying to figure out why your write32 exploit worked in gdb but not on the command line. His personality reminds me a lot of Samy, and possibly myself – no coincidence considering we’re all brown.

Bypassing web application/service security controls using Encoding, Transcoding…

Arian never showed up – it was claimed he was lost in NYC. I suspect he was hung over on a beach in Malaysia, rolling over some chubby MILF. <3 u Arian.

Multidisciplinary Bank Attacks

Got a chance to meet Gunter Ollman, who is much nicer in real life than the curmudgeon persona he has online. He discussed man-in-the-browser banker trojans; their technical capability and the business around them. Given that there were between 3,000 and 6,000 variants of banker trojans identified in 2005 alone, and I’ve heard that some ridiculous percentage of IE6 installations tested were infected with one of those variants, this is definitely pertinent considering how much we all work with the financial industry.

Given the signature-based methodology the trojans use to modify pages, couldn’t we play some defense by doing some DOM re-ordering or id-randomizing to at least make the attacks appear more obvious? Kind of like ASLR for the pages? Seems like some good defensive research could produce protection for at least a year or two.

Conclusions

Thanks to the NY chapter and Tom Brennan for organizing such a great conference considering they had to change venues 2 weeks before the event! Hope to see all of you in Portugal for the EU Summit.

Robert Hansen’s gripe with Google is easy to understand. Unchecked redirects are a phisher’s dream vulnerability. What would be Google’s motivation to not fix such a blatant vulnerability? Well, there’s only a few reasons why someone would choose to purposely not fix a vulnerability:

1. they don’t care about security
2. they don’t know how to fix it
3. they believe the issue is not a vulnerability
4. the cost of the fix does not equate with the risk of the vulnerability
5. the security vulnerability is inherently inseparable from a feature/function

Common sense rules out #1, #2, and #3. If it was #4, that would mean either Google does not want to fix the vulnerabilities since it is too costly to address phishing observed in the wild (repeat: too costly for Google). Given Google’s recent trust issues with privacy and being evil in general, fixing these would seem like an easy win. So, I think #4 can also be ruled out since it doesn’t make sense from Google’s perspective.

So, we’re left with #5. But how could this be? This would mean that the redirects are inherently inseparable from a Google function or functions.

The Vulnerability
Let’s setup the problem. Unchecked redirects are a type of Direct Object Reference problems. These problems occur when a malicious user can figure out arbitrary but valid values for a certain input. This input then gets acted upon by the application without any validation. Other types of direct object issues:

  • file names (../../../etc/passwd)
  • primary key fields (http://bank.com/viewAccount?id=102, what about 103?)

The solution to a Direct Object Reference is to create an intermediary table of values that the user can select. So, in the bank example, let’s assume that the user has access to account IDs 101 and 105. Any other 3 digit number corresponds to another user’s account, and that’s why their simple numeric rotation of the number worked. We need an Indirect Object Reference. What does an Indirect Object Reference (or intermediary table) look like? A few examples:

  • checking1   -> 105
  • file_index1 -> ./marketing.html

Sure, a user can request ‘checking105329′, but the application won’t find it, because the user does not have 105,000 checking accounts. What’s vital to understand here is that an Indirect Object Reference is an offset into a list of valid values. They eliminate the ability of a user to specify arbitrary values.

Ok, so then how can Google fix their vulnerability using this technique? Instead of this URL:

http://google.com/?q=http://www.aspectsecurity.com/

The fix would be to use this one:

http://google.com/?q=url105421

This way, the user can’t supply an arbitrary URL – they can only supply an index into a list of valid URLs. The value of the q parameter must match an actual object/row that’s been cataloged on the server-side. This is only possible assuming Google has that type of representation for documents, which RSnake claims (with more insider knowledge than me, granted) they have, but I’m not convinced – they don’t exactly have a RDBMS like MySQL powering Google indexing.

So even if they do have that URL ID capability- do we win? Can haz cheezburgr now? No, and for the record, if your cat really wants cheeseburgers you are a terrible cat owner. Cats should like tuna. If they really love cheeseburger, that means they’ve eaten enough of your lazily discarded cheeseburgers to become really fond of it, which means two things:

  • You should eat healthier
  • You shouldn’t leave food out

You’ll get ants.

So let’s imagine tomorrow Google was publishing these URLs: http://google.com/?q=url105421. Are we fixed? Hardly. Imagine how trivially easy it would be to get a bad site onto that list of valid URLs. All you would have to do, ostensibly, is create a document. When you eventually get indexed (it is not a challenge to get indexed), you will get a urlXXXX value. So, instead of http://google.com/?q=http://evil.com your URL will be http://google.com/?q=url105426. Wait, did we just make things worse? Yes, I do believe the 2nd URL is actually more likely to be clicked on by the unassuming.

One of the problems surrounding this unchecked redirect is “I’m Feeling Lucky.” A naive attempt to address this would be  to say, “Only a page that has a #1 page ranking for a given search term can have a urlXXXX number.” Of course, as a bad guy I could create an evil document that contains a hash of some secret that is unique to anything else on the Internet and therefore easily be the first page ranked (and thus, make it onto the elite urlXXXX list).

What about solutions?

Solution #1 for Google
Make the “I’m Feeling Lucky” page return a user only if the page on the other end of the rabbit hole has a page rank score somewhere between “I’ve got 30 subscribers to my blog” and “My open source project page recently reached 20,000 downloads.” Sure, you won’t stop someone who has se0wned someone else, but you’re now raising the bar dramatically.

Solution #2 for Google
Realtime, mostly-automated blacklisting.
1. Setup spam catching accounts with MSN.com, Yahoo!, Hotmail, etc.
2. Wait for spam that use Google Redirects pointing to a low ranking site.
3. Automatically add the phishing site to the already-existing blacklist when verified by a security team in realtime.

Okay, those are my thoughts on the unchecked redirects. In summary, I don’t think it’s fixable without a whole lot of work that utilizes out-of-band and reactionary techniques.

Extra Homework: The Google Gadgets Debate
I highly recommend everyone read RSnake, Kuza55 and Tom Ptaceks’ conversation on the Matasano blog about the whole Google Gadgets thing. The comments make the post, so read up.

What a ridiculously fun but busy time for me. I’ve had the honor of beating up important applications at work, going to Blackhat, going on vacation in the beautiful OBX, and all the while pursuing lots of side projects during down time. Let’s catch up chronologically:

1. I taught an Advanced Web Application Penetration Testing course at Blackhat. Mostly great reviews from 40 students, but I did have 1-2 people who should not have been there say it “wasn’t advanced enough.” My response (and I don’t mean to poo-poo) is: webappsec, more advanced?! hahahaha. If you’ve been doing webappsec professionally as a consultant 24×7 for 3-4 years, you’re not going to take a class where you’re going to learn a whole lot – I don’t care who’s teaching. If you have a foundation in security principles and look at lots of code and lots of sites, your knowledge intake will start to level off and sooner rather than later you’re going to start to only pick up new or old corner case scenarios. Don’t get me wrong – those corner cases are numerous and valuable and lots of them are covered in the class, but the point of the class was to show you how to get good coverage and perform a professional audit, not a crimeware authoring tutorial. I mean, who would pay for that? I don’t think the RBN isn’t interested in XSS yet.

So, everyone, I have a request: adjust your expectations on the upper bound of general knowledge in webappsec.

For those of you that missed Blackhat: Billy Hoffman wins the best talk award for my money. The most original and useful research condensed into 50 minutes. The big picture I got out of it is: it’s just not possible to analyze JavaScript malware outside of the browser. I don’t think that was his message, but hey, you did too good of a job, what can I say? He might have also come up with a way of reading random browser memory using faux images in JavaScript (with nods to pdp on the method).

Jeremiah Grossman’s talk was extremely entertaining with great delivery (even though there was a bizarre anti-whitebox bullet at the end). Dan Kaminsky was very entertaining, and incidentally broke the entire Internet. RSnake and Tom Stracener were also entertaining (way better than your talk in San Jose, Tom), even if I’m not totally convinced of Google’s already-convicted-in-the-court-of-public-opinion-stance on the redirect issue. Arian Evans did a good job evangelizing on a subject I know very well, but the truth is I know people aren’t ready for it yet.

2. I started the OWASP Intrinsic Security Working Group. We’ve got some modest goals, including fixing the Internet,  increasing saline levels in the Atlantic Ocean, getting Arian a girlfriend, and other monumental but culturally important goals. We’ve already got some early successes which I’ll be talking about here in a while; sometime before the OWASP Minneapolis Mini Conference on October 21st or the OWASP EU Summit in November, both of which I’ll be attending and speaking. Our main problems are momentum and press, if you can help with either, please let us know!

3. Jerry Hoff is releasing version .5 of OWASP AntiSamy .NET, which you can test here. I was really only a collaborator – he did all the work and gets all the credit (and, unfortunately for me, all of the grant money). If you find something (not just an XSS, but a presentation layer attack or even a usability issue), per usual with AntiSamy, you’ll get some props on the test page and a beer/energy drink at the next OWASP/Blackhat event.

4. I’ve also got a few more projects, including a tool that we’re probably going to release at OWASP NYC 2008 and an XSS “easy button” attack generator that is slightly less lame than it sounds. It’ll be a boon for us whitebox testers who don’t want to spend 5 minutes to think of how to bypass yet-another-annoying-but-always-beatable blacklist. This is how I think about it: XSS fuzzing is like having a huge NOP sled or playing pool with slop: it will probably work, but it won’t be very elegant.

=]

The OWASP AntiSamy Project version 1.2 is now available at its home in Google Code. The highlights of the upgrade from 1.1.1:

  • Internationalization of error messages. Japanese and German almost made the release, but for starters we’ve got the following:
    • English
    • Russian (Sergei Droganov)
    • Italian (Jerry Hoff)
    • Portuguese (Michael Coates)
    • Chinese (Weilin Zhong)
  • A number of bug fixes
  • A number of security issues fixed (reported and self-discovered – some diffs can lead you to the unreported ones =])
  • Added a Policy.getInstance() method that takes an InputStream
  • Added a constructor for the main AntiSamy class that takes a Policy object for repeated use
  • Added a new policy directive to prevent output formatting
  • Added a test suite for regression testing
  • Cleared up the “standalone” issue; the antisamy-bin-1.2.jar no longer contains any supporting libraries to avoid classpath hell
  • We have an antisamy-requried-libs-1.2.zip that contains all the required libraries for your convenience

We’re always looking for features, bugs and improvement ideas – so share your thoughts on the mailing list or on the issues page! Special thanks on this release to Sergei Droganov who is going to provide some official ColdFusion support for AntiSamy in the future, and also to J. Irving who did some valuable testing and is going to become a regular contributer.

Til next version!

The first thing you have to do is go read the whitepaper (or watch the movie) we just put together on some research I did into bypassing authentication and authorization mechanisms with HTTP verb tampering.

It’s only been out for about 2 hours and we’ve already got a few thousand hits. Pretty cool! Ok, assuming you’re up to speed, let’s talk about some of aspects of it we couldn’t fit into the paper.

How I Found It

I was teaching J2EE developers how to write secure code on the road down south, and in my breaks and lunch I was looking at Tomcat 6.x source code for, um, for fun. After finding a handful of other vulnerabilities, I saw this snippet:

protected void doHead(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException
 {
 NoBodyResponse response = new NoBodyResponse(resp);
 doGet(req, response);
 response.setContentLength();
 }

There’s half of the whole thing in a nutshell. HEAD is a silent backdoor to GET in all the web servers. The fact that you can specify JEFF/BBQ/VAJAJAY as your verb and get forwarded to GET handlers in some situations is the second half, and that hilarity we only discovered after the fact.

Blackbox Testing

When I was bouncing the concept off JG the first thing he tried to figure out was how one could detect a bypassable VBAAC mechanism from a blackbox perspective. He said timing, which is right. Send in a GET request, a HEAD request and a JEFF request and compare the timing results. It’s almost certain that if the attack worked with the HEAD or JEFF request, then it would take longer to complete those requests when compared to the GET (which is ostensibly protected). I think this is right, but there might be an easier, less noisy way.

If you make a request for a protected resource, you probably get a default or slightly customized 403 error page delivered by the web or application server. The chances are the response will be standard and have standard header values. However, the HEAD request, if it is successful, will return the real header values of the identical GET request. If that GET was sensitive, it’s headers are probably going to be different regarding content-type, caching, etc.

Stupidity

This is a stupid, stupid, stupid vulnerability to find in 2008. It’s almost criminally negligent for the vendors to put out mechanisms that are so prone to misuse – and it’s negligent that it took us this long to find it! But who knows, maybe the “bad guys” have known for a while.

Credits

  • Jeff Williams, who should have his name on the paper as much as mine at this point, but refuses credit.
  • Jim Manico for setting up some testing environments in a hurry.
  • Jeremiah Grossman, who, for having as recognizable a name as any in security, is always happy to hear ideas from other people.
  • Arian Evans, who has been flirting with this subject for a few years and is totally an 8.5+ on Hot or Not.
  • pdp, who after talking with him in Belgium said that he did something similar to bypass some security in one of his various router hacking sessions (prior art).
  • Everyone else I’ve been talking to and trying to get feedback from over the last few weeks – thanks for keeping it under wraps, although, as you can see from the comments of my last post, the information did make it outside my circle of trust. But for the security community, keeping something a secret for a few weeks is quite an accomplishment!

I just got back from Ghent, Belgium where I presented my research into next generation XSS worms. I hope people don’t take too much FUD from the talk- it’s only meant to show a few things, most notably how I (presume to have) solved the problem of decentralized, reliable, and unpoisonable command and control. Queue up the paper while you read the wrap up!

Personal Highlights

  • Seeing the eyes of the students in my RIA class open up real wide when I describe attack techniques like JavaScript hijacking and DNS rebinding
  • Accidentally getting drunk on 4 Belgian beers (the local beer Duvel [which is Flemish for 'Devil'] has 9% alcohol)
  • Purposely getting drunk on all kinds of beers the next night
  • Meeting Sebastien Deleersnyder and Paolo Coimbra of OWASP for the first time
  • Taking $20 from a sucker who actually bet on Chelsea to beat Man U (Mark Curphey)
  • Seeing the re-engineering Dinis Cruz has done on Ounce to make it scriptable by power users (though it looks like it needs an upgrade to its pre-1990 monochrome UI)
  • Spending time with some of the premier hackers that choose to live in the public eye (pdp, .mario of gnucitizen, who both coincidentally (or not?) have herpes)

Best Talks

Ignoring all the Aspect Security employee talks I can easily pick my top 5:

  1. Gary McGraw‘s exploiting online games was hilarious. Because I was already a giant gaming nerd, I was familiar with most of the techniques discussed, but his presentation was absolutely great. His second talk was also good, but it was dangerous for us consultants in the crowd as we had to keep dodging all the names he was dropping!
  2. Mark Curphey‘s not-easily-summarizable-but-still-very-good talk.
  3. Thomas Roessler‘s explanation of HTML5 security (which you can be sure I’ll be assessing quite soon).
  4. Dinis Cruz‘s abnormally caffeinated self talk about OWASP and the future – you can’t help but be energized to help OWASP more after listening to this guy for more than 5 seconds.
  5. Mario Heidrich‘s (.mario on slackers) dissection of PHPIDS – a great tool which needs a Java version ASAP. I’m entirely in love with the Centrifuge idea. I’ll be honest I never wanted to ask the community if they could fit an XSS into less than 23 characters in fear that there was an obvious one I couldn’t think of.

Out of the refereed papers published at the conference, I like fukami/Ben’s (and my own, of course). It’s not earth shattering, but it’s clever and another example of how undocumented/not-well-known features are often the sources of hilarious issues. I imagine the Flash VM should mark anything past the end-of-function marker (a 16-bit length null byte) non-executable address space, or perhaps more easily it could rip out these malicious islands of code when the SWF file is loaded into memory. I’m really sorry I missed that talk, but I couldn’t let my co-worker Jason Li present on my OWASP AntiSamy project without at least being in the room!

The rest of the refereed papers seemed like solutions to problems already solved in easier ways. Others just have crazy base assertions: “most existing approaches [for input validation] are based on Tainted Mode…” – huh?

Great conference, great people, great city, etc. pdp is going to mix all the pictures up into some whizbang movie and submit it to Cannes, I think. So keep an eye out for that on gnucitizen and House of Hackers!