怎么防止黑客盗取COOKie里面的密码资料

你在自己没有中毒的话，他肯定没办法截取cookies了，而且我用过的远程控制软件没有一款可以直接截取到cookies信息。。

一般都是加密的吧，截取到破解也不容易。。谁会去花费那么多精力获取你的信息呢。。。

Web前端新手应该了解的Cookie知识！

今天小编要跟大家分享的文章是关于Web前端新手应该了解的Cookie知识。正准备学习Web前端知识和准备从事Web

前端工作的小伙伴怎么能不了解Cookie。今天小编就为大家带来了这篇文章，让我们一起来看一看Web前端新手应该了解的Cookie知识。

一、Cookie的出现

浏览器和服务器之间的通信少不了HTTP协议，但是因为HTTP协议是无状态的，所以服务器并不知道上一次浏览器做了什么样的操作，这样严重阻碍了交互式Web

应用程序的实现。

针对上述的问题，网景公司的程序员创造了Cookie。

二、Cookie的传输

服务器端在实现Cookie标准的过程中，需要对任意HTTP请求发送Set-CookieHTTP头作为响应的一部分：

1.Set-Cookie:name=value;expires=Tue,03-Sep-201914:10:21GMT;path=/;

domain=.#;

浏览器端会存储这样的Cookie，并且为之后的每个请求添加CookieHTTP请求头发送回服务器：

1.Cookie:name=value

服务器通过验证Cookie值，来判断浏览器发送请求属于哪一个用户。

三、浏览器中的Cookie

浏览器中的Cookie主要由以下几部分组成：

·名称：Cookie唯一的名称，必须经过URL编码处理。(同名会出现覆盖的情况)

·值：必须经过URL编码处理。

·域(domain)：默认情况下cookie在当前域下有效，你也可以设置该值来确保对其子域是否有效。

·路径(path)：指定Cookie在哪些路径下有效，默认是当前路径下。

·

失效时间(expires)：默认情况下，浏览器会话结束时会自动删除Cookie;也可以设置一个GMT格式的日期，指定具体的删除日期;如果设置的日期为以前的日期，那么Cookie会立即删除。

·安全标志(secure)：指定之后只允许Cookie发送给https协议。

浏览器在发送请求时，只会将名称与值添加到请求头的Cookie字段中，发送给服务端。

浏览器提供了一个非常蹩脚的API来操作Cookie：

1.document.cookie

通过上述方法可以对该Cookie进行写操作，每一次只能写入一条Cookie字符串：

1.document.cookie='a=1;secure;path=/'

通过该方法还可以进行Cookie的读操作：

1.document.cookie//"a=1"

由于上述方法操作Cookie非常的不直观，一般都会写一些函数来简化Cookie读取、设置和删除操作。

对于Cookie的设置操作中，需要以下几点：

对于名称和值进行URL编码处理，也就是采用JavaScript中的encodeURIComponent()方法;

expires要求传入GMT格式的日期，需要处理为更易书写的方式，比如：设置秒数的方式;注意只有的属性名的secure;

每一段信息需要采用分号加空格。

1.functionsetCookie(key,value,attributes){

2.if(typeofdocument==='undefined'){

3.return

4.}

5.attributes=Object.assign({},{

6.path:'/'

7.},attributes)

8.

9.let{domain,path,expires,secure}=attributes

10.

11.if(typeofexpires==='number'){

12.expires=newDate(Date.now()+expires*1000)

13.}

14.if(expiresinstanceofDate){

15.expires=expires.toUTCString()

16.}else{

17.expires=''

18.}

19.

20.key=encodeURIComponent(key)

21.value=encodeURIComponent(value)

22.

23.letcookieStr=`${key}=${value}`

24.

25.if(domain){

26.cookieStr+=`;domain=${domain}`

27.}

28.

29.if(path){

30.cookieStr+=`;path=${path}`

31.}

32.

33.if(expires){

34.cookieStr+=`;expires=${expires}`

35.}

36.

37.if(secure){

38.cookieStr+=`;secure`

39.}

40.

41.return(document.cookie=cookieStr)

42.}

Cookie的读操作需要注意的是将名称与值进行URL解码处理，也就是调用JavaScript中的decodeURIComponent()方法：

1.functiongetCookie(name){

2.if(typeofdocument==='undefined'){

3.return

4.}

5.letcookies=[]

6.letjar={}

7.document.cookie(cookies=document.cookie.split(';'))

8.

9.for(leti=0,max=cookies.length;i

10.let[key,value]=cookies[i].split('=')

11.key=decodeURIComponent(key)

12.value=decodeURIComponent(value)

13.jar[key]=value

14.if(key===name){

15.break

16.}

17.}

18.

19.returnname?jar[name]:jar

20.}

最后一个清除的方法就更加简单了，只要将失效日期(expires)设置为过去的日期即可：

1.functionremoveCookie(key){

2.setCookie(key,'',{expires:-1})

3.}

