lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2007 12:21:14 -0600
From: "Fredrick Diggle" <fdiggle@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