OWASP TOP 2013 (PPT) 投影片簡報翻譯為正體中文版。 ps. 原圖片版權為 OWASP 所有。 ps. 正體中文請依 CC 授權。

1. 微軟MVP最有價值專家
陳傳興, Bruce
OWASP Top-10 2013

2. 關於 OWASP
• 簡稱OWASP
• www.owasp.org / www.owasp.org.cn
• 開放社群、非營利組織
• 所有資源都可免費取得
• 目標在於提高Web應用程式的安全性
• 最有名為OWASP Top Ten Project
Open Web Application Security Project

3. 關於 OWASP Top 10
• 不是一份標準（standard）… “
OWASP Top 10 是一份認知文件
• 通過找出企業組織面臨的最嚴重的風險來提高開發人員對
應用程式安全性的關注度。
• 2010年開始以風險來進行排序，不僅僅對於流行程度。
Top 10
• 2003, 2004, 2007, 2010, 2013 (6/12)
發行 5 次
3

4. Top 10 2013
•由 7 家專業應用安全公司提供
•資料涵蓋上百家組織、上千個
應用
•分析超過 50萬個漏洞
Top 10 2013 文件

5. OWASP Top Ten (2013 Edition)
5

6. What Didn’t Change
• Title: “The Top 10 Most Critical Web Application
Security Risks”
• 標題：前十名最關鍵Web應用程式安全風險
它是關於風險，不是漏洞
• 基於OWASP風險評估方法論選出前10名
OWASP Top 10 風險評估方法論
6

7. 什麼是應用程式的風險？
7
• 攻擊者可以透過應用程式中許多不同的路
徑與方法去危害你的業務或組織。
• 每一種路徑即代表一種風險。

8. OWASP Top 10
風險評估方法論
Threat
Agent
攻擊途徑 漏洞普遍性 漏洞可檢測性 技術影響 商業影響
?
易 廣泛 易 嚴重
?平均 常見 平均 中等
難 少見 難 小
1 2 2 1
1.66 * 1
1.66 加權風險評估
注入範例
1
2
3
8

9. Olny You ~
• 確認一組最嚴重的風險。
• 只有您最了解自己的系統環境和企業情況。
• 你必須親自評估每一種風險。
Top 10重點
• 來自於攻擊類型
• 來自於漏洞
• 來自於造成的影響
Top 10的名稱

10. Mapping from 2010 to 2013
Top 10
OWASP Top 10 – 2010 (old) OWASP Top 10 – 2013 (New)
2010-A1 – Injection 2013-A1 – Injection
2010-A2 – Cross Site Scripting (XSS)
2013-A2 – Broken Authentication and Session
Management
2010-A3 – Broken Authentication and Session
Management
2013-A3 – Cross Site Scripting (XSS)
2010-A4 – Insecure Direct Object References 2013-A4 – Insecure Direct Object References
2010-A5 – Cross Site Request Forgery (CSRF) 2013-A5 – Security Misconfiguration
2010-A6 – Security Misconfiguration 2013-A6 – Sensitive Data Exposure
2010-A7 – Insecure Cryptographic Storage 2013-A7 – Missing Function Level Access Control
2010-A8 – Failure to Restrict URL Access 2013-A8 – Cross-Site Request Forgery (CSRF)
2010-A9 – Insufficient Transport Layer Protection 2013-A9 – Using Known Vulnerable Components (NEW)
2010-A10 – Unvalidated Redirects and Forwards (NEW) 2013-A10 – Unvalidated Redirects and Forwards
3 Primary Changes:  Merged: 2010-A7 and 2010-A9 -> 2013-A6
 Added New 2013-A9: Using Known Vulnerable
Components
 2010-A8 broadened to 2013-A7

11. 2013-A1 – 注入
• 這些攻擊發生在當不可信的資料（通常只是字串）作為命令或者查詢語句的一部
分，被發送給解譯器的時候。
注入意思是…
• 攻擊者發送的惡意資料可以欺騙解譯器，以執行計畫外的命令或者在未被恰當授
權時訪問資料。
• 例如SQL，OS Shell、、XPath、Hibernate以及 LDAP…等注入。
解譯器…
• 許多應用程式仍然易受影響（真的不知道為什麼）…其實我知道
• 即使它是非常簡單就能避免
SQL injection持續相當普遍
• 通常嚴重。整個資料庫通常能被讀取或修改。
典型影響
11

