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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > To: [email protected] > 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/
