Web Application Security（Web應用安全）

Web Application Security

1.web應用面臨的主要安全問題

　　1）黑客入侵：撞庫拖庫、網頁篡改、後門木馬、加密勒索、數據泄露

　　2）惡意內容

2.web應用安全現狀

　　1）網站安全問題：弱口令 > SQL注入 > 信息泄露 > 命令執行

　　2）web應用攻擊類型：Webshell探測  > 命令執行 > sql注入 > 文件包含 >文件上傳

　　3）漏洞類型：緩衝區溢出  > 跨站腳本 > 輸入認證 > SQL注入 > 權限許可與訪問控制

3.Web應用被攻擊的緣由：

　　自身存在漏洞

　　1）業務：缺少業務風險控制手段 。垃圾註冊大量用戶獲取出事擊放和投票權；繞過接口驗證機制，嘗試批量破解用戶帳號密碼（撞庫）

　　2）內容：不對UGC進行內容審覈。

　　3）數據層：數據明文存儲和傳輸。入侵後竊取用戶信息或篡改數據，例如篡改網頁

　　4）應用層：存在應用和業務邏輯漏洞。經過羅東入侵後端服務器和數據庫

　　5）主機層：弱口令、系統漏洞。經過系統漏洞入侵，並上傳後門、木馬

　　6）網絡層：沒有防範DDoS進攻的能力。DDoS/CC攻擊，形成業務中斷

　　7）移動APP:移動App未加固。反編譯破解App客戶端，得到敏感代碼，進而僞造或篡改信息，或製做仿冒應用

　　威脅持續加重

　　1）國家背景支持：政治動機驅動

　　2）漫無目的黑客：腳本小子。處處顯示本身能力的黑客

　　3）網絡犯罪：竊取金融信息、我的信息、DDOS、安裝Botnet等，主要經濟利益驅動

　　4）自動驅動型黑客：名利驅動型。能夠發動高難度的入侵，主要證實本身的能力；

　　5）白帽子：熱愛黑客技術，主要是幫助企業發現安全漏洞，多是專業也多是初學者

　　信息價值的飛速提高-》經濟利益

 

4.web應用安全類型

1）注入：

　　攻擊者發送惡意數據構造數據查詢或操做系統命令

　　注入類型包括：SQL注入、操做系統命令注入、XML注入、LDAP注入等

　　注入是解釋性語言（如腳本語言和標記型語言）不得不面對的挑戰性問題

　　危害：信息泄露（數據庫被竊取）、操做系統被控制

　　

　　SQL注入：

示例：2016年，中國銀行某站MySql注入（涉及管理員密碼/大量用戶卡號信息)

　　　　華爲某站存在SQL注入（17w用戶&任意文件下載）

　　　　天虹基金主站存在SQL注入

 

SQL注入的緣由：

　　對敏感字符不加過濾不作轉義處理

　　　　單引號篡改SQL語句

　　　　註釋符號  --或 /**/篡改SQL語句

　　　　分號；在同一字符串內執行多個數據操做

 

SQL注入代碼示例：

String query="SELECT * FROM accounts WHERE custID=' "+request.getParamenter("id")+"'";

惡意輸入

http://example.com/app/accountView?id='or'1 ='1'

被篡改後的SQL語語句

SELECT * FROM accounts WHERE custID='or'1'='1'
//即custID='  或 '1'='1'時，查詢accouts，但1恆等於1，因此該SQL就等價於 Select * From accouts

 

SQL注入預防

　　對輸入數據進行驗證/編碼/過濾

　　不要動態主裝SQL語句，正確使用預編譯SQL語句

　　若是須要動態組裝sql語句，確保在使用輸入數據在構造SQL以前，對特殊字符進行轉義

　　加固數據庫，控制損失範圍

　　　　禁止將任何高權限帳號（例如：root\data\sa等）用於應用程序數據庫訪問。更安全的方法是單獨爲應用建立有限權限的帳號

　　　　限制帳號所能訪問的數據表

　　　　拒絕帳號訪問敏感的系統存儲過程

 

2）失效的認證和會話管理

　　身份認證：用戶名/密碼>Token/PIN>指紋/臉掃描

　　會話管理：Http利用會話管理機制來實現鏈接識別。用戶登陸經過身份認證後獲取session,一般放在cookie中，以後根據session對用戶身份進行識別，而不須要每次都要登錄

　　危害：信息泄露、用戶會話被劫持

　　預防方法：

　　　　使用SSL保護用戶身份信息和sessionID

　　　　對用戶密碼強度設置作要求