12. SQL Injection – 圖解
Firewall
Hardened OS
Web Server
App Server
Firewall
Databases
LegacySystems
WebServices
Directories
HumanResrcs
Billing
Custom Code
APPLICATION
ATTACK
NetworkLayerApplicationLayer
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
HTTP
request

SQL
query

DB Table


HTTP
response


"SELECT * FROM
accounts WHERE
acct=‘’ OR 1=1--
’"
1.應用程式向攻擊者呈現表單
2.攻擊者從資料中發送攻擊資料
3.應用程式轉送到資料庫造成的
SQL 查詢的攻擊
Account Summary
Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
4.資料庫執行包含攻擊的查詢，
並將加密的結果回傳給應用程式
5.應用程式解密為明文資料，並
將結果回傳給使用者
Account:
SKU:
Account:
SKU:
12

13. SQL Injection – 攻擊案例
• 應用程式存在有漏洞的SQL語句，使用不可
信資料：
• String query ="SELECT * FROM accounts
WHERE custID='" +
Request("id") +"'";

14. SQL Injection – 攻擊案例
• http://example.com/account?id='or '1'='1
• SELECT * FROM accounts
WHERE custID='" + Request("id") +"'";
• SELECT * FROM accounts
WHERE custID='' or '1'='1';

15. A1 – 避免注入弱點
• 最佳選擇是使用安全的API，完全避免使用解譯器或提供參數化介面
的API。
• .NET – ADO.NET參數化 / LINQ / Entity Framework
• 使用支援繫結變數的介面（例如：預存程序）
• 繫結變數允許解譯器在程式碼與資料之間進行區別
• .NET - ADO.NET的"@參數"
• 傳遞至解譯器之前，對所有使用者輸入進行編碼
• 始終對所有使用者提供的輸入執行白名單的輸入驗證
• 始終最小化資料庫權限，以減少漏洞發生時的影響
建議
• 更多資訊，請閱讀：
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
參考
15

16. 2013-A2 – 失效的身份認證和
會話管理
• 意思是憑證必須隨著每個請求傳送
• 一切需要進行身份驗證地方應使用 SSL
HTTP 是一個 “stateless” 協定
• SESSION ID 使用於追蹤狀態，因為 HTTP 不管
• 對於攻擊者，它也是一個好的憑證
• SESSION ID 典型的會暴露在網路、瀏覽器、日誌…
Session 管理弱點
• 密碼修改、記得我、記得密碼、忘記密碼、安全問題、登出、電子郵件…
提防點
• 帳戶洩露(accounts compromised)或使用者會話劫持 (sessions hijacked)
典型影響
16

17. 我的系統存在
Session劫持漏洞嗎？
• 身分驗證憑證沒有用Hash或加密保護？
• 憑證可猜測。
• 薄弱的帳戶管理。
• Session ID暴露在URL裡。
• Session ID沒有超時限制；或者，用戶登出後taken沒有失
效。
• 成功登入後，Session ID沒有替換。
• 密碼、Session ID和其他憑證未使用加密傳輸。
Session保護

18. 失效的身份認證圖解
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
1 使用者傳送憑證
2網站使用URL rewriting
(i.e., 放置sessio在URL)
3 使用者在論壇點擊連結http://www.hacker.com
www.boi.com?JSESSIONID=9FA1DB9EA...
4
Hacker檢查 www.hacker.com日誌
發現使用者的 JSESSIONID
5 Hacker 使用 JSESSIONID
並接收受害者帳戶

19. A2 – 避免失效的身份認證和
會話管理
• 認證應該是簡單，集中與標準化
• 使用由您的容器提供的標準Session Id
• 在所有時間使用SSL保護憑證與Session Id
驗證你的架構
• 忘記自動化分析方法
• 檢查你的SSL憑證
• 檢查所有認證相關的功能
• 驗證登出有實際摧毀Session
驗證實作
• https://www.owasp.org/index.php/Authentication_Cheat_Sheet
參考
19

20. 2013-A3 –
跨站腳本(XSS)
• 來自攻擊者的原始資料被發送到無辜使用者的瀏覽器
• 原始資料沒有經過適當的驗證或轉義 (escape) ，就會導至 XSS
發生任何時間…
• 儲存在資料庫
• 從Web輸入(欄位、隱藏欄位、RUL等) 而來
• 直接傳送JavaScript的值到用戶端
原始資料…
•嘗試在你的瀏覽器輸入
• javascript:alert(document.cookie)
幾乎所有Web應用程式都有此問題
•竊取使用者的Session、竊取敏感性資料、改寫網頁內容、將使用者重導向到網路釣魚或惡意軟體的網站
•大多數嚴重： 安裝 XSS 代理伺服器的攻擊者可以觀察和直接控制在易受攻擊網站上的所有使用者的行為，強制
連線到其他網站
典型影響
20

