web安全漏洞加固方案简析
2019獨角獸企業重金招聘Python工程師標準>>>
????本文比較粗糙，作用是引領大家認識web安全漏洞并根據自己參與的安全加固工作提供一些解決思路。
開始——安全掃描報告
? ? Web應用的安全加固是從安全掃描報告（當然有經驗的架構師和軟件工程師可以在架構和編碼時將漏洞消滅于萌芽），加固人員通常根據報告的內容針對性的完善程序漏洞。
????目前一下是見過IBM Relational AppScan、Fortity、Acunetix Website Audit的安全掃描報告（由于涉及漏洞信息，具體的內容就不展示了）。
IBM Relational AppScan
?
Fortity
Acunetix Website Audit報告
????如果能使用安全掃描工具進行掃描，那就更好了，畢竟報告是掃描工具生成的，掃描工具的結果更詳細，更具參考性。如IBM Relational AppScan。
IBM Relational AppScan掃描結果
消滅漏洞——安全漏洞分析
????以IBM Relational AppScan的漏洞結果為例，我們常見的漏洞如下，大致分4個級別
????????Microsoft Windows MHTML 跨站點腳本編制【級別-高】
????????SQL 盲注【級別-高】
????????已解密的登錄請求【級別-高】
????????跨站點請求偽造【級別-中】
????????鏈接注入【級別-中】
????????通過框架釣魚【級別-中】
????????Autocomplete HTML Attribute Not Disabled for Password Field【級別-低】
????????Internal IP Disclosure Pattern Found in Parameter Value【級別-低】
????????檢測到文件替代版本【級別-低】
????????臨時文件下載【級別-低】
????????HTML敏感信息泄露【級別-參考】
????????發現電子郵件地址模式【級別-參考】
????????發現內部IP泄露模式【級別-參考】
????????潛在的文件上載【級別-參考】
?
注：為避免信息泄漏，請求中很多無關信息進行了修改，關鍵部分不會變更
Microsoft Windows MHTML 跨站點腳本編制【級別-高】
攻擊請求示例?
/demo/page/city/cityAction.do?method=cityTree&uid=1378952840737&id=Content-Type:%20multipart/related;%20boundary=_AppScan%0d%0a--_AppScan%0d%0aContent-Location:foo%0d%0aContent-Transfer-Encoding:base64%0d%0a%0d%0aPGh0bWw%2bPHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw%2b%0d%0a&a_dhx_rSeed=1378952840737
攻擊結果
<?xml?version='1.0'?encoding='utf-8'?> <tree?id="Content-Type:?multipart/related;?boundary=_AppScan --_AppScan Content-Location:foo Content-Transfer-Encoding:base64PGh0bWw+PHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw+ "></tree>攻擊說明
??? 通俗的講，這個漏洞就是攻擊者將一段惡意腳本已參數的形式發往后臺，若web應用沒有進行防御將腳本返回前臺，HTML將會將惡意代碼嵌入頁面，之后用戶信息將暴漏給攻擊者。
????以上面的漏洞為例，這個請求是JavaScript控件生成的，請求將根據一個id查詢其子節點數據并返回，由于樹形控件需要將數據返回前臺并拼接樹，所以id屬性會返回前臺。
????當攻擊者使用HTTP請求分析工具（如HttpWatch、瀏覽器自帶的開發人員工具）獲取該請求地址后，可以修改id的屬性。如果后臺沒有對id屬性進行校驗，那么攻擊腳本將會顯示在頁面，用戶的后續操作將暴漏給攻擊者。
?
建議加固方案
啟動校驗框架，對請求參數進行校驗，比對使用正則表達式對id的值進行校驗——只能是字母和數組。
目前主流的框架如struts、spring都提供了豐富、靈活的校驗框架，加上正則表達式的支持，安全加固工作可以快速的開展。
?
額外說明
a) 這個已經到http請求級別，javascript的校驗框架早已跳過（不得不說javascript校驗是紙老虎，限制一下合法用戶的輸入）
b) 有人會說我輸入合法的id信息，但是不是這用戶有權限管理的id，這個怎么處理？首先，這個不是安全漏洞，應當算作業務漏洞，說明程序在鑒權模塊的設計不夠完善；其次，安全漏洞不應當嵌入業務邏輯中進行，進行加固的最佳位置的進入“控制層”之前（所有的框架都是這樣做的），進行業務校驗的最佳位置是“業務層”之前（簡單系統建議使用AOP的方式在業務代理層中實現）。
?
SQL 盲注【級別-高】
攻擊請求示例
POST /demo/page/reportgroup/ReportGroupUpdate.do?method=add&name=1234%2F**%2Fand%2F**%2F7659%3D7659&parentId=&parentName=1234&addUserGroup=&delUserGroup=&delReportGroup=&reportList=&description=1234
?
攻擊說明
??? 非嚴謹的解釋就是攻擊者將惡意代碼已請求參數的形式傳入后臺，若后臺進行數據庫查詢，惡意代碼嵌入到SQL語句，使攻擊者可以獲得額外信息。假設原SQL是select * from t_user t where t.id = ?，若攻擊者注入* and 1=1，那么sql將是select * from t_user t where t.id = * and 1=1，這樣攻擊者就能看到所有用戶的信息。
??? 實際業務中的SQL遠比以上復雜，但是攻擊者的攻擊方式也不是這么簡單，因此要抓住要點進行防御。
建議加固方案
1． 使用PrepareStatement。預編譯的SQL可以有效防御攻擊者的腳本，如果你使用了ORM框架，不用擔心，通常ORM框架都提供了類似Preparestatement的支持，比如ibatis/mybatis中，SQL中使用##進行參數站位將使用preparestatement。
2． 使用存儲過程。存儲過程轉入參數時將會進行合法性校驗，惡意SQL通常會視為異常參數而無法處理。
3． 啟動校驗框架，對請求參數進行校驗，這個可以更加通用，更加高效的攔截惡意SQL。
已解密的登錄請求【級別-高】
攻擊請求示例
POST /demo/page/user/editUser.jsp?userType=1&sccAdminName=1234&sccAdminPwd=1234&confirmSccAdminPwd=Acme-Hackme+Corp.&systemAdminName=1234&systemAdminPwd=1234&confirmSystemAdminPwd=Acme-Hackme+Corp.&description=1234
?
攻擊說明
很好理解，你的請求中包含了明文密碼。由于抓去http請求非常簡單，將用戶密碼明文傳輸基本就是告訴攻擊者我的密碼是多少。處理密碼，以下信息也需要進行加密處理：
- 用戶名
- 密碼
- 社會保險號碼
- 信用卡號碼
- 駕照號碼
- 電子郵件地址
- 電話號碼
- 郵政編碼
?
?
建議加固方案
1． 前端加密，后臺直接使用加密后的密碼進行匹配。目前主流的方式是前段使用MD5加密，后臺直接使用密文密碼進行匹配。
2． 有些業務比較特別，可能需要明文密碼進行處理，這時候設計前段加密，后端解密的處理，可是由于加密鹽可能被JS暴漏，這個方案不是最好的選擇。
?
跨站點請求偽造【級別-中】
攻擊請求示例
POST /demo/checkkeystore.do HTTP/1.0
Cookie: JSESSIONID=00e66855f6cb368a2f543053af46; SSO=eG9YZStrSUV5U21GYUFuL2JqNjBLa3Zic2QyMXZHU0ZLNW81Z3VrdWZiNG5mbmJ3Mi91QmFjclF2SW5aOGFOWUZpL1V3UTRKQk1MQgpNNW1xY2dHaG5qd0tWQXdVQTNZeng0TW43Y0ZMVUFxZDlENGJPcEVWcTl5clIyV0NnTzRnZjFuSmRxdGhzZG89
Content-Length: 34
Accept: */*
Accept-Language: zh-cn
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Host: 192.168.106.79:8080
Content-Type: application/x-www-form-urlencoded
Referer: http://bogus.referer.ibm.com
?
攻擊說明
關于Referer：
HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求的時候，一般會帶上Referer，告訴服務器我是從哪個頁面鏈接過來的，服務器籍此可以獲得一些信息用于處理。
?
攻擊者可以竊取或操縱客戶會話和 cookie，它們可能用于模仿合法用戶，從而使攻擊者能夠以該用戶身份查看或變更用戶記錄以及執行事務。
?
建議加固方案
??? 使用filter對header的referer信息進行校驗，referer信息可以為空、當前web應用以及信任地址。
?
鏈接注入【級別-中】
攻擊請求示例
GET /demo/page/grade/gradeAction.do?method=userGroupTree&authz=true&nodeType=province&fullId=ha&provinceId=ha&uid=1378952847091&id="'><A%20HREF="/WF_XSRF.html">Injected%20Link</A>&a_dhx_rSeed=1378952847091
?
攻擊說明
???????? 和“跨站點腳本編制”類似，只是請求注入了<a>標簽，參數返回頁面時將在頁面生成可以非法的連接。由于這個相對“跨站點腳本編制”比較明顯，因此級別是中。
?
建議加固方案
啟動校驗框架，對請求參數進行校驗，比對使用正則表達式對參數的值進行校驗——重點過濾<和>。
?
通過框架釣魚【級別-中】
攻擊請求示例
GET /demo/ city/cityAction.do?method=cityTree&uid=1378952840737&id=ha"/>%3cabc+xmlns%3axyz%3d'http%3a%2f%2fwww.w3.org%2f1999%2fxhtml'%3e%3cxyz%3aiframe+src%3d'http%3a%2f%2fdemo.testfire.net'%2f%3e%3c%2fabc%3e&a_dhx_rSeed=1378952840737
?
攻擊說明
???????? 和“跨站點腳本編制”和“鏈接注入“類似，只是請求注入了<iframe>或<frame>標簽，參數返回頁面時將在頁面生成一個非法的嵌套頁面。
?
建議加固方案
啟動校驗框架，對請求參數進行校驗，比對使用正則表達式對參數的值進行校驗——重點過濾<和>。
?
Autocomplete HTML Attribute Not Disabled for Password Field【級別-低】
攻擊說明
??? HTML5中添加了新屬性Autocomplete，該屬性可以可以讓用戶在輸入框中找到歷史填寫信息。若密碼輸入框（<input type="password" />）沒有關系該屬性，攻擊者可能會繞開 Web 應用程序的認證機制。
?
建議加固方案
??? 在開發和修改時，遇到密碼輸入框，關閉Autocomplete屬性。
<input?type="password"?autocomplete="off"?/>?
Internal IP Disclosure Pattern Found in Parameter Value【級別-低】
攻擊請求示例
POST /demo/authn/authAction.do?method=add&forwardUrl=http%3A%2F%2F192.168.11.93%3A80%2Chttp%3A%2F%2Fwww.baidu.com%3A80&resCode=IAM111&resKey=5OlwlhzHNn8%3D&from=iam&targetAction=%2FloginAction%21authByIAM.action
?
攻擊說明
??? 參數值中發現了內部IP，攻擊者可能會收集有關 Web 應用程序的敏感信息，如用戶名、密碼、機器名和/或敏感文件位置。
?
建議加固方案
??? 這個安全級別是低，由于IP地址被攻擊者獲取到后可能展開后續針對服務器的攻擊，而不是直接攻擊當前應用程序，因此可參考修復。
?
檢測到文件替代版本【級別-低】
攻擊請求示例
GET /demo/_userAction.do
?
攻擊結果
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=01853c86546b44cb00af12e425e8; path=/demo
Content-Length: 2120
Server: TongWeb Server
P3P: CP="CAO PSA OUR"
Content-Type: text/html;charset=UTF-8
Date: Thu, 12 Sep 2013 02:55:31 GMT
Connection: close
?
攻擊說明
??? 漏洞掃描工具嘗試在正確請求前添加下劃線“_”等符號，判斷服務器上是否有舊版本或無用文件。
?
建議加固方案
??? 即時清理服務器上的舊版本或無用文件。
?
臨時文件下載【級別-低】
攻擊請求示例
GET /demo/Copy%20of%20userAction.do
?
攻擊結果
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=01850ed7359fdce3604aedd9dac9; path=/demo
Content-Length: 2120
Server: TongWeb Server
P3P: CP="CAO PSA OUR"
Content-Type: text/html;charset=UTF-8
Date: Thu, 12 Sep 2013 02:55:30 GMT
Connection: close
?
攻擊說明
??? 漏洞掃描工具嘗試訪問Copy of userAction.do，從而判斷服務器上是否遺留有備份文件。
?
建議加固方案
??? 即時清理服務器上的備份或無用文件。
?
參考級別的漏洞
參考級別不再一一介紹，參考級別可以說不是漏洞，甚至有些時候就是正常的業務。
????HTML敏感信息泄露【級別-參考】
????????HTML中有有注釋信息，可供攻擊者參考
????發現電子郵件地址模式【級別-參考】
????????HTML中有郵件地址，攻擊者可以獲取目標用戶的郵箱。
????發現內部IP泄露模式【級別-參考】
????????頁面存在填寫IP信息的輸入框，攻擊者可以抓去ip地址
????潛在的文件上載【級別-參考】
????????存在上傳功能，上傳功能可能導致攻擊者上傳惡意腳本。
?
總結
啟用校驗框架
很多漏洞都可以通過校驗框架實現加固，如Microsoft Windows MHTML 跨站點腳本編制【級別-高】、SQL 盲注【級別-高】、鏈接注入【級別-中】、通過框架釣魚【級別-中】。
不開啟檢驗框架是一個重大的錯誤。
?
Header信息校驗
雖然有些瀏覽器不支持header信息，但是這里依舊是攻擊的重點區域，需要對header信息進行統一的管理。
?
安全報告不一定準確
???????? 工具畢竟不是人，程序在判斷漏洞的時候有一些硬性條件，比如：返回200狀態、頁面顯示了某些數據等。
???????? 這些結果也許是錯誤的：假設我的web應用攔截并處理的攻擊，但是我需要在頁面提示，由于服務器響應的這次攻擊請求，漏掃軟件依舊認為web被攻擊了。
?
區分業務校驗和安全漏洞
輸入非權限管理范圍的信息能夠查詢到數據，這類操作是程序的鑒權模塊不完善導致的，不能算作安全漏洞。
同時，安全的加固通常在進入控制層之前完成，如filter或是校驗框架。鑒權通常在業務層之前完成，如service的代理類中。兩者混淆將導致程序復雜度的增加。
?
千里之堤毀于蟻穴
????平時的代碼開發中就應當考慮安全編碼，在漏洞爆發后再修復所帶來的損失將是不可估量的。
????不積跬步無以至千里，加強安全編碼是一項長期的工作，需要每一位開發者重視。
轉載于:https://my.oschina.net/SEyanlei/blog/264307
總結
以上是生活随笔為你收集整理的web安全漏洞加固方案简析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 对List中对象的去重
- 下一篇： tcl中的string trim使用时需