As one of the requirements of Turing is that on three occasions you present a lightning talk on a technical topic, I had put a lot of thought into potential topics. I knew I wanted to try something that was more of a demonstration in nature rather than just informative. After creating and presenting a demo of cross-site scripting that was successful for several of my own criteria, including audience interaction, I offer the lessons I learned on implementing your own technical demonstration.

Early on I had jokingly tweeted about wanting to use stock photography in a technical talk, since the general expectation in the infosec community is the ridiculous public perception of hackers, or at least or at least as portrayed by the media. A topic for another blog post would be how the image-driven format in technology-focused media outlets works well for gadget reporting, but lends to stereotypical presentations for more abstract science or IT topics.

Lesson 1: Use appropriate tools

While our module is currently focused around learning Rails to serve web apps, we started with Sinatra, a lighter weight framework than Rails with fewer “helpers” to get things done. So why did I choose to demonstrate XSS attacks on a website I built with Sinatra?

Simple. I had done research and learned that Rails already contains a lot of helper methods to validate, sanitize, and encode data. Because one of the larger points I was hoping my demonstration would drive home was that hacking code can lead to learning, I wanted a simpler tool, not something with built-in methods that might lead to a developer feeling "safe" or "complacent" about needing to understand the root problem. While these solutions proved simple, more complex demos will ultimately require numerous demos of the demo, so to speak. Don't let your lack of tool preparation distract or break your demo when it's almost always going to be the simplest piece to address.

Lesson 2: Control the interaction

I hoped that the audience would load up the URL I offered for my demo web app, but wasn't quite sure if they would engaged. I planned as if they would and created a script to quickly drop and reset my database should my classmates choose to try out their own XSS attacks on my server.

Indeed, by the second time I flipped back to the website from my slides, I was greeted by numerous pop-up alerts that had been embedded in my database. Amusingly I had lost my terminal screen in my maze of Mac mirrored screens and was only able to reset the database once, so pressed on with multiple alerts.

While in some ways this effect was entirely within the expectations for the talk, it did add a little to my inner chaos. Perhaps, also, I might argue that I should've dropped the database when I wasn't interacting directly with the website, potentially to keep my audience from getting too distracted.

Lesson 3: Balance demonstration with instruction

The flow of my presentation had three examples: a simple XSS mistake or accident, another demonstrating what a real attack might look like and be countered by, and then finally an attack from a plant in the audience that used more sophisticated misuse of HTML tags. This correspondingly let me engage the audience in a demonstration, but then provide context and instruction. The first example introduced the idea of XSS, that database rows can contain any data the user submits, even that with unintended effects when propagated to the view The second example allowed me to lead into introducing (OWASP)[http://www.owasp.org] as a resource and explaining potential attacks and defenses.

Finally, the last example let me pivot on my primary point that hacking teaches us about code. It let me prove in real-time that coding with an assumption of trust about a user blinds us, in this case, to how a simple image tag can be misused, rendering our intentions and perceptions meaningless.

Final score:

I got a lot of laughs for my final XSS demo(I embedded the school favorite Kazoo Kid remix in the page), and a lot of pleased feedback. If there's something you can teach even better by using a demo the audience can engage with, I suggest you take that extra time to drive the point home even better.