在表單提交之間傳遞base64_encoded序列化數據

我正在創建一個基於嚮導的用於輸入用戶輸入的一系列表單。該向導的一個要求是腳本（PHP）不能將輸入保存到數據庫（MySQL）中，直到用戶單擊「保存」按鈕，因此我必須設置一種機制將用戶輸入以一種形式傳輸到另一種形式當用戶點擊「上一個」或「下一個」按鈕時。我研究了使用各種方法，包括cookies，會話，臨時文件等，但我決定將base64_encoded序列化數據嵌入到系列中所有表單中存在的隱藏字段中。此字段中的值將在表單提交中解碼，並在插入當前表單中的其他值後插入下一個表單時進行重新編碼。在表單提交之間傳遞base64_encoded序列化數據

這裏的隱藏字段的外觀示例：

<input type="hidden" name="wizard:presave" value="YTo2OntzOjU6InRpdGxlIjtzOjEwOiJRdWVzdGlvbiAyIjtzOjQ6InRleHQiO3M6MTk6IlllcyBpdCdzIGEgcXVlc3Rpb24iO3M6NDoidHlwZSI7czo2OiJjaG9pY2UiO3M6NzoiY2hvaWNlcyI7YTowOnt9czo1OiJwb2ludCI7aToxO3M6Mjoib3AiO3M6MTM6ImVkaXRfZXhlcmNpc2UiO30=" />

所以問題是：

是它認爲是一個好/壞的做法？
HTMLform中隱藏字段是否有長度限制？
有什麼可能的安全問題？
有沒有更好的選擇？（與解釋，最好不使用JavaScript）

在此先感謝！

來源

2009-12-16 Lukman

我從來沒有見過這種特殊的參數傳遞方法，所以我不能說它是好還是壞。這當然不是「標準」。標準方法要麼是使用隱藏的輸入傳遞提交的方法（未編碼/通常），要麼將其存儲在會話中。我認爲你可能會爲自己做事，所以在這個意義上說，它會傾向於「不理想」。
只要您在表單中使用POST，對於我在HTTP規範中知道的數據大小沒有定義的限制。舊的服務器可能會有實際的限制，但除非你正在做一些極端的事情，比如媒體文件上傳，否則他們不應該擔心。
可能的安全問題是正常的網絡安全缺陷。您從用戶那裏獲取並重新輸出到頁面的任何內容都可能包含跨站點腳本漏洞，並且必須進行適當的清理（如果您對所有內容進行編碼，這都會有點不切實際）。用戶可以製作自己的數據並提交，如果他們喜歡。基本上，假設您處理的所有數據都是不安全的並且受到污染。
會議會在這裏工作得更好。用戶提交的數據不需要經過冗長的編碼過程。同樣，你只需要驗證一次。提交併驗證之後，您可以將其存儲在$ _SESSION的服務器上，直到最終的按鈕被單擊爲止。否則，你不得不擔心重新輸出它，重新接收它，並在每一步重新驗證它。惡意用戶可以提交一組數據，並將其作爲編碼數據進行檢查和重新輸出，然後通過解密，更改數據和重新編碼來製作下一個表單提交。

我強烈建議您重新考慮會話，因爲它將所有數據操作簡化爲「一次性」方案。

來源

2009-12-16 05:25:48 zombat

我重新考慮了使用會話和它的工作原理，但我仍然需要設置一個隨機的'實例ID'以在提交之間傳遞，以便用戶可以在相同會話上運行多個嚮導實例而不會互相干擾。但它會引入其他安全問題，如用戶混淆實例ID等？ – Lukman 2009-12-16 08:24:57

我不這麼認爲。只要您將正確的隨機值存儲在會話中，那麼唯一可用於操作的參數就是會話令牌本身。 – zombat 2009-12-16 18:21:55

實施，它的工作很好。這裏的所有答案都很好，但是這個提供了最好的解釋。謝謝。 – Lukman 2009-12-17 03:50:51

那麼，你可以通過序列化來存儲會話，或者只是簡單地將它存儲爲每一步的方式。當用戶點擊保存時，您可以獲取並驗證會話中所有步驟的數據。

來源

2009-12-16 05:14:43 mauris

嘖嘖嘖:)

是它認爲是一個好/壞的做法？主觀上不好的做法。你使用錯誤的錘子來完成這項工作。
HTMLform中隱藏字段是否有長度限制？ - 不確定是否有限制。
有什麼可能的安全問題？ - 可能有不少，但您可以清理每個請求收到的數據。此外，數據很容易解碼，並可以在客戶端很容易修改（我可以看到它的某種類型的json，你正在使用:)）
有沒有更好的選擇？（與解釋，最好不使用JavaScript） - 使用正確的工具.. sessions也許？

是的...你最有可能會面臨性能和可擴展性的問題（你應該有一個相當規模的用戶負載）與所有的消毒，解析，格式化和運行爲每個請求的安全代碼。

來源

2009-12-16 05:19:26

它被認爲是好的/壞的做法？

取決於目的。到目前爲止，我只將這種結構看作客戶端URL散列，以便記住大型基於ajax的應用程序中的選擇狀態（以便它們是可收藏的），然後通常也會將其縮小。在你的speficic案例中，我會說：使用HTTP會話，並且只傳遞隱藏字段中的基於請求的標識符（也稱爲標記），以便您可以從會話中獲取關聯的信息。

HTMLform中隱藏字段是否有長度限制？

在完整查詢字符串（所有參數名稱和值和分隔符在一起）通常限制爲2048個字符，但您可以更好地堅持256個字符的官方限制。在POST中，它取決於服務器配置。通常這個默認大約2GB。

什麼是可能的安全問題？

那麼，它顯然是可解碼的。

有沒有更好的選擇？（與解釋，最好不使用javascript）

你可以Gzip它使它更短，更不明顯。或者，如前所述，將會話與基於請求的標識符結合使用。

來源

2009-12-16 23:49:18 BalusC

在base64_encode之後嘗試了gzip，但它破壞了html結構。 base64_encode之前的gzip給出幾乎相同的字符串長度。 +1無論如何;） – Lukman 2009-12-17 03:47:54

在表單提交之間傳遞base64_encoded序列化數據

回答

相關問題