21. 跨站腳本圖解
應用程式儲存 XSS 漏洞
3
2
攻擊者設置陷阱 — — 更新設定檔
攻擊者將惡意的腳本輸入
到一個網頁，並在伺服器
上存儲的資料
1
受害者瀏覽網頁 — — 攻擊者的設定檔
腳本以安靜方式傳送受害者的Session / Cookie
腳本運行在受害者的瀏覽
器內且具有完全DOM和
Cookie存取權限
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
21

22. 避免 XSS 漏洞
• 消除漏洞
• 不要在輸出頁中包括使用者提供的輸入 – 但不太可能
• 抵禦漏洞
• 使用內容安全策略(Content Security Policy, CSP)
• 主要建議: 輸出編碼所有使用者提供的輸入
• 依據將要放置於的位置（Body、屬性、JavaScript、CSS、URL）對所有不可信的資
料進行合適的轉義。
• 對所有包含使用者輸入的頁中執行 '白名單' 輸入驗證
• 為使用者支援 HTML，去除有害 HTML 使它安全
建議
• 有關如何正確輸出編碼：
https://www.owasp.org/index.php/XSS_(Cross Site Scripting)
Prevention Cheat Sheet
參考
22

23. 在各種HTML執行環境
進行安全的計畫
CSS 屬性值
(e.g., .pdiv a:hover {color: red; text-decoration:
underline} )
JavaScript 資料
(e.g., <script>
someFunction(‘DATA’)</script> )
HTML 屬性值
(e.g., <input name='person' type='TEXT'
value='defaultValue'> )
HTML 元素內容
(e.g., <div> some text to display </div> )
URI 屬性值
(e.g., <a href=" http://site.com?search=DATA" )
#4: 所有非字母與數字 < 256  HH
ESAPI: encodeForCSS()
#3: 所有非字母與數字 < 256  xHH
ESAPI: encodeForJavaScript()
#1: ( &, <, >, " )  &entity; ( ', / )  &#xHH;
ESAPI: encodeForHTML()
#2: 所有非字母與數字 < 256  &#xHH;
ESAPI: encodeForHTMLAttribute()
#5: 所有非字母與數字 < 256  %HH
ESAPI: encodeForURL()
其他所有環境都不能包含不受信任的資料
建議：僅允許 #1 和 #2，不允許其他
查看: www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet23

24. XSS / CSRF
•攻擊者同樣能使用XSS攻
破應用程式使用在CSRF
（見A8）的防禦機制。
注意

25. 2013-A4 –
不安全的直接物件參考
• 對於系統的某部分，是否只使用者只具有部分存取權限？
• 這是執行正確“授權”的一部分。（隨著A7）
您如何保護您的資料存取？
• 僅列出當前使用者的授權物件，或
• 隱藏物件參考在隱藏欄位
• … 在伺服器端不執行這些限制
• 這稱做表現層存取控制…就只是在表現
• 攻擊者只需篡改參數值
常見錯誤…
• 使用者能夠存取未授權的檔案或資料
典型影響
26

26. 不安全的直接物件參考圖解
• 攻擊者注意他的 acct 參
數是 6065
?acct=6065
• 他修改數字
?acct=6066
• 攻擊者查看受害者的帳戶
資訊
https://www.onlinebank.com/user?acct=6065
27

27. A4 –
避免不安全的直接物件參考
• 消除直接物件參考
– 為它們替代一個臨時對應值 (例如：1, 2, 3)
• 驗證直接物件參考
– 驗證參數值的格式正確
– 驗證使用者是否允許存取目標物件
• 查詢限制是正常作業
– 驗證請求模式允許對目標物件存取
(例如：讀取、寫入、刪除)
http://app?file=1
Report123.xls
http://app?id=7d3J93
Acct:9182374http://app?id=9182374
http://app?file=Report123.xls
Access
Reference
Map
28

