PDO＆消毒日期/刪除HTML

我讓用戶使用此代碼更新其名稱。 A）這足以消毒信息嗎？ b）當我把HTML標籤放在那裏，如<b>name</b>它實際上在我的網站上以粗體顯示！有沒有可以讓PDO去掉所有HTML的選項？PDO＆消毒日期/刪除HTML

2011-05-23 Nikki

看起來相當健康。儘管如此，我建議使用POST而不是GET來進行破壞性/操作性操作。如果你堅持發佈數據，你不太可能遭受CSRF攻擊，儘管它不會讓你完全免疫。

如果不真正想用戶輸入HTML到名稱字段，不用擔心在途中到數據庫過濾數據。通過htmlspecialchars()或htmlentities()逃脫它。

我總是由數據應進入數據庫爲原料儘可能的想法站着。

編輯：差點忘了，請確保在$_GET/$_POST實際的期望值試圖使用他們之前存在，如

if (isset($_POST['name'])) { 
    // now use it

2011-05-23 23:45:21 Phil

哪一個更安全？（真的不關心速度/資源） – Nikki 2011-05-23 23:50:06

@Nikki哪個「什麼」更安全？ 'htmlspecialchars（）'vs'htmlentities（）'？我建議你閱讀手冊並確定哪一個最適合你的目的。 – Phil 2011-05-23 23:51:49

謝謝 - htmlentities是我將要使用的一個，因爲它可以處理所有的html，而不僅僅是特殊字符。 – Nikki 2011-05-23 23:55:32

絕不信任用戶輸入！至少，將$_GET['name']包裝在消毒功能中，如mysql_real_escape_string()以防止SQL注入攻擊。然後，當您輸出用戶提供的數據時，請確保將其包裝在htmlspecialchars()中以防止跨站點腳本攻擊（XSS）。

2011-05-23 23:43:46 Dan

我想，當你像我上面做準備語句PDO會照顧逃避數據。 htmlspecialchars是否足以對所有XSS進行消毒？ – Nikki 2011-05-23 23:45:28

-1代表'mysql_real_escape_string（）'，使用綁定參數要好得多。 +1'htmlspecialchars（）'雖然 – Phil 2011-05-23 23:46:23

@Nikki - 是預處理語句和綁定參數比任何在消毒文本上的嘗試都好。我同意Phil關於-1/+ 1 – 2011-05-23 23:51:23

A）閱讀manual：

到的參數預備報表不需要引用;驅動程序會自動處理此問題。如果應用程序獨佔地使用預處理語句，開發人員可以肯定沒有SQL注入會發生（但是，如果查詢的其他部分正在興建了轉義輸入，SQL注入是仍有可能 ）。

B）永遠不要相信用戶的數據。在輸出中使用htmlspecialchars。

C）使用$ _ POST和查詢，這將改變任何數據令牌，以避免CSRF。

2011-05-23 23:47:35

使用POST將不會避免CSRF。 – 2011-05-24 00:39:59

@Alix Axel使用POST可以避免大部分CSRF攻擊。使用POST和令牌將有助於避免它們全部:) – 2011-05-24 00:42:14

使用帶令牌的GET也可以避免任何CSRF攻擊。使用POST（不帶令牌）只會幫助避免不知道如何POST的人員的CSRF攻擊。我認爲你應該重申一下你的最後一點，因爲這是一個關鍵問題。 – 2011-05-24 01:29:03

回答