經過十六進制消毒處理後，HTML數據超出字段長度

問題是，您無法真正地告訴用戶字段中允許有多少個字符，因爲轉義值顯然比未轉義的字符多。經過十六進制消毒處理後，HTML數據超出字段長度

我看到了幾個解決方案，但沒有看起來非常好：

每個字段

一個白名單（太多的工作，並不完全解決問題）

一個黑名單的每個字段（同上）

使用，可以保存數據，即使所有字符轉義（壞）字段長度

的Un蓋大小的數據庫字段（壞）

保存數據的十六進制轉義和完全傳遞責任，輸出濾波（不太好）

讓用戶猜測的最大尺寸（最差）

還有其他的選擇嗎？這種情況有沒有「最佳做法」？

示例代碼：

$string = 'javascript:alert("hello!");'; 
echo strlen($string); 
// outputs 27 
$escaped_string = filter_var('javascript:alert("hello!");', FILTER_SANITIZE_ENCODED); 
echo strlen($escaped_string); 
// outputs 41

如果數據庫字段的長度，也就是說，40，逃跑的數據不適合。

來源

2008-10-04 Eduardo Marinho

在什麼編程環境下？ Win32，HTML，...？ – 2008-10-04 15:11:36

對不起，這是HTML。爲了澄清，添加了一些標籤。 – 2008-10-04 15:15:11

不要在數據庫周圍構建應用程序 - 爲應用程序構建數據庫！

設計您希望界面如何爲用戶優先工作，計算出最長可接受的字段長度並使用它。

通常，在存儲到數據庫之前不要轉義 - 將原始數據存儲在數據庫中並對其進行格式化以供顯示。如果要輸出多次，則存儲處理後的版本。

記住磁盤空間相對便宜 - 不要浪費精力，試圖使數據庫緊湊。

來源

2008-10-04 15:50:51

作出有關此背景下一些野生的假設：

如果字段可以容納32個字符，也就是32個轉義字符
讓用戶輸入32個字符
逃生/ UNESCAPE不是用戶的問題
爲什麼這是一個問題？
- ，如果這是形式的數據輸入都不會有問題，並
- 如果你因爲某些原因逃離數據並將其傳遞迴再UNESCAPE它存儲

不前更進一步的情況下，它看起來像你正在打擊一個並不存在的問題，或者不需要存在的問題

來源

2008-10-04 15:19:29

這是一個有趣的問題。

我認爲解決方案將是一個問題，如果您分配任何責任給他們，因爲消毒。如果他們有責任猜測最大長度，那麼他們可能會放棄並選擇其他東西（並且不明白他們爲什麼輸入無效）。

這裏是我的想法：使數據庫字段爲輸入大小的150％。這個額外的尺寸作爲「消毒」空間的「填充」，顯示給用戶和驗證器的最大尺寸是實際需要的尺寸。因此，如果您在消毒前檢查輸入長度，並且低於66％的長度限制，那麼您的消毒數據應該是應該很好。如果它們超過緩衝區的額外34％字段空間，則可能不應接受輸入。

唯一的問題是你的數據庫表會更大。如果您想避免這種情況，那麼您總是可以只轉義SQL敏感字符並處理輸出中的其他所有內容。

編輯：鑑於你的例子，我認爲你逃避太多了。在輸出上使用HTMLSpecialChars()的更小範圍的消毒，或者使數據庫字段達到其當前大小的200％。如果你問我，那真是太臃腫了。

來源

2008-10-04 15:25:07

爲什麼你讓用戶輸入轉義字符？
如果你需要允許明確轉義字符，然後理智檢查它

你應該非常從未做任何字符串任何顯著工作之前插值轉義字符如果它是某種仍編碼。先解碼，然後做你的工作。

我發現一些人有一種傾向使用轉義功能，如addSlashes()（或者不管它是在PHP）太早，或解碼的東西（如消除HTML實體），爲時已晚。解碼第一個，做你的東西，然後應用你需要存儲/輸出/等任何編碼。

來源

2008-10-04 15:25:09 Dan

經過十六進制消毒處理後，HTML數據超出字段長度

回答

相關問題