28. A4 –
避免不安全的直接物件參考
• 使用基於使用者或Session的間接物件存取。這樣
能防止攻擊者直接攻擊未授權的資源。例如，一個
下拉式選單包含授權給當前使用者的6個資源，它
可以使用數字1～6來表示使用者選擇的值，而不
是使用資源在資料庫裡的關鍵字。
• 檢查存取。任何來自不可信任來源的直接物件請求
都必須通過存取控制的檢測。
如何防止

29. 2013-A5 – 安全配置錯誤
• 可以發生在一個應用程式的任何層面，從作業系統、Web伺
服器、App伺服器、資料庫、框架…
Web應用程式依賴於一個安全的基礎
• 組態的影響通常是比較全面性
• .NET – web.config 組態檔
組態管理必須延伸到應用程式的所有部分
• 經有漏洞的作業系統或缺少修補程式來安裝後門程式
• 未經授權存取預設帳戶、應用程式功能或資料 – 經由較差的
伺服器配置
典型影響

30. Hardened OS
Web Server
App Server
Framework
安全配置錯誤圖解
App Configuration
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
Test Servers
QA Servers
Source Control
Development
Database
內部人員

31. 我易受到攻擊嗎？
• 所有層面 (OS / Web / App / DB …) 是否有即時更
新？(當然包含你的程式碼)
• 是否安裝或啟用不必要的功能？ (埠口、服務…)
• 預設帳戶或預設密碼是否依然可用？
• 錯誤訊息是否含有大量錯誤資訊？
• 框架 (Struts、Spring、ASP.NET …) 的安全設置是
否理解並正確配置？
關注點

32. 2013-A6 – 敏感資料外洩
• 未能識別的所有敏感性資料
• 未能確定此敏感性資料所存儲的所有地方
• 資料庫、檔案、目錄、日誌檔、備份…等
• 未能確定此敏感性資料被傳送的所有地方
• 在Web上、到後端資料庫，向業務夥伴，
內部通信
• 未能適當地保護每個位置的資料
存儲和傳輸敏感性資料不安全

33. 2013-A6 – 敏感資料外洩
• 攻擊者可存取或修改保密資訊或私人資訊
• 例如，信用卡、健康記鍵、財務資料 (你的或你的客戶
的)
• 攻擊者提取秘密使用在其他攻擊中（例如，社交詐騙）
• 公司的尷尬、 顧客的不滿和失去信任
• 處理事故：如取證、發出道歉信、補發數以千計的信用卡、
提供身份盜竊保險的費用
• 商業上被起訴或被罰款
典型影響

34. 不安全的加密儲存圖解
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
1
受害者在表單中輸入信
用卡卡號
2因為主機閘道不正常，錯
誤處理常式CC詳細的日誌
4 惡意內部人員偷取
400 萬信用卡卡號
Log files
3日誌是用於偵錯目的，所
有IT部門成員都能存取

35. 避免不安全的加密儲存
• 確認所有的敏感性資料， 並且是否都被加密，特
別是備份的資料。
• 傳輸過程是否為明文傳輸？在 Internet 明文傳輸
是非常危險的。
• 是否還在使用舊的或弱的加密演法。例如，MD5。
• 使用加密來應付威脅，不只是進行資料”加密”。
驗證你的架構
• 檔案加密、資料庫加密、資料元素加密…
適當的機制保護

36. 傳輸層保護不足圖解
Custom Code
員工
商業夥伴
外部受害者
Backend Systems
外部攻擊者
1
外部攻擊者從非
網路來竊取憑據
和資料
2
內部攻擊者從內部
網路來竊取憑據和
資料
內部攻擊者

37. 案例
• 一個身份驗證網頁沒有使用SSL。
• 攻擊者只需收集網路封包 (開放的有線或無線網路) ，即可取
得受害者所有資訊。
#1
• 密碼使用unsalted的Hash演算法來儲存。
• 怪客取得密碼資料，這些未使用unsalted Hash演算法加密
的密碼，都可以輕易使用暴力破解法破解。
#2

38. 2013-A7 –
功能等級存取控制缺失
• 匿名使用者可以存取私人網頁嗎？
• 網頁因為權限沒有控管好，使得攻擊者可透過網址直接存取能夠擁
有權限或進階資訊的頁面。
• /admin、/backup、/logs、/manage …
你如何保護存取 URL (網頁)？或會參考 URL 上參數的功能？
• 攻擊者呼叫的功能和服務，需經過但沒經過授權
• 存取其他使用者帳戶的資料
• 執行特權的行動
典型影響

