php介面安全設計知識點（php介面安全和規範）

本文目錄一覽：

• 1、php開發api介面,如何做才算是安全的
• 2、php有什麼安全規則，有哪些？
• 3、學習PHP需要涉及哪些方面的知識
• 4、用PHP做伺服器介面客戶端用http協議POST訪問安全性一般怎麼做
• 5、php開發app介面需要注意什麼

php開發api介面,如何做才算是安全的

這個問題很深

安全，不敢當，因為web安全問題很多，不僅僅是PHP編碼而已，有很多安全上的問題需要做處理，像伺服器漏洞、埠開放都會導致被黑，這都是很正常的。

只能說 比如在我做PHP開發過程的一些安全保護和在網路安全公司開發時的工作要求：

1、最基礎的，提供的api介面 要配置https。

2、api返迴響應的信息，要儘可能使用消息加密返回，如高位數的 rsa加密內容。

3、接收的回調開放介面，儘可能做到使用回調黑、白名單，如加ip白名單放行，或ip黑名單禁止訪問。

4、不要相信用戶輸入、輸入信息要進行編碼轉換、轉義、過濾、使用框架和插件進行處理，如MySQL查詢的要進行參數綁定、如顯示問題要避免xss攻擊會進行過濾。

5、授權操作，錯誤限制設置閥值、超過閥值限制訪問、如最基礎的登錄功能。

6、常見額弱口令問題導致漏銅，應設置高強度口令，避免程序爆破。

7、文件上傳問題、應嚴格校驗文件類型、後綴、格式、及文件目錄許可權設置，從而避免文件上傳漏洞導致惡意代碼或webshell攻擊。

8、開發環境和生產環境隔開，不要再生產上面開debug、及時更新使用框架漏洞補丁如PHP國內常用 tp系列以前偶爾爆出漏洞（我用的較多就是tp5 ….），還有框架不要用最新要選擇最穩定的。

最後注意不管是驗證還是過濾，在客戶端執行過一次也好，在服務端，都要再次執行驗證和校驗。

和盛之文  我的文章保存網站，歡迎訪問學習或參考

php有什麼安全規則，有哪些？

php安全篇值過濾用戶輸入的人蔘數

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

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

例如，下面的數據元素可以被認為是安全的，因為它們是在PHP中設置的。

複製代碼 代碼如下:

?php

$myUsername = ‘tmyer’;

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

但是，下面的數據元素都是有瑕疵的。

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

複製代碼 代碼如下:

?php

$myUsername = $_POST[‘username’]; //tainted!

$arrayUsers = array($myUsername, ‘tom’, ‘tommy’); //tainted!

define(」GREETING」, ‘hello there’ . $myUsername); //tainted!

?

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

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

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

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

複製代碼 代碼如下:

?php

$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 變數。

規則 3：如果不能理解它，就不能保護它

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

例如，您喜歡下面兩段代碼中的哪一段？

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

複製代碼 代碼如下:

?php

//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 查詢字元串，將信息添加到資料庫查詢中。例如，假設有一個簡單的登錄資料庫。這個資料庫中的每個記錄都有一個用戶名欄位和一個密碼欄位。構建一個登錄表單，讓用戶能夠登錄。

清單 5. 簡單的登錄表單

複製代碼 代碼如下:

html

head

titleLogin/title

/head

body

form action=」verify.php」 method=」post」

plabel for=’user’Username/label

input type=’text’ name=’user’ id=’user’/

/p

plabel for=’pw’Password/label

input type=’password’ name=’pw’ id=’pw’/

/p

pinput type=’submit’ value=’login’//p

/form

/body

/html

這個表單接受用戶輸入的用戶名和密碼，並將用戶輸入提交給名為 verify.php 的文件。在這個文件中，PHP 處理來自登錄表單的數據，如下所示：

清單 6. 不安全的 PHP 表單處理代碼

複製代碼 代碼如下:

?php

$okay = 0;

$username = $_POST[‘user’];

$pw = $_POST[‘pw’];

$sql = 「select count(*) as ctr from users where username=’」.$username.」’ and password=’」. $pw.」’ limit 1″;$result = mysql_query($sql);

while ($data = mysql_fetch_object($result)){if ($data-ctr == 1){

//they’re okay to enter the application!

$okay = 1;

}

}

if ($okay){

$_SESSION[‘loginokay’] = true;

header(」index.php」);

}else{

header(」login.php」);

}

?

這 段代碼看起來沒問題，對嗎？世界各地成百（甚至成千）的 PHP/MySQL 站點都在使用這樣的代碼。它錯在哪裡？好，記住 「不能信任用戶輸入」。這裡沒有對來自用戶的任何信息進行轉義，因此使應用程序容易受到攻擊。具體來說，可能會出現任何類型的 SQL 注入攻擊。

例如，如果用戶輸入 foo 作為用戶名，輸入 ‘ or ‘1′=’1 作為密碼，那麼實際上會將以下字元串傳遞給 PHP，然後將查詢傳遞給 MySQL：

複製代碼 代碼如下:

?php

$sql = 「select count(*) as ctr from users where username=’foo’ and password=」 or ‘1′=’1′ limit 1″;?

這個查詢總是返回計數值 1，因此 PHP 會允許進行訪問。通過在密碼字元串的末章節附註入某些惡意 SQL，黑客就能裝扮成合法的用戶。

解 決這個問題的辦法是，將 PHP 的內置 mysql_real_escape_string() 函數用作任何用戶輸入的包裝器。這個函數對字元串中的字元進行轉義，使字元串不可能傳遞撇號等特殊字元並讓 MySQL 根據特殊字元進行操作。清單 7 展示了帶轉義處理的代碼。

清單 7. 安全的 PHP 表單處理代碼

複製代碼 代碼如下:

?php

$okay = 0;

$username = $_POST[‘user’];

$pw = $_POST[‘pw’];

$sql = 「select count(*) as ctr from users where username=’」.mysql_real_escape_string($username).」’ and password=’」. mysql_real_escape_string($pw).」’ limit 1″;$result = mysql_query($sql);

while ($data = mysql_fetch_object($result)){if ($data-ctr == 1){

//they’re okay to enter the application!

$okay = 1;

}

}

if ($okay){

$_SESSION[‘loginokay’] = true;

header(」index.php」);

}else{

header(」login.php」);

}

?

使用 mysql_real_escape_string() 作為用戶輸入的包裝器，就可以避免用戶輸入中的任何惡意 SQL 注入。如果用戶嘗試通過 SQL 注入傳遞畸形的密碼，那麼會將以下查詢傳遞給資料庫：

select count(*) as ctr from users where username=’foo’ and password=’\’ or \’1\’=\’1′ limit 1″資料庫中沒有任何東西與這樣的密碼匹配。僅僅採用一個簡單的步驟，就堵住了 Web 應用程序中的一個大漏洞。這裡得出的經驗是，總是應該對 SQL 查詢的用戶輸入進行轉義。

但是，還有幾個安全漏洞需要堵住。下一項是操縱 GET 變數。

防止用戶操縱 GET 變數

在前一節中，防止了用戶使用畸形的密碼進行登錄。如果您很聰明，應該應用您學到的方法，確保對 SQL 語句的所有用戶輸入進行轉義。

但 是，用戶現在已經安全地登錄了。用戶擁有有效的密碼，並不意味著他將按照規則行事 —— 他有很多機會能夠造成損害。例如，應用程序可能允許用戶查看特殊的內容。所有鏈接指向 template.php?pid=33 或 template.php?pid=321 這樣的位置。URL 中問號後面的部分稱為查詢字元串。因為查詢字元串直接放在 URL 中，所以也稱為 GET 查詢字元串。

