アカウント名:
パスワード:
「JavaScript を有効にしてください。 また Cookie も有効にしてください。」
POSTメソッドを使う限りJavaScriptは不要
ここ [srad.jp]の[返事を書く]が全部 SUBMIT なボタンになっている様子
また JavaScript で自動POSTさせる方法を併用されると(いくつもの条件が必要ですが) CSSXSS 脆弱性の悪用の道が開けるので、POST を使えだけでは十分ではありません。
プレビュー必須にすれば、[返事を書く]がSubmitである必要はありません。
後半で説明していただいたとおり、GET から(通常の A タグやブックマークから)開かれて、そのページの中の Submit で処理が呼ばれるフォームは(適切な防衛をしなければ) CSSXSS 脆弱性により悪用される可能性があるので、掲示板・BLOGやショッピングカートなど、広範囲のウェブアプリケーションが CSSXSS を受けるわけです。
結局、リクエスト1がPOSTの場合、CSSXSSをCSRFに用いることはできないという理解 [slashdot.jp]で合っているのですよね?
基本的なシナリオは、この記事 IBM PROVISION No.48 IBMプロフェッショナル論文3 - Japan [ibm.com]
複数のドメイン上の既存Webサイトに新たな機能を追加する手法
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
JavaScript と Cookie 必須?! (スコア:3, 興味深い)
Re:JavaScript と Cookie 必須?! (スコア:1)
リクエスト1にGETメソッドを使いたい場合の対処法で、
POSTメソッドを使う限りJavaScriptは不要だと思います。
Re:JavaScript と Cookie 必須?! (スコア:2, すばらしい洞察)
新たにサイトを構築するような場合でも、これは困難を伴うと思います。
また JavaScript で自動POSTさせる方法を併用されると(いくつもの条件が必要ですが) CSSXSS 脆弱性の悪用の道が開けるので、POST を使えだけでは十分ではありません。
Re:JavaScript と Cookie 必須?! (スコア:0)
プレビュー必須にすれば、[返事を書く]がSubmitである必要はありません。
POSTで生成されるプレビュー画面に含まれているワンタイムトークンはCSSXSSでは抜けません。
> また JavaScript で自動POSTさせる方法を併用されるとCSSXSS 脆弱性の悪用の道が開けるので、
自動的にプレビュー画面を出すことはできますが、その画面のワンタイムトークンが抜けないのでCSRFは仕掛けられません。
プレビュー強制がいやなら、(脆弱性のあるバージョンの)IEのみプレビュー必須と言うことにしましょう:-)
Re:JavaScript と Cookie 必須?! (スコア:1)
実際の /. には CSSXSS 脆弱性による影響は(このシナリオの範囲では)ありません。
(紛らわしい表現ですみませんでした)
後半で説明していただいたとおり、GET から(通常の A タグやブックマークから)開かれて、そのページの中の Submit で処理が呼ばれるフォームは(適切な防衛をしなければ) CSSXSS 脆弱性により悪用される可能性があるので、掲示板・BLOGやショッピングカートなど、広範囲のウェブアプリケーションが CSSXSS を受けるわけです。
Re:JavaScript と Cookie 必須?! (スコア:1, 参考になる)
> 掲示板・BLOGやショッピングカートなど、広範囲のウェブアプリケーションが CSSXSS を受けるわけです。
ですから必ずPOSTで生成されるプレビューや確認画面を挟めばいいわけです。
というか私の知る限りほとんどすべてのショッピングカートは確認画面を挟むようになっていていきなり買い物を実行したりはしませんから、それほど対策困難ではないと思われます。
(プレビュー機能のない)掲示板なら被害の程度と対策のコストを天秤に掛けて、あえて対策しないという判断もあり得るでしょう。
結局、リクエスト1がPOSTの場合、CSSXSSをCSRFに用いることはできないという理解 [srad.jp]で合っているのですよね?
Re:JavaScript と Cookie 必須?! (スコア:1)
自動POSTでCSRF脆弱性を悪用できると感じたシナリオは、よくよくかんがえると既にセッションの乗っ取りが完了しているケースでした。
基本的なシナリオは、この記事 IBM PROVISION No.48 IBMプロフェッショナル論文3 - Japan [ibm.com]
とよく似たものです。