閱讀439 返回首頁    go 阿裏雲 go 技術社區[雲棲]


談談關於PHP的代碼安全相關的一些致命知識

目標

本教程講解如何防禦最常見的安全威脅:SQL 注入、操縱 GET 和 POST 變量、緩衝區溢出攻擊、跨站點腳本攻擊、瀏覽器內的數據操縱和遠程表單提交。

前提條件

本教程是為至少有一年編程經驗的 PHP 開發人員編寫的。您應該了解 PHP 的語法和約定;這裏不解釋這些內容。有使用其他語言(比如 Ruby、Python 和 Perl)的經驗的開發人員也能夠從本教程中受益,因為這裏討論的許多規則也適用於其他語言和環境。

安全性快速簡介

Web 應用程序最重要的部分是什麼?根據回答問題的人不同,對這個問題的答案可能是五花八門。業務人員需要可靠性和可伸縮性。IT 支持團隊需要健壯的可維護的代碼。最終用戶需要漂亮的用戶界麵和執行任務時的高性能。但是,如果回答 “安全性”,那麼每個人都會同意這對 Web 應用程序很重要。

但是,大多數討論到此就打住了。盡管安全性在項目的檢查表中,但是往往到了項目交付之前才開始考慮解決安全性問題。采用這種方式的 Web 應用程序項目的數量多得驚人。開發人員工作幾個月,隻在最後才添加安全特性,從而讓 Web 應用程序能夠向公眾開放。

結果往往是一片混亂,甚至需要返工,因為代碼已經經過檢驗、單元測試並集成為更大的框架,之後才在其中添加安全特性。添加安全性之後,主要組件可能會停止工作。安全性的集成使得原本順暢(但不安全)的過程增加額外負擔或步驟。

本教程提供一種將安全性集成到 PHP Web 應用程序中的好方法。它討論幾個一般性安全主題,然後深入討論主要的安全漏洞以及如何堵住它們。在學完本教程之後,您會對安全性有更好的理解。

主題包括:

SQL 注入攻擊
操縱 GET 字符串
緩衝區溢出攻擊
跨站點腳本攻擊(XSS)
瀏覽器內的數據操縱
遠程表單提交

Web 安全性 101

在討論實現安全性的細節之前,最好從比較高的角度討論 Web 應用程序安全性。本節介紹安全哲學的一些基本信條,無論正在創建何種 Web 應用程序,都應該牢記這些信條。這些思想的一部分來自 Chris Shiflett(他關於 PHP 安全性的書是無價的寶庫),一些來自 Simson Garfinkel(參見 參考資料),還有一些來自多年積累的知識。

規則 1:絕不要信任外部數據或輸入

關於 Web 應用程序安全性,必須認識到的第一件事是不應該信任外部數據。外部數據(outside data) 包括不是由程序員在 PHP 代碼中直接輸入的任何數據。在采取措施確保安全之前,來自任何其他來源(比如 GET 變量、表單 POST、數據庫、配置文件、會話變量或 cookie)的任何數據都是不可信任的。
例如,下麵的數據元素可以被認為是安全的,因為它們是在 PHP 中設置的。

清單 1. 安全無暇的代碼

$myUsername = ‘tmyer’;
$arrayUsers = array(’tmyer’, ‘tom’, ‘tommy’);
define(”GREETING”, ‘hello there’ . $myUsername);

但是,下麵的數據元素都是有瑕疵的。

清單 2. 不安全、有瑕疵的代碼

$myUsername = $_POST['username']; //tainted!
$arrayUsers = array($myUsername, ‘tom’, ‘tommy’); //tainted!
define(”GREETING”, ‘hello there’ . $myUsername); //tainted!

為什麼第一個變量 $myUsername 是有瑕疵的?因為它直接來自表單 POST。用戶可以在這個輸入域中輸入任何字符串,包括用來清除文件或運行以前上傳的文件的惡意命令。您可能會問,“難道不能使用隻接受字母 A-Z 的客戶端(JavaScript)表單檢驗腳本來避免這種危險嗎?”是的,這總是一個有好處的步驟,但是正如在後麵會看到的,任何人都可以將任何表單下載到自己的機器上,修改它,然後重新提交他們需要的任何內容。

