通用安全編碼規(guī)范

天翼電子商務(wù)有限公司

信息技術(shù)部

】通用安全編碼規(guī)范<文檔編號：BESTPAY-DMAQ-05〉<Version1.0>保密申明本文檔版權(quán)由天翼電子商務(wù)有限公司信息技術(shù)部所有。未經(jīng)天翼電子商務(wù)有限公司信息技術(shù)部書面許可，任何單位和個人不得以任何形式摘抄、復(fù)制本文檔的部分或全部，并以任何形式傳播目錄目的范圍規(guī)范概述安全編碼的原則WEB應(yīng)用程序常見安全問題跨站腳本攻擊定義危害解決方法SQL注入定義危害解決方法惡意腳本執(zhí)行定義危害解決方法文件上傳漏洞定義危害解決方案傳輸敏感信息未使用安全通道定義危害解決方案信息泄漏和錯誤處理不當(dāng)定義危害解決方案跨站請求偽造定義危害代碼示例解決方案訪問控制缺陷權(quán)限提升不安全的直接對象引用不安全的加密定義弱加密示例解決方案限制URL訪問失效定義解決方案Session管理CookiehttponlyflagCookieSecureflagSessionExpires日志和監(jiān)測WEB應(yīng)用程序安全編碼要點SOCKET網(wǎng)絡(luò)安全編程要求安全認(rèn)證要求圖片驗證碼短信驗證碼加密方法及強(qiáng)度要求輸入驗證什么是輸入如何處理輸入輸出編碼輸出編碼的種類輸出編碼的必要性安全輸出編碼方式翼支付常用WEB框架安全Struts2：Action字段沒有驗證器(ActionFiledWithoutValidator)定義危害Struts2:有重復(fù)的Action字段驗證器(DuplicateActionFieldValidators)定義危害示例Struts2:重復(fù)的驗證文件(DuplicateValidationFiles)定義危害Struts2:重復(fù)的驗證器(DuplicateValidators)定義危害Struts2:未聲明驗證器(UndeclaredValidator)定義危害示例Struts2:未經(jīng)驗證的Action(UnvalidateAction)定義危害Struts2:驗證文件無對應(yīng)的Action(ValidationFileWithoutAction)定義Struts2:驗證器無Action域(ValidatorWithoutActionField)定義SpringMVC的不良做法:請求參數(shù)綁定持久對象(SpringMVCPractices:RequestParametersBoundintoPersistedObjects)7.9.1定義7.9.2危害7.9.3示例:附錄安全性測試_checklist代碼安全審計checklist目的為保障天翼電子商務(wù)有限公司（以下簡稱“翼支付”）支付平臺的安全性，構(gòu)建安全健壯的程序，結(jié)合翼支付Web安全遇到的問題以及啟明星辰安全研究實驗室在Web攻防及代碼安全的理論和實踐積累，特制定本規(guī)范，旨在為翼支付開發(fā)團(tuán)隊提供設(shè)計及編寫應(yīng)用程序時普遍應(yīng)該遵循的原則。為充分理解本規(guī)范內(nèi)容，請：＞了解應(yīng)用程序?qū)艿降耐{；＞理解必須考慮的威脅；＞在程序設(shè)計階段考慮到這些威脅。范圍本規(guī)范從應(yīng)用安全開發(fā)的角度出發(fā)，結(jié)合翼支付平臺系統(tǒng)的特點和常見的安全問題，給出支付平臺應(yīng)用系統(tǒng)安全開發(fā)的規(guī)范。供翼支付平臺應(yīng)用系統(tǒng)開發(fā)部門內(nèi)部使用，適用翼支付平臺應(yīng)用系統(tǒng)項目開發(fā)的工作。本規(guī)范定義了翼支付平臺應(yīng)用系統(tǒng)安全開發(fā)和編碼安全相關(guān)的技術(shù)要求。本規(guī)范主要提供設(shè)計應(yīng)用程序時應(yīng)該遵循的一些指南和原則。在應(yīng)用程序易受攻擊的重要環(huán)節(jié)應(yīng)采用系統(tǒng)的方法。將重點放在程序部署、輸入驗證、身份驗證和授權(quán)、加密及數(shù)據(jù)敏感度、配置、會話、異常管理以及適當(dāng)?shù)膶徍撕陀涗洸呗陨?，以確保應(yīng)用程序的安全可靠性。規(guī)范概述當(dāng)今電子商務(wù)時代，應(yīng)用系統(tǒng)為架構(gòu)設(shè)計人員、開發(fā)人員提出一系列復(fù)雜的安全問題。為應(yīng)對這些安全問題，須要應(yīng)用安全思想來構(gòu)建應(yīng)用程序。在初始階段，應(yīng)該使用可靠的安全體系結(jié)構(gòu)和設(shè)計方法，同時要結(jié)合考慮應(yīng)用程序的部署以及企業(yè)的安全策略。如果不能做到這一點，將導(dǎo)致在現(xiàn)有基礎(chǔ)結(jié)構(gòu)上部署應(yīng)用程序時，導(dǎo)致危及應(yīng)用系統(tǒng)的安全性。本規(guī)范提供初步的安全體系結(jié)構(gòu)和設(shè)計指南，并按照翼支付平臺常見的應(yīng)用程序漏洞類別進(jìn)行組織。這些指南是應(yīng)用系統(tǒng)程序安全的重要方面，并且是經(jīng)常發(fā)生錯誤的領(lǐng)域。安全編碼的原則＞程序只實現(xiàn)你指定的功能＞永遠(yuǎn)不要信任用戶的輸入，對用戶輸入數(shù)據(jù)做有效性檢查＞必須考慮意外情況并進(jìn)行處理＞不要試圖在發(fā)現(xiàn)錯誤之后繼續(xù)執(zhí)行＞盡可能使用安全函數(shù)進(jìn)行編程＞小心、認(rèn)真、細(xì)致地編程Web應(yīng)用程序常見安全問題下面的安全問題是根據(jù)應(yīng)用程序漏洞類別描述的。實際經(jīng)驗表明，如果