介绍Cookie基本操作的封装之后，还需要了解浏览器为了限制Cookie不会被恶意使用，规定了Cookie所占磁盘空间的大小以及每个域名下Cookie的个数。

四、服务端的Cookie

相比较浏览器端，服务端执行Cookie的写操作时，是将拼接好的Cookie字符串放入响应头的Set-Cookie字段中;执行Cookie的读操作时，则是解析HTTP请求头字段Cookie中的键值对。

与浏览器最大的不同，在于服务端对于Cookie的安全性操碎了心

signed

当设置signed=true时，服务端会对该条Cookie字符串生成两个Set-Cookie响应头字段：

1.Set-Cookie:lastTime=2019-03-05T14:31:05.543Z;path=/;httponly

2.Set-Cookie:lastTime.sig=URXREOYTtMnGm0b7qCYFJ2Db400;path=/;

httponly

这里通过再发送一条以.sig为后缀的名称以及对值进行加密的Cookie，来验证该条Cookie是否在传输的过程中被篡改。

httpOnly

服务端Set-Cookie字段中新增httpOnly属性，当服务端在返回的Cookie信息中含有httpOnly字段时，开发者是不能通过JavaScript来操纵该条Cookie字符串的。

这样做的好处主要在于面对XSS(Cross-sitescripting)攻击时，黑客无法拿到设置httpOnly字段的Cookie信息。

此时，你会发现localStorage相比较Cookie，在XSS攻击的防御上就略逊一筹了。sameSite

在介绍这个新属性之前，首先你需要明白：当用户从#发起#的请求也会携带上Cookie，而从#携带过来的Cookie称为第三方Cookie。

虽然第三方Cookie有一些好处，但是给CSRF(Cross-siterequestforgrey)攻击的机会。

为了从根源上解决CSRF攻击，sameSite属性便闪亮登场了，它的取值有以下几种：

·

strict：浏览器在任何跨域请求中都不会携带Cookie，这样可以有效的防御CSRF攻击，但是对于有多个子域名的网站采用主域名存储用户登录信息的场景，每个子域名都需要用户重新登录，造成用户体验非常的差。

·lax：相比较strict，它允许从三方网站跳转过来的时候使用Cookie。

为了方便大家理解sameSite的实际效果，可以看这个例子：

1.//#服务端会在访问页面时返回如下Cookie

2.cookies.set('foo','aaaaa')

3.cookies.set('bar','bbbbb')

4.cookies.set('name','cccccc')

5.

6.//#服务端会在访问页面时返回如下Cookie

7.cookies.set('foo','a',{sameSite:'strict'})

8.cookies.set('bar','b',{sameSite:'lax'})

9.cookies.set('baz','c')

如何现在用户在#中点击链接跳转到#，它的请求头是这样的：

1.RequestHeaders

2.

3.Cookie:bar=b;baz=c

五、网站性能优化

Cookie在服务端和浏览器的通信中，主要依靠HTTP的响应头和请求头传输的，所以Cookie会占据一定的带宽。

前面提到浏览器会为每一次HTPP请求自动携带上Cookie信息，但是对于同站内的静态资源，服务器并不需要处理其携带的Cookie，这无形中便浪费了带宽。

在最佳实践中，一般都会将静态资源部署到独立的域名上，从而可以避免无效Cookie的影响。

以上就是小编今天为大家分享的关于Web前端新手应该了解的Cookie知识，希望本篇文章能够对正在从事Web前端工作和准备从事Web

前端学习的小伙伴们有所帮助。想要了解更多Web前端相关知识记得关注北大青鸟Web培训官网！

作者|descire

来源|#/article/286535

*声明：内容与图片均来源于网络(部分内容有修改)，版权归原作者所有，如来源信息有误或侵犯权益，请联系我们删除或授权事宜

cookie注入是如何实现的

严格的讲，cookie是没有注入的，只有利用。

cookie是什么呢。简单的说就是你网上信息了，为什么会有这个东东，因为人家微软IE为了节省你的时间，为了让你更便捷，所以他们设计了cookie这个东西，保存了你的登陆帐号信息，甚至一些填的表格东东都给你保存了，这样当然是提高了效率，便捷了我们，但同时也为黑客们提供了一些利用的条件。

怎么个利用法呢，两个利用的地方：

1，入侵到了你的电脑，或者直接登陆到了你的电脑，将你的cookie拿走，然后查看你的cookie信息，你的那些密码啊，帐号啊。统统滴都尽收眼底，算不算漏洞呢？当然是算滴。哈。

