对于 cookie 的相关内容还可以在网上找些相关资料，就上面的PDF放几张图简单了解一下

在攻击角度着重于：Domain、Path、HttpOnly

SameSite、Secure是在 RFC6265bis 中的内容

创建域	cookie	example.com	sub.example.com	sub.of.sub.example.com
example.com	Set-Cookie: foo=bar; domain=.example.com	-	可见	可见
sub.example.com	Set-Cookie: foo=bar; domain=.example.com	可见	-	可见
sub.example.com	Set-Cookie: foo=bar;	不可见	-	不可见

作者提到了一个很有趣的问题，在实际测试时候，也可以看到domain=example.com会被解析成domain=.example.com

而这个问题感觉是在实现此规范时的误读

简单总结：

设置 cookie 时如果没有指明特定的 domain 属性，则此 cookie 只属于当前域；如果设置 domain 属性，则还属于其下所有子域。
当在某子域攻击 cookie 时，可能影响到相关其他(子)域

此漏洞产生的原因有几个：

大多服务器限制了request headers长度，即请求头长度
如果接收的头部超出长度限制，会返回 413 或者 431 错误
限制性cookie注射(直翻理解下)，可能导致客户端DoS
Domain、Expire属性会帮助将攻击传播至(子)域

这里有一个可以在线测试浏览器 cookie 是否有某些限制的页面

案例

源自客户端：referrer、parameter、hash
源自服务端：js-code-injection

function d(a) {
...
        var b = document.referrer || "none",
            d = "ev_redir_" + encodeURIComponent(a) + "=" + b + "; path=/";
        document.cookie = d;
...
}
...
window.location.hash != "" && d(window.location.hash.substr(1).toLowerCase())

可以看到，代码将锚点部分作为新cookie部分键内容，只要构造附有超长hash页面跳转至此漏洞页面，即可造成客户端Dos

var getURLParameter = function(name) {
    return decodeURIComponent((new RegExp('[?|&]' + name + '=' + '([^&;]+?)(&|#|;|$)').exec(location.search) || [, ""])[1].replace(/+/g, '%20')) || null;
}

var brandedKeyword = function(ref) {
    var match1 = new RegExp("((google|yahoo|bing)(.)&?q=([^&])shopify)", "gi").test(ref);
    return (match1);
}

var ref = getURLParameter('ref');
var ssid = getURLParameter('ssid');

if (ref && !brandedKeyword(document.referrer)) {
    var days = 30;
    var expire = new Date(today + days * 1000 * 60 * 60 * 24);
    setCookieWithExpiration('source', ref, expire);
    if (ssid) {
        setCookieWithExpiration('ssid', ssid, expire);
    }
}

var setCookieWithExpiration = function(key, value, expire) {
    var match = document.location.hostname.match(/shopify..*/)
    var domain
    if (match) {
        domain = '.' + match[0]
    } else {
        domain = '.shopify.com'
    }
    document.cookie = key + "=" + escape(value) + ";path=/" + ";expires=" + expire.toUTCString() + ';domain=' + domain;
};

这段代码通过获取参数ref和ssid创建相应的cookie，也是利用超长造成客户端 dos

Bomb + OAuth

思考：就 OAuth 开始的 CSRF Login，code 2 token，到后来的 Redirect get code，就目前来说，还是存在重定向获取一次性登录 code 比较多，但是在修复经过强校验跳转地址后，是不是就没有攻击点了？

回到重定向获取 code 原理，主要是利用终端 oauth 认证流程的同时获取 code，这样既能保持 code有效性，又能获取到 code 进行利用

Name	Value	Domain
user_sess	original	-
user_sess	attacker’s	.exapmle.com

Name	Value	Domain	Path
user_sess	original	-	/
user_sess	attacker’s	.exapmle.com	/i/

对 Cookie 的一点学习

案例

Bomb + OAuth

参考资料

对 Cookie 的一点学习

Cookie 跨域

Cookie Bomb

案例

Twitter - DOM based cookie bomb

[livechat.shopify.com] Cookie bomb at customer chats

Bomb + OAuth

Cookie Tossing

案例 1 cookie 排序问题

案例 2 同名 cookie 数量问题

参考资料