攻撃者はinspect要素を有害に使用できますか？

Question

これは広い質問ですが、私はここで何か不足していると思います。攻撃者がinspect要素を使用してjavascriptやhtmlを編集するだけでサイトにダメージを与える可能性はありますか？たとえば、誰かが入力の最大長を変更して、サーバーをクラッシュさせるほどのデータをアップロードするのは容易ではないようですが、サーバーでデータをチェックすることは常に良い方法ですが、それでも簡単にはできません。攻撃者が$.ajaxコールを混乱させてサーバーに不正な情報を送信する可能性がある場合は、さらに危険性の高い別の例があります。それは攻撃者のブラウザで、私がもっと気になるべきものか、あるいは一時的な変更ですか？

Answer 1

変更は個々のユーザーのブラウザで一時的です。

ただし、この変更によって、そのユーザーはバックエンドとやりとりすることができます。これは、サイトが攻撃される1つの方法です。

標準ルールは、ユーザー/ブラウザからの入力を絶対に信頼しないことです。隠されたフィールドの値を信用しないでください、長さを変更していないと信じてはいけません。新しい値を追加していないと信じてはいけません（例えばドロップダウン）.Javascriptで行われた検証は、など

いくつかの例：

• 過去にいくつかのショッピングサイトは、フォームで隠しフィールドとして支払われる金額が含まれます。この値を変更すると、依然として取引を承認しながらクレジットカードに請求された金額が変更されました。
• バックエンドサービスに直接ポスティングしてスキップして、SQLおよびHTML/Scriptインジェクション攻撃まで自分自身を開くことができるJavascript検証ルールを持つサイト。
• 予期しない値をフォームに追加できるドロップダウン、ラジオボタン、およびチェックボックスの入力。

Answer 2

これについては気をつけてください。クライアントからの入力を信用しないでください。クライアント側で実行しているチェックが実際に実行されることを期待しないでください。サーバー側の入力を常にチェックする必要があります。 すでに説明したように、ユーザーはさまざまな検査ツールを使用してローカルコードを変更するか、悪意のあるパケットを手動で手作業で作成することができます。

Answer 3

はい、可能です。要素を検査するときには、すべてをローカルで変更できるため、ローカル環境の一時的な変更になりますが、サーバーに影響する可能性のある値を変更できます。

たとえば、オンラインストアがあり、[商品の編集]オプションがあるとします。そこに行くと、製品IDを保管している隠れたフィールドがあります。バックエンドでその製品を更新しようとすると、そのIDを使用して更新する製品を知ることになります。攻撃者はその値を簡単に変更することができ、今では他の製品（彼に属していない製品を含む）を修正することができます。

別の古典的な例では、あなたのバックエンドでは、あなたがたとえば、クエリでその番号を使用して、ユーザーが唯一、数値を提出することができるようになりますことを前提と番号フィールド、

のようなものかもしれません

"SELECT * FROM Products WHERE Price > " + Price; 

数値が必要なので、攻撃者がSQLインジェクションのテキストを送信する方法はないと思うが、簡単にその値を変更できます（テキスト入力の入力番号を変更するか、送信前にjavascriptの値を変更したり、ネットワークトラフィックをインターセプトしてそこから値を変更したりすることができます）。

"SELECT * FROM Products WHERE Price > 0; DROP TABLE Products--" 

これは、ユーザーの入力を信頼してはいけない主な理由です。あなたは数値を期待していますか？それを使用する前に番号であることを確認してください。あなたのユーザーは製品をアップデートしていますか？それを更新する前に、製品が本当に彼に属していることを確認してください。あなたのデータにmaxlengthのプロパティがありますか？サーバを再度チェックして、有効な長さが残っていることを確認してください。

本当に簡単で簡単なもののように見えるかもしれませんが、人々は間違いを犯します。簡単な例は、ユーザーの送信データを信頼するのではなく、リクエストの長さを確認することで回避できる「ハートブレイブ」バグです。

これが、ユーザーが送信したデータを信頼する必要がなく、バックエンドで常にダブルチェックを実行する必要がある主な理由です。