2

Web アプリケーションの現在の傾向は、すべてに GET リクエストを使用する傾向にあるようです。具体的には、サービス、コマンド、およびそのパラメーターを記述する RESTful URL を使用します。数か月前、Jeff Atwood が XSS の危険性について投稿しました。彼は、「img」タグのように一見無害に見えるものをユーザーがサイトに投稿できるようにしても、XSS 脆弱性が発生する可能性があることを示しました。その理由は、ブラウザーがやみくもに「src」属性の URL を要求するためです。これは、ユーザーのログアウトなど、単に迷惑なことや、もっと不吉なことを行う可能性があります。

10 年前に初めて Web 開発を始めたとき、従来の知恵では、フォームには常に GET よりも POST を優先し、サーバー側のアプリケーションではフォームの送信に POST を要求するようにしていました。まさにこの理由からです。ブラウザーは常に GET 要求を送信しますが (前述の "img" タグの例のように)、特定の状況 (具体的には、"method" 属性が POST に設定されたフォーム) でのみ POST 要求を送信します。POST を要求することで、XSS 攻撃の大部分を排除できるようです。これはそれらを好む正当な理由ですか？

4

6 に答える 6

6

REST がすべてに GET を使用することを意味するようになったのはいつからですか? 最後に確認したところ、それは正反対の意味でした。リソースを取得するにはGET リクエストを使用し、サーバーに投稿するには POST リクエストを使用します。

REST の重要なポイントの 1 つは、実行しようとしている操作に最適な HTTP 要求を使用することです。GET は、サーバーの状態を変更せずに、サーバーからデータを取得する目的で使用する必要があります。サーバー上のリソースを更新するために使用しないでください。POST または PUT はそのために設計されています。

意図された方法で HTTP を使用すると、XSS 攻撃の一部 (すべてではない) の回避に役立ちます。また、サイトと通信する際のブラウザーの動作が大幅に改善されます。ブラウザーは、ユーザーからの確認を必要とせずに、GET 要求を安全に繰り返すことができると想定しています。たとえば、ページを更新したり、戻る/進むボタンを使用したりすると、これが行われます。POST はサーバー上で状態を変更することが想定されているため、ブラウザーは通常、POST 要求を繰り返す前に確認を求めます。

于 2009-05-07T01:19:19.513 に答える
2

通常の Ajax 呼び出しと REST 呼び出しを混同しています。

Vanilla Ajax 呼び出しは GET または POST を使用し、それらの処理方法は完全にユーザー次第です。

REST は動詞 GET、HEAD、POST、PUT、DELETE を使用します。

HTTP VERB   REST/CRUD
POST         Create
GET          Read
PUT          Update, Create
DELETE     Delete

XSSではなくCSRFが気になるときはPOST over GETを使いたい。

経験則としては、常に POST を使用し、そのデータを他のサイトと共有する必要があることが確実な場合、またはデータが機密でない場合にのみ GET を使用することです。

しかし、POST を単独で使用するだけでは、100% 保護することはできません。

XSS と CSRF はどちらも非常に重要であり、両方についてアプリを確認する必要がありますが、これらは 2 つの非常に異なる獣です。

CSRF :

ウィキペディア

OWASP

XSS:

OWASP

于 2009-05-07T01:18:24.803 に答える
1

あなたはRESTを誤解していると思います。ポイントは、POST よりも GET を優先することではなく、リクエストがサーバー上のデータに影響を与えない場合は GET を使用し、データが変更される場合は POST を使用することです。REST は、利用可能な HTTP 動詞を適切に使用することがすべてです。

たとえば、検索フォームは GET を使用することが多く、Create X フォームは通常 POST を使用します。

于 2009-05-07T01:18:38.437 に答える
0

XSS は停止しません。XSS は、ユーザーが何らかの形でスクリプトを他のユーザーに出力するように指示する場合です。それにはフィルタリングが必要です。

XSRF も停止しません。ある種のワンタイム トークンを追加して、(埋め込まれた iframe などから投稿するのではなく) 実際にサイトにアクセスしている場合にのみサイトにアクセスできるようにする必要があります。

ただし、POST と GET は、Web アクセラレータとスクレーパー (Google Bot など) がサイトを変更するのを防ぎます。それらはGETリンクにのみ移動するため、サイトを削除したくない場合（これに関するDaily WTFの投稿）、「このアイテムを削除する」がGETではないことを確認してください. ;-)

より一般的には、セマンティクスとフォーム サイズの問題です。GET はフォームを投稿しないため、URL に入力できるものに制限されますが、これはそれほど多くはありません。POST では、任意の量のデータが許可されます。PUT と DELETE はセマンティクスのためのものです。どちらも POST 経由でも実行できます。

于 2009-05-07T02:00:05.873 に答える
0

すでに与えられた答えは本当にあなたの質問に答えます-いいえ、XSSの防止はGETよりもPO​​STを好む正当な理由ではありません。ただし、これのデモンストレーションが必要な場合は、WebScarabやTamper Dataなどのツールを確認してください。これらは、自分のサイトの脆弱性をテストするのに非常に役立ちます。コードを POST リクエストに挿入するのは、GET に挿入するのと同じくらい簡単です。ただし、これらのツールがなくても、サーバー側で POST と GET をチェックしている場合を除き、GET を使用して単純にパラメーターを送信するのは簡単です。たとえば、?parm1=value1&parm2=value2&etc を URL に追加するだけです。

于 2009-05-07T02:16:47.627 に答える
0

GET ではなく POST を使用する必要がある状況もありますが、XSSを回避することはその 1 つではありません。おそらくあなたはXSRFのことを考えているでしょうが、それでも POST を要求しても実際には保護されません。実際、REST の支持者は、GET を使用するだけではなく、対応する " CRUD " 操作に POST、PUT、および DELETE を使用する必要があると実際に言うでしょう。

XSSを回避するには、ユーザーのコンテンツを適切にエスケープおよび/またはスクラブします。

XSRFを回避するには、潜在的に危険な操作を引き起こす副作用でシークレット トークンを要求します。(ところで: シークレット トークンを渡すときに GET リクエストを使用しないことをお勧めします。リファラーでリークが発生する可能性があるためです。)

読み取り専用リクエストには、可能な限りGET を使用してください。(ほとんどの場合、クエリが URL に収まる場合)

書き込み要求には POST (または、可能で適切な場合は PUT または DELETE) を使用します。

于 2009-05-07T01:26:50.710 に答える