這些領(lǐng)域的設(shè)計存在薄弱環(huán)節(jié)，將會導(dǎo)致安全漏洞。下表列出了漏洞的類別每個類別都突出顯示了由于設(shè)計不當(dāng)可能會導(dǎo)致的潛在問題。漏洞類別由于設(shè)計不當(dāng)而引起的潛在問題輸入驗證嵌入到查詢字符串、表單字段、cookie和HTTP頭中的惡意字符串的攻擊。這些攻擊包括命令執(zhí)行、跨站點腳本（XSS）、SQL輸入和緩沖區(qū)溢出攻擊。身份驗證標(biāo)識欺騙、密碼破解、特權(quán)提升和未經(jīng)授權(quán)的訪問。授權(quán)訪問保密數(shù)據(jù)或受限數(shù)據(jù)、篡改數(shù)據(jù)以及執(zhí)行未經(jīng)授權(quán)的操作。配置管理對管理界面進(jìn)行未經(jīng)授權(quán)的訪問、具有更新配置數(shù)據(jù)的能力以及對用戶賬戶和賬戶配置文件進(jìn)行未經(jīng)授權(quán)的訪問。敏感數(shù)據(jù)泄漏保密信息以及篡改數(shù)據(jù)。會話管理捕捉會話標(biāo)識符，從而導(dǎo)致會話劫持及標(biāo)識欺騙。加密訪問保密數(shù)據(jù)或者賬戶憑據(jù)，或者一者均能訪問。參數(shù)操作路徑遍歷攻擊、命令執(zhí)行以及繞過訪問控制機(jī)制，從而導(dǎo)致信息泄漏、特權(quán)提升和拒絕服務(wù)。異常管理拒絕服務(wù)和敏感的系統(tǒng)級詳細(xì)信息的泄漏。審核和記錄不能發(fā)現(xiàn)入侵跡象、不能驗證用戶操作，以及在診斷問題時出現(xiàn)困難。5.1跨站腳本攻擊5.1.1定義什么是跨站腳本攻擊：跨站腳本攻擊（通常簡寫為XSS）是最普通的web應(yīng)用安全漏洞，當(dāng)應(yīng)用程序在發(fā)送給瀏覽器的頁面中包含用戶提供的數(shù)據(jù)，沒有經(jīng)過嚴(yán)格驗證或轉(zhuǎn)義，那么攻擊者就有可能利用網(wǎng)站程序?qū)τ脩糨斎脒^濾不嚴(yán)，輸入可以顯示在頁面上對其他用戶造成影響的HTML代碼，從而盜取用戶資料、利用用戶身份進(jìn)行某種動作或者對訪問者進(jìn)行病毒侵害的一種攻擊方式。5.1.2危害＞敏感數(shù)據(jù)被獲取（cookie盜?。揪W(wǎng)絡(luò)釣魚＞獲取web用戶的網(wǎng)頁內(nèi)容＞SessionRiding（CSRF攻擊）＞獲取用戶的鍵盤擊鍵數(shù)據(jù)＞W(wǎng)eb僵尸＞XSS蠕蟲攻擊者能在受害者瀏覽器中執(zhí)行腳本以劫持用戶會話、迫害網(wǎng)站、插入惡意內(nèi)容、重定向用戶、使用惡意軟件劫持用戶瀏覽器等等。入侵者便通過技術(shù)手段在某個頁面里插入一個惡意HTML代碼，例如記錄論壇保存的用戶信息（Cookie），由于Cookie保存了完整的用戶名和密碼資料，用戶就會遭受安全損失。如這句簡單的javascript腳本就能輕易獲取用戶信息：alert（document.cookie），它會彈出一個包含用戶信息的消息框。入侵者運用腳本就能把用戶信息發(fā)送到他們自己的記錄頁面中，稍作分析便獲取了用戶的敏感信息。跨站腳本攻擊的危險，在如今WEB安全越來越得到重視，他的危險性也越來越大。有效防止跨站腳本攻擊，是WEB程序是否安全的一個重要標(biāo)準(zhǔn)。5.1.3解決方法主要防御方式驗證輸入驗證輸入很簡單，檢查每個輸入的有效性。這可能意味著很多東西，但在典型的和簡單的情況下，這意味著檢查輸入類型和數(shù)據(jù)的長度。例如，如果你是從一個文本框接受一個標(biāo)準(zhǔn)的郵政編碼，你會知道，唯一有效的類型是一個數(shù)字（0-9），而長度應(yīng)該是6，不能多也不能少。并非所有的案例都如此簡答，但很多是相似的。下圖顯示驗證輸入的架構(gòu)。這里的關(guān)鍵是，一切都進(jìn)行驗證，所有的輸入，這并不來自于應(yīng)用程序（包括用戶輸入，請求頭，Cookie，數(shù)據(jù)庫數(shù)據(jù)……）。編碼輸出對于不支持HTML代碼的地方，可用編碼輸出。如：Server.UrlEncode等方法編碼輸出。優(yōu)點：安全可靠。缺點：不支持HTML代碼。對于驗證輸入的另一面就是編碼輸出。編碼輸出，是用來確保字符被視為數(shù)據(jù)，而不是作為HTML元字符被瀏覽器解析。這些技術(shù)定義一些特殊的“轉(zhuǎn)義”字符。沒有正確轉(zhuǎn)義的數(shù)據(jù)它仍然會在瀏覽器中正確解析。編碼輸出只是讓瀏覽器知道數(shù)據(jù)是不是要被解析，達(dá)到攻擊無法實現(xiàn)的目的。需要編碼的部分：HTML實體HTML屬性JavascriptCSSURL輔助防御方式防御手段一：iframesecurity=“restricted”保護(hù)級別：★★★★描述：通過設(shè)置iframesecurity二“restrieted”，能有效防止iframe類的攻擊（對IE有效）。優(yōu)點：有效防止iframe的攻擊。防御手段二：HttpOnly保護(hù)級別：★★★★描述：設(shè)置Cookie的HttpOnly屬性，有效地防止Cookie通過腳本泄密（IE6SP1以上、Firefox3）。優(yōu)點：有效保護(hù)了用戶的Cookie信息。應(yīng)用舉例：系統(tǒng)中，所有登錄驗證的地方，驗證成功后設(shè)置authCookie.HttpOnly二true,設(shè)置Cookie的HttpOnly屬性，這些都應(yīng)用于用戶登錄成功的地方。防御手段三：字符過濾保護(hù)級別：★★卄描述：通過函數(shù)進(jìn)行過濾，能有效防止常見跨站腳本的跨站攻擊。主要過濾常見惡意腳本代碼，如：<applet|meta|xml|blink|link|style|script|embed|object|iframe|frame|frameset|ilayer|layer|bgsound|title|base>OnX事件代碼、Javascript、Vbscript和Style中的expression、behaviour、script、position等。但過濾可能存在不完全的情況。建立自己的XSS攻擊庫，方便測試和收集新的攻擊方式，使過濾函數(shù)更加完善。優(yōu)點：支持HTML，有效防止大部分攻擊代碼。缺點：可能存在過濾不全的情況。SQL注入5.2.1定義什么是SQL注入所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。通過遞交參數(shù)構(gòu)造巧妙的SQL語句，從而成功獲取想要的數(shù)據(jù)。簡單來說，注入往往是應(yīng)用程序缺少對輸入進(jìn)行安全性檢查所引起的，攻擊者把一些包含指令的數(shù)據(jù)發(fā)送給解釋器，解釋器會把收到的數(shù)據(jù)轉(zhuǎn)換成指令執(zhí)行，注入漏洞十分普遍，通常能在SQL查詢、程序參數(shù)等中出現(xiàn)。下圖為SQL攻擊原理圖：5.2.2危害注入能導(dǎo)致數(shù)據(jù)丟失或數(shù)據(jù)破壞、缺乏可審計性或是拒絕服務(wù)。注入漏洞有時甚至能導(dǎo)致完全接管主機(jī)，主要危害有以下幾點：＞繞過防火墻進(jìn)行攻擊＞繞過web應(yīng)用程序的驗證過程＞非法越權(quán)操作數(shù)據(jù)庫內(nèi)容＞隨意篡改網(wǎng)頁內(nèi)容＞添加系統(tǒng)賬戶或數(shù)據(jù)庫賬戶＞上傳和下載非法文件＞本地溢出并獲取系統(tǒng)最高權(quán)限＞安裝木馬后門/僵尸網(wǎng)絡(luò)5.2.3解決方法SQL注入實例：StringsqlString=“SELECT*FROMusersWHEREfullname=”'+form.getFullName()+'”ANDpassword='”‘+form.getPassword()+'“”;正常：username=tony，password=123456SELECT*FROMusersWHEREusername=tony'ANDpassword='123456'攻擊：username=tony，password='OR‘1'='1SELECT*FROMusersWHEREusername=tony'ANDpassword=‘'OR‘1'='1'參數(shù)化查詢預(yù)處理對于JDBC而言,SQL注入攻擊只對Statement有效，對PreparedStatement是無效的，這是因為PrepareStatement不允許在不同的插入時間改變查詢的邏輯結(jié)構(gòu)。如驗證用戶是否存在的SQL語句為：selectcount(*)fromusertablewherename='用戶名'andpswd='密碼'如果在用戶名字段中輸入'or‘1=1'orT='l或是在密碼字段中輸入1'or‘1'='1將繞過驗證，但這種手段只對Statement有效，對PreparedStatement無效，PreparedStatement相對Statement有以下優(yōu)點：＞防注入攻擊＞多次運行速度快＞防止數(shù)據(jù)庫緩沖區(qū)溢出＞代碼的可讀性可維護(hù)性好惡意腳本執(zhí)行5.3.1定義惡意文件執(zhí)行是一種能夠威脅任何網(wǎng)站形式的漏洞，只要攻擊者在具有引入(include)功能程式的參數(shù)中修改參數(shù)內(nèi)容，WEB服務(wù)器便會引入惡意程序內(nèi)容從而收到惡意文件執(zhí)行漏洞攻擊。5.3.2危害攻擊者可利用惡意文件執(zhí)行漏洞進(jìn)行攻擊取得WEB服務(wù)器控制權(quán)，進(jìn)行不法利益或獲取經(jīng)濟(jì)利益。5.3.3解決方法＞驗證輸入，驗證上傳文件名＞檢查上傳文件的大小文件上傳漏洞5.4.1定義Web應(yīng)用程序在處理用戶上傳的文件時，沒有判斷文件的擴(kuò)展名是否在允許的范圍內(nèi)，就把文件保存在服務(wù)器上，導(dǎo)致惡意用戶可以上傳任意文件，甚至上傳腳本木馬到web服務(wù)器上，直接控制web服務(wù)器。5.4.2危害攻擊者可利用文件上傳功能，上傳Webshell從而控制整個主機(jī)系統(tǒng)。5.4.3解決方案＞檢查上傳文件擴(kuò)展名白名單，不屬于白名單內(nèi)，不允許上傳。＞上傳文件的目錄必須是http請求無法直接訪問到的。如果需要訪問的,必須上傳到其他（和web服務(wù)器不同的）域名下，并設(shè)置該目錄為不解析jsp等腳本語言的目錄。＞上傳文件要保存的文件名和目錄名由系統(tǒng)根據(jù)時間生成，不允許用戶自定義。＞圖片上傳，要通過處理（縮略圖、水印等），無異常后才能保存到服務(wù)器。＞上傳文件需要做日志記錄,請參照“ErrorHandingandLogging章節(jié)”傳輸敏感信息未使用安全通道5.5.1定義對于未加密的敏感數(shù)據(jù)在網(wǎng)絡(luò)上傳輸時，需要使用安全的通道。否則應(yīng)用程序?qū)⒈┞渡矸蒡炞C或會話令牌。5.5.2危害＞攻擊者能夠取得或者篡改機(jī)密的或是私有的信息；＞攻擊者通過這些私密信息的竊取從而進(jìn)行進(jìn)一步的攻擊；＞造成企業(yè)形象破損，用戶滿意度下降，甚至?xí)蟹稍V訟等。5.5.3解決方案＞提供合理的保護(hù)機(jī)制；＞對于敏感數(shù)據(jù)的傳輸，對所有連接都要使用TLS；＞在傳輸前對單個數(shù)據(jù)都要進(jìn)行加密；（如XML-Encryption）＞在傳輸前對信息進(jìn)行簽名；（如XML-Signature）＞正確的使用這些機(jī)制；＞使用標(biāo)準(zhǔn)的強(qiáng)加密算法；＞合理管理密鑰和證書；＞在使用前驗證SSL證書；信息泄漏和錯誤處理不當(dāng)5.6.1定義應(yīng)用程序沒有統(tǒng)一的異常處理頁面，導(dǎo)致敏感信息泄漏，常常產(chǎn)生錯誤信息并顯示給使用者。很多時候，這些錯誤信息是非常有利于攻擊者發(fā)起攻擊，因為他們揭示實施細(xì)節(jié)或者對利用漏洞有用的開發(fā)信息。示例：看到此信息，攻擊者可以做以下判斷：a）數(shù)據(jù)庫是oracleb）查詢語句的列數(shù)不正確根據(jù)這個判斷，攻擊者調(diào)整get請求的內(nèi)容，最終達(dá)到獲取數(shù)據(jù)庫所有數(shù)據(jù)的目的。5.6.2危害＞泄漏太多細(xì)節(jié)（如錯誤堆棧跟蹤信息、SQL語句等等）；＞登錄失敗后，通知用戶是否用戶ID或密碼出錯-登錄失敗可能是由于ID或密碼錯誤造成的。這為一個對關(guān)鍵資產(chǎn)發(fā)動暴力破解的攻擊者提供重要信息。5.6.3解決方案>通過web.xml配置文件實現(xiàn)，產(chǎn)生異?；蛘咤e誤時跳轉(zhuǎn)到統(tǒng)一的錯誤處理頁面，避免泄漏過多敏感信息。<error>vexception-type>v/exception-type><location>/error.jsp</location></error>>針對登錄嘗試的攻擊，如果輸入用戶名或者是口令錯誤，可以使用相同的報錯信息，比如都提示“輸入用戶名或密碼錯誤！”。跨站請求偽造5.7.1定義Cross-SiteRequestForgery(CSRF)，跨站請求偽造攻擊。攻擊者在用戶瀏覽網(wǎng)頁時，利用頁面元素(例如img的src)，強(qiáng)迫受害者的瀏覽器向Web應(yīng)用程序發(fā)送一個改變用戶信息的請求。5.7.2危害由于發(fā)生CSRF攻擊后，攻擊者是強(qiáng)迫用戶向服務(wù)器發(fā)送請求，所以會造成用戶信息被迫修改，更嚴(yán)重者引發(fā)蠕蟲攻擊。CSRF攻擊可以從站外和站內(nèi)發(fā)起。從站內(nèi)發(fā)起CSRF攻擊，需要利用網(wǎng)站本身的業(yè)務(wù)，比如“自定義頭像”功能，惡意用戶指定自己的頭像URL是一個修改用戶信息的鏈接，當(dāng)其他已登錄用戶瀏覽惡意用戶頭像時，會自動向這個鏈接發(fā)送修改信息請求。從站外發(fā)送請求，則需要惡意用戶在自己的服務(wù)器上，放一個自動提交修改個人信息的html頁面，并把頁面地址發(fā)給受害者用戶，受害者用戶打開時，會發(fā)起一個請求。如果惡意用戶能夠知道網(wǎng)站管理后臺某項功能的URL,就可以直接攻擊管理員，強(qiáng)迫管理員執(zhí)行惡意用戶定義的操作。5.7.3代碼示例一個沒有CSRF安全防御的代碼如下：代碼中接收用戶提交的參數(shù)“email,tel,realname”，之后修改了該用戶的數(shù)據(jù)，一旦接收到一個用戶發(fā)來的請求，就執(zhí)行修改操作。提交表單代碼：當(dāng)用戶點提交時，就會觸發(fā)修改操作。5.7.4解決方案要防御CSRF攻擊，必須遵循一下三步：1、在用戶登陸時，設(shè)置一個CSRF的隨機(jī)TOKEN，同時種植在用戶的

