[WEB SECURITY] websecurity Digest, Vol 38, Issue 8

rishabh gupta ims2012074 at gmail.com
Tue Feb 4 17:06:04 EST 2014


can any body tell that
how to exploit XSS when method="post"



On Tue, Feb 4, 2014 at 10:29 AM, <websecurity-request at lists.webappsec.org>wrote:

> Send websecurity mailing list submissions to
>         websecurity at 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 at lists.webappsec.org
>
> You can reach the person managing the list at
>         websecurity-owner at 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 at cigital.com>
> To: "websecurity at lists.webappsec.org"
>         <websecurity at lists.webappsec.org>
> Subject: [WEB SECURITY]  Idea: different approach to password hashing
> Message-ID: <D8D4FB3A-7F08-4C96-A19B-E3CD0B4D062F at 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.
>
> > 1) 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]
> > 3) 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
>
> * (1) - http://www.youtube.com/watch?v=8mbkWMEMB9s
>
> * (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/
>
> * (4) - https://github.com/symeapp/srp-client
>
> * (5) - http://goo.gl/Spvzs
>
> * (6) - Quoted from Paul?s mail:
>
> >> 1) 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.
> >> 2) 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 at cs.ucsb.edu>
> To: Jason Wood <jason at jwnetworkconsulting.com>
> Cc: "websecurity at lists.webappsec.org"
>         <websecurity at lists.webappsec.org>
> Subject: Re: [WEB SECURITY] Any Vulnerable Web-Services available
>         online for      testing?
> Message-ID:
>         <CAFSTW4U_Jk+F6RE-Vdn4ULPan3cQbCJtrvh1uf8BUGN==
> eLOMA at 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 at jwnetworkconsulting.com>wrote:
>
> > 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 at 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
> > >
> > > websecurity at lists.webappsec.org
> > >
> >
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
> >
> > _______________________________________________
> > 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
> >
> > websecurity at lists.webappsec.org
> >
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20140203/556bac1a/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> websecurity mailing list
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>
>
> ------------------------------
>
> End of websecurity Digest, Vol 38, Issue 8
> ******************************************
>



-- 
*Rishabh Gupta*
*MS-CLIS*
*IIIT- Allahabad*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20140205/79e3e09e/attachment.html>


More information about the websecurity mailing list