在 PHP 中，如果禁用了 register_globals，那麼可以用 $_GET[‘pid’] 訪問這個字元串。在 template.php 頁面中，可能會執行與清單 8 相似的操作。

清單 8. 示例 template.php

複製代碼 代碼如下:

?php

$pid = $_GET[‘pid’];

//we create an object of a fictional class Page$obj = new Page;

$content = $obj-fetchPage($pid);

//and now we have a bunch of PHP that displays the page?

這 里有什麼錯嗎？首先，這裡隱含地相信來自瀏覽器的 GET 變數 pid 是安全的。這會怎麼樣呢？大多數用戶沒那麼聰明，無法構造出語義攻擊。但是，如果他們注意到瀏覽器的 URL 位置域中的 pid=33，就可能開始搗亂。如果他們輸入另一個數字，那麼可能沒問題；但是如果輸入別的東西，比如輸入 SQL 命令或某個文件的名稱（比如 /etc/passwd），或者搞別的惡作劇，比如輸入長達 3,000 個字元的數值，那麼會發生什麼呢？

在這種情況下，要記住基本規則，不要信任用戶輸入。應用程序開發人員知道 template.php 接受的個人標識符（PID）應該是數字，所以可以使用 PHP 的 is_numeric()函數確保不接受非數字的 PID，如下所示：

清單 9. 使用 is_numeric() 來限制 GET 變數複製代碼 代碼如下:

?php

$pid = $_GET[‘pid’];

if (is_numeric($pid)){

//we create an object of a fictional class Page$obj = new Page;

$content = $obj-fetchPage($pid);

//and now we have a bunch of PHP that displays the page}else{

//didn’t pass the is_numeric() test, do something else!

}

?

這個方法似乎是有效的，但是以下這些輸入都能夠輕鬆地通過 is_numeric() 的檢查：

100 （有效）

100.1 （不應該有小數位）

+0123.45e6 （科學計數法 —— 不好）

0xff33669f （十六進位 —— 危險！危險！）那麼，有安全意識的 PHP 開發人員應該怎麼做呢？多年的經驗表明，最好的做法是使用正則表達式來確保整個 GET 變數由數字組成，如下所示：

清單 10. 使用正則表達式限制 GET 變數

複製代碼 代碼如下:

?php

$pid = $_GET[‘pid’];

