1

ユーザー入力を取得するためのウィザードベースの一連のフォームを作成しています。そのウィザードの要件の1つは、ユーザーが[保存]ボタンをクリックするまでスクリプト（PHP）が入力をデータベース（MySQL）に保存できないことです。そのため、ある形式のユーザー入力を別の形式に転送するメカニズムをデバイス化する必要があります。ユーザーが「前へ」または「次へ」ボタンをクリックしたとき。Cookie、セッション、一時ファイルなどのさまざまな方法を使用することを検討しましたが、シリーズのすべてのフォームに存在する非表示フィールドにbase64_encodedシリアル化データを埋め込むことにしました。このフィールドの値は、フォームの送信時にデコードされ、現在のフォームの他の値が挿入された後、次のフォームに入力するために再エンコードされます。

隠しフィールドがどのように見えるかのサンプルを次に示します。

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

したがって、質問は次のとおりです。

  1. それは良い/悪い習慣と見なされますか？

  2. HTMLformの非表示フィールドの長さに制限はありますか？

  3. 考えられるセキュリティの問題は何ですか？

  4. そして、より良い選択肢はありますか？（説明付き、できればjavascriptを使用せずに）

前もって感謝します！

4

4 に答える 4

1

  1. 私のキャリアの中でこの特定のパラメーターの受け渡し方法を見たことがないので、それが良いか悪いかはわかりません。それは確かに「標準」ではありません。標準のメソッドは、送信されたメソッドを（エンコードされていない/通常は）非表示の入力を使用して渡すか、セッションに保存します。自分で仕事をしているのではないかと思いますので、そういう意味では「理想的ではない」という方向に傾いています。

  2. フォームにPOSTを使用している限り、HTTP仕様で認識しているデータサイズに定義された制限はありません。古いサーバーには実際的な制限があるかもしれませんが、メディアファイルのアップロードなどの極端なことをしているのでない限り、心配する必要はありません。

  3. 考えられるセキュリティの問題は、通常のWebセキュリティの欠陥です。ユーザーから取得してページに再出力するものには、クロスサイトスクリプティングの脆弱性が含まれている可能性があり、適切にサニタイズする必要があります（すべてをエンコードしている場合、これはやや意味がありません）。ユーザーは独自のデータを作成し、必要に応じて送信できます。基本的に、処理するすべてのデータが安全でなく、汚染されていると想定します。

  4. ここではセッションがはるかにうまく機能します。ユーザーが送信するデータは、長いエンコードプロセスを経る必要はありません。また、検証する必要があるのは1回だけです。送信して検証した後、サーバーの$ _SESSIONに保存し、最後のボタンがクリックされるまでそのままにしておくことができます。それ以外の場合は、各ステップで再出力、再受信、および再検証について心配する必要があります。悪意のあるユーザーは、1セットのデータを送信し、それをチェックしてエンコードされたデータとして再出力しますが、エンコードを解除し、データを変更し、再エンコードすることで次のフォーム送信を作成する可能性があります。

すべてのデータ操作が「1回限り」のシナリオに簡素化されるため、セッションを再検討することを強くお勧めします。

于 2009-12-16T05:25:48.113 に答える
1

それは良い/悪い習慣と見なされますか？

目的によって異なります。これまでのところ、大規模なajaxベースのアプリケーションでの選択の状態を記憶するためのクライアント側のURLハッシュ（ブックマーク可能にするため）などの構造を見ただけで、Gzip圧縮して短くすることもよくあります。あなたの特殊なケースでは、HTTPセッションを利用し、セッションから関連情報を取得できるように、非表示フィールドにリクエストベースの識別子（トークンとも呼ばれます）のみを渡します。

HTMLformの非表示フィールドの長さに制限はありますか？

GETでは、完全なクエリ文字列（すべてのパラメータ名と値および区切り文字を合わせたもの）は通常2048文字に制限されていますが、256文字という悪意のある制限を厳守することをお勧めします。POSTでは、サーバーの構成によって異なります。多くの場合、これはデフォルトで約2GBです。

考えられるセキュリティの問題は何ですか？

まあ、それは明らかにデコード可能です。

そして、より良い選択肢はありますか？（説明付き、できればjavascriptを使用せずに）

Gzipで圧縮して、短くして目立たなくすることができます。または、すでに述べたように、リクエストベースの識別子と組み合わせてセッションを利用します。

于 2009-12-16T23:49:18.873 に答える
0

tsk tsk :)

  1. それは良い/悪い習慣と見なされますか？主観的に-悪い習慣..あなたは仕事に間違ったハンマーを使用しています。

  2. HTMLformの非表示フィールドの長さに制限はありますか？-制限があるかどうかわからない。

  3. 考えられるセキュリティの問題は何ですか？-おそらくかなりの数ですが、リクエストごとに受信したデータをサニタイズすることができます。その上、データはデコードするのが非常に簡単で、クライアント側で簡単に変更できます（私はあなたが使用しているある種のjsonを見ることができます:)）

  4. そして、より良い選択肢はありますか？（説明付き、できればjavascriptを使用せずに）-適切なツールを使用します..おそらくセッション？

そしてそうです...すべてのリクエストに対してサニタイズ、解析、フォーマット、セキュリティコードを実行すると、パフォーマンスとスケーラビリティの問題に直面する可能性が高くなります（ユーザーにかなりの負荷がかかる場合）。

于 2009-12-16T05:19:26.830 に答える
0

シリアル化するか、各ステップのように単純に保存することで、セッションに保存できます。ユーザーが[保存]をクリックすると、セッションのすべてのステップからデータを取得して検証します。

于 2009-12-16T05:14:43.070 に答える