舞台裏

Qiita が表でこっちが裏。こっそりやっていく。

20.1.6 X-XSS-Protection

正しさの保証なんてものは(ry

20.1.6 X-XSS-Protection

Some browsers have built in support for filtering out reflected XSS attacks.

いくつかのブラウザは Refrected XSS 攻撃を回避する組み込みのサポートを持っています。

※Referected XSS 攻撃
反射型 XSS 攻撃。リクエスト中に含まれるコードがそのまま実行されるケースの XSS 攻撃。

This is by no means foolproof, but does assist in XSS protection.

これは決して簡単ではないが、 XSS の防御を補助します。

The filtering is typically enabled by default, so adding the header typically just ensures it is enabled and instructs the browser what to do when a XSS attack is detected.

絞り込みは通常デフォルトで有効になっています。よって、ヘッダーを追加すると、 XSS 攻撃が検出された場合に何をすべきかをブラウザに指示します。

For example, the filter might try to change the content in the least invasive way to still render everything.

たとえば、フィルタは、最も侵襲的な方法でコンテンツを変更して、すべてをレンダリングしようとする可能性があります。

At times, this type of replacement can become a XSS vulnerability in itself.

時には、この種の置き換えはXSS脆弱性となることがあります。

Instead, it is best to block the content rather than attempt to fix it.

代わりに、コンテンツを修正しようとするのではなく、ブロックするのが良い。

To do this we can add the following header:

これには次のヘッダーを追加します。

X-XSS-Protection: 1; mode=block

This header is included by default.

このヘッダーはデフォルトで含まれています。

However, we can customize it if we wanted. For example:

しかしながら、私たちは任意にカスタマイズができます。たとえば、

<http>
    <!-- ... -->

    <headers>
        <xss-protection block="false"/>
    </headers>
</http>

Similarly, you can customize XSS protection within Java Configuration with the following:

同様に、次のように Java Configuration で XSS 保護をカスタマイズできます。

@EnableWebSecurity
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
    // ...
    .headers()
        .xssProtection()
            .block(false);
}
}