[Owasp-leaders] HTML5 local storage..

Dave Wichers dave.wichers at owasp.org
Thu Dec 5 21:12:24 UTC 2013


Given the pervasiveness of XSS flaws in apps, I would strongly advise against this. It would just be too easy for a dev team to introduce an XSS flaw and then completely blow away the security of whatever is stored in local storage. This doesn’t increase the likelihood of an XSS flaw (which is already really high), but significantly increases the impact.

 

-Dave

 

From: owasp-leaders-bounces at lists.owasp.org [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Christian Papathanasiou
Sent: Thursday, December 05, 2013 5:31 AM
To: Eoin
Cc: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] HTML5 local storage..

 

No, simply as a alternative to transmitting cookies over the wire and leveraging the same origin policy aspect of local storage to protect against CSRF - two birds one stone :-)

 

Logout will be as per usual 30 minute expiry etc

Sent from my iPhone


On 5 Dec 2013, at 10:25, Eoin <eoin.keary at owasp.org> wrote:

get you .....but storing cookies with the view to not having to log in again on the next visit to the application?

 

On 5 December 2013 10:16, Christian Papathanasiou <christian.papathanasiou at owasp.org> wrote:

Hey Eoin, 

 

Not a certificate store, rather using it to store session id's that I would otherwise/traditionally  transmit as a cookie. 

Basically if site is immune from XSS, would HTML5 local storage be a good place to store your session cookies in. 

 

Reading between the lines it appears to have benefits listed below (always assuming site is XSS immune)

 


Sent from my iPhone


On 5 Dec 2013, at 10:08, Eoin <eoin.keary at owasp.org> wrote:

Would a weak browser (IE6) infected with Malware be an issue here?

Certificate stores / Keystores have passwords etc but local storage does not.

 

 

On 5 December 2013 10:06, Eoin <eoin.keary at owasp.org> wrote:

Hi Chris,

What your saying is using local storage as a "certificate store" sorta affair? Like a keystore for auth/authz when using an app?

 

 

On 5 December 2013 09:56, Christian Papathanasiou <christian.papathanasiou at owasp.org> wrote:

Hi everyone,

Assuming a domain does all the right stuff regarding XSS protection (white listing, output encoding, CSP etc etc) could HTML 5 local storage perhaps be a very interesting candidate for storing session cookies and performing authentication/authorization?

Reading between the lines the following key benefits stood out for me:

Local storage token/cookie not transmitted over  the wire hence minimising opportunity of cookie theft from sniffing

Same origin policy means that local storage cookie will be protected/relatively kimmune from CSRF attacks and hence no additional effort required to CSRF tokenize forms etc.

Of course, if your site has XSS then local storage cookies can be siphoned off or even injected but assuming for the time being that the site is immune to XSS and hence the lack of http only doesn't really matter and everything going over SSL by default (hence secure flag doesn't really matter) would the above benefits hold true?

Of course the user can mangle the local storage token/cookie but that would  in effect not really be different to doing the same with burp proxy etc as long as token/cookie is sufficiently random complex etc and unable to infer other peoples session tokens for horizontal or vertical priv esc.

Am I missing something fundamental  from a security perspective here? :-)

Finally are there any local storage authentication/authorization frameworks out there?

Many thanks & kind regards,
Christian Papathanasiou.


_______________________________________________
OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-leaders





-- 
Eoin Keary
OWASP Member
https://twitter.com/EoinKeary

 




-- 
Eoin Keary
OWASP Member
https://twitter.com/EoinKeary

 




-- 
Eoin Keary
OWASP Member
https://twitter.com/EoinKeary

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20131205/302df2d5/attachment.html>


More information about the OWASP-Leaders mailing list