[Owasp-delhi] New Attack on Webapp Session Data

Sripathi Krishnan sripathi.krishnan at gmail.com
Fri Jun 18 14:37:22 EDT 2010


>
> re. I think this must become a standard part of a vulnerability assessment

Its a clever way of attacking, but IMHO it is applicable under a very small
number of scenarios. In order for a site to be vulnerable, it must meet the
following requirements -

   1. It should store critical data on the client side in an encrypted
   manner, using a particular encryption mode i.e. CBC
   2. It should 'leak' error messages back to the client.
   3. For a single decryption attack to successful, 128*size of message
   calls to the server need to go unnoticed. Each of those calls will lead to
   an exception on the server - and so all of them going unnoticed is a bit
   difficult.
   4. For CAPTCHAs - the server needs to store the solution on the client
   side (in an encrypted manner) - again not that common.
   5. For Viewstate - the site needs to enable client side storage - again a
   non-default setting.

So, rather than testing for this in VA, we should rather enforce your second
comment "Don't store confidential data client side"

re. And brings us to a likely design guideline: don't keep any confidential
> data on the client side. How feasible/realistic is that?

Absolutely feasible and practical. Any critical information must stay on the
server. It should not be sent to the client, encryption or no encryption.

The usual reason for storing information on the client is performance; if
the server is stateless, there is a huge performance improvement. But there
are ways to achieve a stateless architecture *and* still maintain critical
information on the server - it just needs a little bit more work. In other
words, Scalability and Performance need not be orthogonal to Security.


--Sri


On 18 June 2010 19:13, <marcandre.laverdiere at tcs.com> wrote:

> Two researchers have released a tool which can be used to crack web
> server-encrypted session data contained in cookies and parameters hidden in
> HTML pages. The method used by Juliano Rizzo and Thai Duong's Padding
> Oracle Exploitation Tool <http://netifera.com/research/poet/> (Poet) can
> also be used to crack CAPTCHAS.
>
> Full article:
> http://www.h-online.com/security/news/item/Tool-for-cracking-encrypted-session-data-1017626.html
>
> The article contains links to the tool and to the paper. I think this MUST
> become a standard part of a vulnerability assessment.
> And brings us to a likely design guideline: don't keep any confidential
> data on the client side. How feasible/realistic is that?
>
> Marc-Andre Laverdiere-Papineau
> Software Security Researcher
> Innovation Labs
> Tata Consultancy Services
> Plot No 1, Survey No. 64/2, Software Units Layout
> Serilingampally Mandal, Madhapur
> Hyderabad - 500034,Andhra Pradesh
> India
> Ph:- +91 40 66673529
> Mailto: marcandre.laverdiere at tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Outsourcing
> ____________________________________________
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
>
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
>
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
> _______________________________________________
> Owasp-delhi mailing list
> Owasp-delhi at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-delhi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20100619/64821503/attachment-0001.html 


More information about the Owasp-delhi mailing list