iT邦幫忙

2021 iThome 鐵人賽

DAY 14
0
Security

從以卵擊石到堅若磐石之 Web API 安全性全攻略系列 第 14

Day14-守護餅乾大作戰(一)

前言

哈囉大家好,前幾天講完 HTTP Security Headers 之後今天緊接著要講 cookie,雖然 cookie 也是 header 的一部分,但因為 cookie 自己又有太多屬性,所以決定把它獨立出來講

cookie 的部分預計會花三天時間,今明兩天先把 cookie 跟安全有關的屬性 Secure、HttpOnly、SameSite 講一講,接著後天再示範怎麼在 Node.js 跟 Go 裡面把這些屬性加進 cookie 裡~

Secure

首先來講講最簡單的 Secure 屬性,我想大家應該都知道 cookie 會隨著請求一起發出去,所以若是請求發起時沒有使用 HTTPS,那 cookie 就也會以明文傳送,一不小心可能就會在路上被劫走 session ID,非常的不安全

為了解決這個問題,後來 cookie 就多了一個 Secure 屬性可以設定,只要你把這個屬性設定上去,那瀏覽器在發送 cookie 之前就會先看這個請求有沒有 HTTPS,有的話 cookie 才會一併出去

因為這個屬性實在太重要,現在應該大部分網站都有用了,像我剛剛上 Facebook 看他的 cookie 就全部都有 Secure 屬性,不然 cookie 被偷走真的太麻煩

HttpOnly

在以前沒有 HttpOnly 的時代,萬一你瀏覽的網站不小心中了 XSS 攻擊,也就是說那個網站上有駭客植入的腳本,那個惡意的 JS 腳本就可以直接透過 document.cookie 拿到你瀏覽器上儲存的 cookie。拿到 cookie 之後,這個惡意腳本可以把這些 cookie 發送到駭客自己的伺服器,此後就可以使用這些 session cookie 來到用你的身份

你可能會說「那工程師應該想辦法讓網站不要有 XSS 漏洞不是嗎?」,雖然話是這麼說沒錯,但跟資安有關的東西都很難做到百分之百,所以應該要做到即便網站中了 XSS 攻擊,駭客也沒辦法偷走 cookie

所以 HttpOnly 就是為此而來的,當你的 cookie 被加上 HttpOnly 屬性之後,那個 cookie 還是會跟著請求一起被發出去,但他就沒辦法被 JS 腳本存取,因此即便有駭客成功在網站上植入惡意腳本,那個腳本也拿不到你的 cookie,使用者的身份就也不會被盜用

因為這個屬性限縮了 XSS 攻擊能做到的事,所以很多網站都會在比較重要的 session cookie 上加上 HttpOnly,至於其他需要在瀏覽器上存取、而且被偷走好像也沒差的,就不加也沒關係~

小結

今天介紹了 Secure 跟 HttpOnly 這兩個 cookie 屬性,接著明天要講的是 CSRF 攻擊跟 cookie 的 SameSite 屬性

如果對於今天的內容有什麼問題歡迎在下方留言,沒問題的話那就明天見囉~


上一篇
Day13-記得要戴安全帽(三)
下一篇
Day15-守護餅乾大作戰(二)
系列文
從以卵擊石到堅若磐石之 Web API 安全性全攻略30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言