if (strlen($pid)){

if (!ereg(」^[0-9]+$」,$pid)){

//do something appropriate, like maybe logging them out or sending them back to home page}

}else{

//empty $pid, so send them back to the home page}

//we create an object of a fictional class Page, which is now//moderately protected from evil user input$obj = new Page;

$content = $obj-fetchPage($pid);

//and now we have a bunch of PHP that displays the page?

需 要做的只是使用 strlen() 檢查變數的長度是否非零；如果是，就使用一個全數字正則表達式來確保數據元素是有效的。如果 PID 包含字母、斜線、點號或任何與十六進位相似的內容，那麼這個常式捕獲它並將頁面從用戶活動中屏蔽。如果看一下 Page 類幕後的情況，就會看到有安全意識的 PHP 開發人員已經對用戶輸入 $pid 進行了轉義，從而保護了 fetchPage() 方法，如下所示：

清單 11. 對 fetchPage() 方法進行轉義

複製代碼 代碼如下:

?php

class Page{

function fetchPage($pid){

$sql = 「select pid,title,desc,kw,content,status from page where pid=’」.mysql_real_escape_string($pid).」’」;}

}

?

您可能會問，「既然已經確保 PID 是數字，那麼為什麼還要進行轉義？」 因為不知道在多少不同的上下文和情況中會使用 fetchPage() 方法。必須在調用這個方法的所有地方進行保護，而方法中的轉義體現了縱深防禦的意義。

如 果用戶嘗試輸入非常長的數值，比如長達 1000 個字元，試圖發起緩衝區溢出攻擊，那麼會發生什麼呢？下一節更詳細地討論這個問題，但是目前可以添加另一個檢查，確保輸入的 PID 具有正確的長度。您知道資料庫的 pid 欄位的最大長度是 5 位，所以可以添加下面的檢查。

清單 12. 使用正則表達式和長度檢查來限制 GET 變數複製代碼 代碼如下:

?php

$pid = $_GET[‘pid’];

if (strlen($pid)){

if (!ereg(」^[0-9]+$」,$pid) strlen($pid) 5){//do something appropriate, like maybe logging them out or sending them back to home page}

} else {

//empty $pid, so send them back to the home page}

//we create an object of a fictional class Page, which is now//even more protected from evil user input$obj = new Page;

$content = $obj-fetchPage($pid);

//and now we have a bunch of PHP that displays the page?

現在，任何人都無法在資料庫應用程序中塞進一個 5,000 位的數值 —— 至少在涉及 GET 字元串的地方不會有這種情況。想像一下黑客在試圖突破您的應用程序而遭到挫折時咬牙切齒的樣子吧！而且因為關閉了錯誤報告，黑客更難進行偵察。

緩衝區溢出攻擊

緩衝區溢出攻擊 試圖使 PHP 應用程序中（或者更精確地說，在 Apache 或底層操作系統中）的內存分配緩衝區發生溢出。請記住，您可能是使用 PHP 這樣的高級語言來編寫 Web 應用程序，但是最終還是要調用 C（在 Apache 的情況下）。與大多數低級語言一樣，C 對於內存分配有嚴格的規則。

緩衝區溢出攻擊向緩衝區發送大量數據，使部分數據溢出到相鄰的內存緩衝區，從而破壞緩衝區或者重寫邏輯。這樣就能夠造成拒絕服務、破壞數據或者在遠程伺服器上執行惡意代碼。

防止緩衝區溢出攻擊的惟一方法是檢查所有用戶輸入的長度。例如，如果有一個表單元素要求輸入用戶的名字，那麼在這個域上添加值為 40 的 maxlength 屬性，並在後端使用 substr() 進行檢查。清單 13 給出表單和 PHP 代碼的簡短示例。

學習PHP需要涉及哪些方面的知識

PHP需要掌握的知識還是比較多的，最基本的比如：PHP基本的語法、php框架以及CMS、mysql資料庫設計表、mysql資料庫的基本SQL語句。現在一般PHP的都得會前端，那就包括：js/ajax、html、css。如果更高點層次的就是linux伺服器。

PHP攻城獅踐行學習路線圖：

1、用集成環境安裝PHP環境，一定要記住這一點，不要自己分開去裝，尤其是自學的朋友。不然你會覺得很複雜，會沒有信心學下去的。也要注意任何高手都不是一蹴而就的，是一步一步，不同的階段歷練才有最後的沉澱。

2、先了解一些基本的變數類型，語法，函數，基本邏輯，寫簡單的代碼。前期以嘗試，培養興趣為主。這段時間是打基礎很好的時候，這個會影響你後面的發展，不過也可以在後期去完善。

3、這時候你可能覺得PHP就這樣，沒什麼難度，或者有的覺得太難了，簡直一臉疑惑。這個到底有什麼用。在這時候一定要堅持下來，可以試試先放一下，別太較真。慢慢的困惑你的會被你領悟的。這時，建議學習html+css+js,緩解自己的壓力，這個相對簡單,簡歷信心。尤其是js，總結其實有相同的思路，可以結合著一起體會。

4、這些都感覺有80%了解就可以先放放了，現在在學習MySQL，也是先了解基礎的。這個是幹什麼的，我可以用它做什麼。因為之前裝的集成環境。為什麼感覺是凌亂的，我想告訴你的是，一是不要在自己沒能力解決問題的時候死磕，浪費時間，喪失信心。這時候我們要做的是學習壯大自己，不要灰心。二是我本來覺得這一切都了解才是完整的。我們的目標也是要把這些都做好，這才是一個合格的PHP程序員。

5、這一切都順利的話，你基本離預設的目標不遠了，完成了整個學習的70%了。後面的是在之前的基礎上升華。把HTML和css、js結合、靜態文件和PHP結合、PHP和MySQL結合。這個階段可能越到的問題會異常的多，一定要學會解決問題。網上很多都是答案，同樣你要學會問問題。

6、這些之後你基本已經快到學習的尾聲了，但還缺少經驗。這時，你可以看一些網上開源的cms，例如織夢，國內用的多，越到問題好解決。看看一些視頻（網上免費的很多），查漏補缺，總結歸納形成自己的知識體系。是時候該準備慶祝下自己這段的時間沒有白費（一般2到3各月，看平時每天花的時間），基本成為一個合格的PHP程序員了。也該恭喜你了，其實並不那麼難。堅持，堅持；努力，努力；學習，學習

用PHP做伺服器介面客戶端用http協議POST訪問安全性一般怎麼做

1.請求頭裡帶用戶username和password，到伺服器端做驗證，通過才繼續下邊業務邏輯。

優點：防止了伺服器端api被隨意調用。

缺點：每次都交互用戶名和密碼，交互量大，且密碼明文傳輸不安全。

2.第一次請求，要求username和password，驗證通過，種cookie到客戶端，app保存cookie值。

每次請求帶上cookie。

點評：和pc上瀏覽器認證的原理一樣了。

以上兩點，只有註冊用戶，才能有權訪問業務邏輯，而app有大量的不需要註冊數據api。

php開發app介面需要注意什麼

1.制定規範

開發前一定要定好一個規範，比如要定好數據返回的通用參數和格式。關於數據格式，用的比較多的有xml和json，我建議用json，因為json比xml的好處更多。

2.精簡的返回數據

介面數據因符合需要什麼返回什麼的原則，比如要查詢某個用戶的餘額和註冊時間，網頁裡面的做法可能是select * from user where uid=1，但是介面一定要select balance,regtime from user where uid=1。因為介面返回數據是要有開銷的，要流量的，能少返回數據就盡量少返回，這樣可以大大的提高性能。

3.數據類型要嚴格

要注意數據的類型，整數類型的數據一定要轉為int，因為app客戶端開發的java、object-c語言對數據類型比較嚴格，類型不對會照成app閃退。

4.要寫介面文檔

一定要寫好介面文檔，並按照模塊寫，而且還要書寫規範，最好的格式是：

介面請求地址；請求參數（包括參數名、類型、是否必填）；測試參數舉例；返回參數（參數名，並註明每個參數的含義）。

這樣哪怕以後項目很大，以不會照成維護困難的問題。

5.保證代碼正確性

要驗證保證代碼正確無誤，而且生成環境中要屏蔽掉錯誤，避免頭部有額外的輸出，照成返回的json等數據解析失敗而導致app閃退等。

6.要優化代碼的性能

app要求響應迅速，這樣才能給用戶比較好的體驗感。所以移動介面端在處理業務邏輯的時候，要避免不要執行太複雜的sql語句，或者含有大量的循環，能做成緩存的盡量做緩存，比如將首頁的熱點模塊信息可以存到redis緩存中。在不考慮網速的情況下，比較理想的介面響應時間應該是200毫秒以內。

7.不要隨意更改舊介面

app不像網頁，app一旦發布，有人使用之後，介面就不要亂修改了。以後升級也是，修改要在保證介面原有結構之上進行額外的擴展，否則會導致調用舊版介面的app出現bug。

8. 注意介面的安全

安全高於一切，必須要保證介面的安全。電話號碼等敏感信息在傳輸的過程中一定要加密，否則可能會被別人抓包到。拿取用戶信息的介面一定要驗證許可權，以防止介面被惡意調用，泄密用戶信息，甚至篡改信息。