知道的越多，不知道的就越多，業餘的像一棵小草！
編輯：業餘草
來源：https://www.xttblog.com/?p=5000
有沒有想過，如果網站的 Cookie 特別多特別大，會發生什麼情況？
不多說，馬上來試驗一下：
for (i = 0; i < 20; i++)
document.cookie = i + '=' + 'X'.repeat(2000)什麼，網站居然報錯了？
然而現實中，幾乎所有的服務器都會對請求頭長度做限制，避免畸形封包消耗服務器資源。
那麼有趣的事就來了 —— Cookie 是可以長期儲存的，所以只要不過期，對應的站點就一直無法訪問！
爲什麼會這樣！因爲博客園是支持自定義裝扮的，用戶可以嵌入自己的腳本。於是，一旦執行了惡作劇腳本，站點 Cookie 被污染，導致整個網站都無法訪問了！
進階
根據這個原理，我們繼續挖掘 Cookie 的相關屬性，讓攻擊效果變得更好。
expires
Cookie 之所以能被持久儲存，完全得益於 expires 這個過期值。
理論上，Cookie 的過期時間可以足夠長。不過鑑於實際情況，最多也就幾個月的時間。
但對於互聯網來說，這也非常長了，誰能容忍一個網站幾個月沒法用？
所以，我們可以設置足夠久的過期時間 —— 只要用戶不主動清空 Cookie，相應的站點就一直沒法訪問！
domain
例如博客園，所有用戶都在 www.cnblogs.com 下。除了這個主站，能否將其他的子站服務也一起破壞呢？
答案是可以！因爲 Cookie 具有一個特殊的屬性 domain，它允許子站設置上級站點的 Cookie。甚至可以是根域！
於是 www.cnblogs.com 的頁面，就能寫入超大 Cookie 到 cnblogs.com 域下了。
未來，只要用戶訪問 *.cnblogs.com 的資源，統統變成 400 了。
只要某網站任何一個子站能夠運行跨站腳本，攻擊者就可以對該網站進行全站屏蔽了！（GFW：比我還狠~）
path
不過太霸道也是不好的。尤其是這年頭大家都懂些網絡知識，清緩存這樣簡單的事，不少小白用戶都會嘗試下。
所以，爲了低調起見，我們不對頁面進行屏蔽，以免被過早被用戶發現。
我們只屏蔽特殊的 URL，例如 AJAX 請求接口。這樣，頁面仍能正常打開，只是後期的一些操作總是提示失敗 —— 於是，用戶大多會認爲是網站出問題了，而不會懷疑是自己的原因。
爲了能更精確的控制 Cookie 粒度，path 屬性得利用起來。例如，我們只污染博客園的 /mvc/vote/VoteComment.aspx 頁面：
for (i = 0; i < 20; i++)
document.cookie = i + '=' + 'X'.repeat(2000) + ';domain=cnblogs.com; path=/mvc/vote/VoteComment.aspx'
這樣，頁面仍能正常瀏覽，只是把『點贊』功能給屏蔽了：
協議
仔細回顧一遍 Cookie 屬性，除了 secure，再沒和 URL Scheme 相關的屬性了。
這意味着，HTTP 和 HTTPS 的 Cookie 默認都是共享的。因此，我們可以在 HTTP 下屏蔽 HTTPS 站點了！
不過 XSS 也不是也想有就能有的，但在特殊的條件下，任何站點都可以有 XSS —— 那就是流量被劫持的時候。
當用戶流量被劫持時，中間人可以模擬出任何 HTTP 站點，因此就能對任意站點設置 Cookie：
當用戶打開任意 HTTP 頁面時，往其中注入腳本。接着悄悄創建目標站點的隱藏框架頁，中間人返回特定的頁面內容，其中的腳本即可修改目標站點 Cookie 了。
下面就來嘗試一下吧。
通過代理，我們模擬流量被劫持的場景。當打開任意頁面時，開始對目標站點釋放 DeBuff：
最後，切換回正常網絡 —— 發現邪惡光環仍在生效：
用途
或許你要說了，這除了惡作劇惡搞之外，有實際意義嗎？
不過，只要充分發揮想象，還是能玩出一些有趣的效果。例如配合 XSS：
屏蔽資料修改頁面，阻止用戶改密碼
屏蔽註銷接口，保持用戶會話不過期
屏蔽管理後臺，讓管理員暫時無法操作（XSS 盲打時，對管理員造成眩暈效果，持續時間視管理員 IQ 而定）
或者流量劫持的場合：
屏蔽前端檢測腳本，降低用戶安全性
屏蔽程序、補丁的更新站點，等等
小結
當然，這種所謂的『拒絕服務』，只是本地自欺欺人而已，對真實服務器並沒什麼影響。
雖然效果不及傳統攻擊，但這種方式顯得更文明一些。只對部分人、甚至部分功能實施攻擊，而完全不妨礙其他用戶。