39. 功能等級存取控制缺失圖解
• 攻擊者注意到該URL包含
他的角色
/user/getAccounts
• 他修改為其他目錄 (角色)
/admin/getAccounts, or
/manager/getAccounts
• 攻擊者查看更多帳戶資訊
，不僅僅是他們自己
https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts

40. 避免功能等級存取控制缺失
• 限制已認證使用存取 (如果是未公開的)
• 執行任何基於使用者或基於角色的權限設置 （如果是私有的）
• 完全禁止對未經授權的頁面類型請求 (例如，config 檔、log 檔、
source 檔…等)
對於功能，網站需要做好
• 先用管理者權限瀏覽一遍所有功能，然後用普通使用者再瀏覽所有功能。
• 「展示層存取控制」實際上並不提供保護，你應該實現存取層或商業邏
輯層的檢查。
驗證你的架構

41. 2013-A8 –
跨站請求偽造 (CSRF)
• 攻擊受害者的瀏覽器騙到易受攻擊的 Web 應用程式發出命令
• 漏洞是由於瀏覽器在每個請求會自動包括用戶驗證資料 (Session ID，IP
Adress，Windows 網域憑證…等)
跨站請求偽造
• 如果一個駭客可以在你的線上銀行應用程式引導您的滑鼠和讓你按一下的連結？
• 他們會讓你做什麼？
想像一下…
• 啟動交易 (轉帳、登出使用者、關閉帳戶)
• 存取敏感性資料
• 變更帳戶資訊
典型影響

42. CSRF 漏洞模式
• 問題
– 網頁瀏覽器會自動包含許多憑證在每一個請求
– 即使請求是由表單、腳本或另一個網站的圖片
• 所有單純依靠自動認證的網站是脆弱的
– (幾乎所有的網站都這樣)
• 自動提供的憑證
– Session cookie
– Basic authentication header
– IP address
– Client side SSL certificates
– Windows domain authentication

43. CSRF 圖解
3
2
攻擊者在網路上某些網站設置陷阱
(或簡單經由 E-Mail)1
當登入有弱點網站，受害者觀看攻擊者的網站
易受攻擊網站看到從受
害者的合法請求和執行
請求的操作
<img> 標籤由瀏覽器登入
– 傳送 GET 請求 (包含憑
證) 到易受攻擊的網站
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
隱藏 <img> 標籤包含對
易受攻擊的網站攻擊
CSRF 漏洞的應用程式

44. A8 – 預防CSRF漏洞
• 將一個秘密不會自動提交的token添加到所有敏感性請求
– 這使得攻擊者不可能在欺騙請求
• (除非有一個XSS漏洞在你的應用程式)
– Token 應該使用強壯的加密或隨機字串
• 選項
– 在Session儲存單一的token並加到所有表單與連結
• 隱藏欄位: <input name="token"
value="687965fdfaew87agrde" type="hidden"/>
• 單次使用的 URL: /accounts/687965fdfaew87agrde
• 表單 Token: /accounts?auth=687965fdfaew87agrde …
– 小心洩露token在referer標頭
• 建議使用隱藏欄位
– 針對每個功能使用唯一的 token
• 使用雜湊功能名稱、Session id
– 敏感性功能要求二次身份驗證
– 透過 CAPTCHA 以判明他們是一個真實的人
• 不允許攻擊者儲存攻擊到你的網站
– 正確編碼所有的輸入
• 查看: www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

45. 1
10
100
1,000
10,000
100,000
1,000,000
10,000,000
100,000,000
每個人都在使用
有漏洞的函式庫
2900 萬有漏洞的
下載 - 2011
Libraries 31
Library
Versions
1,261
Organizations 61,807
Downloads 113,939,358
Vulnerable
Download
26%
Safe
Download
74%
https://www.aspectsecurity.com/news/press/the-unfortunate-reality-of-insecure-libraries

46. 2013-A9 –
使用含有已知漏洞的組件
• 一些有漏洞組件 (例如：框架、函式庫) 能被自動化工具確認與利用
• 這將擴大有針對性的攻擊者的威脅區域
有漏洞組件是常見的
• 幾乎每個應用程式都有這些問題，因為大多數開發團隊並不側重於確保它們
的元件或函式庫都是最新
• 在許多情況下，開發人員甚至不知道他們正在使用的所有元件，也不介意它
們的版本。
普遍的
• 全方位的漏洞可能包括注入，失效的存取控制，XSS…
• 影響可能範圍從最小到完整主機接管與資料洩漏…
典型影響
47

