開發人員可以運用諸多基本原則來增強Web應用程序的安全性。主要有以下三條原則:
盡量減小權限
對訪問資源的賬戶進行配置時,始終要把這些賬戶的權限限制在需要的最小權限。
千萬不要相信用戶的輸入,驗證任何輸入的內容
這對Web應用程序來說尤為重要。確保應用程序並不依賴客戶端的驗證。在服務器上應當重復所有的檢查工作,因為要是沒有約束條件,比較容易構建網頁副本,有可能導致破壞性代碼在運行,,或者導致引起系統崩潰的拒絕服務(DoS)攻擊。
有節制地使用錯誤消息
雖然在開發程序時,詳細的錯誤消息很有幫助,但它們對惡意用戶來說同樣是寶貴的信息來源。所以指定函數名這類細節沒有太大的意義。這樣的細節記錄在另一個日志中比較好。
下面幾個示例介紹了沒有經過驗證的用戶輸入如何被壞人利用的具體情況,並且介紹了避免這些問題的建議。
SQL注入
如果允許任意的SQL命令執行,就會出現SQL注入(SQL injection)。當SQL語句在代碼裡面動態構建時,通常會出現這種情況。
以下面用C#編寫的代碼為例,該代碼試圖檢查用戶名/密碼組合是否正確:
string username = txtUsername.Text; string password = txtPassword.Text; string SQL = "SELECT * FROM tblUsers WHERE username = '" username "' AND password = '" password "';"; //執行SQL
用戶名和密碼從服務器端的兩個文本框獲取,並且SQL語句被創建,然後該語句執行。如果沒有記錄返回,那麼表明用戶輸入的詳細資料不正確,或者沒有經過注冊; 否則用戶可以進入到下一個階段。
如果用戶在兩個文本框裡面輸入了Joe和mypassword,那麼SQL語句會是:
SELECT * FROM tblUsers WHERE username = 'Joe' AND password = 'mypassword';
這正是開發人員的意圖。不過要是用戶往密碼文本框裡面輸入: ' OR 'a' = 'a,SQL就會是:
SELECT * FROM tblUsers WHERE username = 'Joe' AND password = '' OR 'a' = 'a';
現在,密碼不重要了,因為'a'='a'總是正確的。如果用來連接到數據庫的賬戶有權刪除數據而不是僅僅有權讀取數據,就會出現更糟糕的情形。假設用戶往密碼文本框裡面輸入: '; DELETE FROM tblUsers WHERE 'a' = 'a'。這會得出以下的語句:
SELECT * FROM tblUsers WHERE username = 'Joe' AND password = '';
DELETE FROM tblUsers WHERE 'a' = 'a';
現在,整個用戶表就會被清空。
防止這類問題主要有兩種辦法。一是,可以使用存儲過程(stored procedure)來執行用戶驗證步驟。設置參數值時,避免使用單引號等特殊符號,因而不可能為WHERE語句添加額外的斷言(predicate),也不會運行多個SQL語句。譬如說,可以構建像下面這樣的存儲過程,接受兩個輸入參數後,返回表明用戶是不是合法用戶的第三個參數:
CREATE PROCEDURE spCheckUser
(
@Username VARCHAR(20),
@Password VARCHAR(20),
@IsValid BIT OUTPUT
)
AS
DECLARE @UserCount INT
SELECT @UserCount = COUNT(*)
FROM tblUsers
WHERE Username = @Username
AND Password = @Password
IF @UserCount = 1
SET @IsValid = 1
ELSE
SET @IsValid = 0
現在,初始代碼經改動後可以使用存儲過程:
SqlCommand sqlCommand = new SqlCommand("spCheckUser");
SqlParameter sqlParam = new SqlParameter("@Username", SqlDbType.VarChar, 20)
sqlParam.Value = txtUsername.Text;
sqlParam.Direction = ParameterDirection.Input;
sqlCommand.Parameters.Add(sqlParam);
sqlParam = new SqlParameter("@Password", SqlDbType.VarChar, 20)
sqlParam.Value = txtPassword.Text;
sqlParam.Direction = ParameterDirection.Input;
sqlCommand.Parameters.Add(sqlParam);
sqlParam = new SqlParameter("@IsValid", SqlDbType.Bit, 1)
sqlParam.Direction = ParameterDirection.Output;
sqlCommand.Parameters.Add(sqlParam); //執行命令,並檢索輸出參數值
輸入和輸出參數使用相關類型來說明。如今區別在於,基本的ADO.NET類會把字符串' OR 'a' = 'a當成實際用戶的密碼來處理,而不是當成可執行SQL來處理。
避免這種安全漏洞的第二種辦法(也適用於所有的用戶輸入)就是,確保特殊字符或者字符串被禁用。對SQL而言,導致問題的那個字符就是單引號,所以如果沒法使用存儲過程,那麼就把所有單引號變成雙引號,這可以防止有人構建額外的SQL:
string username = txtUsername.Text;
string password = txtPassword.Text;
username = username.Replace("'","''");
password = password.Replace("'","''");
string SQL = "SELECT *
FROM tblUsers
WHERE username = '" username "'
AND password = '" password "';";
//執行SQL
現在,構建的SQL成為:
SELECT *
FROM tblUsers
WHERE username = 'Joe'
AND password = '''
OR ''a'' = ''a';
這意味著該用戶沒有被識別。
跨站腳本
跨站腳本(有時縮寫成XSS)允許來自一個地方的代碼在另一個網站裡面運行。正如在大多數情況下一樣,只要驗證用戶輸入的內容就可以避免這問題。以接受HTML格式的帖子的公告牌為例。假定用戶在發布消息中加入了以下內容:
Hello everyone
要是不對腳本塊進行任何驗證及刪除,這條消息就會出現,標准的警告信息也會顯示。假定這個示例沒有惡意,再考慮下一個示例:
var I = new Image();
i.src = escape(document.cookie);
現在,該用戶的cookie會被傳送到惡意網站,然後記錄在網絡日志裡面。這不是原先需要的操作,可能會洩露私人信息,或者讓不懷好意的人以合法用戶的身份登錄到公告牌。可以通過采用正則表達式來搜索及清除像< script>及其內容這些元素的辦法來防止這個問題。
數據溢出
數據過多可能會帶來問題,這有兩個原因。一是,因為應用程序往往會崩潰,譬如說,如果程序試圖把50個字符寫入到列大小只有40個字符的數據庫表,就會引起程序崩潰。顯然,良好的錯誤捕獲方法應當可以防止這一問題,但如果用戶輸入的是有效內容,而且來自可信用戶,那麼這個問題往往不會發生。數據過多輕則帶來差勁的用戶體驗,重則導致嚴重消耗服務器資源,要是問題頻頻發生,還會導致整個服務無法使用。如果輸入內容專門旨在導致錯誤、機器過載,這就叫拒絕服務(DoS)攻擊。
第二個問題是緩沖器溢出。有時候,輸入的數據會溢出旨在存放它的內存區,而成為可執行代碼的一部分。只要對輸入到輸入框中的數據進行精心設計,攻擊者就可以在服務器上執行任意代碼。
為了避免該問題,不要依靠客戶端技術,譬如設置文本框的最大長度屬性。這很容易被跳過。有些浏覽器(包括IE在內)允許javascript URL。如果網頁的文本框有一個標為txtSurname的id,那麼下列代碼拷貝到浏覽器的地址欄上後,就會改變最大長度屬性:
javascript:document.getElementById
("txtSurname").maxLength = 1000
防止這個問題的方法仍然是在服務器上進行檢查,看看輸入內容是否超過所需長度; 必要的話縮減輸入內容。(作者單位系河南省鎮平縣教師進修學校)