質問編集履歴
3
文の修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
反射型XSSは多くの場合、ユーザがフィッシングサイトに誘導され、そこからスクリプト等を含んだリクエストを投げてしまうことで攻撃が成り立ちます。パラメーターに脆弱性がある場合はパラメータにスクリプトを入れることは容易ですが、ヘッダーの場合はFormによるリクエストの送信ではヘッダーの値にスクリプトを入れることはできませんし、JSによる送信では多くの制限がかかると思っています。
|
|
9
|
+
反射型XSSは多くの場合、ユーザがフィッシングサイトに誘導され、そこからスクリプト等を含んだリクエストを投げてしまうことで攻撃が成り立ちます。パラメーターに脆弱性がある場合はフィッシングサイトがリクエストのパラメータにスクリプトを入れることは容易ですが、ヘッダーの場合はFormによるリクエストの送信ではヘッダーの値にスクリプトを入れることはできませんし、JSによる送信では多くの制限がかかると思っています。
|
|
10
10
|
|
|
11
11
|
JSによるヘッダー付与しようとした場合、
|
|
12
12
|
|
2
文の修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
反射型XSSは多くの場合、ユーザがフィッシングサイトに誘導され、そこからスクリプト等を含んだリクエストを投げてしまうことで攻撃が成り立ちます。パラメーターに脆弱性がある場合は
|
|
9
|
+
反射型XSSは多くの場合、ユーザがフィッシングサイトに誘導され、そこからスクリプト等を含んだリクエストを投げてしまうことで攻撃が成り立ちます。パラメーターに脆弱性がある場合はパラメータにスクリプトを入れることは容易ですが、ヘッダーの場合はFormによるリクエストの送信ではヘッダーの値にスクリプトを入れることはできませんし、JSによる送信では多くの制限がかかると思っています。
|
|
10
10
|
|
|
11
11
|
JSによるヘッダー付与しようとした場合、
|
|
12
12
|
|
1
文の修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
HTTP ヘッダーの値がレスポンスに出力され、それがエスケープされていないことでXSSの脆弱性が出た場合、それはパラメーターの値のエスケープ不足によりXSSが出た場合より危険度(CVSSの値)は低いといえるでしょうか？
|
|
5
|
+
HTTP ヘッダーの値がレスポンスに出力され、それがエスケープされていないことでXSSの脆弱性が出た場合、それはパラメーターの値のエスケープ不足によりXSSが出た場合より危険度(CVSSの値)は低いといえ、修正の緊急度を下げる理由になるでしょうか？
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
@@ -22,6 +22,6 @@
|
|
|
22
22
|
|
|
23
23
|
現実的には、ヘッダーの値にXSSの脆弱性があっても攻撃シナリオが成り立たない場合が多いと思います。(もちろん、HTTPヘッダーインジェクションや古いブラウザ等の別の要因があれば異なりますが)
|
|
24
24
|
|
|
25
|
-
そのため「ヘッダーの値を変更して攻撃するのは難しいから、脆弱性を修正をしない/後回しにする」という考え方
|
|
25
|
+
そのため「ヘッダーの値を変更して攻撃するのは難しいから、脆弱性を修正をしない/後回しにする」という考え方をする理由になるのかが気になります。
|
|
26
26
|
|
|
27
|
-
もし
|
|
27
|
+
また、もし現実的に起こり得る(フィッシングサイト経由でヘッダーの値にスクリプトを入れるような)攻撃シナリオをご存じでしたら教えてください。
|