2017.W09 - CSRF 的攻與受 - 資安
By Agatha
at 2017-02-28T10:45
at 2017-02-28T10:45
Table of Contents
2017.W09 - CSRF 的攻與受
> 弔念 228 一早起來就開始寫扣
## 前言 ##
一直沒有人想投稿 內容越寫越廣了 ...
再沒人投稿 下一次可能就要寫 OS 了 QQ
## 內容 ##
CSRF (Cross-Site Request Forgery)[0],中文稱之為跨站請求偽造
是一種偽造使用者操作的攻擊手法
因為攻擊形式又被叫做 one-click attack [1]
攻擊的方式 利用偽造使用者正常的請求 (HTTP Request) 而達到攻擊的目的
一般來說透過瀏覽器的請求 都用 HTTP[2] 的 GET、POST 等請求來完成
除了一些些特例之外
網站的設計者 對於某些敏感的操作 (e.g. 刪除、匯款) 都會驗證身份
這裡的驗證身份 在食物上都會用 session 來確認使用者是已經登入的帳號
(題外話 有興趣的人記得要了解 Cookie 與 Session 的差別)
因為 Browser 的特性 會將可以使用的 cookie 一併包含在 HTTP 請求當中
攻擊者就用這個特性來做到 one-click attack 的攻擊
可以參考此文章[3] 的情境 發現攻擊者可以利用以下方式來發送 CSRF:
1. 一個圖文不符的假 Link (<a>、<img> 等)
2. 你看不到的 iframe
3. JavaScript 自動幫你 Submit 一個 POST 請求
## 防禦方式 ##
一個好的網站設計者 會提供一個 CSRF Token 或者 state token
來確定這次的 HTTP 請求真的是 user 當下 送出的
Token 可以根據實作上的方式 分為綁定 session 或者是每次都不一樣
前者可以防禦 CSRF 的攻擊 而後者則可以防禦重放攻擊 (Reply Attack)[4]
重放攻擊是重複執行上一次使用者合法的操作
像是 Alice 匯款給 Bob
Bob 就可以利用 Reply Attack 讓 Alice 一直匯 一直匯 一直匯...
另一種則是 Chrome 最新提出來的 SameSite Cookie[5]
也就是 Browser 只會在 Host 跟請求網站一致的時候 才會將 Cookie 包含在請求當中
透過這種方式 就可以完全避免掉 CSRF
[0]: https://en.wikipedia.org/wiki/Cross-site_request_forgery
[1]: https://www.owasp.org/index.php/One-Click_Attack
[2]: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
[3]: http://blog.techbridge.cc/2017/02/25/csrf-introduction/
[4]: https://en.wikipedia.org/wiki/Replay_attack
[5]: https://www.chromestatus.com/feature/4672634709082112
--
> 弔念 228 一早起來就開始寫扣
## 前言 ##
一直沒有人想投稿 內容越寫越廣了 ...
再沒人投稿 下一次可能就要寫 OS 了 QQ
## 內容 ##
CSRF (Cross-Site Request Forgery)[0],中文稱之為跨站請求偽造
是一種偽造使用者操作的攻擊手法
因為攻擊形式又被叫做 one-click attack [1]
攻擊的方式 利用偽造使用者正常的請求 (HTTP Request) 而達到攻擊的目的
一般來說透過瀏覽器的請求 都用 HTTP[2] 的 GET、POST 等請求來完成
除了一些些特例之外
網站的設計者 對於某些敏感的操作 (e.g. 刪除、匯款) 都會驗證身份
這裡的驗證身份 在食物上都會用 session 來確認使用者是已經登入的帳號
(題外話 有興趣的人記得要了解 Cookie 與 Session 的差別)
因為 Browser 的特性 會將可以使用的 cookie 一併包含在 HTTP 請求當中
攻擊者就用這個特性來做到 one-click attack 的攻擊
可以參考此文章[3] 的情境 發現攻擊者可以利用以下方式來發送 CSRF:
1. 一個圖文不符的假 Link (<a>、<img> 等)
2. 你看不到的 iframe
3. JavaScript 自動幫你 Submit 一個 POST 請求
## 防禦方式 ##
一個好的網站設計者 會提供一個 CSRF Token 或者 state token
來確定這次的 HTTP 請求真的是 user 當下 送出的
Token 可以根據實作上的方式 分為綁定 session 或者是每次都不一樣
前者可以防禦 CSRF 的攻擊 而後者則可以防禦重放攻擊 (Reply Attack)[4]
重放攻擊是重複執行上一次使用者合法的操作
像是 Alice 匯款給 Bob
Bob 就可以利用 Reply Attack 讓 Alice 一直匯 一直匯 一直匯...
另一種則是 Chrome 最新提出來的 SameSite Cookie[5]
也就是 Browser 只會在 Host 跟請求網站一致的時候 才會將 Cookie 包含在請求當中
透過這種方式 就可以完全避免掉 CSRF
[0]: https://en.wikipedia.org/wiki/Cross-site_request_forgery
[1]: https://www.owasp.org/index.php/One-Click_Attack
[2]: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
[3]: http://blog.techbridge.cc/2017/02/25/csrf-introduction/
[4]: https://en.wikipedia.org/wiki/Replay_attack
[5]: https://www.chromestatus.com/feature/4672634709082112
--
Tags:
資安
All Comments
By Necoo
at 2017-03-03T17:30
at 2017-03-03T17:30
By Linda
at 2017-03-07T05:45
at 2017-03-07T05:45
By William
at 2017-03-10T19:54
at 2017-03-10T19:54
By Daph Bay
at 2017-03-11T10:33
at 2017-03-11T10:33
Related Posts
2017.W08 - Side-Channel Attack
By Sandy
at 2017-02-21T23:06
at 2017-02-21T23:06
新北市學生個資外洩
By Charlotte
at 2017-02-19T11:16
at 2017-02-19T11:16
python 網路 推薦書
By Anthony
at 2017-02-16T08:20
at 2017-02-16T08:20
2017.W07 PPTP - (Point to Point Tunneling Protocol
By Bennie
at 2017-02-14T20:50
at 2017-02-14T20:50
外交部出國登錄資料遭攔截 萬筆個資恐已外洩
By Lucy
at 2017-02-08T11:13
at 2017-02-08T11:13