3

私は最近、djangoローカルサーバープロジェクトをいじっていましたが、次のような入力がありました

<form....{% csrf_token %}
....
<input type="text" value="foo" readonly />
....
</form>

これで、入力の値は希望どおり（ "foo"）のままになりますが、google chrome inspectを使用して、読み取り専用入力の値を変更し、新しい値をサーバーに渡すことができました。これにより、問題が回避されました。価値。

だから私はいくつかの質問があります：

  1. このようなセキュリティリスクを防ぐための一般的なルールまたはメンタルチェックリストは何ですか？

  2. JavaScriptコンソールを使用して、このようなデータを破損することもできますか？更新：YEP。

  3. それで、基本的にサーバー側ですべてのチェックを行う必要がありますか？

  4. 3に該当しない場合、html / jsインスペクターから保護されているクライアント側の検証は何ですか？

編集：

これまでの回答から推測すると、3は「はい」です。それでも、クライアント側のセキュリティ/チェックを気にする必要がありますか？彼らは実際に私をより安全にするのでしょうか、それとも単に誤った安心感（これは悪いことです）ですか？サーバー側でいくつかのチェックを保存するためにクライアント側のチェックを行う必要があります。そうすれば、パフォーマンスが向上する可能性がありますか？ 基本的に：クライアント側のチェックはどのくらい行う必要がありますか？

4

4 に答える 4

2

セキュリティのために、Javascriptやクライアント側で返信することはできません。サーバーが安全であることを確認してください。

たとえば、ポートにtelnetで接続し、適切なデータをサーバーに送信できます。これは、Javascript（またはクライアント側の他のテクノロジー（）を介して阻止およびチェックします。

Javascriptを使用するだけで、クライアントでのユーザーエクスペリエンスがより楽しく、より応答性が高くなります。セキュリティのために使用しないでください。

于 2013-03-08T13:42:35.640 に答える
1

サーバーコードは最終的な権限である必要があります。クライアントが行った検証の品質に依存することはできません。すべてのクライアントを表示します。HTMLであろうとなかろうと、悪意のあるユーザーと間違いのあるコーダーの両方の影響を受けやすいものです。

于 2013-03-08T13:41:07.607 に答える
1

  1. ユーザーから送信されたデータ（Cookie、セッション、HTTPリクエストのパラメーターなど）を絶対に信じないでください。ユーザーが送信するすべてのデータを変更できます。

  2. はい、もちろん

  3. それはまだ行われていません。

于 2013-03-08T13:43:59.380 に答える
1

そもそもなぜその読み取り専用の値が必要なのかを自問してください。おそらく、ユーザーが最初にフォームをリクエストしたときに、それを生成したのはあなたのコードでした。では、ユーザーがフォームを再送信したときに利用できないフォームをユーザーがリクエストしたときに、コードで利用できたものは何でしょうか。何も存在しないはずです。そのため、フォームに表示する必要がなくても、送信時にそのフィールドを簡単に生成できるという結論に達するはずです。

于 2013-03-08T13:54:34.400 に答える