Re: [Full-disclosure] on xss and its technical merit



ok... so you are rejecting my well put arguments... no problem

1) how hard is it find xss in applications

How hard was to find stack overflows in 1990 or even before that? 'A'
x 100000000 or 'A' * 100000000 and then check the EIP for
0x41414141... great trick! I was still a kid when people were mass
exploiting everything that was under the sun and as you can see there
was some very successful worm outbreaks... today, hacking stacks and
heaps and all that comes with them is harder, yes... of course it is
harder. you are dealing with some 40 year old problem. People know
about it. People understand it.

XSS today is where buffer overflows were 10-15 year ago. Moreover, did
you missed when I said that 99% of all sites are vulnerable to XSS.
Given the percentage of available XSS vulnerabilities, what chance you
think you have finding one? simple math! of course it is easy. It is
easy for most of XSS issues. However, those that really matter are not
easy at all. DOM based XSS is a debug hell, mainly because every time
you want to do something you have to deal with the remote server. This
is not very ofline.

2) how hard it is to successfully exploit the vulnerability

now we are talking. it really depends on what you want to do. let's
say that you want to steal some cookies. ok lame. not very
interesting! but exploiting a XSS vulnerability is an art on its own.
check this out man:

myspace. we know samy right? ok, the guy needed to write a worm on a
live application without releasing it too early. so you think that
this is not a skill on itself. when did you performed agile code
execution of a life system. I doubt that anyone has ever done it.

if you want to do it right, then it is harder to get a successful XSS
attack. do you know why? cuz XSS involves a bit of strategy as well.
because it is an indirect type of attack. A single XSS attack
sometimes may involve several sub XSS each one of which call the next
one in an exponential manner. By the time you reach level 5 you head
is so screwed up that you need to start all over again because you
code breaks on 50 places. JavaScript in particular is not an easy
language. You may think that you know it but you don't know 90% of it.
When it comes to scoping you get into a mess of things. Have you ever
done XSS on GMail. Try it! See how far you will go. Unless you have
some solid understanding on AJAX debuging and some nifty tools that
can put back Google's mess into order, you have no chance. Today
software hackers relay on tools such as IDA Pro or Soft Ice, which is
discontinue but still. Check this out there are not tools like that
for XSS and in particular AJAX, therefore I have to start from zero.
Where is my JavaScript deobfiscator? I don't have one... I have to
write it myself. Where is my debugger. I am stuck with Firebug for
Firefox... Great! How about dynamic tracing, tracking, stepping and
all other things on a complete BlackBox application that you can only
see the incoming and outgoing requests. At least when you have a
binary you know what it is. You can do it offline and you have all of
the parts.

XSS can be very complicated. Don't be fulled by what people post on FD.

On Nov 4, 2007 8:42 PM, reepex <reepex@xxxxxxxxx> wrote:
you see you are arguing how useful xss can be for an attacker, but the point
of this argument is

1) how hard is it find xss in applications
2) how hard it is to successfully exploit the vulnerability

compared to other vulnerabilities xss is way down on the scale

i also believe this is what pdp wanted to argue as he believes xss is on the
same scale as other bugs following 1 and 2

On Nov 4, 2007 2:28 PM, < nexus@xxxxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



reepex wrote:
1) XSS isnt techincal no matter how its used
I totally disagree with you.. isn't technical for those who cannot
realize how much powerful can be a xss, especially if persistent.



2) people who use xss on pentests/real hacking/anything but phishing are
lame and only use it because they cannot write real exploits (non-web)
or
couldnt find any other web bugs (sql injection, cmd exec,file include,
whatever)
Imho the pentesting will move day by day closer to web applications
flaws testing, since the web applications are self written by webmasters
and more exposed to possible bugs. Concerning sql inj or rfi are not
more difficult to be discovered..



3) XSS does not have a place on this list or any other security list and
i
remember when the idea of making a seperate bugtraq for xss was proposed
and
i still think it should be done.
Dunno about that, even if i agree that all the xss flaws found should
not be reported here, they would be too much.



4) if you go into a pentest/audit and all you get out is xss then its a
failed pentest and the customer should get a refund.
I don't agree with this too for the same reasons as before.



5) publishing xss shows your weakness and that you dont have the ability
to
find actual bugs ( b/c xss isnt a vuln its crap )
Imho a xss is a vuln as much as the others, since if used smartly could
get quite dangerous.

Reading a report from zone-h i read that the most effective hacking
cause it's the xss.. i don't know if i shall agree with this, but
obviously it should make us think about it.

bye

/nexus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHLitaVVYXVqV+ctMRAkcEAKCLXroIu80OemE/m/voaN4iczrJigCfTH3Q
EJOb41+Eex4lFNy1AHJ9xhE=
=ICJh
-----END PGP SIGNATURE-----



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/




--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/