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 11:06:47 -0500
From: "Jay" <jay.tomas@...osecguru.com>
To: <blsonne@...ers.com>, <coderman@...il.com>,
	<full-disclosure@...ts.grok.org.uk>
Subject: Re: on xss and its technical merit

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@...ers.com]
To: coderman@...il.com,full-disclosure@...ts.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/


_______________________________________________
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