在典型的PHP應用開發中，大多數的邏輯涉及數據處理任務，例如確認用戶是否成功登錄，在購物車中加入商品及處理信用卡交易。

數據可能有無數的來源，做為一個有安全意識的開發者，你需要簡單可靠地區分兩類數據：

l已過濾數據

l被污染數據

所有你自己設定的數據可信數據，可以認為是已過濾數據。一個你自己設定的數據是任何的硬編碼數據，例如下面的email地址數據：

$email = ’[email protected]’;

上面的Email地址[email protected]并不來自任何遠程數據源。顯而易見它是可信的。任何來自遠程數據源的數據都是輸入，而所有的輸入數據都是被污染的，必須在要在使用前對其進行過濾。

被污染數據是指所有不能保證合法的數據，例如用戶提交的表單，從郵件服務器接收的郵件，及其它web應用中發送過來的xml文檔。在前一個例子中，$email是一個包含有已過濾數據的變量。數據是關鍵，而不是變量。變量只是數據的容器，它往往隨著程序的執行而為被污染數據所覆蓋：

$email = $_POST[’email’];

當然，這就是$email叫做變量的原因，如果你不希望數據進行變化，可以使用常量來代替：

CODE:

define(’EMAIL’, ’[email protected]’);

如果用上面的語句進行定義，EMAIL在整個腳本運行中是一個值為[email protected]的不變的常量，甚至在你把試圖把它重新賦值時也不會改變（通常是不小心）。例如，下面的代碼輸出為[email protected] (試圖重定義一個常量會引起一個級別為Notice的報錯信息)。

CODE:

<?php

define(’EMAIL’, ’[email protected]’);

define(’EMAIL’, ’[email protected]’);

echo EMAIL;

?>

小提示

欲更多了解常量, 請訪問 http://php.net/constants.

正如第一章中所討論過的，register_globals可使確定一個變量如$email的來源變得十分困難。所有來自外部數據源的數據在被證明合法前都應該被認為被污染的。

盡管一個用戶能用多種方式發送數據，大多數應用還是依據表單的提交結果進行最重要的操作。另外一個攻擊者只要通過操縱提交數據（你的應用進行操作的依據）即可危害，而表單向他們方便地開放了你的應用的設計方案及你需要使用的數據。這也是表單處理是所有Web應用安全問題中的首先要關心的問題的原因。

一個用戶可以通過三種方式您的應用傳輸數據：

l通過URL(如GET數據方式)

l通過一個請求的內容（如POST數據方式）

l通過HTTP頭部信息（如Cookie）

由于HTTP頭部信息并不與表單處理直接相關，在本章中不作討論。通常，對GET與POST數據的懷疑可以推及到所有輸入，包括HTTP頭部信息。

表單通過GET或POST請求方式傳送數據。當你建立了一個HTML表單，你需要在form標簽的method屬性中指定請求方式：

<form action='http://example.org/register.php' method='GET'>

在前例中，請求方式被指定為GET，瀏覽器將通過URL的請求串部分傳輸數據，例如，考慮下面的表單：

CODE:

<form action='http://example.org/login.php' method='GET'>

<p>Username: <input type='text' name='username' /></p>

<p>Password: <input type='password' name='password' /></p>

<p><input type='submit' /></p>

</form>

如果我輸入了用戶名chris和密碼mypass，在表單提交后，我會到達URL為http://example.org/login.php?username=chris&password=mypass的頁面。該URL最簡單的合法HTTP/1.1請求信息如下：

CODE:

GET /login.php?username=chris&password=mypass HTTP/1.1

Host: example.org

并不是必須要使用HTML表單來請求這個URL，實際上通過HTML表單的GET請求方式發送數據與用戶直接點擊鏈接并沒有什么不同。

記住如果你在GET方式提交的表單中的action中試圖使用請求串，它會被表單中的數據所取代。

而且，如果你指定了一個非法的請求方式，或者請求方式屬性未寫，瀏覽器則會默認以GET方式提交數據。

為說明POST請求方式，只對上例進行簡單的更改，考慮把GET請求方式更改為POST的情況：

CODE:

<form action='http://example.org/login.php' method='POST'>

<p>Username: <input type='text' name='username' /></p>

<p>Password: <input type='password' name='password' /></p>

<p><input type='submit' /></p>

</form>

如果我再次指定用戶名chris和密碼mypass，在提交表單后，我會來到http://example.org/login.php頁面。表單數據在請求的內部而不是一個URL的請求串。該方式最簡單的合法HTTP/1.1請求信息如下

CODE:

POST /login.php HTTP/1.1

Host: example.org

Content-Type: application/x-www-form-urlencoded

Content-Length: 30

username=chris&password=mypass

現在你已看到用戶向你的應用提供數據的主要方式。在下面的小節中，我們將會討論攻擊者是如何利用你的表單和URL作為進入你的應用的缺口的。