Message-ID: <a8fe69350712130736k61d40ba4q482d0ccda2943863@mail.gmail.com>
Date: Thu, 13 Dec 2007 09:36:23 -0600
From: "Fredrick Diggle" <fdiggle@...il.com>
To: Jay <jay.tomas@...osecguru.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: on xss and its technical merit

Once again you completely fail at reading comprehension. Let me help.

1. "Saying XSS isn't a vulnerability is like like saying a binary that has a
buffer overflow isn't vulnerable."
  Wrong! An application coded in a way that allows a user to write data past
the end of the memory allocated for that data contains a flaw. An
application which outputs arbitrary user input does not contain a flaw. The
intended purpose was to output the user input verbatim and that is exactly
what the code does. If this functionality allows an attacker to in some way
gain something useful then the vulnerability exists in the component which
allowed this. I think that I covered the possibilities and their associated
components in my initial mail.

2. "XSS needs javascript , binary needs its own malcode as well."
  Blatantly incorrect! XSS does not require javascript, it requires the
browser to interpret input rather than simply display it (this generally
means certain input is parsed and interpreted as a scripting language
(javascript is ONE scripting language and therefore NOT a requirement)).
Also what the heck is malcode? If you are implying that to exploit an
application which has been compiled into bytecode which can be directly
interpreted by the target architecture that I must introduce my own bytecode
into memory and force the processor to execute it then you are sorely
mistaken. It would depend greatly on the type of vulnerability, the context
in which the code is running, and the attackers creativity. Also generally
people use the word shellcode but that is just semantics.

 3. "Every vulnerability needs a medium to be exploited."
  I guess if by medium you mean the ability to perceive and possibly (but
not necessarily) interact with the system in question. If code has a bug
which unintentionally sends users passwords to FD on the 3rd of every month
I suppose that wouldn't be a vulnerability by your definition?

4. "Naysayers of XSS want some elegant exciting actions. Its not."
  Did I ever ask for elegance? I asked what the inherent vulnerability in
redisplaying user input is.

5. "Its a case of not sanitizing input that allows arbitrary code to be
executed."
  arbitrary code? really?

6. "Simple things like umm secure coding, url scan, mod_security, noscript
could combat this easily."
  I reference my initial suggestion that someone get busy building some
horribly complex way to make function pointers impossible to overwrite.
There is a lot of money to be made.

7. "Its like someone walking past a car and seeing a million dollars sitting
in the front seat. Thief opens unlocked door and takes money. Now a more
elegant way would be to manipulate the chemical composition of the glass
back to a gaseous form and reaching through. Either way the loot is gone."
  No. I would agree that both of those examples are exploitation. I disagree
that either of them has anything to do with XSS however. In this situation
XSS would be the equivalent of following the owner to the bank where he
deposits it, dressing up as him and trying to get the bank to release his
money to you. The vulnerability would not be your ability to dress up as him
but the bank's stupidity in buying it.

8. "I really dont understand why some in this community are so quick to say
this is no find, this isnt new, this is <insert blah>. I guess it makes them
feel intelluctually superior to tear down the ideas of others whether they
deserve it or not. In some cases they do."
  Like you, now?

9. "Are members of this community so starved for their own self worth that
they strive to squash the ideas of others instinctively? Would make for a
interesting study."
  Perhaps you should pursue this as security apparently isn't your niche :>

10. "Jay "><script>alert('YAY!')</script>""
  Are you the guy that has been releasing all that "exploit code" to
milw0rm? please stop you are clogging the pipes.

YAY!


On Dec 13, 2007 7:55 AM, Jay <jay.tomas@...osecguru.com> wrote:

