Re: [WEB SECURITY] websecurity Digest, Vol 38, Issue 8
can any body tell that
how to exploit XSS when method="post"
On Tue, Feb 4, 2014 at 10:29 AM, websecurity-request@lists.webappsec.orgwrote:
Send websecurity mailing list submissions to
websecurity@lists.webappsec.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
or, via email, send a message with subject or body 'help' to
websecurity-request@lists.webappsec.org
You can reach the person managing the list at
websecurity-owner@lists.webappsec.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of websecurity digest..."
Today's Topics:
1. Idea: different approach to password hashing (John Steven)
2. Re: Any Vulnerable Web-Services available online for
testing? (Alexandros Kapravelos)
Message: 1
Date: Mon, 3 Feb 2014 15:04:04 -0500
From: John Steven jsteven@cigital.com
To: "websecurity@lists.webappsec.org"
websecurity@lists.webappsec.org
Subject: [WEB SECURITY] Idea: different approach to password hashing
Message-ID: D8D4FB3A-7F08-4C96-A19B-E3CD0B4D062F@cigital.com
Content-Type: text/plain; charset="Windows-1252"
Jim,
Stalwart AppSec educator?thanks for the nod. Paul,
Your problem characterization is thoughtful, considering different forms
of attack and the various surfaces upon which they can occur. You?ve even
re-considered the (informal) threat model applying your proposed control
alternatives. Well-played. Since you?ve taken the problem one or two steps
past where most have, it?s worth following up beyond what I?ve posted
publicly.
[Adaptive One-way Functions]
I would not oppose an approach predicated solely on an adaptive one-way
function. Research load characteristics and tune for effective results.
- Throw a lot of hardware at it. Lots.
You could throw iron at the problem (*1) using the standard adaptive
one-way function formulations. Distributing the work from server to client
is a natural response, yes, but not one I?ve seen in practice very often.
You?re correct that doing so ?inherits? another problem: continued support
for a user-specific salt (*2). You rightly indicate that it also inherits
the problem of obscured credential replay by MitM.
In essence, this design leads down a slippery slope to a home-rolled
challenges/response (C/R) protocol?something to be avoided. We see Existing
C/R schemes, such as OAuth, protect plaintext credentials against MitM
theft. Bearer tokens (application/end-point ?passwords') used by these
schemes can help designers limit the amount of CPU-intensive server-based
credential verification. When designing systems, prefer these to
home-rolled schemes; their limitations are well-understood (*3).
As a user, you?re probably familiar with organizations (like social media
sites) that rely on PBKDF2 or bcrypt with high work factors to protect
databased credentials but also use tokens to reduce the amount of
bcrypt-driven password verification that occurs. If you?ve already forsaken
OAuth, explore other fancy C/R protocols with Javascript support like SRP
(*4).
[Keyed Macs]
- Use a [server-side] HMAC, ? [and do it well]
I would suggest this approach and advise carefully solving knock-on
problems.
As stated, I?m a fan of this approach, principally because it is both
simple and because it forces the attacker into asymmetric (disadvantaged)
warfare with the defender (*5). That is, the defender is subject to only
nominal password verification effort whereas the attacker must pay to brute
force (or steal) the secret key prior to enjoying the same ease of
verification.
As Jim hedged, one inherits the ?key protection? problem with this scheme.
Detractors rightly indicate organizations can easily screw key protection
up. Within my own experience, it?s been easy to design solutions because
the organizations with which I work enjoy benefits like a) separate of
duties involved in generating, handling, and using key material, b)
reasonable application server configuration, and c) broadly deployed HSM
support. Though, even without fancy hardware, organizations often have
existing regimes for production secret protection.
[Paul?s Proposed Design]
Paul, the approach you proposed (*6), as I understand it, may be
represented as follows:
(0) Client C: uname ?> Server S
(1) S: SHA2(server_salt + uname) ?> C
(2) C: bcrypt(salt, pw) ?> S
(3) S: verify(SHA2(<bcrypt result>))
My ?brief? analysis of this approach places it (surprisingly?) in an
equivalence class with bcrypt itself, once known to an attacker. For those
interested in why, contact me offline.
This scheme does provide some additional protections to credentials in
flight (during step (2)). if designers desire this effect, I?d recommend
revisiting the C/R section and selecting from that family of approach.
-jOHN
John Steven
iCTO, Cigital
+1,703-727-4034 | @M1splacedsoul
https://google.com/+JohnStevenCigital
-
(2) - Some ascribe anti-reversing properties to salts beyond obscuring
duplicate plaintext and raising space/time difficulty on targeted
individual attack. This results in complaint about salts made public. -
(3) - http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
-
(5) - http://goo.gl/Spvzs
-
(6) - Quoted from Paul?s mail:
- The salt can be generated as hash(server_salt + user_name) - where
server_salt is a random number that is unique to the server, public, and
the same for all users. The resulting hash appears to have the required
properties of a salt.
- The server should do a single, fast, hash operation on the hash it
receives. As an example: the server stores SHA-256(bcrypt(salt, password)).
The client sends bcrypt(password) then the server applies SHA-256 and
checks the hash.
- ():
John Stevens
...John Steven?s...
Message: 2
Date: Mon, 3 Feb 2014 12:00:06 -0800
From: Alexandros Kapravelos kapravel@cs.ucsb.edu
To: Jason Wood jason@jwnetworkconsulting.com
Cc: "websecurity@lists.webappsec.org"
websecurity@lists.webappsec.org
Subject: Re: [WEB SECURITY] Any Vulnerable Web-Services available
online for testing?
Message-ID:
<CAFSTW4U_Jk+F6RE-Vdn4ULPan3cQbCJtrvh1uf8BUGN==
eLOMA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
There is also WackoPicko
https://github.com/adamdoupe/WackoPicko
Cheers,
Alexandros Kapravelos
PhD Student in Computer Science
University of California, Santa Barbara
On Sat, Feb 1, 2014 at 10:39 AM, Jason Wood
jason@jwnetworkconsulting.comwrote:
Damn Vulnerable Web Services has been released by Secure Ideas.
http://dvws.professionallyevil.com
Jason
On Feb 1, 2014, at 10:07 AM, Pankaj Upadhyay mr.p.upadhyay@gmail.com
wrote:
Hi All,
As someone has compiled a list of all intentionally vulnerable web
applications, do we have any such list for web services?
I need some vulnerable web-services for my learning. Thought if any of
you know any such available web-services?
--
Thanks,
Pankaj Upadhyay
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
I assume we are talking about a reflected XSS vuln, correct?
Most of the time, you can submit what was originally a POST request as a
GET request. The easiest way is to use an interception proxy. In Burp
Repeater, you can do this with a simple right click: ("Change request
Method"), but really all it involves is changing the HTTP VERB from POST to
GET, moving the paramters from the BODY to the URI, and removing the
Content-Length Header.
In your proxy, it will look like this:
Before:
POST /index.html HTTP/1.1
[Other headers]
Content-Length: 21
param1=abc¶m2=<xss here>
After:
GET /index.html?param1=abc¶m2=<xss here> HTTP/1.1
[Other headers]
But if you want to illustrate the danger of sending a hyperlink to someone
else, you just covert it to:
http://www.example.com/index.html?param1=abc¶m2=<xss here>
If reflected XSS, and the web server or the web application really does
only accept the vulnerable input in a POST request, your only hope left,
AFAIK, is to combine it with a CSRF.
Of course if it is a stored XSS, you should be able to submit it as a POST
without an issue.
Hope this helps,
Seth
On Tue, Feb 4, 2014 at 5:06 PM, rishabh gupta ims2012074@gmail.com wrote:
can any body tell that
how to exploit XSS when method="post"