2，一些网站设计的不太合理，导致了cookie的利用。当然前提是拿到这个网站管理员的帐号和密码，如今的密码不都是MD5加密的么，如果密码相当的复杂怎么办？暴力？不可能吧，几个月甚至几年的时间，你以为黑客就没招了？如果你网站对cookie设置不严格，嘿嘿，对不起，俺不需要你的密码，仍然可以进去，如何操作？就是将你在那个网站的cookie里的帐号和密码改成管理员的帐号和密码，然后再跑到那个网站一刷新。嘿嘿。奇迹发生了。你的身份已经是管理员了。。。。省略一千字。。哈哈。。JACK还跑到这里来了。。不小心被我碰到啦。。

cookie的隐私泄漏

实际上，Cookie中保存的用户名、密码等个人敏感信息通常经过加密，很难将其反向破解。但这并不意味着绝对安全，黑客可通过木马病毒盗取用户浏览器Cookie，直接通过偷取的Cookie骗取网站信任。可以看出，木马病毒入侵用户电脑是导致用户个人信息泄露的一大元凶。

自1993年Cookie诞生以来，其就拥有专属性原则，即A网站存放在Cookie中的用户信息，B网站是没有权限直接获取的。但是，一些第三方广告联盟的代码使用范围很广。这就造成用户在A网站搜索了一个关键字，用户继续访问B网站，由于B网站也使用了同一家的第三方广告代码，这个代码可以从Cookie中获取用户在A网站的搜索行为，进而展示更精准的推广广告。比如搜索“糖尿病”等关键词，再访问其联盟网站，页面会立刻出现糖尿病治疗广告。如果并未事先告之，经用户同意，此做法有对隐私构成侵犯的嫌疑。这个还处在灰色地带。

因此，跨站Cookie恰恰就是用户隐私泄露的罪魁祸首，所以限制网站使用跨站Cookie，给用户提供禁止跟踪(DNT)功能选项已成为当务之急。据了解，IE、Chrome、360、搜狗等浏览器均可以快速清除用户浏览器网页的Cookie信息。但从整体的隐私安全保护环境来看，安全软件仍然存在着巨大的防护缺口。所以安全软件也可以并且有必要提供定期清理网站Cookie，并监测跨站Cookie使用的功能，保护用户隐私安全。 英国伦敦的一名软件开发者已发现了一串代码，能在浏览器的隐私模式中执行普通会话，这将导致隐私模式的失效。

目前，所有主流浏览器都提供了隐私保护模式。在这种模式下，网站的Cookies无法追踪用户身份。例如，谷歌Chrome浏览器提供了名为“Incognito”的功能，而火狐浏览器则提供了“隐私窗口”功能。

不过，新发现的这一漏洞将导致浏览器隐私模式的失效。例如，当用户使用普通浏览器，在亚马逊网站上购物或浏览Facebook时，用户可能会启动一个隐私窗口，去浏览存在争议内容的博客。如果这一博客使用了与亚马逊同样的广告网络，或是集成了Facebook的“点赞”按钮，那么广告主和Facebook可以知道，用户在访问亚马逊和Facebook的同时也访问了这一争议博客。

对于这一漏洞，用户有一个临时解决办法，但是比较麻烦：用户可以在启动隐私模式之前删除所有Cookies文件，或者使用一个专门的浏览器，完全在隐私模式下进行浏览。讽刺的是，这一漏洞是由于一项旨在加强隐私保护的功能所引起的。

如果用户在浏览器地址栏使用前缀https://，为某些网站的通信加密，那么一些浏览器会对此进行记忆。浏览器会保存一个“超级Cookie”，从而确保当用户下次连接该网站时，浏览器会自动进入https通道。即使用户启用了隐私模式，这一记忆仍会存在。

与此同时，这样的超级Cookie也允许第三方网络程序，例如广告和社交媒体按钮，对用户进行记忆。

发现这一漏洞的独立研究员萨姆·格林哈尔(Sam Greenhelgh)在博客中表示，这种功能还没有被任何公司所使用。不过在这种方式被公开之后，没有任何办法去阻止各家公司这样做。

在线隐私软件公司Abine联合创始人尤金·库兹涅佐夫(Eugene Kuznetsov)认为，这种“超级Cookie”将成为下一代追踪工具。这种工具脱胎于Cookies，但变得更加复杂。目前，用户在浏览过程中总是会存在设备唯一识别码，以及具有唯一性的浏览器指纹，这些痕迹很难被擦除。

由于“超级Cookie”的存在，互联网匿名性变得更加困难。库兹涅佐夫表示：“我们已经看到了关于隐私保护的军备竞赛。追踪互联网用户的愿望就像是寄生虫。你浏览器中的任何内容都在被网站和广告主审视，从而实现更多的追踪。”Mozilla已经在最新版火狐浏览器中对此进行了修复，而谷歌则倾向于使Chrome维持原状。谷歌已经知道了“超级Cookie”带来的问题，但仍选择继续启用Chrome的https记忆功能。在安全性和隐私保护之间，谷歌选择了前者。

微软IE浏览器并不存在这样的问题，因为这款浏览器并未内建https记忆功能。格林哈尔还表示，在iOS设备上，“超级Cookie”带来的问题同样存在。