cookie中，當(dāng)用戶瀏覽器關(guān)閉、或用戶再次登錄、或退出時，清除token。2、在表單中，生成一個隱藏域，它的值就是COOKIE中隨機(jī)TOKEN。3、表單被提交后，就可以在接收用戶請求的web應(yīng)用中，判斷表單中的TOKEN值是否和用戶COOKIE中的TOKEN值一致，如果不一致或沒有這個值，就判斷為CSRF攻擊，同時記錄攻擊日志（日志內(nèi)容見“ErrorHandingandLogging”章節(jié)）。由于攻擊者無法預(yù)測每一個用戶登錄時生成的那個隨機(jī)TOKEN值，所以無法偽造這個參數(shù)。示例：代碼中$csrfToken.hiddenField將會生成一個隱藏域，用于生成驗證token，它將會作為表單的其中一個參數(shù)一起提交。5.8訪問控制缺陷5.8.1權(quán)限提升定義訪問控制過程中身份驗證有缺陷，導(dǎo)致用戶越權(quán)訪問信息。危害由于web應(yīng)用程序沒有做權(quán)限控制，或僅僅在菜單上做了權(quán)限控制，導(dǎo)致的惡意用戶只要猜測其他管理頁面的URL,就可以訪問或控制其他角色擁有的數(shù)據(jù)或頁面，達(dá)到權(quán)限提升目的。這個威脅可能導(dǎo)致普通用戶變成管理員權(quán)限。代碼示例一個僅僅做了菜單控制的代碼：惡意用戶，可以直接猜測“管理所有用戶”的頁面，通過URL訪問，看到管理員頁面。解決方案在打開管理頁面URL時，首先判斷當(dāng)前用戶是否擁有該頁面的權(quán)限，如果沒有權(quán)限，就判定為“權(quán)限提升”攻擊，同時記錄安全日志。建議使用成熟的權(quán)限框架處理權(quán)限問題，比如springsecurity。5.8.2不安全的直接對象引用定義所謂“不安全的直接對象引用”，指的是一個已經(jīng)授權(quán)的用戶，通過更改訪問時的一個參數(shù)，從而訪問到原本并沒有得到授權(quán)的對象°Web應(yīng)用往往在生成Web頁面時會用它的真實名字，且并不會對所有的對象訪問時來檢查用戶權(quán)限，所以這就造成不安全的對象直接引用漏洞。我們看如下的一個示例，也許這樣就更容易理解什么是不安全的對象直接引用。＞攻擊者發(fā)現(xiàn)他自己的參數(shù)是6065，即acct=6065;＞他可以直接更改參數(shù)為6066，即acct=6066;＞這樣他就可以直接看到6066用戶的賬戶信息。危害這種漏洞損害參數(shù)所引用的所有數(shù)據(jù)。除非名字空間很稀疏，否則攻擊者很容易訪問該類型的所有數(shù)據(jù)?；蛘邜阂庥脩艨梢詣h除或修改其他人數(shù)據(jù)代碼示例以下代碼存在這個漏洞，web應(yīng)用在修改用戶個人信息時，從從用戶提交的request參數(shù)（用戶可控數(shù)據(jù)）中，獲取了userid，執(zhí)行修改操作。修改用戶個人信息頁面：表單中，將用戶的userid作為隱藏字段，提交給處理修改個人信息的應(yīng)用。下面代碼是修改個人信息的應(yīng)用：這段代碼是從request的參數(shù)列表中，獲取userid，也就是表單提交上來的userid，之后修改userid對應(yīng)的用戶數(shù)據(jù)。而表單中的userid是可以讓用戶隨意修改的。解決方案從用戶的加密認(rèn)證cookie中，獲取當(dāng)前用戶的id,并且需要在執(zhí)行的SQL語句中，加入當(dāng)前用戶id作為條件語句。由于是web應(yīng)用控制的加密算法，所以惡意用戶無法修改加密信息。示例代碼：代碼中通過GetUseridFromCookie,從加密的COOKIE中獲取了當(dāng)前用戶的id,并加入到SQL語句中的WHERE條件中。5.9不安全的加密5.9.1定義系統(tǒng)中涉及到敏感信息的數(shù)據(jù)直接明文存儲,極不安全,需要加密存儲。或者采用程序員自己編寫的“簡單算法”加密,一旦被人獲取足夠的“樣本”,將有可能被反向推測出解密算法,從而泄露重要信息。一些低強(qiáng)度的密碼算法，如DES、RC2等已經(jīng)可以很容易的在短時間內(nèi)被人所破解,其它一些容易被誤用的“密碼算法”,如base64、escape、urlencode等,其實并不是密碼算法,只是簡單的編碼而已,不能起到密碼算法保護(hù)信息的作用。5.9.2弱加密示例線性加密算法,下面以“古典密碼算法”為例：該算法對字符串做“Offset”位偏移，極易被破解，不宜采用。5.9.3解決方案詳見§6.3。5.10限制URL訪問失效URL中或者其他參數(shù)包含文件、目錄、數(shù)據(jù)庫記錄或者關(guān)鍵字等參照物，導(dǎo)致接口處信息泄露。定義這個漏洞事實上也是與認(rèn)證相關(guān)的，與我們前面提到的不安全的直接對象引用也是類似的,不同在于這個漏洞是說系統(tǒng)已經(jīng)對URL的訪問做限制，但這種限制卻實際并沒有生效。常見的錯誤是，我們在用戶認(rèn)證后只顯示給用戶認(rèn)證過的頁面和菜單選項，而實際上這些僅僅是表示層的訪問控制而不能真正生效，攻擊者能夠很容易的就偽造請求直接訪問未被授權(quán)的頁面。我們舉個例子來說明這個過程：＞攻擊者發(fā)現(xiàn)他自己的訪問地址為/user/getAccounts;＞他修改他的目錄為/admin/getAccounts或/manager/getAccounts;＞這樣攻擊者就能夠查看到更多的賬戶信息。解決方案對每個URL，我們必須做三件事：＞如果這個URL不是公開的，那么必須限制能夠訪問他的授權(quán)用戶?加強(qiáng)基于用戶或者角色的訪問控制；?完全禁止訪問未被授權(quán)的頁面類型（如配置文件、日志文件、源文件等）＞驗證架構(gòu)在每一個層次都使用簡單肯定的模型；確保每一層都有一個訪問機(jī)制。＞驗證實現(xiàn)不要使用自動化分析工具；?確保每個URL都被外部過濾器或其他機(jī)制保護(hù)；確保服務(wù)器的配置不允許對非授權(quán)頁面的訪問。ISession管理Cookiehttponlyflag定義Cookiehttponly，是設(shè)置COOKIE時,可以設(shè)置的一個屬性，如果COOKIE沒有設(shè)置這個屬性，該COOKIE值可以被頁面腳本讀取。當(dāng)攻擊者發(fā)現(xiàn)一個XSS漏洞時，通常會寫一段頁面腳本，竊取用戶的COOKIE，為了增加攻擊者的門檻，防止出現(xiàn)因為XSS漏洞導(dǎo)致大面積用戶COOKIE被到，應(yīng)該在設(shè)置認(rèn)證COOKIE時，增加這個屬性。代碼示例這段代碼沒有設(shè)置httponly屬性：response.setHeader("SET-COOKIE","user="+request.getParameter("cookie"));解決方案設(shè)置cookie時，加入屬性即可：response.setHeader("SET-COOKIE","user="+request.getParameter("cookie")+";HttpOnly");下圖可以看到cookie已經(jīng)加入了httponly屬性：常見問題如何在COOKIE類中設(shè)置httponly?■目前的jdk版本只支持在setHeader時，設(shè)置httponly。Httponly已經(jīng)可以防止用戶COOKIE被竊取，還需要做XSS防御嗎？■這個flag只能增加攻擊者的難度，不能達(dá)到完全防御xss攻擊。CookieSecureflag定義CookieSecure，是設(shè)置COOKIE時，可以設(shè)置的一個屬性，設(shè)置了這個屬性后，只有在https訪問時，瀏覽器才會發(fā)送該COOKIE。瀏覽器默認(rèn)只要使用http請求一個站點，就會發(fā)送明文COOKIE，如果網(wǎng)絡(luò)中有監(jiān)控，可能被截獲。如果Web應(yīng)用網(wǎng)站全站是https的，可以設(shè)置COOKIE加上Secure屬性，這樣瀏覽器就只會在https訪問時，發(fā)送cookie。攻擊者即使竊聽網(wǎng)絡(luò)，也無法獲取用戶明文cookie。代碼示例這段代碼沒有設(shè)置Secure屬性response.setHeader("SET-COOKIE","user="+request.getParameter("cookie")+";HttpOnly");進(jìn)行網(wǎng)絡(luò)監(jiān)聽，可以看到下圖是沒有設(shè)置Secure屬性的COOKIE發(fā)送的數(shù)據(jù)包：解決方案在設(shè)置認(rèn)證COOKIE時，加入Secure：response.setHeader("SET-COOKIE","user="+request.getParameter("cookie")+";HttpOnly;Secure");再次訪問http網(wǎng)站，抓數(shù)據(jù)包可以看到，已經(jīng)不再發(fā)送這個COOKIE了。SessionExpires定義Session有效期安全攻擊。由于Session沒有在Web應(yīng)用中設(shè)置強(qiáng)制超時時間，攻擊者一旦曾經(jīng)獲取過用戶的Session，就額可以一直使用。代碼示例這段代碼沒有在服務(wù)器中設(shè)置強(qiáng)制超時時間。response.setHeader("SET-COOKIE","user="+request.getParameter("cookie")+";HttpOnly;Secure");解決方案在設(shè)置認(rèn)證cookie中，加入兩個時間，一個是“即使一直在活動，也要失效”的時間，一個是“長時間不活動的失效時間”。并在Web應(yīng)用中，首先判斷兩個時間是否已經(jīng)超時，再執(zhí)行其他操作。//判斷會員的cookie是否過期5.12日志和監(jiān)測做好系統(tǒng)的日志監(jiān)測，記錄好后臺管理操作和異常情況，有利于監(jiān)測系統(tǒng)未知漏洞，通過操作日志，還能找出系統(tǒng)出錯或?qū)δ承┲匾僮鞯墓芾韱T、操作時間、IP等信息。有效地預(yù)防，檢測，增強(qiáng)系統(tǒng)的安全性。對重要的日志都進(jìn)行記錄，如：登陸日志、系統(tǒng)錯誤日志、數(shù)據(jù)庫錯誤日志等。Web應(yīng)用程序安全編碼要點6.1SOCKET網(wǎng)絡(luò)安全編程要求＞在socket函數(shù)調(diào)用時，明確參數(shù)中綁定的端口、IP地址和網(wǎng)卡接口。Windows環(huán)境下，在遇到多個網(wǎng)卡的情況時，需要通過注冊表來獲得網(wǎng)卡接口和IP地址的信息，包括WindowsNT和windows2000。＞判斷連接的合法身份。即,為防止惡意的連接以及可能是無效的連接，建議在socket連接期間，判斷連接的對端是否是合法的真正的連接。＞對于UDP連接，可以獲得連接對方的IP地址和端口，從而可以判斷對方的有效性和合法性；寸于TCP連接，由于每次連接需要三次握手，而且還有超時機(jī)制，存在兩種方式來控制。＞對于TCP連接，需要盡量在三次握手完成前完成判斷，同時防止端口掃描的攻擊。＞盡可能確保socket應(yīng)用能通過合理設(shè)置的防火墻。＞在可能的情況下，盡量減少socket連接數(shù)目。＞盡量不能使用回?fù)艿募夹g(shù)。＞盡量采用有連接狀態(tài)的協(xié)議，例如TCP協(xié)議。由于防火墻一般采取禁止一切的策略，對于UDP協(xié)議比較難以設(shè)置。＞在一個應(yīng)用程序中，盡量使用同一種協(xié)議，不能使用多種協(xié)議。＞盡量將客戶端和服務(wù)器端的端口做成可以配置，不能硬編碼在程序中。6.2安全認(rèn)證要求為防止采用單一用戶名、口令登陸被暴力破解，部分頁面被重復(fù)提交數(shù)據(jù)造成灌水、刷票等，網(wǎng)站應(yīng)考慮雙因素或多因素認(rèn)證。目前，普遍采用圖片驗證碼、短信驗證碼，加入時間等隨機(jī)因素，進(jìn)行雙因素認(rèn)證。6.2.1圖片驗證碼在網(wǎng)站登錄、發(fā)表評論時，往往都需要用戶輸入驗證碼。圖片驗證機(jī)制就是指根據(jù)一定的隨機(jī)數(shù)產(chǎn)生算法來產(chǎn)生的一串隨機(jī)數(shù)字或符號，并加入一些干擾像素最終生成相應(yīng)的用于驗證的圖片。只有當(dāng)用戶肉眼識別出其中的驗證碼信息，輸入表單并提交網(wǎng)站驗證，驗證成功后才能使用該網(wǎng)站提供的某項特定功能。驗證碼的主要用途是用于防止有人利用機(jī)器人自動批量注冊對特定的注冊用戶用特定的程序暴力破解。一般來講，自動注冊或者表單自動填寫程序不能有效識別圖片驗證碼中的數(shù)字或字符，因此從一定程度上實現(xiàn)了阻擋攻擊的作用。在某支付公司某應(yīng)用系統(tǒng)中用戶登錄表單無驗證碼驗證，存在暴力破解的風(fēng)險。建議頁面增加圖片驗證碼，以防止帳戶被暴力破解。同時因為圖片驗證碼也存在被繞過的可能，為解決該問題，在增加驗證碼的同時，須要在服務(wù)端進(jìn)一步做判斷，比如每分鐘客戶端嘗試向服務(wù)器提交的驗證碼次數(shù)不能超過三次，如果超過需要在下一分鐘再提交服務(wù)器進(jìn)行驗證。6.2.2短信驗證碼在網(wǎng)站安全架構(gòu)設(shè)計中，短信驗證碼提供了有效的用戶輔助身份驗證。但是，為了防止短信驗證碼被繞過，應(yīng)注意，用戶手機(jī)號應(yīng)包含在服務(wù)器端，系統(tǒng)在調(diào)用用戶手機(jī)號是只能從服務(wù)器端獲得，不得提供手機(jī)號的接口，防止被惡意用戶篡改。例如，下圖是某支付公司支付頁面，點擊“獲取驗證碼”時，獲取的請求中包含了手機(jī)號碼參數(shù)，可被篡改，且無校驗，導(dǎo)致可將驗證碼發(fā)送到任意手機(jī)上，繞過手機(jī)短信的校驗。6.3加密方法及強(qiáng)度要求＞禁止使用自己編寫的密碼算法。＞不要將編碼(如Base64)和密碼算法混為一談，前者不是密碼算法。＞不要使用低強(qiáng)度的密碼算法，如DES、RC2等，必須采用符合業(yè)內(nèi)安全強(qiáng)度標(biāo)準(zhǔn)的密碼算法，見下表：對于存儲在數(shù)據(jù)庫或日志中的敏感數(shù)據(jù)，建議采用安全的Hash算法。存儲策略—基于安全哈希算法加密存儲用戶的口令安全哈希算法的存儲方式已經(jīng)得到廣泛使用。哈希算法可用于保障信息的完整性、抗抵賴性、屬于單向算法，即便哈希的結(jié)果被截獲，對方也是無法還原出明文的。如果在哈希的過程中加入鹽值，那就更好了，可以起到混淆的作用。也有加密方案提到通過非對稱加密算法加密后存儲，比如RSA，但是這種方法使用起來比較麻煩，另外還需要考慮系統(tǒng)后臺的密鑰管理，一旦密鑰泄漏，后果非常嚴(yán)重。強(qiáng)對稱加密算法如3DES也存在類似問題。所以依然推薦采用哈希算法。Hash算法的選擇哈希算法有多種，常見的有MD5和SHA系列。現(xiàn)在有個叫彩虹表的東西，窮舉某個哈希值所對應(yīng)的明文，導(dǎo)致MD5和SHA-1已經(jīng)不再安全。而SHA-256或者SHA-512目前還是比較安全的，而且計算消耗的資源不會比MD5或SHA-1差太多。從代碼實現(xiàn)的角度考慮，各算法的參數(shù)都一樣，返回值類型也一樣，只是函數(shù)名和返回值長度變了，所以如果已經(jīng)使用了MD5或SHA-1,可以很方便切換到更安全的算法上。3)添加鹽值以鹽值為用戶名，算法為SHA-256為例，用戶最終存儲在后臺的口令就可以為SHA256“用戶名+口令”。而登錄的時候，有兩種驗證策略：可在客戶端計算出SHA256“輸入的用戶名+輸入的口令”，將計算的結(jié)果明文傳輸給服務(wù)端，由服務(wù)端比較該值與后臺數(shù)據(jù)庫中存儲的是否相同。將輸入的用戶名，口令加密傳輸?shù)椒?wù)端，在服務(wù)端計算SHA256“輸入的用戶名+輸入的口令”，，再與數(shù)據(jù)庫存儲的內(nèi)容做比較。加密傳輸現(xiàn)在比較流行的方法是HTTPS。可以看到，服務(wù)端不知道用戶的口令明文，所以即使數(shù)據(jù)庫被攻破，也不會泄漏用戶的口令。加鹽的好處在于使口令存儲變的更加安全。比如最常見的口令是123456，假設(shè)有100個用戶都這么設(shè)置，如果不加鹽，這100個用戶后臺加密存儲的口令就一模一樣，這就是一個安全隱患。加了鹽值還可以增加彩虹表碰撞的難度，就算用戶使用了最簡單的口令，加了鹽值后就難以破解。另外鹽值最好選擇用戶注冊后，就不會改變的信息，或是由這些信息計算后的另一個值。比如，如果鹽值設(shè)置成了用戶郵箱，那就要確保這個郵箱不能修改，否則一旦郵箱改了，HASH“新郵箱+口令”HHASH“舊郵箱+口令”，，從而用戶改了郵箱就不能再登錄了。6.4輸入驗證6.4.1什么是輸入應(yīng)用程序從各個方面獲取輸入，例如所有用戶發(fā)送的，或者是應(yīng)用程序與用戶交互往返的數(shù)據(jù)（用戶提交的數(shù)據(jù),cookie信息，查詢字符串參數(shù)等），以及后臺數(shù)據(jù)（數(shù)據(jù)庫、配置數(shù)據(jù)和其他數(shù)據(jù)來源）。所有輸入的數(shù)據(jù)都會在某些情況下影響請求的處理。輸入驗證是一個很復(fù)雜的問題,并且是應(yīng)用程序開發(fā)人員需要解決的首要問題。然而,正確的輸入驗證是防御目前應(yīng)用程序攻擊的最有效方法之一。正確的輸入驗證是防止XSS、SQL注入、緩沖區(qū)溢出和其他輸入攻擊的有效對策。輸入驗證非常復(fù)雜,因為對于應(yīng)用程序之間甚至應(yīng)用程序內(nèi)部的輸入,其有效構(gòu)成沒有一個統(tǒng)一的答案。同樣,對于惡意的輸入也沒有一個統(tǒng)一的定義。更困難的是,應(yīng)用程序?qū)θ绾翁幚泶溯斎雽绊憫?yīng)用的風(fēng)險。例如,您是否存儲用于其他應(yīng)用程序的數(shù)據(jù),或者應(yīng)用程序是否接受來自其他應(yīng)用程序所創(chuàng)建的數(shù)據(jù)源的輸入？以下做法可以增強(qiáng)Web應(yīng)用程序的輸入驗證：＞假定所有輸入都是惡意的＞集中方法＞不要依賴客戶端驗證＞注意標(biāo)準(zhǔn)化問題＞限制，拒絕和凈化輸入假定所有輸入都是惡意的開始輸入驗證時,首先假定所有輸入都是惡意的,除非有證據(jù)表明它們并無惡意。無論輸入是來自服務(wù)、共享文件、用戶還是數(shù)據(jù)庫,只要其來源不在可信任的范圍之內(nèi),就應(yīng)對輸入進(jìn)行驗證。例如,如果調(diào)用返回字符串的外部Web服務(wù),如何知道該服務(wù)不會執(zhí)行惡意命令呢？另外,如果幾個應(yīng)用程序?qū)懭胪粋€共享數(shù)據(jù)庫,您在讀取數(shù)據(jù)時,如何知道該數(shù)據(jù)是否安全呢？集中方法將輸入驗證策略作為應(yīng)用程序設(shè)計的核心元素。考慮集中式驗證方法,例如,通過使用共享庫中的公共驗證和篩選代碼。這可確保驗證規(guī)則應(yīng)用的致性。此外,還能減少開發(fā)的工作量,且有助于以后維護(hù)工作。許多情況下，不同的字段要求不同的驗證方法，例如，要求使用專門開發(fā)的常規(guī)表達(dá)式。但是，通?？梢缘玫津炞C常用手段（如電子郵件地址、標(biāo)題、名稱、包括郵政編碼在內(nèi)的通訊地址，等等）的常規(guī)方法。下圖顯示了此驗證方法：不要依賴客戶端驗證應(yīng)使用服務(wù)器端代碼執(zhí)行其自身的驗證。如果攻擊者繞過客戶端或關(guān)閉客戶端腳本例程（例如，通過禁用JavaScript腳本），后果如何？使用客戶端驗證可以減少客戶端到服務(wù)端的往返次數(shù)，但不要依賴這種方法進(jìn)行安全驗證。注意標(biāo)準(zhǔn)化問題數(shù)據(jù)的標(biāo)準(zhǔn)形式是最標(biāo)準(zhǔn)、最簡單的形式。標(biāo)準(zhǔn)化是指將數(shù)據(jù)轉(zhuǎn)化為標(biāo)準(zhǔn)形式的過程。文件路徑和URL尤其傾向于標(biāo)準(zhǔn)化問題，許多廣為人知的漏洞利用都直接源自標(biāo)準(zhǔn)化缺陷。例如，請考慮以下字符串，它以標(biāo)準(zhǔn)形式表示了文件及其路徑。/www/public/testfile.jsp以下字符串都指向同一個文件testfile.jsp/www/public/../root/testfile.jsp/www/public///testfile.jsp%2fwww%2fpublic%2f%2f%2ftestfile.jsp（urlencode）（十六進(jìn)制表示）最后一個示例使用十六進(jìn)制指定字符：%2E代表句號%3A代表冒號%5C代表反斜杠符號%2f代表斜杠通常，應(yīng)設(shè)法避免讓應(yīng)用程序接受用戶輸入的文件名，以防止標(biāo)準(zhǔn)化問題?？梢钥紤]其他設(shè)計方法。例如，讓應(yīng)用程序為用戶確定文件名。如果確實需要用戶輸入文件名，在作出安全決策（如授予或者拒絕對特定文件的訪問權(quán)限）之前，應(yīng)確保這些文件名具有嚴(yán)格定義的形式。限制、拒絕和凈化輸入輸入驗證的首選方法是從開始就限制允許輸入的內(nèi)容。按照已知的有效類型、模式和范圍驗證數(shù)據(jù)要比通過查找已知有害字符的數(shù)據(jù)驗證方法容易。設(shè)計應(yīng)用程序時，應(yīng)了解應(yīng)用程序需要輸入什么內(nèi)容。與潛在的惡意輸入相比，有效數(shù)據(jù)的范圍通常是更為有限的集合。然而，為了使防御更為徹底，您可能還希望拒絕已知的有害輸入，然后凈化輸入。下圖顯示了我們推薦的策略。限制輸入限制輸入與允許輸入有益數(shù)據(jù)類似。這是首選的輸入驗證方法。其思想是定義一個篩選器，根據(jù)類型、長度、格式和范圍來篩選輸入的數(shù)據(jù)。定義應(yīng)用程序字段可以接受的數(shù)據(jù)輸入，并強(qiáng)制應(yīng)用該定義。拒絕一切有害數(shù)據(jù)。限制輸入可能包括在服務(wù)器上設(shè)置字符集，以便在本地建立輸入的規(guī)范格式。驗證數(shù)據(jù)的類型、長度、格式和范圍在適當(dāng)?shù)牡胤綄斎霐?shù)據(jù)使用強(qiáng)類型檢查，例如，在用于操作和處理輸入數(shù)據(jù)的類中，以及在數(shù)據(jù)訪問例程中。例如，可以使用參數(shù)化的存儲過程來訪問數(shù)據(jù)，以便利于輸入字段的強(qiáng)類型檢查所帶來的好處。應(yīng)該檢查字符串字段的長度，在許多情況下，還應(yīng)檢查字符串的格式是否正確。例如，郵政編碼和身份證號碼等都具有明確定義的格式，可以使用常規(guī)表達(dá)式進(jìn)行驗證。嚴(yán)格的檢查不僅是很好的編程習(xí)慣，還能讓攻擊者更難利用您的代碼。攻擊者可能會通過類型檢查，但長度檢查會加大攻擊者實施攻擊的難度。拒絕已知的有害輸入雖然不能完全依賴于這種方法，但還是應(yīng)該拒絕“有害”數(shù)據(jù)。此方法通常不會像使用上述的“允許”方法那樣有效，但二者結(jié)合使用可以收到最佳效果。要拒絕有害數(shù)據(jù)，需假定應(yīng)用程序知道惡意輸入的所有變體。請記住，字符有多種表達(dá)方式。這是“允許”方法成為首選方法的另一個原因。雖然在應(yīng)用程序已經(jīng)部署、不能再做重大更改時，“拒絕”方法非常有用，但它不如“允許”方法那樣可靠，因為有害數(shù)據(jù)（如可用于識別常見攻擊的樣式）不是保持不變的。有效數(shù)據(jù)的形式是保持不變的，但有害數(shù)據(jù)的范圍卻是時常變化的。凈化輸入凈化是為了使用潛在危害的數(shù)據(jù)變得安全。如果所允許的輸入范圍不能保證輸入數(shù)據(jù)的安全性，那么凈化輸入是非常有用的。凈化包括從刪除用戶輸入字符串后面的空格到去除值（以便按照文字格式處理該數(shù)據(jù)）等一切行為。在Web應(yīng)用程序中，另一個常見的凈化輸入示例是使用URL編碼或HTML編碼來包裝數(shù)據(jù)，并將其作為文本而不是可執(zhí)行腳本來處理。HtmlEncode方法去除HTML自字符，而UrlEncode方法對URL進(jìn)行編碼，使其成為有效的URI請求。在實踐中以下是使用上述方法處理常見輸入字段的幾個示例：姓氏字段：這是一個很好的應(yīng)用限制輸入的示例。在這種情況下，可以接受的字符串范圍為ASCIIA-Z和a-z,以及連字符和波浪線（在SQL中，波浪線沒有意義），以便處理類似O'Dell之類的姓氏。還應(yīng)限制輸入內(nèi)容的最大長度。數(shù)量字段：這是應(yīng)用輸入限制的另一個例子。在此示例中，可以使用簡單的類型和范圍限制。例如，輸入數(shù)據(jù)應(yīng)該是介于0和1000之間的正整數(shù)。自定義文本字段：示例包括留言板上的備注字段。在這種情況下，您可能允許輸入字母和空格，以及省略符號、逗號和連字符等常用字符。允許輸入的字符集只包括符號、括號和大括號。有些應(yīng)用程序可能允許用戶使用一組有限的腳本字符修飾文本，如粗體“<b>”、斜體“<i>”，甚至包含指向他們所喜愛的URL的連接。處理URL時，驗證時應(yīng)先對所輸入的值進(jìn)行編碼，以便將其作為URL處理。不驗證用戶輸入的現(xiàn)有Web應(yīng)用程序。在理想解決方案中，應(yīng)用程序?qū)z查每個字段和入口點的輸入內(nèi)容是否可以接受。然而，如果現(xiàn)有Web應(yīng)用程序不驗證用戶輸入，則需要一種權(quán)宜方法來降低風(fēng)險，知道改進(jìn)應(yīng)用程序的輸入驗證策略。以下兩種方法都不能確保守護(hù)如數(shù)據(jù)的安全處理，因為這要依賴于輸入的來源，以及應(yīng)用程序使用輸入數(shù)據(jù)的方式，目前，它們作為快速的補(bǔ)救措施，能在短期內(nèi)提高應(yīng)用程序的安全性。向客戶端寫回數(shù)據(jù)時，對用戶輸入的數(shù)據(jù)進(jìn)行HTML編碼和URL編碼。在這種情況下，假設(shè)所有輸入均未作為HTML處理，并且向客戶端寫回的所有輸出都包含在受保護(hù)的表單中。這是凈化操作在起作用。6.4.2如何處理輸入處理用戶的輸入很多針對web應(yīng)用程序的攻擊都涉及到提交未預(yù)期的輸入，它導(dǎo)致了該應(yīng)用程序設(shè)計者沒有料到的行為。因此，對于應(yīng)用程序安全性防御的一個關(guān)鍵要求是它必須以一個安全的方式處理用戶的輸入?；谳斎氲穆┒纯赡茉谝粋€應(yīng)用程序的功能的任何地方，并與通常使用的技術(shù)類型相關(guān)。對于這種攻擊，輸入驗證是常用的必要防護(hù)。不存在通用的單一的防護(hù)機(jī)制。各種類型的輸入一個典型的Web應(yīng)用程序在不同范圍內(nèi)處理用戶提供的數(shù)據(jù)。某種類型的輸入驗證可能對于所有這些輸入形式是不可行的。在許多情況下，一個應(yīng)用程序?qū)τ谔囟ǖ妮斎腠椖軌驅(qū)嵤┓浅?yán)格的驗證檢查。比如提交給登錄函數(shù)的用戶名可以要求最大長度和只能包含字母。在另外一些情況下，應(yīng)用程序必須容納更大范圍的可能性的輸入。比如提交給一個個人信息頁面的地址字段，它可以包含字母、數(shù)字、空格、連接符，撇號以及其它字符。對于這種類型，仍然需要加以可行限制，如不能超過合適的長度，以及不能包含HTML標(biāo)記。在某些情形下，一個應(yīng)用程序可能需要接受來自用戶的任意的輸入。比如，一個blog應(yīng)用程序的用戶，他創(chuàng)建的博客的主題是關(guān)于Web應(yīng)用程序攻擊的內(nèi)容，那么他提交的內(nèi)容則可以包含明顯的攻擊字符串。該應(yīng)用程序需要以一個安全的方法把這些輸入存儲在一個數(shù)據(jù)庫中并寫到磁盤上，以及回顯給用戶。所以該應(yīng)用程序不能因為輸入看起來有潛在的惡意語句而簡單拒絕。除了來自用戶的瀏覽器的各種輸入外，典型的應(yīng)用程序也接受從服務(wù)器到客戶端，然后回傳給服務(wù)器的數(shù)據(jù)。這些項目包括諸如cookies和隱藏的表單字段，它們不會被這個應(yīng)用程序的普通用戶所看到，但是對于攻擊者來說是可見和可修改的。在這些情況中，應(yīng)用程序可以對所接收到的數(shù)據(jù)進(jìn)行特定的驗證。例如要求參數(shù)必須有一個指定數(shù)值集中的值，如表明用戶所偏愛的語言的cookie，或以一個指定的格式，如一個客戶的ID號。進(jìn)一步說，當(dāng)應(yīng)用程序發(fā)現(xiàn)返回自用戶的由服務(wù)器生成的數(shù)據(jù)已經(jīng)被修改了的話，這通常就表明該用戶正在探測應(yīng)用程序的漏洞。在此類情況下，應(yīng)用程序應(yīng)該拒絕請求并記錄下這個探測事件。處理輸入的方式處理用戶的輸入有很多方式。不同的方式適合不同的情形和不同的輸入類型。有些時候一個組合的方式是可取的。黑名單這種方式通常使用一個黑名單，它包含已知的被用在攻擊方面的一套字面上的字符串或模式。驗證機(jī)制阻擋任何匹配黑名單的數(shù)據(jù)。一般來說，這種方式是被認(rèn)為對于檢查用戶的輸入效果最差的一種方式。主要有兩個原因，首先是Web應(yīng)用程序中的一個典型的漏洞可以使用很多種不同的輸入來被利用，輸入可以是被加密的或以各種不同的方法標(biāo)識。其二，漏洞利用的技術(shù)是在不斷地改進(jìn)的。有關(guān)利用已存在的漏洞類型的新的方法不可能被當(dāng)前黑名單阻擋。白名單這種方式采用一個白名單，它包含一套字面上的字符串或模式，或一套標(biāo)準(zhǔn)，它們用來匹配符合要求的輸入。這種檢查機(jī)制允許匹配白名單的數(shù)據(jù)，阻止之外的任何數(shù)據(jù)。這種方式雖然最有效，但不是通用的，比如撇號和連字符可以被用于對數(shù)據(jù)庫的攻擊，但是有時應(yīng)用程序卻應(yīng)該允許它的輸入。過濾這種方式下，潛在的惡意字符被刪除，留下安全的字符，或者在進(jìn)一步處理被執(zhí)行之前，它們被適當(dāng)?shù)丶用芑蛉サ??；跀?shù)據(jù)過濾的方式通常是十分有效的，并且在許多情形中，可作為處理惡意輸入的通用解決方案。比如，針對跨站腳本攻擊的通常的防護(hù)是在字符被嵌入到應(yīng)用程序的頁面之前進(jìn)行HTML加密。然而如果幾種潛在的惡意數(shù)據(jù)在一個輸入項中的話，有效的過濾是困難的，在這種情況下，邊界檢查方法則是更適用的。安全地處理數(shù)據(jù)非常多的web應(yīng)用程序漏洞的出現(xiàn)是因為用戶提供的數(shù)據(jù)是以不安全的方法被處理的。在一些情況下，存在安全的編程方法能夠避免通常的問題。例如，SQL注入攻擊能夠通過正確的參數(shù)查詢被阻止，在另外的情況中，應(yīng)用程序功能設(shè)計的方法存在內(nèi)在的不安全性，比如把用戶的輸入傳遞給操作系統(tǒng)的命令解釋器。安全處理數(shù)據(jù)的方式不能適用于web應(yīng)用程序需要執(zhí)行的所有工作，但是它對于處理潛在的惡意輸入通常是比較有效的方式。語義檢查語義檢查用于防止各種變形數(shù)據(jù)的輸入，這些數(shù)據(jù)的內(nèi)容被精心制作來干擾應(yīng)用程序的處理。然而對于有一些漏洞，攻擊者的輸入在表面看來和普通用戶的輸入是一樣的，說到底檢查就失去了作用。例如一個攻擊者可能會通過改變隱藏的表意字段中的帳號來試圖獲得對他人銀行賬戶的訪問。要阻止這種未授權(quán)的訪問，應(yīng)用程序需要驗證帳號是否屬于該用戶。邊界檢查對于web應(yīng)用程序，核心安全問題的出現(xiàn)是因為接受自用戶的數(shù)據(jù)是不可信的，盡管在客戶端實現(xiàn)的輸入驗證檢查能夠提高性能和用戶體驗，但是這對于實際到達(dá)服務(wù)器的數(shù)據(jù)卻沒有任何擔(dān)保。用戶的數(shù)據(jù)在被服務(wù)端應(yīng)用程序第一時間接受到的一刻就是邊界，此時應(yīng)用程序需要采取步驟來防衛(wèi)惡意的輸入，鑒于核心問題的本質(zhì)，對于互聯(lián)網(wǎng)邊界間的輸入檢查這一問題的思考是很有意義的，哪些是“惡意的”或不可信任的，以及服務(wù)端應(yīng)用程序哪些是“好的”或可信任的。我們給出了一個簡單的想法：輸入驗證的角色是清除到達(dá)的數(shù)據(jù)中的潛在的惡意數(shù)據(jù)，然后把干凈的數(shù)據(jù)傳遞給可信任的應(yīng)用程序。據(jù)此，這些數(shù)據(jù)可以被信任和處理而不做進(jìn)一步的檢查或考慮可能的攻擊。當(dāng)我們開始檢查一些實際的漏洞的時候，會很明顯地發(fā)現(xiàn)上面的簡單的想法是不充分的。原因如下：鑒于web應(yīng)用程序?qū)崿F(xiàn)的功能的廣泛性，以及所應(yīng)用的技術(shù)的不同，一個典型的web應(yīng)用程序需要防衛(wèi)大量的不同的基于輸入的攻擊，每種輸入攻擊都可能采用了一套不同的數(shù)據(jù)。針對外部邊界僅設(shè)計單一的一個機(jī)制來防衛(wèi)所有這些攻擊是非常困難的。許多應(yīng)用程序的函數(shù)包含相互牽連的一系列不同的處理，單個用戶所提交的一塊數(shù)據(jù)可能導(dǎo)致不同組件之間的許多操作，上一個輸出可能作為下一個的輸入。當(dāng)數(shù)據(jù)被傳送時，它可能有所變化，與最初的輸入可能有所不同，這樣一個熟練的黑客可能能夠操縱這個應(yīng)用程序以在處理的關(guān)鍵階段導(dǎo)致惡意輸入的產(chǎn)生，也就是攻擊接受該數(shù)據(jù)的組件，這對于在外部邊界預(yù)見用戶輸入的每塊數(shù)據(jù)的處理的所有結(jié)果來實現(xiàn)一個驗證機(jī)制是十分困難的。防衛(wèi)不同種類的輸入攻擊可能需要對用戶的輸入執(zhí)行不同的驗證檢查，這些驗證檢查是不兼容的。例如阻止跨站腳本攻擊可以要求HTML轉(zhuǎn)義“〉”為“>”而阻止命令注入攻擊可能需要禁止包含“&”和“”字符的輸入。試圖在應(yīng)用程序的外部邊界同時阻止所有種類的攻擊有時是不可能的。一個使用邊界檢查概念的更有效的模型是，服務(wù)器端的每個組件或功能單元把它的輸入當(dāng)作是來自一個潛在的惡意源。數(shù)據(jù)檢查除了在客戶端和服務(wù)端之間的邊界外，也在這些認(rèn)為可信的邊界被執(zhí)行。這個模型對前面列出的問題列表提供了一個解決方案。每個組件針對自身可能的漏洞的特定的輸入攻擊能夠自我防衛(wèi)。當(dāng)數(shù)據(jù)在不同組件之間傳遞時，驗證檢查就可以對前面?zhèn)鱽頂?shù)據(jù)進(jìn)行檢查，由于不同的驗證檢查是在不同的處理階段被執(zhí)行的，所以他們之間不會產(chǎn)生沖突。下圖演示了一個防衛(wèi)惡意輸入最有效的方式，用戶登錄導(dǎo)致對用戶提交的輸入進(jìn)行了幾步處理，并且每步都執(zhí)行了適當(dāng)?shù)臋z查。圖示：在多個處理階段使用邊界檢查應(yīng)用程序接受用戶的登錄的詳細(xì)數(shù)據(jù)，表單處理檢查輸入的每一項，包括允許的字符、長度是否在指定的范圍內(nèi)、以及不能包含任何已知的共計特征碼。應(yīng)用程序執(zhí)行一個SQL查詢來驗證用戶的證書。為了阻止SQL注入攻擊，用戶輸入的任何可能攻擊數(shù)據(jù)庫的字符在構(gòu)造查詢之前都被去掉。如果登錄成功，應(yīng)用程序?qū)褋碜杂脩舻臄?shù)據(jù)傳遞給一個SOAP服務(wù)器以檢索他的賬戶的更多的信息。為了阻止SOAP注入攻擊，用戶數(shù)據(jù)中的任何XML元字符都被適當(dāng)?shù)丶用芴幚?。?yīng)用程序把用戶的賬戶信息回傳給用戶的瀏覽器以顯示。為了防止跨站腳本攻擊，應(yīng)用程序HTML加密嵌在返回的頁面中的用戶提供的任何數(shù)據(jù)?？傊?，所有牽涉的組件間都應(yīng)作邊界檢查。情況的變化會導(dǎo)致所涉及的組件發(fā)生變化。例如如果登錄失敗后，應(yīng)用程序會發(fā)送一個警告郵件給該用戶的話，那么任何合并到該郵件中的用戶數(shù)據(jù)可能需要針對SMTP注入攻擊做檢查。6.5輸出編碼6.5.1輸出編碼的種類輸出編碼是轉(zhuǎn)換輸入數(shù)據(jù)為輸出格式的過程序，輸出格式不包含，或者只是有選擇性的包含允許的特殊字符。輸出的種類有：>支持HTML代碼的輸出>不支持HTML代碼的輸出URL的輸出頁面內(nèi)容的輸出Keywords、Description等js腳本的輸出style樣式的輸出xml數(shù)據(jù)的輸出>服務(wù)控件的輸出6.5.2輸出編碼的必要性輸出編碼能夠有效地防止HTML注入（跨站腳本XSS攻擊）等，也能確保輸出內(nèi)容的完整性和正確性。6.5.3安全輸出編碼方式防御手段一：過濾保護(hù)級別：★★★☆描述：對于支持HTML代碼的輸出，輸出前要確保代碼中不含有跨站攻擊腳本才能輸出。通過寫過濾函數(shù)，進(jìn)行強(qiáng)制過濾。優(yōu)點：支持HTML，有效防止主流XSS攻擊。缺點：有可能出錯，函數(shù)設(shè)計難度大。防御手段二：HTML編碼描述：對于不支持HTML的輸出，在輸出到頁面前要進(jìn)行Server.HtmlEncode編碼，部分服務(wù)器控件或者XSLT轉(zhuǎn)換本身就支持Server.HtmlEncode編碼,可不必重復(fù)編碼。優(yōu)點：非?？煽?。缺點：不支持HTML輸出。防御手段三：URL編碼保護(hù)級另山★★★★★描述：對于URL的輸出，要對輸出URL進(jìn)行Server.UrlEncode處理。如：〈imgsrc=”輸出內(nèi)容”border二”0”alt二”logo”/〉的輸出要確保輸出內(nèi)容的Url編碼正確，不允許”””的輸出。優(yōu)點：可靠性高。缺點：應(yīng)用范圍少。防御手段四：轉(zhuǎn)化特殊符號的編碼形式描述：對于頁面內(nèi)容的輸出，要確保輸出的正確性和允許輸出的數(shù)據(jù)。如：頁面〈metacontent二”輸出內(nèi)容name二”Keywords”/〉的輸出。要確保輸出內(nèi)容中不包含特殊符號”””輸出前要轉(zhuǎn)換特殊符號的編碼形式，將”””轉(zhuǎn)換為"；同樣的輸出有title二'”'的輸出等。對于js腳本的輸出，要確保輸出代碼中不包含跨站腳本，注意”'”和”””的輸出，以免被組合成危險的js代碼。如：圖片模塊，圖片地址的輸出。對于style樣式的輸出，要確保樣式的正確性，目前系統(tǒng)主要應(yīng)用到標(biāo)題顏色的輸出，如果增加其他樣式的輸出，要確保樣式的安全性才能輸出。對于xml數(shù)據(jù)的輸出，要確保數(shù)據(jù)中是否有XML不允許的字符，要對特殊字符進(jìn)行轉(zhuǎn)換才能輸出