HUEの管理者の皆さん、こんにちは。
最近、HUEに多くのセキュリティオプションが追加されました。 これらは可能な限りデフォルトでオンになっています。
このドキュメントではいくつかの修正点について説明し、Hueの管理者が、HUEをインストールを実行して管理できるようにします。ブラウザがHUEのWebサーバーからページを要求するたびに、HUEはHTTP応答ヘッダーと共にコンテンツを返します。これらのヘッダーの中には、content-encoding、cache-control、ステータスエラーコードなどのコンテンツメタデータが含まれています。これらに加え、HUEのコンテンツを処理するときにブラウザにどのように動作するかを伝えるHTTPセキュリティヘッダーもあります。 例えば、strict-transport-securityを使用すると、ブラウザがHTTPS経由でのみ通信するように強制できます。
Content-Security-Policy: header
新しいContent-Security-Policy HTTPレスポンスヘッダーは、最新のブラウザーでXSSのリスクを軽減するのに役立ちます。これは、HTTPヘッダーを介してどの動的リソースがロードできるかを宣言することによって実現されます。（詳細について読む：https://content-security-policy.com/ ）
[desktop]
secure_content_security_policy="script-src 'self' 'unsafe-inline' 'unsafe-eval' *.google-analytics.com *.doubleclick.net *.mathjax.org data:;img-src 'self' *.google-analytics.com *.doubleclick.net http://*.tile.osm.org *.tile.osm.org *.gstatic.com data:;style-src 'self' 'unsafe-inline';connect-src 'self';child-src 'self' data:;object-src 'none'"
#HUE 3.11以降でデフォルトで有効
content-security-policy ヘッダーを無効にする場合は、次の値を使用します。 （自己責任において使用してください）
[desktop]
secure_content_security_policy=""
#(自己責任で使用してください)
動的リソースがHTTPヘッダーを介してロードすることを許可する宣言を無効にする場合、次の値を使用できます。 （自己責任で使用してください）
[desktop]
secure_content_security_policy="default-src 'self' 'unsafe-eval' 'unsafe-inline' data: *;"
#(自己責任で使用してください)
[
]1 ブロックされた画像コンテンツの例
Server: header
HUEは、Webサーバー情報の公開を最小限に抑え、Webサーバーのバージョンやその他の詳細に関する洞察を最小限に抑えます。 エンドユーザーからの変更は必要ありません。次のHTTP応答ヘッダーを生成します:
Server:apache
これらのHTTP応答ヘッダーは上記のセキュリティ修正の後に生成される
x-content-type-options:nosniff
X-Frame-Options:SAMEORIGIN
x-xss-protection:1; mode=block
Content-Security-Policy:script-src 'self' 'unsafe-inline' 'unsafe-eval' *.google-analytics.com *.doubleclick.net *.mathjax.org data:;img-src 'self' *.google-analytics.com *.doubleclick.net http://*.tile.osm.org *.tile.osm.org data:;style-src 'self' 'unsafe-inline';connect-src 'self';child-src 'self' data:;object-src 'none'
Strict-Transport-Security:max-age=31536000; includeSubDomains
Server:apache
X-Content-Type-Options: header
一部のブラウザは、取り込んだアセットのコンテンツタイプを推測し、Content-Typeヘッダーをオーバーライドします。 ブラウザがコンテンツタイプを推測することを防ぎ、常にContent-Typeヘッダーに指定されているタイプを使用するようにするには、X-Content-Type-Options：nosniffヘッダーを渡すことができます。
[desktop]
secure_content_type_nosniff=true
#HUE 3.11以降でデフォルトで有効
X-XSS-Protection: header
一部のブラウザでは、XSS攻撃のように見えるコンテンツをブロックする機能があります。 これらは、ページのGETまたはPOSTパラメータでJavascriptコンテンツを検索することによって機能します。ブラウザでXSSフィルタを有効にして、疑わしいXSS攻撃を常にブロックするようにするには、X-XSS-Protection: 1、 mode = blockヘッダを渡します。
[desktop]
secure_browser_xss_filter=true
#In HUE 3.11 and higher it is enabled by default.
[
]2 
上記のオプションで受け取った新しいヘッダの例
Strict-Transport-Security: header
HUEサイトでHTTPとHTTPSの両方の接続が提供されている場合、ほとんどのユーザーはデフォルトでセキュリティで保護されていない接続になります。最高のセキュリティを確保するには、すべてのHTTP接続をHTTPSにリダイレクトする必要があります。 HTTPSを介してのみアクセスする必要があるサイトでは、新しいブラウザーに「Strict-Transport-Security」ヘッダーを設定することにより、（一定期間）安全でない接続を介してドメイン名への接続を拒否するように指示できます。これにより、MITM（Man-in-the-Middle：中間者）攻撃を軽減します。 HUEでは、httpsが有効な場合、デフォルトでhttpsに切り替えることができるようになりました。
セキュアなビットセットでcsrftokenとセッションクッキーを提供
可能であれば、HUEは安全なビットセットでcsrftokenとセッションクッキーを配信するようになりました。安全なフラグが使用されると、CookieはHTTPS経由でのみ送信されます。
csrftokenはセキュアなビットを持つセッションクッキー
ワイルドカード証明書をサポート
Hueはワイルドカード証明書をサポートするようになりました。これは、ワイルドカード証明書と証明書の検証機能に欠けている機能をSANに追加します（subjectAlternativeName）。
_* .example.com_のワイルドカード証明書は、これらのドメインをすべて保護します:
- payment.example.com
- contact.example.com
- login-secure.example.com
- www.example.com
サブドメインの証明書を別々に取得する代わりに、すべてのメインドメインとサブドメインに対して1つの証明書を使用してお金を節約することができます。
ワイルドカードはサブドメインの1つのレベルのみをカバーするため（アスタリスクは完全な停止に一致しません）、これらのドメインは証明書に対して有効ではありません。:
- test.login.example.com
任意のホストヘッダーの受け入れの修正
Hueでは任意のホストヘッダ受け入れを修正しました。これで、Hueサーバーが提供できるホスト/ドメイン名を設定できます。
allowed_hosts=”host.domain,host2.domain,host3.domain”
[desktop]
allowed_hosts="*.domain"
# your own fqdn example: allowed_hosts="*.hadoop.cloudera.com"
# or specific example: allowed_hosts="hue1.hadoop.cloudera.com,hue2.hadoop.cloudera.com"
セッションストアを埋めることによるサービス拒否(DoS)の可能性を修正
Django CVE-2015-5143 http://www.cvedetails.com/cve/CVE-2015-5143/</a>
Djangoのutils.html.strip_tags関数がサービス拒否(DoS)になりうる問題を修正
Django CVE-2015-2316 http://www.cvedetails.com/cve/CVE-2015-2316/</a>