第十章 OWASP Top 10 的預(yù)防
作者：Gilberto Najera-Gutierrez
譯者：飛龍
協(xié)議：CC BY-NC-SA 4.0
簡介
每個滲透測試的目標(biāo)都是識別應(yīng)用社裆、服務(wù)器或網(wǎng)絡(luò)中的可能缺陷，它們能夠讓攻擊者有機會獲得敏感系統(tǒng)的信息或訪問權(quán)限太闺。檢測這類漏洞的原因不僅僅是了解它們的存在以及推斷出其中的漏洞，也是為了努力預(yù)防它們或者將它們降至最小判族。
這一章我們臀稚，我們會觀察一些如何預(yù)防多數(shù) Web 應(yīng)用漏洞的例子和推薦疫粥，根據(jù) OWASP：
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
A1 預(yù)防注入攻擊
根據(jù) OWASP，Web 應(yīng)用中發(fā)現(xiàn)的最關(guān)鍵的漏洞類型就是一些代碼的注入攻擊故爵，例如 SQL 注入玻粪、OS 命令注入、HTML 注入（XSS）。
這些漏洞通常由應(yīng)用的弱輸入校驗導(dǎo)致劲室。這個秘籍中伦仍，我們會設(shè)計一些處理用戶輸入和構(gòu)造所使用的請求的最佳實踐。
操作步驟
-
為了防止注入攻擊很洋，首先需要合理校驗輸入充蓝。在服務(wù)端，這可以由編寫我們自己的校驗流程來實現(xiàn)喉磁，但是最佳選擇是使用語言自己的校驗流程谓苟，因為它們更加廣泛使用并測試過。一個極好的激勵就是 PHP 中的
filter_var协怒，或者 ASP.NET 中的 校驗助手涝焙。例如，PHP 中的郵箱校驗類似于：function isValidEmail($email){ return filter_var($email, FILTER_VALIDATE_EMAIL); } -
在客戶端孕暇，檢驗可以由創(chuàng)建 JavaScript 校驗函數(shù)來完成纱皆，使用正則表達式。例如芭商，郵箱檢驗流程是：
function isValidEmail (input) { var result=false; var email_regex = /^[a-zA-Z0-9._-]+@([a-zA-Z0-9.-]+\.)+[azA-Z0-9.-]{2,4}$/; if ( email_regex.test(input) ) { result = true; } return result; } -
對于 SQL 注入，避免拼接輸入值為查詢十分關(guān)鍵搀缠。反之铛楣，使用參數(shù)化查詢。每個編程語言都有其自己的版本：
PHP MySQLLi：
$query = $dbConnection->prepare('SELECT * FROM table WHERE name = ?'); $query->bind_param('s', $name); $query->execute();C#：
string sql = "SELECT * FROM Customers WHERE CustomerId = @ CustomerId"; SqlCommand command = new SqlCommand(sql); command.Parameters.Add(new SqlParameter("@CustomerId", System. Data.SqlDbType.Int)); command.Parameters["@CustomerId"].Value = 1;Java：
String custname = request.getParameter("customerName"); String query = "SELECT account_balance FROM user_data WHERE user_ name =? "; PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( ); 考慮注入出現(xiàn)的時機艺普，對減少可能的損失總量也有幫助簸州。所以，使用低權(quán)限的系統(tǒng)用戶來運行數(shù)據(jù)庫和 Web 服務(wù)器歧譬。
確保輸入用于連接數(shù)據(jù)庫服務(wù)器的用戶不是數(shù)據(jù)庫管理員岸浑。
禁用甚至刪除允許攻擊者執(zhí)行系統(tǒng)命令或提權(quán)的儲存過程，例如 MSSQL 服務(wù)器中的
xp_cmdshell瑰步。
工作原理
預(yù)防任何類型代碼注入攻擊的主要部分永遠是合理的輸入校驗矢洲，位于服務(wù)端也位于客戶端。
對于 SQL 注入缩焦，始終使用參數(shù)化或者預(yù)編譯查詢读虏。而不是拼接 SQL 語句和輸入。參數(shù)化查詢將函數(shù)參數(shù)插入到 SQL 語句特定的位置袁滥，消除了程序員通過拼接構(gòu)造查詢的需求盖桥。
這個秘籍中，我們使用了語言內(nèi)建的校驗函數(shù)题翻，但是如果你需要校驗一些特殊類型的參數(shù)揩徊，你可以通過使用正則表達式創(chuàng)建自己的版本。
除了執(zhí)行正確校驗，我們也需要在一些人蓄意注入一些代碼的情況下塑荒，降低淪陷的影響熄赡。這可以通過在操作系統(tǒng)的上下文中為 Web 服務(wù)器合理配置用戶權(quán)限，以及在數(shù)據(jù)庫服務(wù)器上下文中配置數(shù)據(jù)庫和 OS 來實現(xiàn)袜炕。
另見
對于數(shù)據(jù)校驗來講本谜，最有用的工具就是正則表達式。在處理和過濾大量信息的時候偎窘，它們也能夠讓滲透測試變得更容易乌助。所以好好了解它們很有必要。我推薦你查看一些站點：
http://www.regexr.com/ 一個很好的站點陌知，其中我們可以獲得示例和參數(shù)并測試我們自己的表達式來查看是否有字符串匹配他托。
http://www.regular-expressions.info 它包含教程和實例來了解如何使用正則表達式。它也有一份實用的參考仆葡，關(guān)于主流語言和工具的特定實現(xiàn)赏参。
http://www.princeton.edu/~mlovett/reference/Regular-Expressions.pdf （Jan Goyvaerts 編寫的《Regular Expressions, The Complete Tutorial》）就像它的標(biāo)題所說，它是個正則表達式的非常完備的腳本沿盅，包含許多語言的示例把篓。
A2 構(gòu)建合理的身份驗證和會話管理
帶有缺陷的身份驗證和會話管理是當(dāng)今 Web 應(yīng)用中的第二大關(guān)鍵的漏洞。
身份驗證是用戶證明它們是它們所說的人的過程腰涧。這通常通過用戶名和密碼來完成韧掩。一些該領(lǐng)域的常見缺陷是寬松的密碼策略，以及隱藏式的安全（隱藏資源缺乏身份驗證）窖铡。
會話管理是登錄用戶的會話標(biāo)識符的處理疗锐。在 Web 服務(wù)器中，這可以通過實現(xiàn)會話 Cookie 和標(biāo)識來完成费彼。這些標(biāo)識符可以植入滑臊、盜取，或者由攻擊者使用社會工程箍铲、XSS 或 CSRF 來“劫持”雇卷。所以，開發(fā)者必須特別注意如何管理這些信息颠猴。
這個秘籍中聋庵，我們會設(shè)計到一些實現(xiàn)用戶名/密碼身份驗證，以及管理登錄用戶的會話標(biāo)識符的最佳實踐芙粱。
操作步驟
如果應(yīng)用中存在只能由授權(quán)用戶查看的頁面祭玉、表單或者任何信息片段，確保在展示它們之前存在合理的身份驗證春畔。
確保用戶名脱货、ID岛都、密碼和所有其它身份驗證數(shù)據(jù)是大小寫敏感的，并且對每個用戶唯一振峻。
-
建立強密碼策略臼疫，強迫用戶創(chuàng)建至少滿足下列條件的密碼：
對于 8 個字符，推薦 10 個扣孟。
使用大寫和小寫字母烫堤。
至少使用一個數(shù)字。
至少使用一個特殊字符（空格凤价、
!鸽斟、&、#利诺、%富蓄，以及其它）。禁止用戶名慢逾、站點名稱立倍、公司名稱或者它們的變體（大小寫轉(zhuǎn)換、l33t侣滩、它們的片段）用于密碼口注。
禁止使用“常見密碼”列表中的密碼：https://www.teamsid.com/worst-passwords-2015/ 。
-
永遠不要顯示用戶是否存在或者信息格式是否正確的錯誤信息君珠。對不正確的登錄請求寝志、不存在的用戶、名稱或密碼不匹配模式葛躏、以及所有可能的登錄錯誤使用相同的泛化信息。這種信息類似于：
登錄數(shù)據(jù)不正確悠菜。
用戶名或密碼無效舰攒。
訪問禁止。
密碼不能以純文本格式儲存在數(shù)據(jù)庫中悔醋。使用強哈希算法摩窃，例如 SHA-2、scrypt芬骄、或者 bcrypt猾愿，它們特別為難以使用 GPU 破解而設(shè)計。
在對比用戶輸入和密碼時账阻，計算輸入的哈希之后比較哈希之后的字符串蒂秘。永遠不要解密密碼來使用純文本用戶輸入來比較。
避免基本的 HTML 身份驗證淘太。
-
可能的話姻僧，使用多因素驗證（MFA）规丽，這意味著使用不止一個身份驗證因素來登錄：
一些你知道的（賬戶信息或密碼）
一些你擁有的（標(biāo)識或手機號）
一些你的特征（生物計量）
如果可能的話，實現(xiàn)證書撇贺、預(yù)共享密鑰赌莺、或其它無需密碼的身份校驗協(xié)議（OAuth2、OpenID松嘶、SAML艘狭、或者 FIDO）。
對于會話管理翠订，推薦使用語言內(nèi)建的會話管理系統(tǒng)巢音，Java、ASP.NET和 PHP蕴轨。它們并不完美港谊，但是能夠確保提供設(shè)計良好和廣泛測試的機制，而且比起開發(fā)團隊在時間緊迫情況下的自制版本橙弱，它們更易于實現(xiàn)歧寺。
始終為登錄和登錄后的頁面使用 HTTPS -- 顯然，要防止只接受 SSL 和 TLS v1.1 連接棘脐。
為了確保 HTTPS 能夠生效斜筐，可以使用 HSTS。它是由 Web 應(yīng)用指定的雙向選擇的特性蛀缝。通過 Strict-Transport-Security 協(xié)議頭顷链，它在
http://存在于 URL 的情況下會重定向到安全的選項，并防止“無效證書”信息的覆寫屈梁。例如使用 Burp Suite 的時候會出現(xiàn)的情況嗤练。更多信息請見： https://www.owasp.org/index.php/HTTP_Strict_Transport_Security 。始終設(shè)置 HTTPOnly 和安全的 Cookie 屬性在讶。
設(shè)置最少但實際的會話過期時間煞抬。確保正常用戶離開之后，攻擊者不能復(fù)用會話构哺，并且用戶能夠執(zhí)行應(yīng)用打算執(zhí)行的操作革答。
工作原理
身份校驗機制通常在 Web 應(yīng)用中簡化為用戶名/密碼登錄頁面。雖然并不是最安全的選擇曙强，但它對于用戶和開發(fā)者最簡單残拐，以及當(dāng)密碼被盜取時，最重要的層面就是它們的強度碟嘴。
我們可以從這本書看到溪食，密碼強度由破解難度決定，通過爆破娜扇、字典或猜測眠菇。這個秘籍的第一個提示是為了使密碼更難以通過建立最小長度的混合字符集來破解边败，難以通過排除更直覺的方案（用戶名、常見密碼捎废、公司名稱）來猜測笑窜，并且通過使用強哈希或加密儲存登疗，難以在泄露之后破解排截。
對于會話管理來說，過期時間辐益、唯一性和會話 ID 的強度（已經(jīng)在語言內(nèi)建機制中實現(xiàn)）断傲，以及 Cookie 設(shè)置中的安全都是關(guān)鍵的考慮因素。
談?wù)撋矸菪ｒ灠踩淖钪匾膶用媸侵钦绻⒖梢酝ㄟ^中間人攻擊攔截或者服務(wù)认罩，沒有任何安全配置、控制或強密碼是足夠安全的续捂。所以垦垂，合理配置的加密通信頻道的使用，例如 TLS牙瓢，對保護我們的用戶身份數(shù)據(jù)來說極其重要劫拗。
另見
OWASP 擁有一些非常好的頁面，關(guān)于身份校驗和會話管理矾克。我們推薦你在構(gòu)建和配置 Web 應(yīng)用時閱讀并仔細考慮它們页慷。
- https://www.owasp.org/index.php/Authentication_Cheat_Sheet
- https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
A3 預(yù)防跨站腳本
我們之前看到，跨站腳本胁附，在展示給用戶的數(shù)據(jù)沒有正確編碼酒繁，并且瀏覽器將其解釋并執(zhí)行為腳本代碼時發(fā)生。這也存在輸入校驗因素控妻，因為惡意代碼通常由輸入變量插入州袒。
這個秘籍中，我們會涉及開發(fā)者所需的輸入校驗和輸出編碼饼暑，來防止應(yīng)用中的 XSS 漏洞稳析。
工作原理
應(yīng)用存在 XSS 漏洞的第一個標(biāo)志是洗做，頁面準(zhǔn)確反映了用戶提供的輸入弓叛。所以，嘗試不要使用用戶提供的信息來構(gòu)建輸出文本诚纸。
當(dāng)你需要將用戶提供的信息放在輸出頁面上時撰筷，校驗這些數(shù)據(jù)來防止任何類型代碼的插入。我們已經(jīng)在 A1 中看到如何實現(xiàn)它畦徘。
出于一些原因毕籽，如果用戶被允許輸入特殊字符或者代碼段抬闯，在它插入到輸出之前，過濾或合理編碼文本关筒。
-
對于過濾溶握，在 PHP 中，可以使用
filter_var蒸播。例如睡榆，如果你想讓字符串為郵件地址：$email = "john(.doe)@exa//mple.com"; $email = filter_var($email, FILTER_SANITIZE_EMAIL); echo $email;對于編碼，你可以在 PHP 中使用
htmlspecialchars：$str = "The JavaScript HTML tags are <script> for opening, and </ script> for closing."; echo htmlspecialchars($str); 在 .NET 中袍榆，對于 4.5 及更高版本胀屿，
System.Web.Security.AntiXss命名空間提供了必要的工具。對于 .NET 框架 4 及之前的版本包雀，你可以使用 Web 保護庫：http://wpl.codeplex.com/宿崭。同樣，為了防止儲存型 XSS才写，在儲存進數(shù)據(jù)庫或從數(shù)據(jù)庫獲取之前葡兑，編碼或過濾每個信息片段。
不要忽略頭部琅摩、標(biāo)題铁孵、CSS和頁面的腳本區(qū)域，因為它們也可以被利用房资。
工作原理
除了合理的輸入校驗蜕劝，以及不要將用戶輸入用作輸出信息，過濾和編碼也是防止 XSS 的關(guān)鍵層面轰异。
過濾意味著從字符串移除不允許的字符岖沛。這在輸入字符串中存在特殊字符時很實用。
編碼將特殊字符轉(zhuǎn)換為 HTML 代碼表示搭独。例如婴削，&變?yōu)?code>&、<變?yōu)?code><牙肝。一些應(yīng)用允許在輸入字符串中使用特殊字符唉俗，對它們來說過濾不是個選擇。所以應(yīng)該在將輸入插入頁面配椭，或者儲存進數(shù)據(jù)庫之前編碼輸入虫溜。
另見
OWASP 擁有值得閱讀的 XSS 預(yù)防速查表：
A4 避免直接引用不安全對象
當(dāng)應(yīng)用允許攻擊者（也是校驗過的用戶）僅僅修改請求中的，直接指向系統(tǒng)對象的參數(shù)值股缸，來訪問另一個未授權(quán)的對象時衡楞，就存在不安全對象的直接引用（IDOR）。我們已經(jīng)在本地文件包含和目錄遍歷漏洞中看到了一些例子敦姻。
根據(jù) OWASP瘾境，IDOR 是 Web 應(yīng)用中第四大關(guān)鍵漏洞歧杏。這些漏洞通常由不良的訪問控制實現(xiàn)，或者“隱藏式安全”策略（如果用戶不能看到它迷守，他們就不能知道它的存在）導(dǎo)致犬绒。這些在沒有經(jīng)驗的開發(fā)者之中是個常見的做法。
這個秘籍中兑凿，我們會涉及在設(shè)計訪問控制機制時應(yīng)該考慮的關(guān)鍵層面懂更，以便預(yù)防 IDOR 漏洞。
操作步驟
使用非直接引用優(yōu)于直接引用急膀。例如沮协，不要通過參數(shù)中的名稱來引用頁面（
URL?page="restricted_page"），而是要創(chuàng)建索引卓嫂，并在內(nèi)部處理它（URL?page=2）慷暂。將非直接引用映射到用戶（會話）層面，于是用戶僅僅能夠訪問授權(quán)的對象晨雳，即使它們修改了下標(biāo)行瑞。
在傳遞相應(yīng)對象之前校驗引用，如果請求的用戶沒有權(quán)限來訪問餐禁，展示通用錯誤頁面血久。
輸入校驗也是很重要的，尤其是目錄遍歷和文件包含的情況下帮非。
永遠不要采取“隱藏式安全”的策略氧吐。如果有些文件包含受限的信息，即使它沒有引用末盔，有些人也會把它翻出來筑舅。
工作原理
不安全對象的直接引用在 Web 應(yīng)用中的表現(xiàn)形式有所不同，從目錄遍歷到敏感的 PDF 文檔的引用陨舱。但是它們的大多數(shù)都依賴于一個假設(shè)翠拣，即用戶永遠不會找到方法來訪問不能顯式訪問的東西。
為了防止這種漏洞游盲，需要在設(shè)計和開發(fā)期間執(zhí)行一些積極操作。設(shè)計可靠授權(quán)機制益缎，來驗證嘗試訪問一些信息的用戶的關(guān)鍵是，是否用戶真正允許訪問它畦娄。
將引用對象映射為下標(biāo)來避免對象名稱直接用于參數(shù)值（就像 LFI 中的那樣）是第一步弊仪。攻擊者也可以修改下標(biāo)熙卡，這很正常驳癌，就像對對象名稱所做的那樣。但是數(shù)據(jù)庫中存在下標(biāo)-對象的表的話役听，添加字段來規(guī)定訪問所需的權(quán)限級別颓鲜，比起沒有任何表并且直接通過名稱來訪問資源，要容易得多典予。
之前說過甜滨，下標(biāo)的表可能包含訪問對象所需的權(quán)限級別，更加嚴(yán)格的話還有擁有者的 ID瘤袖。所以衣摩，它只能夠在請求用戶是擁有者的情況下訪問。
最后捂敌，輸入校驗必須存在于 Web 應(yīng)用安全的每個層面艾扮。
A5 基本的安全配置指南
系統(tǒng)的默認(rèn)配置，包括操作系統(tǒng)和Web 服務(wù)器占婉，多數(shù)用于演示和強調(diào)他們的基本或多數(shù)有關(guān)特性泡嘴，并不能保護它們不被攻擊。
一些常見的可能使系統(tǒng)淪陷的默認(rèn)配置逆济，是數(shù)據(jù)庫酌予、Web 服務(wù)器或CMS 安裝時創(chuàng)建的默認(rèn)管理員賬戶，以及默認(rèn)管理員頁面奖慌、默認(rèn)楒眨回溯錯誤信息，以及其它升薯。
這個秘籍中莱褒，我們會涉及 OWASP Top 10 中第五大關(guān)鍵漏洞，錯誤的安全配置涎劈。
操作步驟
-
可能的話广凸，刪除所有管理員應(yīng)用，例如 Joomla 的 admin蛛枚，WordPress 的 admin，PhpMyAdmin扭吁，或者 Tomcat Manager。如果不能這樣蝌诡，使它們只能從本地網(wǎng)絡(luò)訪問浦旱，例如，在 Apache 服務(wù)器中禁止來自外部網(wǎng)絡(luò)的 PhpMyAdmin 訪問甥捺，修改
httd.conf文件（或者相應(yīng)的站點配置文件）涎永。<Directory /var/www/phpmyadmin> Order Deny,Allow Deny from all Allow from 127.0.0.1 ::1 Allow from localhost Allow from 192.168 Satisfy Any </Directory>這會首先禁止所有地址到
phpmyadmin目錄的訪問羡微，之后它允許任何來自 locaohost 和以192.168開頭的地址的請求妈倔，這是本地網(wǎng)絡(luò)的地址。 -
修改所有 CMS听怕、應(yīng)用闽烙、數(shù)據(jù)庫黑竞、服務(wù)器和框架的所有管理員密碼很魂，使其強度足夠遏匆。一些應(yīng)用的例子是：
- Cpanel
- Joomla
- WordPress
- PhpMyAdmin
- Tomcat manager
禁用所有不必要或未使用的服務(wù)器和應(yīng)用特性幅聘。從日常或每周來看陵叽，新的漏洞都出現(xiàn)在 CMS 的可選模塊和插件中巩掺。如果你的應(yīng)用不需要它們胖替，就不要激活它們独令。
始終執(zhí)行最新的安全補丁和更新燃箭。在生成環(huán)境，建立測試環(huán)境來預(yù)防使站點不工作的缺陷十分重要邻薯，因為新版本存在一些兼容性及其它問題累榜。
建立不會泄露跟蹤信息信柿、軟件版本渔嚷、程序組件名稱稠曼，或任何其它調(diào)試信息的自定義的錯誤頁面。如果開發(fā)者需要跟蹤錯誤記錄或者一些一些標(biāo)識符對于技術(shù)支持非常必要量瓜，創(chuàng)建帶有簡單 ID 和錯誤描述的索引绍傲，并只展示 ID 給用戶烫饼。所以當(dāng)錯誤報告給相關(guān)人士的時候，它們會檢查下標(biāo)并且知道發(fā)生了什么錯誤比藻。
采取“最小權(quán)限原則”银亲。每個用戶在每個層面（操作系統(tǒng)群凶、數(shù)據(jù)庫请梢、或應(yīng)用）上都應(yīng)該只能夠嚴(yán)格訪問正確操作所需的信息。
使用上一個要點來考慮賬戶当窗，構(gòu)建安全配置的原則元咙，并且將其應(yīng)用到每個新的實現(xiàn)庶香、更新或發(fā)布以及當(dāng)前系統(tǒng)中赶掖。
強制定期的安全測試或?qū)徲嬌萋福瑏韼椭鷻z測錯誤配置或遺漏的補丁膳灶。
工作原理
談?wù)摪踩团渲脝栴}時轧钓，“細節(jié)決定成敗”十分恰當(dāng)聋迎。web 服務(wù)器霉晕、數(shù)據(jù)庫服務(wù)器牺堰、CMS伟葫、或者應(yīng)用配置應(yīng)該在完全可用和實用筏养、以及保護用戶和擁有者之間取得平衡渐溶。
Web 應(yīng)用的一個常見錯誤配置就是一些 Web 管理站點對整個互聯(lián)網(wǎng)都可見茎辐。這看起來并不是個大問題，但是我們應(yīng)該知道依啰，管理員登錄頁面更容易吸引攻擊者孔飒，因為它可以用于獲得高級權(quán)限等級坏瞄，并且任何 CMS鸠匀、數(shù)據(jù)或者站點管理工具都存在已知的常用默認(rèn)密碼列表缀棍。所以父腕，我們強烈推薦不要把這些管理站點暴露給外部璧亮，并且盡可能移除它們枝嘶。
此外群扶，強密碼的使用竞阐，以及修改默認(rèn)密碼（即使它們是強密碼）骆莹，在發(fā)布應(yīng)用到公司內(nèi)部網(wǎng)絡(luò)汪疮，以及互聯(lián)網(wǎng)的時候需要強制執(zhí)行智嚷。當(dāng)今，當(dāng)我們將服務(wù)器開放給外部的時候猜嘱，它收到的第一個流量就是端口掃描，登錄頁面請求弦撩，以及登錄嘗試，甚至在第一個用戶知道該應(yīng)用之前感凤。
自定義錯誤頁面的使用有助于安全準(zhǔn)備陪竿，因為 Web 服務(wù)器和應(yīng)用中的默認(rèn)的錯誤信息展示太多的信息（從攻擊者角度），它們關(guān)于錯誤庸蔼、所使用的編程語言、椏萄危回溯、所使用的數(shù)據(jù)庫佳簸、操作系統(tǒng)以及其它听想。這些信息不應(yīng)該暴露汉买，因為它會幫助我們理解應(yīng)用如何構(gòu)建蛙粘，并且提供所使用軟件的版本和名稱出牧。攻擊者通過這些信息就可以搜索已知漏洞梢褐，并構(gòu)造更加有效的攻擊過程轰枝。
一旦我們的服務(wù)器上的部署應(yīng)用和所有服務(wù)都正確配置玷室，我們就可以制訂安全原則并且將其應(yīng)用于所有要配置的新服務(wù)器或者已更新的服務(wù)器，或者當(dāng)前帶有合理規(guī)劃的生產(chǎn)服務(wù)器江滨。
這個配置原則需要持續(xù)測試，以便改進它以及持續(xù)保護新發(fā)現(xiàn)的漏洞晶密。
A6 保護敏感數(shù)據(jù)
當(dāng)應(yīng)用儲存或使用敏感信息（信用卡號碼、社會安全號碼模她、健康記錄稻艰，以及其它）時，必須采取特殊的手段來保護它們侈净，因為它可能為負(fù)責(zé)保護它們的組織帶來嚴(yán)重的信用尊勿、經(jīng)濟或者法律損失，以及被攻破畜侦。
OWASP Top 10 的第六名是敏感數(shù)據(jù)泄露元扔，它發(fā)生在應(yīng)該保護的數(shù)據(jù)以純文本泄露夏伊，或者帶有弱安全措施的時候。
這個秘籍中垄懂，我們會涉及一些處理漫谷、傳遞和儲存這種數(shù)據(jù)類型的最佳實踐竖共。
操作步驟
如果你使用的敏感數(shù)據(jù)可以在使用之后刪除妓布，那么刪除它。最好每次使用信用卡的時候詢問用戶，避免被盜取告希。
在處理支付的時候指么，始終使用支付網(wǎng)關(guān)盗似，而不是在你的服務(wù)器中儲存數(shù)據(jù)号阿。查看：
http://ecommerce-platforms.com/ ecommerce-selling-advice/choose-payment-gateway-ecommerce-store。如果我們需要儲存敏感數(shù)據(jù)，我們要采取的第一個保護就是使用強密碼算法和相應(yīng)的強密鑰來加密据某。推薦 Twofish、AES、RSA 和三重 DES寡喝。
密碼儲存在數(shù)據(jù)庫的時候，應(yīng)該以單項哈希函數(shù)的哈希形式存儲，例如疮绷，bcypt、scrypt 或 SHA-2。
-
確保所有敏感文檔只能被授權(quán)用戶訪問奄薇。不要在 Web 服務(wù)器的文檔根目錄儲存它們，而是在外部目錄儲存涮因，并通過程序來訪問惩妇。如果出于某種原因必須在服務(wù)器的文檔根目錄儲存敏感文件身隐，使用
.htaccess文件來防止直接訪問：Order deny,allow Deny from all -
禁用包含敏感數(shù)據(jù)的頁面緩存琐驴。例如布近，在 Apache 中我們可以禁用 PDF 和 PNG 的緩存瞒御，通過
httpd.conf中的下列設(shè)置：<FilesMatch "\.(pdf|png)> FileETag None Header unset ETag Header set Cache-Control "max-age=0, no-cache, no-store, mustrevalidate" Header set Pragma "no-cache" Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT" </FilesMatch> 如果你允許文件上傳，始終使用安全的通信頻道來傳輸敏感數(shù)據(jù)烤惊，也就是帶有 TLS 的 HTTPS，或者 FTPS（SSH 上的 FTP）擂仍。
工作原理
對于保護敏感數(shù)據(jù)盲赊，我們需要最小化數(shù)據(jù)泄露或交易的風(fēng)險依疼。這就是正確加密儲存敏感數(shù)據(jù)律罢，以及保護加密密鑰是所做的第一件事情的原因膀值。如果可能不需要儲存這類數(shù)據(jù)，這只是個理想選擇误辑。
密碼應(yīng)該使用單向哈希算法沧踏，在將它們儲存到數(shù)據(jù)之前計算哈希。所以巾钉，即使它們被盜取翘狱，攻擊者也不能立即使用它們，并且如果密碼強度足夠砰苍，哈希也是足夠強的算法潦匈，它就不會在短時間內(nèi)被破解。
如果我們在 Apache 服務(wù)器的文檔根目錄（/var/ www/html/）儲存敏感文檔或數(shù)據(jù)师骗，我們就通過 URL 將這些信息暴露用于下載历等。所以，最好將它儲存到別的地方辟癌，并編寫特殊的服務(wù)端代碼來在必要時獲取它們寒屯，并帶有預(yù)先的授權(quán)檢查。
此外黍少，例如 Archive.org寡夹、WayBackMachine 或者 Google 緩存頁面，可能在緩存含有敏感信息的文件時厂置，以及我們沒能在應(yīng)用的上一個版本有效保護它們時產(chǎn)生安全問題菩掏。所以，不允許緩存此類文檔非常重要昵济。
A7 確保功能級別的訪問控制
功能級別的訪問控制是訪問控制的一種智绸，用于防止匿名者或未授權(quán)用戶的功能調(diào)用。根據(jù) OWASP访忿，缺乏這種控制是 Web 應(yīng)用中第七大嚴(yán)重的安全問題瞧栗。
這個秘籍中，我們會看到一些推薦來提升我們的應(yīng)用在功能級別上的訪問控制海铆。
操作步驟
確保每一步都正確檢查了工作流的權(quán)限迹恐。
禁止所有默認(rèn)訪問，之后在顯示的授權(quán)校驗之后允許訪問卧斟。
用戶殴边、角色和授權(quán)應(yīng)該在靈活的媒介中儲存憎茂，例如數(shù)據(jù)庫或者配置文件，不要硬編碼它們锤岸。
同樣竖幔，“隱藏式安全”不是很好的策略。
工作原理
開發(fā)者只在工作流的開始檢查授權(quán)能耻，并假設(shè)下面的步驟都已經(jīng)對用戶授權(quán)赏枚，這是常見的現(xiàn)象亡驰。攻擊者可能會嘗試調(diào)用某個功能晓猛，它是工作流的中間步驟，并由于控制缺失而能夠訪問它凡辱。
對于權(quán)限戒职，默認(rèn)禁止所有用戶是個最佳實踐。如果我們不知道一些用戶是否有權(quán)訪問一些功能透乾，那么它們就不應(yīng)該執(zhí)行洪燥。將你的權(quán)限表轉(zhuǎn)化為授權(quán)表。如果某些用戶在某些功能上沒有顯式的授權(quán)乳乌，則禁止它們的訪問捧韵。
在為你的應(yīng)用功能構(gòu)建或?qū)崿F(xiàn)訪問控制機制的時候，將所有授權(quán)儲存在數(shù)據(jù)庫中汉操，或者在配置文件中（數(shù)據(jù)庫是最好的選項）再来。如果用戶角色和權(quán)限被硬編碼，它們就會難以維護磷瘤、修改或更新芒篷。
A8 防止 CSRF
當(dāng) Web 應(yīng)用沒有使用會話層面或者操作層面的標(biāo)識，或者標(biāo)識沒有正確實現(xiàn)的時候采缚，它們就可能存在跨站請求偽造漏洞针炉，并且攻擊者可以強迫授權(quán)用戶執(zhí)行非預(yù)期的操作。
CSRF 是當(dāng)今 Web 應(yīng)用的第八大嚴(yán)重漏洞扳抽，根據(jù) OWASP篡帕， 并且我們在這個秘籍中會看到如何在應(yīng)用中防止它。
操作步驟
第一步也是最實際的 CSRF 解決方案就是實現(xiàn)唯一贸呢、操作層面的標(biāo)識镰烧。所以每次用戶嘗試執(zhí)行某個操作的時候，會生成新的標(biāo)識并在服務(wù)端校驗贮尉。
唯一標(biāo)識應(yīng)該不能被輕易由攻擊者猜測拌滋，所以它們不能將其包含在 CSRF 頁面中。隨機生成是個好的選擇猜谚。
在每個可能為 CSRF 目標(biāo)的表單中包含要發(fā)送的標(biāo)識败砂《脑“添加到購物車”請求、密碼修改表單昌犹、郵件坚芜、聯(lián)系方式或收貨信息管理，以及銀行的轉(zhuǎn)賬頁面都是很好的例子斜姥。
標(biāo)識應(yīng)該在每次請求中發(fā)送給服務(wù)器鸿竖。這可以在 URL 中實現(xiàn)，或者任何其它變量或者隱藏字段铸敏，都是推薦的缚忧。
驗證碼的使用也可以防止 CSRF。
同樣杈笔，在一些關(guān)鍵操作中詢問重新授權(quán)也是個最佳實踐闪水，例如，銀行應(yīng)用中的轉(zhuǎn)賬操作蒙具。
工作原理
防止 CSRF 完全是確保驗證過的用戶是請求操作的人球榆。由于瀏覽器和 Web 應(yīng)用的工作方式，最佳實踐是使用標(biāo)識來驗證操作禁筏，或者可能的情況下使用驗證碼來控制持钉。
由于攻擊者打算嘗試破解標(biāo)識的生成，或者驗證系統(tǒng)篱昔，以一種攻擊者不能猜測的方式每强，安全地生成它們非常重要。而且要使它們對每個用戶和每個操作都唯一旱爆，因為復(fù)用它們會偏離它們的目的舀射。
驗證碼控制和重新授權(quán)有時候會非常麻煩，使用戶反感怀伦。但是如果操作的重要性值得這么做脆烟，用戶可能愿意接受它們來換取額外的安全級別。
另見
有一些編程庫有助于實現(xiàn) CSRF 防護房待，節(jié)省開發(fā)者的大量工作邢羔。例子之一就是 OWASP 的 CSRF Guard：https://www.owasp.org/index.php/CSRFGuard。
A9 在哪里尋找三方組件的已知漏洞
現(xiàn)在的 Wbe 應(yīng)用不再是單個開發(fā)者桑孩，也不是單個開發(fā)團隊的作品拜鹤。開發(fā)功能性、用戶友好流椒、外觀吸引人的 Web 應(yīng)用涉及到三方組件的使用敏簿，例如編程庫，外部服務(wù)的 API（Fackbook、Google惯裕、Twitter）温数，開發(fā)框架，以及許多其它的組件蜻势，其中編程撑刺、測試和打補丁的工作量很少，甚至沒有握玛。
有時候這些三方組件被發(fā)現(xiàn)存在漏洞够傍，并且它們將這些漏洞轉(zhuǎn)移到了我們的應(yīng)用中。許多帶有漏洞組件的應(yīng)用很長時間都沒有打補丁挠铲，使整個組織的安全體系中出現(xiàn)缺陷冕屯。這就是 OWASP 將使用帶有已知漏洞的三方組件劃分為 Web 應(yīng)用安全的第九大威脅的原因。
這個秘籍中市殷，我們會了解愕撰，如果一些我們所使用的組件擁有已知漏洞，應(yīng)該到哪里尋找醋寝，以及我們會查看一些這種漏洞組件的例子。
操作步驟
第一個建議是带迟，優(yōu)先選擇受支持和廣泛使用的知名軟件音羞。
為你的應(yīng)用所使用的三方組件保持安全更新和補丁的更新。
用于搜索一些特定組件的漏洞的好地方就是廠商的網(wǎng)站：它們通常擁有“發(fā)布說明”部分仓犬，其中它們會公布它們糾正了哪個 bug 或漏洞嗅绰。這里我們可以寸照我們所使用的（或更新的）版本，并且插件是否有有已知的問題沒有打補丁搀继。
同樣窘面，廠商通常擁有安全建議站點，例如 Microsoft：
https://technet.microsoft.com/library/security/叽躯，Joomla：https:// developer.joomla.org/security-centre.html财边，和Oracle：http://www. oracle.com/technetwork/topics/security/alerts-086861.html。我們可以使用它們來保持我們用于應(yīng)用的軟件的更新点骑。也有一些廠商無關(guān)的站點酣难，它們致力于通知我們漏洞和安全問題。有個非常好的網(wǎng)站黑滴，集中了多個來源的信息憨募，是 CVE Details（
http://www.cvedetails.com/）。這里我們可以搜索多數(shù)廠商或產(chǎn)品袁辈，或者列出所有已知漏洞（至少是擁有 CVE 號碼的漏洞）菜谣，并且按照年份、版本和 CVSS 分?jǐn)?shù)排列。同時尾膊，黑客發(fā)布利用和發(fā)現(xiàn)的站點也是個獲得漏洞和我們所使用的軟件的信息的好地方甘磨。最流行的是 Exploit DB（
https://www.exploit-db.com/）。 Full disclosure 郵件列表（http://seclists.org/fulldisclosure/）眯停，以及 Packet Storm 的文件部分（https://packetstormsecurity.com/files/）济舆。一旦我們發(fā)現(xiàn)了我們軟件組件中的漏洞，我們必須評估它是否對我們的應(yīng)用必要莺债，或者需要移除滋觉。如果不能這樣，我們需要盡快打補丁齐邦。如果沒有可用的補丁或變通方案椎侠，并且漏洞是高危的，我們必須開始尋找組件的替代措拇。
工作原理
考慮在我們的應(yīng)用中使用三方軟件組件之前我纪，我們需要查看它的安全信息，并了解丐吓，我們所使用的組件是否有更穩(wěn)定更安全的版本或替代浅悉。
一旦我們選擇了某個，并且將其包含到我們的應(yīng)用中券犁，我們需要使其保持更新术健。有時它可能涉及到版本改動以及沒有后向兼容，但是這是我們想要維持安全的代價粘衬。如果我們不能更新或為高危漏洞打補丁荞估，我們還可以使用 WAF（Web 應(yīng)用防火墻）和IPS（入侵檢測系統(tǒng)）來防止攻擊。
除了在執(zhí)行滲透測試的時候比較實用稚新，下載和漏洞發(fā)布站點可以被系統(tǒng)管理員利用勘伺，用于了解可能出現(xiàn)什么攻擊，它們的原理褂删，以及如何保護應(yīng)用避免它們飞醉。
A10 重定向驗證
根據(jù) OWASP，未驗證的重定向和轉(zhuǎn)發(fā)是 Web 應(yīng)用的第十大嚴(yán)重安全問題笤妙。它發(fā)生在應(yīng)用接受 URL 或內(nèi)部頁面作為參數(shù)來執(zhí)行重定向或轉(zhuǎn)發(fā)操作的時候冒掌。如果參數(shù)沒有正確驗證，攻擊者就能夠濫用它來使其重定向到惡意網(wǎng)站蹲盘。
這個秘籍中股毫，我們會了解如何驗證我們接受的用于重定向或轉(zhuǎn)發(fā)的參數(shù)，我們需要在開發(fā)應(yīng)用的時候?qū)崿F(xiàn)它召衔。
操作步驟
不希望存在漏洞嗎铃诬？那就不要使用它。無論怎樣，都不要使用重定向和轉(zhuǎn)發(fā)趣席。
如果需要使用重定向兵志，嘗試不要使用用戶提供的參數(shù)（請求變量）來計算出目標(biāo)。
如果需要使用參數(shù)宣肚，實現(xiàn)一個表想罕，將其作為重定向的目錄，使用 ID 代替 URL 作為用戶應(yīng)該提供的參數(shù)霉涨。
始終驗證重定向和轉(zhuǎn)發(fā)操作涉及到的輸入按价。使用正則表達式或者白名單來檢查提供的值是否有效。
工作原理
重定向和轉(zhuǎn)發(fā)是釣魚者和其它社會工程師最喜歡用的工具笙瑟，并且有時候我們對目標(biāo)沒有任何安全控制楼镐。所以，即使它不是我們的應(yīng)用往枷，它的安全問題也會影響我們的信譽框产。這就是最好不要使用它們的原因。
如果這種重定向的目標(biāo)是已知站點错洁，例如 Fackbook 或 Google秉宿，我們就可以在配置文件或數(shù)據(jù)表中建立目標(biāo)目錄，并且不需要使用客戶端提供的參數(shù)來實現(xiàn)墓臭。
如果我們構(gòu)建包含所有允許的重定向和轉(zhuǎn)發(fā) URL 的數(shù)據(jù)表蘸鲸，每個都帶有 ID，我們可以將 ID 用于參數(shù)窿锉，而不是目標(biāo)本身。這是一種白名單的形式膝舅，可以防止無效目標(biāo)的插入嗡载。
最后同樣是校驗。我們始終要校驗每個來自客戶端的輸入仍稀，這非常重要洼滚，因為我們不知道用戶要輸入什么。如果我們校驗了重定向目標(biāo)的正確性技潘，除了惡意轉(zhuǎn)發(fā)或重定向之外遥巴，我們還可以防止可能的 SQL 注入、XSS或者目錄遍歷享幽。所以铲掐，它們都是相關(guān)的。
