HTTP Proxy for XSS Channels
Last week I was reading the brief of Black Hat Europe 2007 Kicking Down the Cross Domain Door (One XSS at a Time) speak. It seems a nice one and there is a very good idea in it, using a proxy for a XSS Proxy like XSS Shell or Beef.
Since I’m not quite sure that’s the intention of speakers but for sure they are going to present a very similar concept.
Let’s consider this attack scenario,
There is a XSS in a website, you exploited XSS vulnerability and gain the admin’s session, but admin folder is protected by IP restrictions or NTLM etc. Of course you able to got it through XSS Shell but the problem is you want to exploit it more. Let’s say you looking for an SQL Injection to do more.
Since you are a damn lazy attacker you want to use some web application scanner or any similar tool to attack the admin part of the website. Hypothetically you can use custom HTTP Proxy which can send request to XSS Shell and read responses from XSS Shell. In this way your local proxy will help you to run virtually any application which supports HTTP proxy against target over XSS’ ed admin session and attack the restricted part of the page succesfully.
Another example, may you want to exploit a blind sql injection in a IP restricted place. Generally it's quite impossible and crazy process to try to exploiting a blind sql injection manually, so you should automate it.
Simple Map of XSS Shell Proxy Attack Process
Attack Engine (nikto, webinspect, custom application, blind sql injection tool, etc.) >> Local XSS Shell Proxy (attacker desktop) >> Master - XSS Shell Admin (web server) >> XSS Shelled Victim (desktop) >> Victim Server (web server)
vice versa for response...
Update : Jikto
Another important update :
Jikto is about attacking other websites, which means you need to find a way to bypass same-origin policy, I have no idea how Jikto is able to do it yet. We need to wait for ShoomoCon to find out this answer.
News at CNet, Currently it doesn't make sense to me, injecting a piece of JS to client browser and able to do cross-domain requests (I assume we are not talking about a browser vulnerability - maybe they got some new nasty trick). Possibly I'm missing a point...