Date: Thu, 13 Dec 2007 08:55:06 -0500
From: "Jay" <jay.tomas@...osecguru.com>
To: <fdiggle@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: on xss and its technical merit

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/

Powered by blists - more mailing lists