mailing list archives
Re: on xss and its technical merit
From: "pdp (architect)" <pdp.gnucitizen () googlemail com>
Date: Mon, 5 Nov 2007 08:00:19 +0000
On Nov 5, 2007 12:07 AM, reepex <reepex () gmail com> wrote:
On Nov 4, 2007 4:43 PM, pdp (architect) <pdp.gnucitizen () googlemail com>
lets say 10000 servers are running a vuln ftpd and another 10000 are
the same open source web app. Which would you rather have the explot
also which would be more practical to attack? assuming you have the same
system and a good exploit you could get all the 10000 ftpds, while the
on 10000 msg boards would require 10000 users to view the page you
well I will go for the 10000 ftpds in general. However, it really
depends on what I am doing. As I said, these FTPDs may give you access
to the system but probably not access to the data which to me is a lot
more interesting. In this case 10000 XSS sounds a lot more valuable.
Which 'data' are you talking about? the servers info (in this case the
server running the ftpd daemon) or the data/personal machines of the users
of the ftpd?
I would rather have control of the ftpd then simply backdoor the daemon to
work on indivivual users, just as I would rather control on the web server
itself rather than any pre-exsiting xss bugs.
again the whole point is that you do not need xss ever if you have client
side exploits or access to the server itself.
well of course. I would like to control the server as well but
sometimes this is simply not possible or feasible in anyway. remember,
we are not talking about whether XSS is suitable for all kinds of
attacks. We are talking about the technical merits of XSS.
Keep in mind that many client side exploits are XSS for the browser,
as I've already mentioned.
Well for example, the FTP and the Web server both have to be in the
DMZ. However the Web server also needs to speak to the Application
Server. Compromising the FTP server does not give you anything apart
from a control over the FTP. You have no access to the data probably.
If you compromise the Web server, ok fair enough, this is more then
critical but again, how feasible is it .... I don't know?
There are XSS script kiddies as well Buffer Overflow script kiddies.
Just because you can find XSS does not mean that you've done something
amazing and extraordinary. It takes skills and a lot of effort to make
something out of it. But as I said before, open your mind. There are
endless potentials when it comes to XSS.
yes and i guess bad for you is that the only xss you really see posted (fd,
milw0rm, security focus) is people posting <script>alert('hi')</script>
BTW, it does look like an achievement when you find a XSS inside an
application that 1000 more people play with (look for similar bugs) on
a daily basis. XSS in some small apps are stupid. XSS on the default
Google Search Interface is as valuable as remotely exploitable buffer
overflow for Linux 2.6.x kernels (distribution independent).
Again i think if you are attacking the users of a site instead of the site
itself this is acceptable but your attacks could become much more hazardous
if you owned the google server itself (maybe a stretch in the case of
google) and added whatever code you wanted to the front page/ or embedded
your nice browser exploit in the page. either of these ways seems much more
valuable then xssing people who are signed in and visited your page.
ok... but what are the chances of hacking into the Google Web server?
Close to nothing, especially when you are dealing with a closed source
software. One of the way to own the server is to trick the admins into
visiting a page which will steal their authenticated sessions or
infect their browsers. IMHO, this one makes a lot more sense and
sounds a lot more feasible.
One of the things that I like about XSS in general is that in order to
exploit a vulnerability you really have to plan every stage of the
attack. Setting traps and making Google's and Yahoo's systems play
your game is an extraordinary experience and a great eye opener.
also (unless im missing) something in another email you mentioned like 15
different kinds of xss which I am sure are all interesting in their own way
but the most you can get out of them is simple browser games.
As I said, this is not the case. Chrome based XSS, we covered a few in
the XSS book I believe, are very different, for example. In some case
the XSS vector resides inside a Sandbox. Now you need to find a way to
get out of the sandbox and and as such reaching again the browser
internals. Flash based XSS can lead to a lot of damages especially
when combined with something like desktop AIR applications which are
granted with full control over the client machine. AIR also can run
HTML pages which also can lead to evalated privilages and as such
access to the system. What about desktop and mobile Widgets?
XSS, like Buffer Overflow attacks, can be very customized. In terms of
Flash, for example, you need to know how the Flash file is structured.
You have to decompile it if you can. Simple decompiler like Flair does
not work for Flex. You need to know about what APIs the developers
have embed and how to use them in order to exploit the victim. XSS in
flash is also fun. You might not be able to modify the file system but
you might be able to steal Audio and Video input from the victim. This
is what I call a super bug!
pdp (architect) | petko d. petkov
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
Re: on xss and its technical merit pdp (architect) (Nov 04)
Re: on xss and its technical merit nate . mcfeters (Nov 04)
Re: on xss and its technical merit Eric Rachner (Nov 05)
- Re: on xss and its technical merit, (continued)