有趣的代碼攻防戰

寫在前面

今天這篇文章，是一篇關於代碼安全的內容。大部份內容可能對於如今來講都已經很小兒科了。可是我在瞭解這方面的內容時，着實仍是被這些前輩們腦洞大開的手段所折服。 因此今天就特意盤點了一些比較出名的漏洞問題。

漏洞大盤點

代碼漏洞

不安全的代碼-注入式攻擊

注入式（Inject）攻擊是一類很是常見的攻擊方式，其基本特徵是程序容許攻擊者將不可信的動態內容注入到程序中，並將其執行，這就可能徹底改變最初預計的執行過程，產生惡意效果。

一、XSS

1.一、反射型 XSS（非持久性跨站攻擊）

通常是利用網站某些頁面會直接輸出請求參數的特性，經過在 url 的請求參數包含惡意腳本，致使用戶打開該 url 的時候，執行惡意腳本。

例：http://localhost:8080/test.jsp?abc= <script>alert(「123」) </script>

用戶在訪問這個頁面的時候，就會觸發彈窗。

固然，通常的 XSS 攻擊不會這麼簡單的就讓你彈個窗，甚至可能彈出你的cookie信息。

1.二、存儲型 XSS（持久性跨站攻擊）

該種類型的攻擊通常是經過表單輸入（好比發佈文章、回覆評論等功能中）插入一些惡意腳本，而且保存到數據庫，待其餘用戶加載對應的頁面的時候，該段腳本就會被加載並執行。

與反射型 XSS 相比，該類的攻擊更具備危害性，由於它影響的不僅是一個用戶，而是大量用戶，並且該種類型還可進行蠕蟲傳播；就如以前的貼吧和微博事件，用戶訪問了含有惡意腳本的頁面，用戶的cookie信息被盜取了，而且馬上使用用戶的帳戶去發表新的帖子或微博同時注入惡意腳本，使得該惡意腳本不斷被傳播下去。

1.三、DOM Based XSS（基於 Dom 的跨站點腳本）

基於 DOM 的跨站點腳本與前面兩種類型有什麼區別呢？其實它注入的方式是基於前面兩種類型的方式的，只不過是注入的腳本是經過改變DOM來實施的。

採用該種方式有一個好處就是從源代碼中不易被發現而已。

如何去防禦 XSS

基於上面漏洞產生的緣由，咱們若要想防護該種攻擊，就須要從源頭抓起（用戶輸入），制定一套合理且安全的 XSS 過濾規則。 如下介紹一些過濾方法

對 HTML 標籤及一些特殊符號進行轉義

該種方法是一種很是簡單的過濾方法，僅僅是經過轉義的方式將一些 HTML 標籤和屬性轉義，好比 < 轉義成 &lt ;， 這樣像的腳本就運行不了。固然簡單的過濾方式也就表明很容易就會被繞過。 另外若是須要使用含有富文本的功能時，使用這樣的過濾就會使富文本失去做用。

使用白名單、黑名單的方式進行過濾

白名單、黑名單顧名思義是要定義哪些東西是可經過的，哪些東西不可經過。好比常見<b>、<p>; 、<等等標籤，不可經過的好比 javascript、<a>、<script>、<iframe>、onload 等等一些屬性，將其進行轉義。 固然使用該種方法也有自身的缺點，你並不可能窮舉出全部元素，也可能會某些元素在黑名單內，但在某些狀況它是須要使用的，這就須要咱們在設計 XSS 過濾器的時候權衡好，取最合理最適合需求的設計。

二、SQL注入

首先，就是最多見的SQL注入攻擊。一個典型的場景就是Web系統的用戶登陸功能，根據用戶輸入的用戶名和密碼，咱們須要去後端數據庫覈實信息。

假設應用邏輯是，後端程序利用界面輸入動態生成相似下面的 SQL，而後讓 JDBC 執行。 Select * from use_info where username = 「input_usr_name」 and password = 「input_pwd」

可是，若是我輸入的 input_pwd 是相似下面的文本，「 or 「」=」

那麼，拼接出的 SQL 字符串就變成了下面的條件，OR 的存在致使輸入什麼名字都是複合條件的。 Select * from use_info where username = 「input_usr_name」 and password = 「」 or 「」 = 「」 這個例子，各位小夥伴們應該很容易可以理解到它的攻擊性。上面例子中，程序指望用戶輸入一個數值，但實際輸入的則是SQL語句片斷。

根據這個套路，咱們就能夠注入不少很騷的SQL片斷了，好比刪庫，跑路之類的~

三、操做系統命令注入

操做系統命令注入。

好比：Java 語言提供了相似Runtime.exec(…)的API，能夠用來執行特定命令，假設咱們構建了一個應用，以輸入文本做爲參數，執行下面的命令： ls –la input_file_name

可是若是用戶輸入是：

