计算机网络(6): http cookie

Cookie作用：

1）帮助管理用户会话信息（用户需要记录的信息：登陆状态等）

2）跟踪浏览器的行为

3）用户自定义设置

实现方式：

当用户浏览带有Cookie的网站时，网站自动为其生成一个唯一的标志符号，并且在后端数据库里以其为索引添加一项（这样就能记录用户信息了），用户收到这个信息后，在之后请求阶段都带上这个头部！官方描述如下：

当服务器收到HTTP请求时，服务器可以在响应头里面添加一个Set-Cookie选项。浏览器收到响应后通常会保存下Cookie，之后对该服务器每一次请求中都通过Cookie请求头部将Cookie信息发送给服务器。另外，Cookie的过期时间、域、路径、有效期、适用站点都可以根据需要来指定

过期时间： 

会话期Cookie

是最简单的Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。会话期Cookie不需要指定过期时间（Expires）或者有效期（Max-Age）。需要注意的是，有些浏览器提供了会话恢复功能，这种情况下即使关闭了浏览器，会话期Cookie也会被保留下来，就好像浏览器从来没有关闭一样。

持久性Cookie

和关闭浏览器便失效的会话期Cookie不同，持久性Cookie可以指定一个特定的过期时间（Expires）或有效期（Max-Age）。

域：

Domain 和 Path 标识定义了Cookie的作用域：即Cookie应该发送给哪些URL。

Domain 标识指定了哪些主机可以接受Cookie。如果不指定，默认为当前文档的主机（不包含子域名）。如果指定了Domain，则一般包含子域名。

例如，如果设置 Domain=mozilla.org，则Cookie也包含在子域名中（如developer.mozilla.org）。

Path 标识指定了主机下的哪些路径可以接受Cookie（该URL路径必须存在于请求URL中）。以字符 %x2F ("/") 作为路径分隔符，子路径也会被匹配。

例如，设置 Path=/docs，则以下地址都会匹配：

  • /docs
  • /docs/Web/
  • /docs/Web/HTTP

 

是否可以link其他站点：

SameSite Cookie允许服务器要求某个cookie在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击（CSRF）。

SameSite cookies是相对较新的一个字段，所有主流浏览器都已经得到支持。

下面是例子：

Set-Cookie: key=value; SameSite=Strict

SameSite可以有下面三种值：

None

浏览器会在同站请求、跨站请求下继续发送cookies，不区分大小写。

Strict

浏览器将只发送相同站点请求的cookie(即当前网页URL与请求目标URL完全一致)。如果请求来自与当前location的URL不同的URL，则不包括标记为Strict属性的cookie。

Lax

在新版本浏览器中，为默认选项，Same-site cookies 将会为一些跨站子请求保留，如图片加载或者frames的调用，但只有当用户从外部站点导航到URL时才会发送。如link链接

 

其他：

1. 安全问题

会话劫持和XSS

在Web应用中，Cookie常用来标记用户或授权会话。因此，如果Web应用的Cookie被窃取，可能导致授权用户的会话受到攻击。常用的窃取Cookie的方法有利用社会工程学攻击和利用应用程序漏洞进行XSS攻击。（跨站脚本攻击(Cross Site Script为了区别于CSS简称为XSS)指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。）

如：

攻击者想拥有留言系统中后台管理员的权限，只要截取添加管理员账号时的HTTP请求信息，然后使用XML HTTP对象在后台发送一个HTTP请求即可。

怎么截取添加后台管理员账号的请求消息呢？这个不是抓包获取，是在正常添加用户时XSS代码中用 xmlhttp对象发送一个POST请求，由于该请求带上了被攻击者的Cookie并一同发送到服务端，所以能在后台悄悄地添加一个管理员账户。

添加管理员请求的POST数据：UserName=12345&password=1234

XSS Shellcode：

var params ="UserName=xss&password=1234";

xmlhttp.send(params);

 

跨站请求伪造（CSRF）

在不安全聊天室或论坛上的一张图片，它实际上是一个给你银行服务器发送提现的请求：

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

当你打开含有了这张图片的HTML页面时，如果你之前已经登录了你的银行帐号并且Cookie仍然有效（还没有其它验证步骤），你银行里的钱很可能会被自动转走。有一些方法可以阻止此类事件的发生：

  • 对用户输入进行过滤来阻止XSS；
  • 任何敏感操作都需要确认；
  • 用于敏感信息的Cookie只能拥有较短的生命周期；

 

2. 隐私问题

第三方Cookie
每个Cookie都会有与之关联的域（Domain），如果Cookie的域和页面的域相同，那么我们称这个Cookie为第一方Cookie（first-party cookie），如果Cookie的域和页面的域不同，则称之为第三方Cookie（third-party cookie.）。一个页面包含图片或存放在其他域上的资源（如图片广告）时，第一方的Cookie也只会发送给设置它们的服务器。通过第三方组件发送的第三方Cookie主要用于广告和网络追踪。这方面可以看谷歌使用的Cookie类型（types of cookies used by Google）。大多数浏览器默认都允许第三方Cookie，但是可以通过附加组件来阻止第三方Cookie（如EFF的Privacy Badger）。

 

