Message-ID: <a8fe69350712130858w48910ab0lae5a95273f1bb462@mail.gmail.com>
Date: Thu, 13 Dec 2007 10:58:16 -0600
From: "Fredrick Diggle" <fdiggle@...il.com>
To: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: on xss and its technical merit

I can see how my explanation would make very little sense to someone with as
little technical ability as yourself. I feel badly as perhaps my antics have
threatened what you hope to one day turn into a career. Unfortunately I
think that you will find it difficult finding a job based solely on your
detailed technical knowledge of all things xss.

I have perused many careers on the monster dot com and after much perusal
have decided to stick with what I know.

To answer what I believe your question was intended to be I am currently
employed by the Sao Paolo Zoo, I work primarily with primates but have also
periodically been asked to brush the hippopatamus' teeth (a task which I do
not particularly enjoy as ).

You are rather stupid so don't be too hard on yourself for feeling that way.
I posted only one initial email on this topic and have merely responded to
other's attacks since then.

YAY!



On Dec 13, 2007 10:33 AM, pdp (architect) <pdp.gnucitizen@...glemail.com>
wrote:

> bravo :) this is the most senseless explanation I have ever seen, perhaps
> you should peruse a different career as well... I am not trying to be funny
> but I couldn't resist to write to you in person after seeing your email.
> Cheers and good luck.
>
> pdp
>
> P.S. btw, what do you do for a leaving? and btw, I feel stupid since it is
> more then obvious this conversation is made up and mainly between the same
> guy posting from different emails. so, please stop. it is getting really out
> of control and it is rather annoying,
>
> On Dec 13, 2007 3:36 PM, Fredrick Diggle <fdiggle@...il.com> wrote:
>
> > 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
> > > >
> > > >
> > >
> > >
> >
> > _______________________________________________
> > 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 http://www.hakiri.com

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