47. 你能做些什麼來
避免這種情況？
• 自動化定期檢查 (例如，nightly build)，如果你的函式庫已過時的話
• 自動化也能告訴你已知的漏洞
理想
• 由專人定期檢查，看看你的函式庫是否已經過時和升級那些
• 如果有任何過時元件，但你真的不想升級，請檢查是否有與這些已知安全問題漏洞資料
庫
• 如果是這樣，請升級那些含已知安全問題的部分元件
最低限度
• 由專人定期檢查，看看是否有你使用的函式庫含有已知的漏洞
• 檢查 CVE或其他 vuln 資料庫
• 如果有任何訊息，至少更新這些元件
應該也
48

48. Automation Example for Java
– Use Maven ‘Versions’ Plugin
Output from the Maven Versions Plugin – Automated Analysis of Libraries’ Status
against Central repository
Most out of Date! Details Developer Needs
This can automatically be run EVERY TIME software is built!! 49

49. 漏洞資料庫
• CVE
– http://cve.mitre.org/
• National Vulnerability Database
– http://nvd.nist.gov/
• SecurityFocus
– http://www.securityfocus.com/bid
• VUPEN Security
– http://www.vupen.com/english/

50. 2013-A10 –
未驗證的重導向與轉送
• 經常包括在目標 URL 裡提供使用者的參數
• 如果它們沒有被驗證，攻擊者可以轉送受害人到他們選擇的網站
Web 應用程式重導向是非常常見
• 他們在同一個應用程式內部將請求轉送到一個新的頁面
• 有時，參數定義了目標頁面
• 如果未驗證，攻擊者可能能夠使用未經驗證的轉送繞過身份驗證或授權檢查
轉送 (在.NET名Transfer) 也是常見
• 將受害者重導向到網路釣魚或惡意軟體的網站
• 攻擊者的請求轉送通過安全檢查，從而取得未經授權的功能或資料存取
典型影響

51. 未驗證的重導向圖解
3
2
攻擊者經由 Email 或網頁寄送攻擊內容給受害者
From: 國稅局
Subject: 我們的記錄顯示，你的退稅
款項尚未領取，請點擊這裡開始你的
退款作業。
1
應用程式重導向受害者
到攻擊者網站
請求發送給易受攻擊的網站
，其中包括攻擊者的目標網
站作為參數。發送重導向到
受害者攻擊者的網站
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
4 邪惡網站會安裝惡意軟體或
使用網路釣魚取得隱私訊息
受害者點擊含有未經驗證的參數鏈接
Evil Site
http://www.irs.gov/taxrefund/claim.jsp?year=2006
& … &dest=www.evilsite.com

52. 未驗證的轉送圖解
2
攻擊者攻擊脆弱的網頁，他們有機會獲得1
應用程式授權請求，依
然是脆弱網頁
請求傳送到脆弱的網頁，
其中使用者就可以存取。
重導向直接轉向到使用者
的私人網頁，並繞過存取
控制。
3 轉送頁面無法驗證參數，攻擊者轉送
至未經授權的網頁，成功繞過存取控
制
public void doPost( HttpServletRequest request,
HttpServletResponse response) {
try {
String target = request.getParameter( "dest" ) );
...
request.getRequestDispatcher( target
).forward(request, response);
}
catch ( ...
Filter
public void sensitiveMethod(
HttpServletRequest request,
HttpServletResponse response) {
try {
// Do sensitive stuff here.
...
}
catch ( ...

53. A10 –
避免未驗證的重導向與轉送
• 當你可以時，避免使用重導向與轉送
• 如果使用，不要用使用者參數去定義目標URL
• 如果你“必須”包括使用者參數，那麼就要
• 驗證每個參數，以確保其有效和授權為當前使用者
• (首選) – 使用伺服器映射去解析提供給使用者實際目標頁面的選擇
數個選項
• 理想情況下，在你執行轉送前，你會先呼叫存取的控制器，確保用
戶被授權
• 最好是確保可以訪問原始頁面的使用者有權限存取目標頁面
一些關於保護轉送的想法

54. 網站淪陷資料庫
• Zone-H
– http://www.zone-h.org
• </xssed>
– http://www.xssed.com/archive

55. Thank you
OWASP Top-10 2013