> Saying XSS isn't a vulnerability is like like saying a binary that has a
> buffer overflow isn't vulnerable. XSS needs javascript , binary needs its
> own malcode as well.
>
> Every vulnerability needs a medium to be exploited.
>
> Naysayers of XSS want some elegant exciting actions. Its not. Its a case
> of not sanitizing input that allows arbitrary code to be executed. Simple
> things like umm secure coding, url scan, mod_security, noscript could combat
> this easily.
>
> Its like someone walking past a car and seeing a million dollars sitting
> in the front seat. Thief opens unlocked door and takes money. Now a more
> elegant way would be to manipulate the chemical composition of the glass
> back to a gaseous form and reaching through. Either way the loot is gone.
>
> I really dont understand why some in this community are so quick to say
> this is no find, this isnt new, this is <insert blah>. I guess it makes them
> feel intelluctually superior to tear down the ideas of others whether they
> deserve it or not. In some cases they do. Are members of this community so
> starved for their own self worth that they strive to squash the ideas of
> others instinctively? Would make for a interesting study.
>
> Jay "><script>alert('YAY!')</script>
>
> ----- Original Message -----
> From: Fredrick Diggle [mailto:fdiggle@...il.com]
> To: jay.tomas@...osecguru.com
> Cc: full-disclosure@...ts.grok.org.uk
> Sent: Wed, 12 Dec 2007 13:17:18 -0600
> Subject: Re: [Full-disclosure] on xss and its technical merit
>
> Thank you info sec guru for your glowing review. Did you even read my
> post?
> I think I explained quite succinctly why XSS is not a vulnerability. Do
> you
> have some argument with what I posted or are you going to stick with
> criticizing my tone? You win oh guru of the info sec industry thing.
>
> <3 fredrick
>
> YAY!
>
> On Dec 12, 2007 12:57 PM, Jay <jay.tomas@...osecguru.com> wrote:
>
> > Its amazing the last 2 posters even have to time to read FD. With all
> the
> > super important super secret projects they must be working. They preface
> > everything with Im not going to put much thought into this then proceed
> to
> > vomit a bunch of useless rhertoic throwing in how trivial it is and how
> much
> > experience they have beating up 10 year olds or something.
> >
> > I actually think this thread should die as 1 side of the house believes
> > XSS and XSRF as viable attack vectors. The other side thinks its
> rubbish.
> >
> > So let it die and then all the folks who are so bored <yawn> with XSS
> and
> > CSRF can post their remarkable works and amaze us all.
> >
> > Jay
> >
> >
> > ----- Original Message -----
> > From: Fredrick Diggle [mailto:fdiggle@...il.com]
> > To: full-disclosure@...ts.grok.org.uk
> > Sent: Wed, 12 Dec 2007 12:21:14 -0600
> > Subject: Re: [Full-disclosure] on xss and its technical merit
> >
> > What no one seems to realize is that XSS by its very nature is not a
> > vulnerability. It is a perfectly valid mechanism to aid in exploitation
> > but
> > can anyone cite me an example where xss in and of itself accomplishes
> > anything? I can think of pretty much 3 examples of XSS (granted without
> > giving it much thought because lets face it it isn't worth much thought)
> >
> > 1. you are taking something from a user which is accessible from the
> > scripting language context of their browser.
> >  In this case the vulnerability is not XSS the vulnerability is either
> > that
> > you (or the web browser) are storing something valuable in an insecure
> > way.
> > The most obvious example of this is something like session cookies which
> > if
> > your auth/session management is implemented in a secure way won't matter
> a
> > bit. It follows that the vulnerability is not XSS but instead that some
> > developer stored something valuable in a stupid way. All of the retards
> on
> > the list will no doubt ask me for a secure session management schema
>  but
> > I
> > am a firm believer that sharing  is communism so screw you.
> >
> > 2. You are forcing the users browser to make a request and complete some
> > task within the context of the application.
> >  In this case again the vulnerability is not XSS but instead that the
> > application allows users to do important things without verifying who
> they
> > are. this is "request forgery" not xss, xss is only the mechanism by
> which
> > the exploit is carried out. so again xss is not a vulnerability.
> >
> > 3. You are doing some other funkiness through the scripting language
> (all
> > that crap about internal network scanning comes to mind)
> >  AGAIN this is not a vulnerability. If it is possible to do this crap
> > through xss then it is also possible through any website the user
> visits.
> > That means that if this crap is doable then you should report it to the
> > guys
> > who develop the scripting language backend and not some guy who doesn't
> > sanitize things that he outputs. so once more the vulnerability is NOT
> xss
> > it is an issue with the scripting language.
> >
> > The only other case that you could make for this is ui defacement I
> guess
> > but in that case the vuln is not "xss" but that the developer didn't
> > properly separate user generated content from backend content to make it
> > clear that "the content in these areas does not express the views of the
> > site" blah blah blah legal mumbo jumbo.
> >
> > XSS is however a perfectly viable mechanism to aid in exploitation. For
> > example lets say there is a command exec bug within an administrative
> > interface of some app. You aren't able to exploit directly so you USE
> xss
> > TO
> > exploit indirectly.
> >
> > Saying that xss is a vulnerability is like saying that having a function
> > pointer stored in memory is a vulnerability. Sure I can use it to take
> > over
> > your box is I can find a way to overwrite it but try implementing
> anything
> > without it.
> >
> > I honestly kind of like where that would go though so lets take that to
> > its
> > logical conclusion. Everyone can get all upset every time they find a
> app
> > that uses an object and then someone can get rich off of a method to
> waste
> > memory by putting canaries around ever function pointer. It'll be fun
> and
> > I'll never have to worry about finding a job.
> >
> > YAY!
> >
> >
> >
> > ========= Begin Drivel =========
> >
> > I would say that XSS or CSRF is a means to an end. Its not that you can
> > XSS
> > is what you do with once you find it. Its not a sexy beast that you can
> > blog
> > about but it an attack vector none the less.
> >
> > The simpler the attack the greater the success. So yeah it takes little
> > skill to find. It take equally little skill to securely code the app to
> > sanitize in the first place. If an app is vuln to XSS chances are the
> rest
> > of the app is crap anyways...
> >
> > Jay
> >
> > ----- Original Message -----
> > From: Byron Sonne [mailto:blsonne_at_rogers.com]
> > To: coderman_at_gmail.com,full-disclosure_at_lists.grok.org.uk
> > Sent: Wed, 12 Dec 2007 09:48:07 -0500
> > Subject: Re: [Full-disclosure] on xss and its technical merit
> >
> > coderman wrote:
> > *> so perhaps "xss should be discussed much less" is the only *
> > *> concrete thing we all agree on? *
> >
> > FTW
> >
> > It's pretty obvious that finding XSS has a low entrance barrier; this
> > explains its popularity. It's just not very impressive. At the same
> > time, if finding an xss gets some kid interested in security, then I
> > suppose it can't be all bad.
> >
> > In any case, wikipedia has something interesting on this, I never
> > thought about how to categorize them, but then again, I usually start
> > vomiting from boredom at the mere site of the word 'xss' in a subject
> > line.
> >
> > *>From http://en.wikipedia.org/wiki/Xss, take it as you will: *
> >
> > Type 0
> >
> > This form of XSS vulnerability has been referred to as DOM-based or
> > Local cross-site scripting, and while it is not new by any means, a
> > recent paper (DOM-Based cross-site scripting) does a good job of
> > defining its characteristics. With Type 0 cross-site scripting
> > vulnerabilities, the problem exists within a page's client-side script
> > itself.
> >
> > Type 1
> >
> > This kind of cross-site scripting hole is also referred to as a
> > non-persistent or reflected vulnerability, and is by far the most common
> > type. These holes show up when data provided by a web client is used
> > immediately by server-side scripts to generate a page of results for
> > that user. If unvalidated user-supplied data is included in the
> > resulting page without HTML encoding, this will allow client-side code
> > to be injected into the dynamic page
> >
> > Type 2
> >
> > This type of XSS vulnerability is also referred to as a stored or
> > persistent or second-order vulnerability, and it allows the most
> > powerful kinds of attacks. It is frequently referred to as HTML
> > injection. A type 2 XSS vulnerability exists when data provided to a web
> > application by a user is first stored persistently on the server (in a
> > database, filesystem, or other location), and later displayed to users
> > in a web page without being encoded using HTML entities.
> > Cheers,
> > B
> >
> >
>
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists