怎么判断localstorage

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了怎么判断localstorage相关的知识,希望对你有一定的参考价值。

参考技术A 基本使用方法如下:localStorage.name = "k1w1"; 这样的话,你的本地磁盘中就会有个数据库存下了这个数据。我无法接受数据写到了我的本地磁盘而我找不到它的确切位置,于是通过寻找发现:Chrome 的存储方式是以sqlite的数据库文件形式存储。存在C:\Users\Username\AppData\Local\Google\Chrome\User Data\Default\Local Storage 中,虽然后缀名是.localstorege 但是实际上就是sqlite的数据库文件,可以用sqlite打开,并看到其中的数据。这么蛋疼的找它存在哪里是因为我想删掉在学习使用local storage时产生的一些垃圾数据,有点电脑洁癖。就像当初我喜欢选择性删除cookies一样。Firefox存在哪里暂时没有找到,感觉像是被加了密的sqlite数据库文件(这样的话firefox的安全性就高一些了),不过我每次关掉firefox它都会自动删掉所有浏览数据,所以也暂时不想找它存在哪了。

html5 localstorage 怎么取存储条数

在HTML5本地存储出现以前,WEB数据存储的方法已经有很多,比如HTTP Cookie,IE userData,Flash Cookie,Google Gears。其实再说细点,浏览WEB的历史记录也算是本地存储的一种方式。到目前为止,HTML5本地存储方式已经获得了广泛的支持,其中支持的浏览器包括:IE 8+、FF 3.5+、Safari 4+、Chrome 4+、Opera 10.5+,手机平台包括iPhone 2+和Android 2+。最新的HTML5本地存储规范文档,可以在线查看
http://dev.w3.org/html5/webstorage/
      HTML5本地存储的前身就是Cookie,通过使用localStorage对象将WEB数据持久留存在本地。相比较而言,HTML5本地存储中每个域的存储大小默认是5M,比起Cookie的4K要大的多。而且存储和读取数据的代码极为简练:
      那么现在我们是否可以简单的认为,HTML5存储已经可以代替Cookie存储了呢?还有这种新的存储方式在实际应用中带来了哪些新的安全风险呢?带着这些疑问我们来进行下面的讨论。
      (1) 是否可以代替Cookie
      浏览器使用Cookie进行身份验证已经好多年,既然现在localStorage存储空间那么大,是否可以把身份验证的数据直接移植过来呢?目前来看,把身份验证数据使用localStorage进行存储还不太成熟。我们知道,通常可以使用XSS漏洞来获取到Cookie,然后用这个Cookie进行身份验证登录。后来为了防止通过XSS获取Cookie数据,浏览器支持了使用HTTPONLY来保护Cookie不被XSS攻击获取到。而目前localStorage存储没有对XSS攻击有任何抵御机制,一旦出现XSS漏洞,那么存储在localStorage里的数据就极易被获取到。
如果一个网站存在XSS漏洞,那么攻击者注入如下代码,就可以获取使用localStorage存储在本地的所有信息。

 
      攻击者也可以简单的使用localStorage.removeItem(key)和localStorage.clear()对存储数据进行清空。
     (2) 不要存储敏感信息
      从(1)中知道,从远程攻击角度来看,localStorage存储的数据容易被XSS攻击获取,所以不宜把身份验证信息或敏感信息用localStorage存储。而从本地攻击角度来看, localStorage自身的存储方式和存储时效并不宜存储敏感信息。
      五大浏览器现在都已经支持以localStorage方式进行存储,其中Chrome,Opera,Safari这三款浏览器中都有了查看本地存储的功能模块。但是不同浏览器对localStorage存储方式还是略有不同的。以下是五大浏览器localStorage存储方式:
      
      通过上面的描述可以看出,除了Opera浏览器采用BASE64加密外(BASE64也是可以轻松解密的),其他浏览器均采用明文存储数据。
      另一方面,在数据存储的时效上,localStorage并不会像Cookie那样可以设置数据存活的时限,只要用户不主动删除,localStorage存储的数据将会永久存在。
      根据以上对存储方式和存储时效的分析,建议不要使用localStorage方式存储敏感信息,那怕这些信息进行过加密。
     (3) 严格过滤输入输出
      对于本地存储,为了方便加载数据,常常会把数据存储在本地,等再次加载时,直接从本地读取数据显示在网页上。在某些情况下,在localStorage存储中写入或读取数据的时候,如果数据没有经过输入输出严格过滤,那么这些数据极可能被作为HTML代码进行解析,从而产生XSS攻击。
      Twitter就发生过localStorage XSS漏洞。此漏洞触发的条件是,在Twitter的个人主页上执行以下存储代码后,每次再打开个人主页时就会弹出/xss/框。
      从这段代码可以看出,Twitter会使用localStorage方法把一些个人数据存储到本地,每次加载个人主页面的时候就会从本地存储获取数据,然后由于Twitter忽略了对去除数据的严格过滤,导致存储的代码会被当作HMTL编码执行,进而发生跨站攻击。

      有关Twitter localStorage XSS 漏洞详的细信息可以查看:http://www.wooyun.org/bugs/ wooyun-2010-03075。虽然Twitter这个漏洞利用起来非常困难,但它再一次告诉我们:本着一切输入输出都是有害的原则,要对数据进行严格的输入输出过滤。
     (4) 容易遭受跨目录攻击
      localStroage存储方式不会像Cookie存储一样可以指定域中的路径,在localStroage存储方式中没有域路径的概念。也就是说,如果同一个域下的任意路径存在XSS漏洞,整个域下存储的数据在知道存储名称的情况下都可以被获取到。
      假设下面两个链接是使用localStorage来存储数据:


      用户xisigr和xhack各自的blog链接虽然属于同一个域,但却有不同的路径,一个路径为xisigr,另一个路径为xhack。假设xisigr用户发现自己的路径下存在存储型XSS漏洞,那么就可以在自己的blog中加入获取数据代码,其中核心代码为localStorage.getItem(“name”)。xhack用户并不需要登录blog,他只要访问http://h.example.com/xisigr,本地存储数据就会被获取到。
     (5) 容易遭受DNS欺骗攻击
      Google在没有使用HTML5本地存储前,是使用Google Gears方式来进行本地存储的。那时Google Gears就遭到过DNS欺骗攻击。Google Gears支持离线存储,可以把Gmail,WordPresss这样的网站数据以SQLite数据库的形式存储下来,以后用户就可以对存储的网站数据进行离线读取或删除操作。如果攻击者发动DNS欺骗攻击,那么就可以注入本地数据库,获取数据或者留下永久的后门,造成对用户持久的危害。Google Gears所遭受的DNS欺骗攻击方式在HTML5本地存储上也是同样有效的。
     (6) 恶意代码栖息的温床
      在第六点中给出“恶意代码栖息的温床”这个小标题有些夸大的效果。其实这里想说的是,HTML5本地存储在空间上和时间上都将成为今后存储的趋势,料想“恶意代码们”自然会大雁南飞转移栖息到这张温床上。

      那么,何为HTML5本地存储的空间和时间呢?空间这里指的是存储空间,比起Cookie 4K空间的微小来说,HTML5的localStroage方法默认就可以使浏览器存储5M空间可以说是博大,而Safari浏览器可以支持到500M更加让HTML5存储霸气外露。时间上,随着HTML5技术日渐成熟,除了各大浏览器厂商争先在自己的产品中支持HTML5外,一些大应用软件厂商也对其信赖有加。比如2011年11月Adobe宣布放弃手机上的FLASH, 而由HTML5全面取而代之。随着时间的推移,HTML5大步流星的前行速度也会越来越快,也会使得用到HTML5本地存储的应用会越来越多。
 上面从理论上分析了 “恶意代码栖息的温床”的可能性。而从实际技术上的可行性也非常简单。下面是在本地留后门的核心代码:
     以上分析,均出自天融信TopLAB前沿安全实验室的研究,希望借此文让HTML5的本地存储安全问题得到大家的广泛重视。HTML5非常精彩,但也存在风险,我们要做的工作还很多。

参考技术A 1在HTML5本地存储出现以前,WEB数据存储的方法已经有很多,比如HTTP Cookie,IE userData,Flash Cookie,Google Gears。其实再说细点,浏览WEB的历史记录也算是本地存储的一种方式。到目前为止,HTML5本地存储方式已经获得了广泛的支持,其中支持的浏览器包括:IE 8+、FF 3.5+、Safari 4+、Chrome 4+、Opera 10.5+,手机平台包括iPhone 2+和Android 2+。最新的HTML5本地存储规范文档,可以在线查看
2http://dev.w3.org/html5/webstorage/
3 HTML5本地存储的前身就是Cookie,通过使用localStorage对象将WEB数据持久留存在本地。相比较而言,HTML5本地存储中每个域的存储大小默认是5M,比起Cookie的4K要大的多。而且存储和读取数据的代码极为简练:
那么现在我们是否可以简单的认为,HTML5存储已经可以代替Cookie存储了呢?还有这种新的存储方式在实际应用中带来了哪些新的安全风险呢?带着这些疑问我们来进行下面的讨论。
(1) 是否可以代替Cookie
浏览器使用Cookie进行身份验证已经好多年,既然现在localStorage存储空间那么大,是否可以把身份验证的数据直接移植过来呢?目前来看,把身份验证数据使用localStorage进行存储还不太成熟。我们知道,通常可以使用XSS漏洞来获取到Cookie,然后用这个Cookie进行身份验证登录。后来为了防止通过XSS获取Cookie数据,浏览器支持了使用HTTPONLY来保护Cookie不被XSS攻击获取到。而目前localStorage存储没有对XSS攻击有任何抵御机制,一旦出现XSS漏洞,那么存储在localStorage里的数据就极易被获取到。
如果一个网站存在XSS漏洞,那么攻击者注入如下代码,就可以获取使用localStorage存储在本地的所有信息。

攻击者也可以简单的使用localStorage.removeItem(key)和localStorage.clear()对存储数据进行清空。
(2) 不要存储敏感信息
从(1)中知道,从远程攻击角度来看,localStorage存储的数据容易被XSS攻击获取,所以不宜把身份验证信息或敏感信息用localStorage存储。而从本地攻击角度来看, localStorage自身的存储方式和存储时效并不宜存储敏感信息。
五大浏览器现在都已经支持以localStorage方式进行存储,其中Chrome,Opera,Safari这三款浏览器中都有了查看本地存储的功能模块。但是不同浏览器对localStorage存储方式还是略有不同的。以下是五大浏览器localStorage存储方式:

通过上面的描述可以看出,除了Opera浏览器采用BASE64加密外(BASE64也是可以轻松解密的),其他浏览器均采用明文存储数据。
另一方面,在数据存储的时效上,localStorage并不会像Cookie那样可以设置数据存活的时限,只要用户不主动删除,localStorage存储的数据将会永久存在。
根据以上对存储方式和存储时效的分析,建议不要使用localStorage方式存储敏感信息,那怕这些信息进行过加密。
(3) 严格过滤输入输出
对于本地存储,为了方便加载数据,常常会把数据存储在本地,等再次加载时,直接从本地读取数据显示在网页上。在某些情况下,在localStorage存储中写入或读取数据的时候,如果数据没有经过输入输出严格过滤,那么这些数据极可能被作为HTML代码进行解析,从而产生XSS攻击。
Twitter就发生过localStorage XSS漏洞。此漏洞触发的条件是,在Twitter的个人主页上执行以下存储代码后,每次再打开个人主页时就会弹出/xss/框。
从这段代码可以看出,Twitter会使用localStorage方法把一些个人数据存储到本地,每次加载个人主页面的时候就会从本地存储获取数据,然后由于Twitter忽略了对去除数据的严格过滤,导致存储的代码会被当作HMTL编码执行,进而发生跨站攻击。

有关Twitter localStorage XSS 漏洞详的细信息可以查看:http://www.wooyun.org/bugs/ wooyun-2010-03075。虽然Twitter这个漏洞利用起来非常困难,但它再一次告诉我们:本着一切输入输出都是有害的原则,要对数据进行严格的输入输出过滤。
(4) 容易遭受跨目录攻击
localStroage存储方式不会像Cookie存储一样可以指定域中的路径,在localStroage存储方式中没有域路径的概念。也就是说,如果同一个域下的任意路径存在XSS漏洞,整个域下存储的数据在知道存储名称的情况下都可以被获取到。
假设下面两个链接是使用localStorage来存储数据:

用户xisigr和xhack各自的blog链接虽然属于同一个域,但却有不同的路径,一个路径为xisigr,另一个路径为xhack。假设xisigr用户发现自己的路径下存在存储型XSS漏洞,那么就可以在自己的blog中加入获取数据代码,其中核心代码为localStorage.getItem(“name”)。xhack用户并不需要登录blog,他只要访问http://h.example.com/xisigr,本地存储数据就会被获取到。
(5) 容易遭受DNS欺骗攻击
Google在没有使用HTML5本地存储前,是使用Google Gears方式来进行本地存储的。那时Google Gears就遭到过DNS欺骗攻击。Google Gears支持离线存储,可以把Gmail,WordPresss这样的网站数据以SQLite数据库的形式存储下来,以后用户就可以对存储的网站数据进行离线读取或删除操作。如果攻击者发动DNS欺骗攻击,那么就可以注入本地数据库,获取数据或者留下永久的后门,造成对用户持久的危害。Google Gears所遭受的DNS欺骗攻击方式在HTML5本地存储上也是同样有效的。
(6) 恶意代码栖息的温床
在第六点中给出“恶意代码栖息的温床”这个小标题有些夸大的效果。其实这里想说的是,HTML5本地存储在空间上和时间上都将成为今后存储的趋势,料想“恶意代码们”自然会大雁南飞转移栖息到这张温床上。

那么,何为HTML5本地存储的空间和时间呢?空间这里指的是存储空间,比起Cookie 4K空间的微小来说,HTML5的localStroage方法默认就可以使浏览器存储5M空间可以说是博大,而Safari浏览器可以支持到500M更加让HTML5存储霸气外露。时间上,随着HTML5技术日渐成熟,除了各大浏览器厂商争先在自己的产品中支持HTML5外,一些大应用软件厂商也对其信赖有加。比如2011年11月Adobe宣布放弃手机上的FLASH, 而由HTML5全面取而代之。随着时间的推移,HTML5大步流星的前行速度也会越来越快,也会使得用到HTML5本地存储的应用会越来越多。
上面从理论上分析了 “恶意代码栖息的温床”的可能性。而从实际技术上的可行性也非常简单。下面是在本地留后门的核心代码:
以上分析,均出自天融信TopLAB前沿安全实验室的研究,希望借此文让HTML5的本地存储安全问题得到大家的广泛重视。HTML5非常精彩,但也存在风险,我们要做的工作还很多。

以上是关于怎么判断localstorage的主要内容,如果未能解决你的问题,请参考以下文章

JS怎么判断8点30分上班,到11点30分就显示下班

BlockingQueue 怎么判断全部堵塞

用C#怎么样判断用户IP地址是否国内的

java中怎么判断一个对象是否为空

thymeleaf 怎么判断添加属性

java怎么判断成功连接到数据库