Web应用中Cookie相关安全问题研究_学习笔记

cookie基础： 参考链接 https://blog.csdn.net/Auuuuuuuu/article/details/79977466

1.是用于保持HTTP会话状态/缓存信息

   由服务器/脚本写入

      Server:

          Set-Cookie: user=bob; domain=.bank.com; path=/;

      JS:

          document.cookie=“user=bob; domain=.bank.com; path=/;”; 

    属性：name/domain/path/httponly/secure/expire...

2.存储于浏览器/传输于HTTP头部

   Cookie: user=bob; cart=books;

   JS:

         console.log(document.cookie);

   —> “user=bob; cart=books;”

 

特点：写时带属性，而读时无属性。

而一个cookie是由三元组[name,domain,path]决定的

name, domain, path任一不同，则Cookie不同

alice覆盖bob   而jack和alice共存。

 

cookie泄露

http中cookie明文传输，被中间人获取即可得到会话凭证

防范：可以使用https对数据进行加密传输

但是这并不足够安全，首先再补充知识：

Cookie基础：同源策略(SOP)

   Web SOP: [protocol, domain, port]

      http://www.bank.com

      http://www.bank.com:8080

      https://www.bank.com

      以上并不同源，受sop隔离保护，跨域访问资源会被阻止，而在cookie中

 Cookie SOP: [domain, path]

    − 仅以domain/path作为同源限制

    − 不区分端口

    − 不区分HTTP / HTTPS 非同源

    Cookie: session=secret; domain=.bank.com; path=/;

      访问http://bank.com和https://bank.com页面时，cookie都会被发送

 

 Cookie SOP：Domain向上通配  

通配的原因：cookie本身就是为了传递状态的，根域名写入cookie 子域名即可附带，且便于开发

在对Cookie读写时，以“通配”的方式判断Domain是否有效 

写入：

    当页面为 http://www.bank.com 时：

    Set-Cookie: user1=aaa; domain=.bank.com; path=/;     接受

    Set-Cookie: user2=bbb; domain=www.bank.com; path=/;  接受

    Set-Cookie: user3=ccc; domain=.www.bank.com; path=/;  接受

    Set-Cookie: user4=ddd; domain=other.bank.com; path=/;  拒绝

第四个不满足向上匹配，

读取： 访问 http://www.bank.com （上例）

    Cookie: user1=aaa; user2=bbb; user3=ccc;

            访问 http://user.bank.com

     Cookie: user1=aaa;   

     只有user1 user1域为.bank  向下通配   user2,user3不符合

 Cookie SOP：Path向下（后）通配

Set-Cookie: session=bob; domain=.bank.com; path=/;

Set-Cookie: cart=books; domain=.bank.com; path=/buy/;

                访问http://bank.com/

                Cookie: session=bob;

                 访问http://bank.com/buy/

                 Cookie: session=bob; cart=books;     session=bob;也会被读取出来

综上，我们在思考https是否有效的防止cookie泄露？

虽然使用https 加密了对bank.com的访问但是

cookie sop不区分协议并且domain向下通配 

当攻击者构造一个img标签促使受害者发起对non.bank的http请求，

而我们对此进行中间人攻击，获取到的cookie即可得到bank.com的cookie值

防御：

我们可以将某些Cookie设置为Secure属性，此时即使我们被劫持，session=bob也不会被读取出来，实现了保护。

 

 

Cookie覆盖

我们虽然保证了数据的机密性，但是Secure属性却无法保证数据的完整性。

我们可以覆盖cookie的值

攻击者引出一个http的流量，由于设置了Secure属性，cookie带不出来，得不到，但是可以写入一个同名的cookie

name path domain 完全相同  value不同进行覆盖

可能读者会感觉到鸡肋，去覆盖受害者的登录凭证，登录攻击者的会话，有什么作用？

但是在web2.0时代的丰富场景中，我们设想google搜索中，登录的gmail邮箱，我们覆盖其登录凭证，登录攻击者的gmail，即可得到受害者的搜索记录，等操作记录。

但是还是有点问题，因为太容易被发现，不隐蔽，易察觉，危害有限。

 

Cookie注入：反射

广义的反射：

   服务端将Cookie拼接到HTML页面

   JS将Cookie渲染到DOM/参与运算