解決方案很簡單:必須對 $_POST['username'] 運行清理代碼。如果不這麼做,那麼在使用 $myUsername 的任何其他時候(比如在數組或常量中),就可能汙染這些對象。

對用戶輸入進行清理的一個簡單方法是,使用正則表達式來處理它。在這個示例中,隻希望接受字母。將字符串限製為特定數量的字符,或者要求所有字母都是小寫的,這可能也是個好主意。

清單 3. 使用戶輸入變得安全

$myUsername = cleanInput($_POST['username']); //clean!
$arrayUsers = array($myUsername, ‘tom’, ‘tommy’); //clean!
define(”GREETING”, ‘hello there’ . $myUsername); //clean!
function cleanInput($input){
$clean = strtolower($input);
$clean = preg_replace(”/[^a-z]/”, “”, $clean);
$clean = substr($clean,0,12);
return $clean;
}

規則 2:禁用那些使安全性難以實施的 PHP 設置

已經知道了不能信任用戶輸入,還應該知道不應該信任機器上配置 PHP 的方式。例如,要確保禁用 register_globals。如果啟用了 register_globals,就可能做一些粗心的事情,比如使用 $variable 替換同名的 GET 或 POST 字符串。通過禁用這個設置,PHP 強迫您在正確的名稱空間中引用正確的變量。要使用來自表單 POST 的變量,應該引用 $_POST['variable']。這樣就不會將這個特定變量誤會成 cookie、會話或 GET 變量。

要檢查的第二個設置是錯誤報告級別。在開發期間,希望獲得盡可能多的錯誤報告,但是在交付項目時,希望將錯誤記錄到日誌文件中,而不是顯示在屏幕上。為什麼呢?因為惡意的黑客會使用錯誤報告信息(比如 SQL 錯誤)來猜測應用程序正在做什麼。這種偵察可以幫助黑客突破應用程序。為了堵住這個漏洞,需要編輯 php.ini 文件,為 error_log 條目提供合適的目的地,並將 display_errors 設置為 Off。

規則 3:如果不能理解它,就不能保護它

一些開發人員使用奇怪的語法,或者將語句組織得很緊湊,形成簡短但是含義模煳的代碼。這種方式可能效率高,但是如果您不理解代碼正在做什麼,那麼就無法決定如何保護它。

例如,您喜歡下麵兩段代碼中的哪一段?

清單 4. 使代碼容易得到保護

//obfuscated code
$input = (isset($_POST['username']) ? $_POST['username']:”);
//unobfuscated code
$input = ”;
if (isset($_POST['username'])){
$input = $_POST['username'];
}else{
$input = ”;
}

在第二個比較清晰的代碼段中,很容易看出 $input 是有瑕疵的,需要進行清理,然後才能安全地處理。

規則 4:“縱深防禦” 是新的法寶

本教程將用示例來說明如何保護在線表單,同時在處理表單的 PHP 代碼中采用必要的措施。同樣,即使使用 PHP regex 來確保 GET 變量完全是數字的,仍然可以采取措施確保 SQL 查詢使用轉義的用戶輸入。
縱深防禦不隻是一種好思想,它可以確保您不會陷入嚴重的麻煩。

既然已經討論了基本規則,現在就來研究第一種威脅:SQL 注入攻擊。

防止 SQL 注入攻擊

在 SQL 注入攻擊 中,用戶通過操縱表單或 GET 查詢字符串,將信息添加到數99一係列操作有點兒太嚴格了。畢竟,十六進製串有合法的用途,比如輸出外語中的字符。如何部署十六進製 regex 由您自己決定。比較好的策略是,隻有在一行中包含過多十六進製串時,或者字符串的字符超過特定數量(比如 128 或 255)時,才刪除十六進製串。

