Web應用程序開發是一個很寬泛的話題。本文僅討論Web應用開發者應當避免的安全錯誤。這些錯誤涉及到任何開發者都不應當忽視的基本安全原則。
開發者應當注意哪些基本的安全原則?應當避免哪些安全錯誤?為回答這些問題，下面的建議可以回答上述問題。
自以為是：開發自己的安全方法
有些開發者錯誤地認為自己的算法或認證方法更安全：畢竟黑客從未見識過這種方法，所以他們在破解時會更困難。果真如此嗎?
答案是否定的。開發者自己開發認證或登錄方法是一個錯誤，因為他會犯一個或一些黑客能夠發現的錯誤。開發者應當依靠現有的經過完全測試的安全方法，原因在于它們已經被安全社團反復測試過了。因此，這些方法不太可能包含被開發者忽視的重大安全漏洞。有安全專家指出，任何人都可以發明一種他們自己無法破解的加密算法，但要開發一種別人無法破解的方法就困難多了。所以，開發者還是老老實實地用經認證或安全測試的方法吧。
粗心大意：直接使用用戶提供的信息訪問數據庫
在開發應用程序特別是在開發Web應用程序時，許多開發者沒有充分地驗證從用戶那兒接收到的輸入數據。這種做法存在安全問題，因為它允許非法的數據進入客戶的數據庫，并且還有更大的安全隱患。不能對用戶的輸入進行驗證(無論是來自Web還是來自API)會導致SQL注入、跨站腳本攻擊、命令劫持、緩沖區溢出，以及被攻擊者利用的其它Web應用程序漏洞。
這種錯誤在Web應用程序的開發中是最常見的。如果沒有保護這些程序，用戶就有可能利用輸入字段將惡意腳本注入到應用程序或者訪問數據庫的私密數據。當然，多數用戶不會有什么惡意企圖，但開發者必須用防御的心態和方法來處理用戶輸入。
開發者不應當輕易相信用戶輸入，而要在客戶端和服務器端進行雙重驗證。否則，就有可能產生嚴重的漏洞，如：跨站腳本攻擊和SQL注入等。
忽視全局：關注組件而非整個系統
大型的開發項目往往是由多個開發者開發應用程序的不同部分，因而開發人員就容易關注個別組件。當然，如此開發的應用程序，其每個小部分可能很安全，但開發者是否考慮過整體的安全性?
許多安全問題并非產生于組件自身，而是在數據和過程從業務進程的一部分流動到另一部分時才會出問題。開發者一般都承擔著一項業務進程的一部分，并且一般不理解業務過程的其它部分。這種認知缺乏會導致不安全的數據傳遞，從而將數據暴露給各種攻擊和威脅，如中間人攻擊、數據完整性問題、信息泄露等。
開發者對企業的業務服務有一個系統的觀點是至關重要的，只有這樣才能理解所有的組件如何協作，以及如何保證合并后的應用程序的安全。
后期修補：在開發后期增加安全功能
有的網站或Web應用在構建時并沒有內建安全性。記住：安全并不是以后增加的東西，它應當是整個應用架構的整體功能的一部分。架構是應用開發的最重要的方面，因為它會影響應用程序的所有其它方面，其中就包括安全性。
這種錯誤的表現(如漏洞和錯誤配置)可以追溯到開發階段：開發者最后將安全作為一種額外增加的特性或功能。如有的開發團隊有這樣的認識：不錯，所有的功能都正常運行，現在開始解決安全性問題吧。這種思想會帶來應用程序架構上的安全漏洞從而增加風險。在應用程序完全部署后，任何人都很難去解決跨站請求偽造(CSRF)及大量的SQL注入漏洞了。所以，開發者應當在開發和構建Web應用程序的整個生命周期中構建安全性。
放任用戶：允許用戶生成弱口令
每當有攻擊者破解網站或Web應用并暴露用戶口令時，一個明確的事實都會隨之浮出水面：用戶們的安全習慣太差。例如，用戶們的最常用的口令是“abcde”或“12345678”之類。Web應用的開發者不應當允許用戶創建弱口令。開發者應當要求用戶的口令達到足夠的長度，確保其易于記憶但又難以猜測(例如，強口令至少應當包含字母、數字及特殊字符，長度達10個字符以上)。最好的口令未必是最復雜的。強迫用戶使用過度復雜的口令往往導致用戶一些不安全的做法，例如把口令寫下來然后再貼到電腦的一個地方。
忽視加密：以純文本存儲用戶口令和數據
Web應用開發者最常犯的錯誤是沒有保證用戶認證憑據的安全。用戶們想當然地認為網站或Web應用會做得很安全，但不幸的是，太多的網站或Web應用沒有做好。從總體上說， Web應用或網站在處理和保存口令方式上往往存在漏洞。
問題是：怎樣才能正確地保存口令?這里重點談一個最常見卻很不安全的做法：以明文保存口令。許多大公司也有可能犯這樣的錯誤。對企業數據庫的任何損害都不應當使用戶數據遭受風險，尤其是用戶們使用的口令。因而，企業的應用程序應當對用戶的口令和其它細節進行加密，然后才將其保存在一個數據庫中。
企業應用的開發者必須思考，在黑客取得企業數據庫的訪問權時，他們能怎樣輕易地竊取數據?如果開發者加密數據，就會導致個人和企業信息的大量泄露。
僅僅因為數據庫引擎要求用戶名和口令并不意味著黑客無法竊取數據文件和獲取其中的信息。數據的安全性依賴于數據庫引擎的安全性，如果黑客利用了數據庫引擎的漏洞，就可以輕松地訪問數據庫。這正是許多大型游戲和電子商務網站遭受破解的原因，也是包含信用卡數據在內的所有個人信息失竊的原因。
“明修棧道”：通過URL路徑名傳遞變量
還有一種危險但常見的做法：許多開發者把變量放在URL中，這會為黑客打開利用其它應用或數據的大門。這種錯誤的風險非常巨大。
開發者絕對不能允許用戶與之交互的變量成為文件路徑的一部分。如果URL中包含下載文件的路徑，攻擊者就可以修改URL，使其引用另一個文件，從而可能下載包含用戶口令的文件。由此，攻擊者用一個鏈接(例如，該鏈接允許用戶下載應用程序的免費版)就達到了利用漏洞的目的。
正所謂開發者“明修”了“棧道”，卻被攻擊者“暗渡”了“陳倉”。
顧此失彼：僅在客戶端執行授權
如今，越來越多的開發者日漸重視客戶端。這種趨勢會使應用程序更快更強大，但如果開發者不能正確地解決程序的授權問題，就會帶來安全隱患。
很多Web應用的開發者依賴客戶端的瀏覽器去完成以前在服務器完成的任務。從安全的觀點看，這種做法缺少了許多控制，因為開發者并不了解客戶端的種類。客戶端甚至有可能并非瀏覽器。開發者不應當輕易地相信發生在客戶端的操作，不應當僅依賴JavaScript或客戶端代碼來實現關鍵功能，對于涉及到付款信息和其它敏感信息的功能，尤其要注意。
盲目樂觀：認為自己不可能出問題
在開發Web應用程序時，開發人員容易犯的錯誤是：想當然地認為自己的應用程序不會遭到攻擊，或者認為自己不會犯錯誤。這些想法都會導致安全問題。開發者應當總是設想自己的程序會遭受攻擊，而且自己也會犯安全方面的錯誤。這種思想有助于開發者避免或減少安全風險，從而避免公司遭受損失。
誰都會犯錯。如果開發者在黑客找到漏洞之前自己先找到了問題，問題還不算大。在開發者和軟件測試者測試和審計Web應用程序時，或在企業投入使用程序之前，開發者或測試者不妨使用著名的開源工具OWASP ZAP來掃描企業的應用程序，查找一些常見的漏洞和錯誤。
結束語
此文談到了一些最基本的卻是很重要的一些安全錯誤。希望開發者在此基礎上能夠進一步發現和總結在Web應用開發過程中的其它問題，構建更堅實的安全保障。
京公網安備 11010502049343號