attack attacker aws backtrack book burp cloud conference cors csrf dradis embedded encoding exploit framework html5 injection javascript metasploit methodology model network node opinion payload pentest presentation python reporting review shellcode slides soap sql sqlmap web web service wondering XML XSS
  • home
  • whoami
  • links
  • blog
  • follow me
archives
  • July 2014
  • January 2014
  • November 2013
  • September 2013
  • June 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
« prev post next post »
Content-type does matter
May 26th
2012

First of all I must say that there are web applications which get output escaping right. I had a confrontation recently with one. I could store malicious attack strings in the database that were shown on the UI, still I couldn’t evade the output escaping even though I tried really hard. At the end I had to accept that the JavaScript generated UI was too good.

But it didn’t last long. During a sleepless night as my head span around of exploits and evil attack scenarios the IDEA came. The whole communication between the client and server was in JSON using XMLHttpRequest. My attack strings were still unescaped in the JSON response and the client side JavaScript did all the dirty work. That would have been still alright even though that it doesn’t comply with the security in-depth theorem. And here comes the BUT: in some responses the HTTP Content-type header was incorrectly set to text/HTML instead of the application/json and that is just great. It means that tha attacker only needs a URL that will return the malicious XSS string with the text/HTML content type and he could immediately start to send it to users.

I’m sure most of you have already figured out the trick but let me clearify it. When the browser sees the Content-type: text/HTML it will do anything to render the response as HTML. It will be so glad when it finds the little piece of <script> tag in the middle of the uninteresting JSON, that it will immediately render it hence the evil JavaScript gets executed. From this point it only depends on the JavaScript code whether the user will realise what happened or not. The moral of the story is that it doesn’t metter how good written your application is because if you make just one mistake that is just enought for the attackers.

To let you take something away from the story here are the mitigations that could have stopped this attack:

  • Validate and escape input before saving it in the database.
  • Set the Content-type header properly.
      • blogger
      • digg
      • facebook
      • linkedin
      • reddit
      • stumble
      • twitter
« prev post next post »

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>