Date: Wed, 12 Dec 2007 13:17:18 -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

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