web應用存在的10大安全問題，安全測試不容忽視！
隨著web、社交網路等一系列新型的網際網路產品的不斷升級，基於Web環境的網際網路應用越來越廣泛，企業資訊化的過程中各種應用都架設在web平臺上，Web業務的迅速發展也引起黑客們的強烈關注，接踵而至的就是web安全威脅的凸顯，對web伺服器的攻擊可以說是形形色色。
先回顧一下前幾年發生過的由於網際網路安全問題引發的事件
1、攜程網使用者支付資訊出現漏洞：漏洞洩露的資訊包括使用者的姓名、身份證號碼、銀行卡卡號、銀行卡CVV碼
2、UC瀏覽器使用者敏感資料洩漏的漏洞：只要使用者通過UC瀏覽器搜尋並登入人人、新浪微博等網站，其提交的使用者資訊和密碼都有可能被黑客擷取
3、小米論壇存在使用者資料洩露：洩露涉及800萬小米論壇註冊使用者
那麼造成這些問題的原因是什麼呢？下面我來為大家進行分析。
web應用通常存在的10大安全問題
- SQL注入
拼接的SQL字串改變了設計者原來的意圖，執行了如洩露、改變資料等操作，甚至控制資料庫伺服器， SQL Injection與Command Injection等攻擊包括在內 - 跨站指令碼攻擊（XSS或css）
跨站指令碼(Cross-Site Scripting)是指遠端WEB頁面的html程式碼可以插入具有惡意目的的資料，當瀏覽器下載該頁面，嵌入其中的惡意指令碼將被解釋執行，從而對客戶端使用者造成傷害。簡稱CSS或XSS - 沒有限制URL訪問
系統已經對URL的訪問做了限制，但這種限制卻實際並沒有生效。攻擊者能夠很容易的就偽造請求直接訪問未被授權的頁面 - 越權訪問
使用者對系統的某個模組或功能沒有許可權，通過拼接URL或Cookie欺騙來訪問該模組或功能 - 洩露配置資訊
伺服器返回的提示或錯誤資訊中出現伺服器版本資訊洩露、程式出錯洩露物理路徑、程式查詢出錯返回SQL語句、過於詳細的使用者驗證返回資訊。 - 不安全的加密儲存
常見的問題是不安全的金鑰生成和儲存、不輪換金鑰，和使用弱演算法。使用弱的或者不帶salt 的雜湊演算法來保護密碼也很普遍。外部攻擊者因訪問的侷限性很難探測這種漏洞。他們通常必須首先破解其他東西以獲得需要的訪問。 - 傳輸層保護不足
在身份驗證過程中沒有使用SSL / TLS，因此暴露傳輸資料和會話ID，被攻擊者截聽，或使
用過期或者配置不正確的證書。 - 登入資訊提示
使用者登入提示資訊會給攻擊者一些有用的資訊，作為程式的開發人員應該做到對登入提示信
息的模糊化，以防攻擊者利用登入得知使用者是否存在 - 重複提交請求
程式設計師在程式碼中沒有對重複提交請求做限制，這樣就會出現訂單被多次下單，帖子被重
復發布。惡意攻擊者可能利用此漏洞對網站進行批量灌水，致使網站癱瘓 - 網頁尾本錯誤
訪問者所使用的瀏覽器不能完全支援頁面裡的指令碼，形成“指令碼錯誤”，也就是網站中的腳
本沒有被成功執行。遇到“指令碼錯誤”時一般會彈出一個非常難看的指令碼執行錯誤警告視窗
在OWASP（The Open Web Application Security Project）的安全問題TOP10裡，以下幾個佔比超過50%：
sql注入：
拖庫
通過技術手段，利用網站安全漏洞把伺服器資料庫中的資料全部或部分獲取；網站越大，使用者資訊越多，拖庫的影響越大，危害越大
撞庫
很多使用者在登入不同網站時為了圖方便好記，往往喜歡用統一的使用者名稱和密碼，黑客把拖庫取得的使用者名稱及密碼跟網路銀行、支付寶、淘寶等有價值的網站進行匹配登入，這就是“撞庫”
爆破
俗稱“暴力破解”或“爆破”，對已知的使用者名稱，使用密碼字典庫暴力嘗試、破解使用者密碼；如果網站不限制密碼重試次數，被爆破成功的概率較高，這裡的拖庫，就是我們平時所說的sql注入，利用前端和後臺的疏忽，將後臺資料庫中的資料全部拖出
解決辦法：
1. 不要信任使用者的輸入，對使用者的輸入進行校驗
正則校驗、長度限制、特殊字元轉碼（' --）
2. 不要使用動態拼接SQL
引數化sql、型別判定
3. 不要使用管理員許可權的資料庫連線
為每個應用開放有限的獨立許可權
4. 資料庫機密資訊不要明文儲存 加密、hash
5. 異常資訊不要直接返回給使用者
使用自定義的錯誤資訊進行包裝
跨站指令碼攻擊（Cross Site Scripting）
這裡解釋一下，因為跨站指令碼攻擊的縮寫是CSS，為了與CSS區分，所以這裡縮寫為XSS
攻擊者向web頁面裡插入惡意html程式碼 使用者瀏覽該頁之時，嵌入其中的html程式碼會被執行，通常以獲取使用者cookie為目的注入內容以javascript為主，xss又分反射型和儲存型，兩者原理類似反射型xss的特點是請求即執行；而儲存型xss的特點是先儲存，再執行；
大概過程可以用一張圖概括
解決辦法：
內容過濾：過濾關鍵字 "javascript..."
轉碼：分號、<>...
Cookie屬性:Secure、http-only
失效的身份認證和會話管理
這類問題細分起來種類繁多，舉幾個有代表性的吧
web應用在開發時，可能存在為了實現需求而自定義身份認證方式或會話管理方式，例：會話id存在url中，這樣如果直接copy別人的url，那麼可以直接使用這個人的賬戶資訊；使用者名稱、密碼等資訊cookie未設定過期時間，那麼當他人登入同一客戶端時，也可能會直接使用他人賬戶；
解決辦法：
避免未經授權訪問會話狀態
限制會話壽命
對身份驗證 cookie 的內容進行加密
不要在網路上以純文字形式傳送密碼
在web應用程式中是什麼導致安全性問題呢？一般有以下幾個原因
- 複雜應用系統程式碼量大、開發人員多、難免出現疏忽
- 系統屢次升級、人員頻繁變更，導致程式碼不一致
- 歷史遺留系統、試執行系統等多個Web系統共同運行於同一臺伺服器上
- 開發人員未經過安全編碼培訓或者公司根本就沒有統一的安全編碼規範
- 測試人員經驗不足或者沒經過專業的安全評估測試就釋出上線
- 沒有對使用者的輸入進行驗證：
1）永遠不要信任使用者的輸入，要對使用者的輸入進行校驗
2）數字型的輸入必須是合法的數字
3）字元型的輸入中對 編碼符號要進行特殊處理
4）驗證所有的輸入點，包括Get，Post，Cookie以及其他HTTP頭
總結：
Web安全是我們測試組一直以來作為和效能測試並駕齊驅的兩個重點。開發的過程中還需要著重注意，該轉義的地方轉義；該遮蔽的地方遮蔽，該過濾的地方過濾等等。下半年又到了，勢必又有大批的發號抽獎之類的活動開發、上線，在這個過程中，安全問題是我們每個人應該緊繃的神經，對於我們測試人員來說，每個活動需要做到手動安全測試加自動化安全測試相結合。
歡迎加入51軟體測試大家庭，在這裡你將獲得【最新行業資訊】，【免費測試工具安裝包】，【軟體測試技術乾貨】，【面試求職技巧】... 51與你共同學習，一起成長！期待你的加入： QQ 2173383349
關注51Testing軟體測試網，提升it技能，從不會到熟練只差一步。