input_file_name;rm –rf/* 那將是毀滅性的打擊，可是編程語言自己是作了不少的限制，這些操做未必能夠真的可以完成攻擊，可是這種隱患終究仍是存在的。

預防注入式攻擊

在 Java 應用進行數據庫訪問時，若是不用徹底動態的SQL，而是利用PreparedStatement，能夠有效防範 SQL 注入。無論是SQL注入，仍是OS命令注入，程序利用字符串拼接生成運行邏輯都是個可能的風險點！

在數據庫層面，若是對查詢、修改等權限進行了合理限制，就能夠在必定程度上避免被注入刪除等高破壞性的代碼。

暴力攻擊

臭名昭著-DoS攻擊

拒絕服務（DoS）攻擊，能夠說是名聲很響的暴力攻擊方式。

最多見的DoS攻擊有對計算機網絡的帶寬攻擊和連通性攻擊。帶寬攻擊指以極大的通訊量衝擊網絡，使得全部可用網絡資源都被消耗殆盡，最後致使合法的用戶請求沒法經過。連通性攻擊指用大量的鏈接請求衝擊計算機，使得全部可用的操做系統資源都被消耗殆盡，最終計算機沒法再處理合法用戶的請求。

哈希碰撞攻擊

哈希碰撞是一種有趣的攻擊方式。對方能夠輕易消耗系統有限的CPU和線程資源。從這個角度思考，相似加密、解密、圖形處理等計算密集型任務，都要防範被惡意濫用，以避免攻擊者經過直接調用或者間接觸發方式，消耗系統資源。

好比在Java中，有一個有趣的攻擊方式：

攻擊者能夠事先構造大量相同哈希值的數據，而後以Json數據的形式發送給服務器端，服務器端在將其構建成爲 Java 對象過程當中，一般以Hastable或HashMap等形式存儲，哈希碰撞將致使哈希表發生嚴重退化，算法複雜度可能上升一個數量級（HashMap1.8以後在紅黑樹結構的優化，也是應對此問題的優化），進而耗費大量CPU資源。衝突多了，就會極大的下降get的性能，形成極嚴重的卡頓，甚至服務器崩掉~

Android-WebView

addJavascriptInterface接口引發遠程代碼執行漏洞

此問題在4.2之後的版本被修復了

咱們Native和Js互相通信，可能會這麼寫咱們本地的Java代碼：

webView.addJavascriptInterface(new JSObject(), "mJSObject");
複製代碼

這段代碼是否是挺正常的？的確挺正常吶。若是咱們用民主富強文明和諧的眼光去看，的確沒問題。不過若是咱們懷着一顆搞破壞的心呢？ 咱們既然能拿到這個Java對象，那麼對於咱們來講，咱們可使用反射隨心所欲了。（這個問題，烏雲曾給出過明確的漏洞描述）

function execute(cmdArgs){
    for (var obj in window) {
        if ("getClass" in window[obj]) {
            alert(obj);
            return  window[obj].getClass().forName("java.lang.Runtime")
                 .getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);
        }
    }
}
複製代碼

不需多解釋吧，這是當前很著名的WebView漏洞問題。

• 1，WebView添加了JavaScript對象，而且當前應用具備讀寫SDCard的權限。
• 2，JS中能夠遍歷window對象，找到存在「getClass」方法的對象的對象，而後再經過反射的機制，獲得Runtime對象，而後調用靜態方法來執行一些命令，好比訪問文件的命令.
• 3，再從執行命令後返回的輸入流中獲得字符串，就能夠獲得文件的信息了。（理論上SD卡的全部內容均可以拿到了）

網絡傳輸

防不勝防 - 中間人攻擊

中間人攻擊原理大概是用戶在正常上網的時候，同網段的惡意用戶對其進行欺騙。惡意用戶向局域網廣播:我是路由器，而後正經常使用戶(電腦無防護)收到之後認爲惡意用戶就是路由器，而後向惡意用戶發送數據包，惡意用戶能夠截獲數據包，再向路由器發送正經常使用戶的數據包，路由器將返回的數據包在給惡意用戶，惡意用戶在給正經常使用戶，惡意用戶就造成了中間人的效果，能夠向返回的數據包注入html代碼，達到劫持用戶網站的效果，不過如今大部分的網站都是https且雙向認證，比較難獲取到用戶發送數據包中的帳號密碼。

CSRF攻擊

CSRF，全名：Cross site Request Forgery（跨站域請求僞造）。通常的攻擊方式是，經過請求僞造盜取用戶的cookie信息，進而進行操做。

• 一、首先用戶A請求登錄了服務器B，這時服務器 B 響應了用戶A，而且會返回惟一標識的該用戶的 cookie 信息。
• 二、用戶A在未退出服務器B時（即仍與服務器 B保持會話狀態），訪問了帶有惡意腳本的服務器 C，服務器 C 響應給用戶 A 一個惡意頁面，而且經過惡意腳本假裝用戶 A 向服務器 B 發送請求，此時服務器 B 誤覺得是用戶 A 請求，故響應並返回了用戶 A 的 cookie 信息。
• 三、服務器 C 收到用戶 A 與 服務器 B 的cookie信息後，保存起來，並利用該信息假裝成用戶 A 去訪問服務器 B，再進行相應的破壞~

尾聲

這部份內容，其實並不是是對深層技術的討論。只是最近無心中看到這部分的內容，感受頗有趣就收集起來寫了這篇文章，算是忙碌的工做之中娛樂一下吧~

這裏是一幫應屆生共同維護的公衆號，內容是咱們在從應屆生過渡到開發這一路所踩過的坑，以及咱們一步步學習的記錄，若是感興趣的朋友能夠關注一下，一同加油，一同努力~！~！