The cookie monster in your browsers / filedescriptor
===

- Morden: RFC6265 and RFC6265bis

HTTP Respose 
Http/1.1 200 ok 
Set-Cookie:Sid=123; path=/admin 

JavaScript API (W)
document.cookie ='lang=en'

Attribute 
Expires |Max-Age| Domain| Path| SameSite|  


Flag 
Secure|HttpOnly 

Domain to subdomains

example.com 
Set-Cookie: foo=bar ; (sub.exmaple.com ) (sub.of.sub.example.com )

Domain=example.com (must set )

if u dont have the domain
the cookie not found the domain so domain = must

Dot or no Dot

1. No difference (old RFC vs New RFC style )
2. Both widen scope of a cookie to all (sub)domains
3. Correct way to limit the scope is to *not* have the domain attribute
4. tbc

Cookie Bomb
Most Servers have length limit on request headers
When this limit is exeeded , HTTP 413 or 431 [(Ref: MDN)](https://developer.mozilla.org/zh-TW/docs/Web/HTTP/Status) is returned
limited cookies injection can still result in clinet-side Dos 攻擊
Domain and Explire attributes can help persit the attack across (sub)domains .

https://example.com/aaa.....aaa ->>> https://twitter/#A

Public Suffix List
- Community created
- some domains cannot have cookies
- the same list that restricts domain=.com.tw

Cookie bomb + appcache = ?
1. Set many cookies on root path
2.Requests to every file will result in http 413
3.appcache's fallback kicks in and replaces the response
4.???
5.Profit!

XSS+OAuth

1.Perform Cookie Bomb Attack via XSS
2.

like use ssl to login google .
and google will oauth and return 302 found and set cookie:sid=123

1Authorizattion code is single-use
oauth/callback?code=123 <----

Path and http

two cookie same name
Cookie: csrf_token=foo; csef_token=foo;
you can set other cookie same name

Cookie tossing
consists of the tuple (name,domain ,path )
(sub)domains can force a cookei with the same name

Yummy cookies across domains
Github used on *.github.com

Scenario
XSS on ton.twitter.com
Twitter.com uses auth_token for session id and _Twitter_sess for storing CSRF token

Could modity _twitter_sess with and attacker-known value and have stie-wide

Http only
Cookies with this flag cannot be r/w form javascrpt api
safari <12 has a bug allows wiriting to httponly cookie with java api

cookie:_twtter_sess=attackers; _twitter_see=original
authenticity_token=attacke-known

self_XSS ->full XSS

有些網站還是沒有設定子網域，所以會有這樣的弱點。
因為你想限制 cookie 範圍，越小越好。可以參考 RFC 6265。
所以把沒有在用的 domain ，設定成沒有用的，那可能會被改成有用的。

有個頁面講到沒有頁面沒有設定屬性，那麼會在
IE 在 Windows10 已修正這個問題，但目前在以前的版本還是有這樣的問題。
這個算是 cookie bomb，這個是微軟的問題，所以沒辦法修，只有更新作業系統版本。

大部份的主機的服務會有限制，如果沒有限制的話，會限制你的標頭，如果太長它就不會回應你。
如果超過的話 HTTP 會回你 413 或是 431 錯誤訊息。

也可以限制Client-side 避免 injection in DOS。
也可以限制Domain 跟 Cookie 有效期限。

Twitter 也有這樣的弱點，它們的Cookie 讀取你的資訊，它會記錄你是從哪裡來的

https://URL/aaa => https://twitter/#A
https://URL/aaa => https://twitter/#B
https://URL/aaa => https://twitter/#C

很長的Cookie 長度，就會汙染瀏覽器。
設計者可能會分享這樣的弱點，甚至會社群會公開清單，還會一系列的domain轉址時不存cookie，因為太長了 XDDDD

部份的子域名可能會限制Cookie存取，或是設定它們的權限，因為它可能會汙染網域。
因為在清單內，你不知道它是不是從哪裡來的，但你可以允許設定像說 domain= .com.tw

另外一個exploiting 是 cookie bomb + appache => 可以透過有root cookie 取存路徑
然後HTTP 會回應413，但還有其他的方式…

其他的方式是 XSS + OAuth =>
http://www.google.com/oauth?client_id=A

回應 HTTP 201
可以改 Cookie 或是改 URL 代入的參數取得該User權限 (曾經的花旗銀行…)
但現在比較少了，可以再透過Redirect方式去取用。
http://www.google.com/oauth?URL=www.facebook.com?User=B
但可能伺服器可能會拒絕
(1) 存取時間可能有限制
(2) 目前Cookie屬性已經有在用了
(3) 後面帶的URL參數或Cookie由於轉址太長了，所以難以讀取…
(4) 可能轉址或加密其他的狀況…

可能成功的狀況
(1) Cookie 名字相同，即使doamin 不同也能有機會去汙染

Twitter 有成功汙染，但目前已經修復好了。
但這個情境在其他的網頁應該也有機會發生。

Scenario
其實也有CSRF token 的漏洞，經過修改也有server-side CSRF。

HttpOnly
有設定這個屬性的話，就無法透過Javascript API讀取
Safari 在 12 版前是可以去複寫 httpOnly 的cookie的。
可以透過覆寫值去改cookie (透過排序定優先度)

請一樣參考 RFC 6265(6.1)
不過如果Cookie有更長路徑(特定路徑)，一樣就會在前面。
最多一個domain 50 個cookies，每個cookie長度是 4069 bytes
超出的話就將最舊的cookie替換掉。因為空間不夠了，舊的會被移除。

At least 4096 bytes cookie
Overflowing cookie jar

Self XSS to full XSS
用自己的帳號去做 XSS，然後進一步取得邏輯，然後進一步去改了其他人的cookie

1.document.cookie='_master_udr=attackers;path=/admin/oauth

2.oauth/authorize?client_id=editor (login )

3.https://script-editor./oauth/callback?codattackers

4.https://victim.jyshopify.com/admin/oauth/authorzize?ClientID=Edit

另外還可以用Session Fixation 應用
由於domain Session 很脆弱，所以也可能被改。
透過

CSRF cookie injection
RFC 2965 (3.3.4)

github.com/eclips/jetty.project/issues

Safari 版本 10 前可以用。像說可以透過 path:/admin
或是加上 `;, ClientID='-alert(2)-'`
造成 cookie injection

更進一步由於有(;) 所以可能可以覆蓋。因為伺服器會認為這個是兩個cookie。
或是在 / 後面加 , 所以cookie的值也會被覆蓋過。

這樣的弱點瀏覽器很多，這個弱點超常見，但因為我超忙，沒空
所以可以參考我的github，去看哪些分割符號或瀏器，我已經嘗試過了。

修改方向：
加屬性 _Host檢查或是可以參考cookie 寫法的檢核
或是跟著 RFC 6265 規範做。
RFC 6265 Servers must only follow
PAS：CSRF or others會在2020 解決。(chrome瀏覽器會自行加入cookie 做檢核)

Q&A：印度超多沒有設定的cookie屬性，有什麼建議嗎…？
A：希望開發人員多參考規範寫法(？)

1.https://script-editorshopifycloud.com
force a session cookie scoped to .shopifcloud.com using XSS

Safari < version10 
RFC 2109 (4.2.2)

cookie base 

Set-cookie:realm=hotmail.com;, clientid='-alert(2)'-'

###### tags: `HITCONCMT2019`,`HITCONCMT`,`HITCON`