Matthew Hughes – Ruby Aspirations and Infosec Inclinations

Siri. It’s a bit terrifying, isn’t it? Part HAL from 2001: A Space Oddessy; part Data from Star Trek: The Next Generation. If you’re cool enough to have an iPhone ( which I’m not, obviously), it allows you to sift through the lolcats, rickrolls and pornography of the internet to find whatever we want. Consider it to be part Betty Suarez from Ugly Betty, meticulously scheduling your life and part Eye of Sauron, finding and retrieving information like an obedient Labrador bringing in the paper.

The problem with Siri is that it has the propensity to say some rather funny, often socially unacceptable things. Sort of like a drunk uncle at a wedding. From hurling profanities at random twelve year old boys, to telling you where to stash a corpse; It’s a never ending fountain of hilarity.

As it goes with these sort of things, various sites have sprung up allowing you to make your own (probably unfunny) fake Siri verbal exchange. The most popular of these is ifakesiri. The way they work is fairly simple:

• The user submits a short exchange between Siri and a fictional iPhone user to the web application.
• The web application then takes the input, formats it to appear as if it was on the Siri app on the iPhone.
• The user is then redirected to a page with the fake image rendered by the web application.
• The user can then share the image with his friends, choosing to hotlink the image, or redirect to the web application.

Now, what happens if you decide to put a little bit of Javascript in? Nothing special. Something like <script>alert(‘xss’);</script>, or something a bit more sophomoric…

I did, actually.

What we have here is what’s called in the business a ‘Cross Site Scripting’ vulnerability. Here, the web application has  taken an input without validating if the contents are safe or not.

Consider the web application to be like FedEx. Fedex doesn’t really validate the contents of your package, do they? If they did, they’d probably still throw it over your fence anyway, but that’s beside the point. Fedex takes your package (your input), and transports it to the recipient (reflects the input). It doesn’t verify if the CD you’re sending to your friend is the new Adele album or something good (see what I did there?).

And that therein is the problem. The application doesn’t prevent the user from whacking in some code, be it innocuous (like <script>alert(‘xss’);</script>) or something considerably more malevolent.

I’m going to finish on couple of points. Firstly, I informed the owner of the web application of the vulnerability six days before the post was published. More than enough time to fix the vulnerability. Secondly, all the above has been explained far more elegantly than myself by J4vv4d‘s very own mini-infosec cynic (redacted at the request of Reed Publications)  daughter.

Input validation