跨站點腳本攻擊

在跨站點腳本(XSS)攻擊中,往往有一個惡意用戶在表單中(或通過其他用戶輸入方式)輸入信息,這些輸入將惡意的客戶端標記插入過程或數據庫中。例如,假設站點上有一個簡單的來客登記簿程序,讓訪問者能夠留下姓名、電子郵件地址和簡短的消息。惡意用戶可以利用這個機會插入簡短消息之外的東西,比如對於其他用戶不合適的圖片或將用戶重定向到另一個站點的 JavaScript,或者竊取 cookie 信息。

幸運的是,PHP 提供了 strip_tags() 函數,這個函數可以清除任何包圍在 HTML 標記中的內容。strip_tags() 函數還允許提供允許標記的列表,比如 或 。

清單 16 給出一個示例,這個示例是在前一個示例的基礎上構建的。

清單 16. 從用戶輸入中清除 HTML 標記

if ($_POST['submit'] == “go”){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing….
}
function cleanHex($input){
$clean = preg_replace\
(”![\][xX]([A-Fa-f0-9]{1,3})!”, “”,$input);
return $clean;
}
“” method=”post”
Name
“text” name=”name” id=”name” size=”20″ maxlength=”40″/>

從安全的角度來看,對公共用戶輸入使用 strip_tags() 是必要的。如果表單在受保護區域(比如內容管理係統)中,而且您相信用戶會正確地執行他們的任務(比如為 Web 站點創建 HTML 內容),那麼使用 strip_tags() 可能是不必要的,會影響工作效率。

還有一個問題:如果要接受用戶輸入,比如對貼子的評論或來客登記項,並需要將這個輸入向其他用戶顯示,那麼一定要將響應放在 PHP 的 htmlspecialchars() 函數中。這個函數將與符號、< 和 > 符號轉換為 HTML 實體。例如,與符號(&)變成 &。這樣的話,即使惡意內容躲開了前端 strip_tags() 的處理,也會在後端被 htmlspecialchars() 處理掉。

瀏覽器內的數據操縱

有一類瀏覽器插件允許用戶篡改頁麵上的頭部元素和表單元素。使用 Tamper Data(一個 Mozilla 插件),可以很容易地操縱包含許多隱藏文本字段的簡單表單,從而向 PHP 和 MySQL 發送指令。

用戶在點擊表單上的 Submit 之前,他可以啟動 Tamper Data。在提交表單時,他會看到表單數據字段的列表。Tamper Data 允許用戶篡改這些數據,然後瀏覽器完成表單提交。

讓我們回到前麵建立的示例。已經檢查了字符串長度、清除了 HTML 標記並刪除了十六進製字符。但是,添加了一些隱藏的文本字段,如下所示:

清單 17. 隱藏變量

if ($_POST['submit'] == “go”){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing….
}
function cleanHex($input){
$clean = \
preg_replace(”![\][xX]([A-Fa-f0-9]{1,3})!”, “”,$input);
return $clean;
}
”” method=”post”
Name
“text” name=”name” id=”name” size=”20″ maxlength=”40″/>

注意,隱藏變量之一暴露了表名:users。還會看到一個值為 create 的 action 字段。隻要有基本的 SQL 經驗,就能夠看出這些命令可能控製著中間件中的一個 SQL 引擎。想搞大破壞的人隻需改變表名或提供另一個選項,比如 delete。

圖 1 說明了 Tamper Data 能夠提供的破壞範圍。注意,Tamper Data 不但允許用戶訪問表單數據元素,還允許訪問 HTTP 頭和 cookie。

要防禦這種工具,最簡單的方法是假設任何用戶都可能使用 Tamper Data(或類似的工具)。隻提供係統處理表單所需的最少量的信息,並把表單提交給一些專用的邏輯。例如,注冊表單應該隻提交給注冊邏輯。

