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) <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > To: [EMAIL PROTECTED] > > > Cc: full-disclosure@lists.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 < [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: full-disclosure@lists.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
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/