iT邦幫忙

2026 iThome 鐵人賽

0

DAY33 工作階段安全/XSS/CSRF

  • 一. 工作階段Session
    • 1-1 Session Token
  • 二. XSS 跨網站腳本攻擊
    • 2-1 XSS種類
    • 2-2 XSS防範
  • 三. CSRF 跨網站請求偽造
    • 3-1 XSS與CSRF的差異
  • 四. 整理SQL Injection、XSS、CSRF

一. 工作階段Session

當登入一個網站成功時,伺服器會建立一個Session
用來記住你是誰以及你的狀態

Session ID
伺服器用來辨識每個Session的一組唯一識別碼

1-1 Session Token

當登入成功時->
網站伺服器會給你一組Session Token
之後
每次請求時都會帶著Token
像身分證一樣
伺服器看到Token就會知道是你,不用再次登入

當登出了或超過一定的時間沒動作時->
Token就會失效,需重新登入

Session ID與Session Token的不同
Session ID
一把鑰匙,本身沒有資訊,要拿去開伺服器的櫃子才知道裡面有什麼
Session ID 送去伺服器->伺服器拿ID去查資料庫->找到對應身分資料
Session Token
一張身分證,本身就帶著各種資訊
Session Token 送去伺服器 ->伺服器直接解開Token -> 裡面已經寫好身分資料

工作階段劫持 Session Hijacking
攻擊者使用某種攻擊手法偷走Session Token
冒充你的身分去操作

Cookie儲存資料
網站存在我瀏覽器中的一小段資料
之後每次造訪同個網站時,瀏覽器會自動帶上對應的Cookie
伺服器就會讀取Cookie給的資料

常見用途:

  • Session Token
  • 偏好設定
  • 等等

二. XSS 跨網站腳本攻擊

Cross-Site Scripting
跨網站腳本攻擊

攻擊者把惡意程式碼注入網頁,其他使用者觀看頁面時,惡意程式碼可能被執行

IPAS 114-2 Q27
下列何種攻擊方法是利用網頁的輸入欄位或網址,插入惡意的腳本(Script),使其他使用者在瀏覽該網頁時執行該腳本?
A: 跨網站腳本攻擊,XSS

假設網站留言板有XSS漏洞:

正常使用者在留言板輸入:大家好

留言板正常紀錄:大家好

攻擊者則會輸入惡意Script:

結果網站沒有正確處理->
攻擊者輸入被當指令->
受害者瀏覽頁面->
受害者的瀏覽器執行Script

攻擊對象
SQL injection -> 資料庫Database
XSS -> 使用者的瀏覽器Browser

XSS通常會造成什麼危害
如果惡意Script在受害者的瀏覽器中執行成功,可能會:

  • 取得網頁中可存取的敏感資訊
  • 竊取Session資訊
  • 偽造畫面
  • 修改網頁顯示
  • 操作使用者目前的登入狀態

2-1 XSS種類

  1. 儲存型XSS Stored XSS
    • 攻擊者輸入的Script被網站儲存起來了
  2. 反射型XSS Reflected XSS
    • 惡意Script被送進伺服器後,伺服器沒過濾反射回瀏覽器執行
  3. DOM XSS
    • 文件物件模型XSS
    • 惡意Script被瀏覽器在前端執行

2-2 XSS防範

官方指引特別強調:
Web Application 需做好Input輸入的驗證

還有輸出也需要進行編碼(DAY32)

把原本可能被瀏覽器當成HTML或Script的特殊內容,轉成只顯示文字的安全形式

例如<script>其中的<和>被轉化成:
&lt和&gt
最終瀏覽器實際看到的是
&lt;script&gt而不是<script>

常見的編碼有:
<->&lt;
>->&gt;
"->&quot;
'->&#x27;

三. CSRF 跨網站請求偽造

利用受害者已經登入的Session,騙他的瀏覽器替攻擊者送出請求

前面說到:
網站在登入後,瀏覽器會存一個Session Token在Cookie裡
之後每次請求,瀏覽器都會自動帶上Cookie
而伺服器看到Cookie就認為是你本人在操作

CSRF:

  1. MIKEY登入了某個網站A(瀏覽器有了MIKEY的Cookie)
  2. MIKEY沒登出,跑去逛別的網站B
    • 因為沒登出所以Session Token還在
  3. 那個網站B藏了一個惡意程式碼:
    • 讓MIKEY的瀏覽器發送請求給網站A
  4. 瀏覽器看到是送給網站A的請求
    • 自動帶上MIKEY的Cookie
  5. 網站A看到是MIKEY的Cookie
    • 以為是MIKEY本人操作
    • 請求成功

3-1 XSS與CSRF的差異

XSS的攻擊者要:

讓攻擊者的Script在受害者的瀏覽器執行
執行程式碼

CSRF的攻擊者要:

你登入了,我要利用你的登入狀態,來替我請求
發送請求

IPAS 114-2 Q26
下列何項措施最能有效防禦跨站請求偽造(Cross-Site Request Forgery, CSRF)攻擊?
A: 在表單中加入隱藏的隨機令牌 CSRF Token

以上面的例子舉例:
正常使用者開起網站A時:

  1. 伺服器->
  2. 產生隨機的Token->
  3. 伺服器把CSRF Token藏在頁面裡,回傳給瀏覽器->
    • 可能是表單hidden欄位
    • 可能是<meta>標籤
  4. 使用者請求時,帶上CSRF Token
  5. 伺服器收到請求後,驗證Cookie,CSRF Token

攻擊者要從網站B偷偷發送請求給網站A時:

  1. 瀏覽器自動帶上Cookie
  2. 但Token藏在網站A,網站B讀不到,所以拿不到CSRF Token
  3. 伺服器驗證
    • Cookie 有
    • CSRF Token 沒有

這裡Session Token像身分證
而CSRF Token是今天的通關密語暗號
攻擊者偷用身分證進去,但他沒有通關密語

CSRF 和 Session Hijacking
Session Hijacking(劫持)
攻擊者偷走你的Session Token直接變成攻擊者的
CSRF
攻擊者沒有你的Session Token,只是騙你的瀏覽器幫攻擊者送請求

四. 整理SQL Injection、XSS、CSRF

攻擊 目標
SQL Injection 惡意SQL被資料庫執行
XSS 惡意Script被瀏覽器執行
CSRF 登入的狀態被騙跨網站送請求
Session Hijacking Session Token 被攻擊者偷走,冒充身分

上一篇
DAY32 應用程式安全
系列文
格鬥教練想轉職學資安是否搞錯了什麼(自學第一步)IPAS初級筆記 共 32 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言