如果未对其进行有效的过滤，即可存在注入，并且不是个例

究其原因：

是我们的惯性思维导致的

该例子简单的进行黑名单过滤，替换成 #   但存在二次转义，可绕过。

防xss仅仅是对xss进行了黑名单过滤，太简单，而且可能不做任何处理。

 

 

cookie并不唯一，读的时候并不带属性。而允许重名

 

我们此时不覆盖，设置两个 不同域 但是同名，同path的cookie，此时代表两个cookie，

而我们此时服务器面对同名的cookie该选择哪一个呢？

 

官方解释：

如果Cookie头中存在两个同名Cookie，服务器不应该根据 它们出现的先后顺序来决定谁有效。 ——RFC6265

 

潜台词： “我也没辙，那就约定俗成，按顺序来处理吧”

原因：  cookie特性：写时带属性，而读时无属性  服务器只能看到一前一后同名的cookie

优先级顺序：

 

重名：顺序/优先级

浏览器对Cookie String的排序原则

    具有更长Path的Cookie更靠前（浏览器是知道cookie的属性，会根据path进行排序）

    如果Path长度相等，更早创建的Cookie更靠前

    Cookie: session=bob; session=attacker

而我们此时攻击者就构造靠前的cookie-------》提高path，更早的创建

   提高优先级：更长Path

目标页面：https://user.bank.com/admin/index.php?type=1

              Cookie: session=attacker; session=bob;

 Server -> Set-Cookie: session=bob; domain=.user.bank.com; path=/;

 Attacker -> Set-Cookie: session=attacker; domain=.bank.com; path=/admin;

 

如果本身path=/admin 我们构造path=/admin/

Server -> Set-Cookie: session=bob; domain=.user.bank.com; path=/admin;

Attacker -> Set-Cookie: session=attacker; domain=.bank.com; path=/admin/

 

总能最长？Cookie职责之一，负责多页面之间的状态传递

或者 本身为path=/admin/ 构造path=/admin/index.php

Server -> Set-Cookie: session=bob; domain=.user.bank.com; path=/admin/;

Attacker -> Set-Cookie: session=attacker; domain=.bank.com; path=/admin/index.php;

 

cookie除了不会把域写死，path也不会确定到某一个页面，如果写死了某一个页面，就失去了其传递性

所以我们可以构造path=/admin/index.php?type=1

Attacker -> Set-Cookie: session=attacker; domain=.bank.com; path=/admin/index.php?type=1; (Firefox)

 

提高优先级：更早创建

    目标页面：https://user.bank.com/   此时我们的path 无path可长

Server -> Set-Cookie: session=bob; domain=.bank.com; path=/;

1.可以对其附加属性

Attacker-> Set-Cookie: session=none; domain=.bank.com; path=/; expires=Mon, 1 Jan 1970

Attacker -> Set-Cookie: session=attacker; domain=user.bank.com; path=/; ...

Server -> Set-Cookie: session=bob; domain=.bank.com; path=/;

                       Cookie: session=attacker; session=bob; 更早创建

 

2.增加   /   构造畸形path

Attacker -> Set-Cookie: session=attacker; domain=user.bank.com; path=//; (Firefox)

 

我们实现了精确控制作用域domain、path

总能构造更高优先级Path、Creation-time

此时我们在看之前的google搜索记录身份替换攻击如何隐蔽

我们将path写为/search  domain为www.google.com

搜索时会使用ajax访问https://www.google.com/search?q=kcon（现在是参数q了~）

此时攻击者cookie优先级更高  实现了搜索记录的记录

而当受害者访问主页https://www.google.com/时path不同，返回的还是受害者本身会话，

其他页面域不同，也是本身会话，实现了有效的隐蔽替换

 

  

 

 

 

写的很清楚了~ 不能准确的删除，要不就都删除了，github提出了方案，但是遍历情况多，开销大

所以出现了

 

拓展：通用攻击

假设WordPress的wp_vul_path/vul.php 存在Cookie漏洞

要实现这种攻击domain需要写入为.com形式，而这种形式是被拒绝的

但是也存在 

只要使用该浏览器发送的wordpress站点的请求，都会被攻击。

 

总结：

防护：

使用hsts防护，但未普及。

 

治本：修订标准，不允许在http下写入或者覆盖secure cookie