PS：

唯一的标志符号：uuid怎么生成？

UUID是128位的全局唯一标识符，通常由32字节的字符串表示。它可以保证时间和空间的唯一性，也称为GUID，全称为：UUID —— Universally Unique IDentifier，Python 中叫 UUID。
它通过MAC地址、时间戳、命名空间、随机数、伪随机数来保证生成ID的唯一性。
UUID主要有五个算法，也就是五种方法来实现。

      • uuid1()——基于时间戳。由MAC地址、当前时间戳、随机数生成。可以保证全球范围内的唯一性，但MAC的使用同时带来安全性问题，局域网中可以使用IP来代替MAC。
      • uuid3()——基于名字的MD5散列值。通过计算名字和命名空间的MD5散列值得到，保证了同一命名空间中不同名字的唯一性，和不同命名空间的唯一性，但同一命名空间的同一名字生成相同的uuid。 
      • uuid4()——基于随机数。由伪随机数得到，有一定的重复概率，该概率可以计算出来。
      • uuid5()——基于名字的SHA-1散列值。算法与uuid3相同，不同的是使用 Secure Hash Algorithm 1 算法。

 

最近对cookie有了更深的理解，特此批注：

 

Cookie和Session

不要混淆 session 和 session 实现。

本来 session 是一个抽象概念，开发者为了实现中断和继续等操作，将 user agent 和 server 之间一对一的交互，抽象为“会话”，进而衍生出“会话状态”，也就是 session 的概念。

而 cookie 是一个实际存在的东西，http 协议中定义在 header 中的字段。可以认为是 session 的一种后端无状态实现。

而我们今天常说的 “session”，是为了绕开 cookie 的各种限制，通常借助 cookie 本身和后端存储实现的，一种更高级的会话状态实现。

所以 cookie 和 session，你可以认为是同一层次的概念，也可以认为是不同层次的概念。具体到实现，session 因为 session id 的存在，通常要借助 cookie 实现，但这并非必要，只能说是通用性较好的一种实现方案。


链接：https://www.zhihu.com/question/19786827/answer/84540780

CSRF攻击是什么

CSRF是跨站请求伪造的缩写，也被称为XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。
跟跨网站脚本（XSS）相比，XSS利用的是用户对指定网站的信任，CSRF利用的是网站对用户网页浏览器的信任。
因为CSRF攻击利用的是冲着浏览器分不清发起请求是不是真正的用户本人。，也就是说，简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

 

CSRF攻击基本原理

CSRF是跨站请求伪造的缩写，也被称为XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。
跟跨网站脚本（XSS）相比，XSS利用的是用户对指定网站的信任，CSRF利用的是网站对用户网页浏览器的信任。
因为CSRF攻击利用的是冲着浏览器分不清发起请求是不是真正的用户本人。，也就是说，简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

最简单的CSRF攻击

  1. 用户Alice登录和访问某银行网站A，保留cookie。
  2. Alice被某些信息诱导访问危险网站B。
  3. 危险网站B上有一个<img>标签：<img src="http://www.examplebank.com/account=Alice&amount=1000&payfor=Badman" >
  4. 这个标签的src不指向一张图片，而是一个http请求，这个请求向银行要求将Alice的1000元转给Badman，由于Alice的浏览器上有cookie，这样浏览器发出的这个请求就能得到响应执行。
  5. 这样Alice的钱就被偷了。
链接：https://zhuanlan.zhihu.com/p/37293032

作者：PPPPPython
链接：https://zhuanlan.zhihu.com/p/37295186
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

XSS攻击

 

XSS攻击是什么

  • XSS是跨站脚本攻击的缩写，是一种网站应用程序的安全漏洞攻击，是代码注入的一种。
  • 通常是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。
  • 这些恶意网页程序通常是JavaScript，但实际上也可以包括Java，VBScript，ActiveX，Flash或者甚至是普通的HTML。
  • 攻击成功后，攻击者可能得到更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。

 

XSS攻击基本原理——代码注入

在web的世界里有各种各样的语言，于是乎对于语句的解析大家各不相同，有一些语句在一种语言里是合法的，但是在另外一种语言里是非法的。这种二义性使得黑客可以用代码注入的方式进行攻击——将恶意代码注入合法代码里隐藏起来，再诱发恶意代码，从而进行各种各样的非法活动。只要破坏跨层协议的数据/指令的构造，我们就能攻击。
历史悠久的SQL注入和XSS注入都是这种攻击方式的典范。现如今，随着参数化查询的普及，我们已经离SQL注入很远了。但是，历史同样悠久的XSS却没有远离我们。
XSS的基本实现思路很简单——比如持久型XSS通过一些正常的站内交互途径，例如发布评论，提交含有JavaScript的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本，从而被攻击。

 
 

参考：
rfc文档：https://github.com/renaesop/blog/issues/4

官方文档：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Cookies

XSS和会话劫持：https://www.cnblogs.com/dolphinX/p/3391351.html

python uuid：https://www.cnblogs.com/loveapple/p/9445507.html

posted @ 2020-02-14 17:32  Plorde  阅读(297)  评论(0)  编辑  收藏  举报