　　　　登陸使用驗證嗎或雙因子認證帳號進行短時鎖定（雙因子

　　　　對連續屢次登陸失敗的帳號進行短時鎖定

不使用簡單或可預期的密碼保護問題

驗證成功後更換sessionID

不在URL中顯示sessionID

設置session閒置超時

確保退出、註銷功能強制銷燬session

 

3）跨站腳本攻擊（XSS)

　　攻擊者經過在Web頁面輸入點 注入惡意腳本，若web應用對輸入數據不進行處理，直接結果輸出到瀏覽器，瀏覽器將執行惡意腳本

　　XSS攻擊類型：

　　　　非持久型：也稱反射型XSS,經過Ge和post方法，將注入的惡意數據放置在URL的query字符串 或 form 數據中。若是服務器端對輸入的數據不進行過濾，驗證或編碼，將惡意數據直接呈現給客戶，可能會形成XSS

　　　　持久型，也叫存儲型XSS,一般由於服務器端未將輸入的惡意腳本經過驗證就直接存儲到數據庫

　　危害：Dos攻擊（使網絡阻塞/主機資源耗盡）、信息泄露、篡改網頁

　　示例：2011年，新浪微博Xss攻擊事件：大量用戶中毒後自動向本身的粉絲髮送帶連接的私信和微博，並自動關注一名hellosamy的用戶。因爲微博使用的是短連接，用戶只能看到誘人的新聞標題的私信和微博，當他們點擊連接後便也會中毒，形成惡性循環

 

　　預防方式：

　　　　編碼：直接將HTML標籤最關鍵的字符<>&編碼爲&it;&gt;&amp

　　　　過濾：將script/style/iframe/onmouseover等有害字符串去掉，但保留<>&等有限的基本標籤

　　　　防範XSS的真正挑戰在於全面

　　　　　　輸入過濾：比較低效，只使用過濾會很難全面（前端包含91中HTML標籤、十多種編碼方式、數種對象類型...），並且可能致使意外結果（例如：alice's變成alices)，有時候還須要屢次過來（例如：<scrip<script>t> ）

　　　　　　輸入編碼：可設計全局的解決方案

　　　　　　輸出編碼：用於解決輸入編碼沒法處理的已入庫數據

　　　　　　　　藉助第三方代碼庫

　　　　　　　　　　Java：OWASP的WSAPI與Java Encoder、Coverity Security Library(CSL）

　　　　　　　　　　JavaScript：Encoder.js、DOMPurify

 

4）不安全對象直接引用

　　用戶能夠經過修改訪問參數能夠直接訪問非受權信息（例如：http://www.ddd.com/userinfo.do?ID=3)

　　緣由：開發者未設置合理的訪問權限控制

　　示例：澳大利亞一個稅務局網站被攻擊者經過簡單的修改ID獲取了上萬家公司的信息

　　危害：信息泄露

　　預防方式：（如下方案結合使用）

　　　　使用隨機書使惟一標識變得難以猜想，增長攻擊難度

　　　　隱藏實際引用，使用隨機書爲直接引用標識，生成非直接引用標識

　　　　確保對每一個頁面的訪問都堅持訪問去權限和頁面全部權

 

5.Web 安全測試工具

　　白盒商業：

　　　　HPE Fortify(Static Code Analyzer)

　　　　IBM Security AppScan Source

　　　　CA Veracode Greenlight

　　　　Sonar Source Code Analyzers

　　白盒開源：

　　　　SonarQube,SonarLint

　　　　FindBugs

　　黑盒商業：

　　　　HPE Fortify WebInspect

　　　　SoapUI NG Pro

　　黑盒開源：

　　　　Selenium

　　　　soapUI

　　　　OWASP ZAP

　　　　sqlmap

　　　　Metasploit

　　　　w3af

　　　　Burp Suite

6.Web應用安全交互測試工具（即，開發時提示是否有漏洞）

　　　　商業：

　　　　　　HPE Fortify Declnspect

7.HPE Fortify 使用

　　Static Code Analyzer 源碼靜態掃描

　　WebInspect動態掃描

　　將掃描工具和集成Software Security Center。掃描發現的漏洞會自動建立SSC。SSC能夠對比先後測試結果改進，提供測試報表

 

8.Web安全控制的流程：

　　inital review

　　Threat modeling

　　Design review

　　Code review

　　Risk assessment

　　Risk mitigation

　　Benchmark

　　Maintain

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

　　

 

 

 

 

 

 

 

 

 

 

 

 

 

 

沒有對敏感字符