如果已經建立了一個通用表單處理函數,有許多頁麵都使用這個通用邏輯,那該怎麼辦?如果使用隱藏變量來控製流向,那該怎麼辦?例如,可能在隱藏表單變量中指定寫哪個數據庫表或使用哪個文件存儲庫。有 4 種選擇:
不改變任何東西,暗自祈禱係統上沒有任何惡意用戶。

重寫功能,使用更安全的專用表單處理函數,避免使用隱藏表單變量。

使用 md5() 或其他加密機製對隱藏表單變量中的表名或其他敏感信息進行加密。在 PHP 端不要忘記對它們進行解密。

通過使用縮寫或昵稱讓值的含義模煳,在 PHP 表單處理函數中再對這些值進行轉換。例如,如果要引用 users 表,可以用 u 或任意字符串(比如 u8y90×0jkL)來引用它。

後兩個選項並不完美,但是與讓用戶輕鬆地猜出中間件邏輯或數據模型相比,它們要好得多了。

現在還剩下什麼問題呢?遠程表單提交。

遠程表單提交

Web 的好處是可以分享信息和服務。壞處也是可以分享信息和服務,因為有些人做事毫無顧忌。
以表單為例。任何人都能夠訪問一個 Web 站點,並使用瀏覽器上的 File > Save As 建立表單的本地副本。然後,他可以修改 action 參數來指向一個完全限定的 URL(不指向 formHandler.php,而是指向https://www.yoursite.com/formHandler.php,因為表單在這個站點上),做他希望的任何修改,點擊 Submit,服務器會把這個表單數據作為合法通信流接收。

首先可能考慮檢查 $_SERVER['HTTP_REFERER'],從而判斷請求是否來自自己的服務器,這種方法可以擋住大多數惡意用戶,但是擋不住最高明的黑客。這些人足夠聰明,能夠篡改頭部中的引用者信息,使表單的遠程副本看起來像是從您的服務器提交的。

處理遠程表單提交更好的方式是,根據一個惟一的字符串或時間戳生成一個令牌,並將這個令牌放在會話變量和表單中。提交表單之後,檢查兩個令牌是否匹配。如果不匹配,就知道有人試圖從表單的遠程副本發送數據。
要創建隨機的令牌,可以使用 PHP 內置的 md5()、uniqid() 和 rand() 函數,如下所示:

清單 18. 防禦遠程表單提交

session_start();
if ($_POST['submit'] == “go”){
//check token
if ($_POST['token'] == $_SESSION['token']){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing….
}else{
//stop all processing! remote form posting attempt!
}
}
$token = md5(uniqid(rand(), true));
$_SESSION['token']= $token;
function cleanHex($input){
$clean = preg_replace(”![\][xX]([A-Fa-f0-9]{1,3})!”, “”,$input);
return $clean;
}
” method=”post”
Name

這種技術是有效的,這是因為在 PHP 中會話數據無法在服務器之間遷移。即使有人獲得了您的 PHP 源代碼,將它轉移到自己的服務器上,並向您的服務器提交信息,您的服務器接收的也隻是空的或畸形的會話令牌和原來提供的表單令牌。它們不匹配,遠程表單提交就失敗了。

結束語

本教程討論了許多問題:

使用 mysql_real_escape_string() 防止 SQL 注入問題。

使用正則表達式和 strlen() 來確保 GET 數據未被篡改。

使用正則表達式和 strlen() 來確保用戶提交的數據不會使內存緩衝區溢出。

使用 strip_tags() 和 htmlspecialchars() 防止用戶提交可能有害的 HTML 標記。

避免係統被 Tamper Data 這樣的工具突破。

使用惟一的令牌防止用戶向服務器遠程提交表單。

本教程沒有涉及更高級的主題,比如文件注入、HTTP 頭欺騙和其他漏洞。但是,您學到的知識可以幫助您馬上增加足夠的安全性,使當前項目更安全。

最後更新:2017-07-12 11:02:21

  上一篇:go  OssImport係列之三——分布式部署
  下一篇:go  OssImport係列之二——單機部署