【翻訳】強度の弱い暗号をまだ利用している支払いサービス事業者
この記事は、2016 年 2 月 24 日付で Mozilla Security Blog に投稿された Payment Processors Still Using Weak Crypto（筆者: Richard Barnes）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。
Web を保護する活動の一環として、Mozilla は Web PKI のガバナンスに参加しています。Web PKI とは、ブラウザが Web サイトを認証できるようにするセキュリティ証明書の仕組みです。Mozilla は 他のブラウザや Web におけるステークホルダー とともに、証明書の発行手続に関する 標準 に同意します。これから私たちはこの標準を適用し、加えて Mozilla 独自のポリシー も追加します。このポリシーは Firefox が信頼する「ルート」から（直接・間接にかかわらず）発行された証明書すべてに適用されます。
パブリックなインターネット上で支払情報を交換する支払いサービス事業者の中には、サーバと支払端末の間に安全な通信路を確保するために Web PKI 証明書（Firefox の信頼するルートまでチェインがつながっている証明書など）を利用していることがあり、これまで私たちはこのような事業者を紹介してきました。残念ながら、ブラウザ以外の Web PKI ユーザの中には、Web の獲得したセキュリティの向上に追いつけていないものがあります。（証明書の完全性を確認するために用いる）SHA-1 ハッシュアルゴリズムは、Web PKI における利用を廃止することが宣言されましたが、そのような事業者はデバイスを更新できておらず、代替の SHA-2 がサポートされていません。なお、SHA-1 の利用期限は昨年に決定されたものです。この結果、支払サービスに関係する多くのデバイスは、サービスを運用させるために SHA-1 の証明書をサーバに要求し続けています。
特に Worldpay PLC の場合、自身が利用する認証局の Symantec を通じて、限られた数の SHA-1 証明書を発行する権限の認可を Mozilla に要請しました。この証明書は多くの古いデバイスをサポートするために必要ですが、Mozilla の同意する標準に違反しています。また、この要請があったのは、認可を必要とする日まで 2 週間を切っているタイミングでした。dev.security.policy のメーリングリストで議論 を重ねた結果、これらのデバイスを利用するユーザの混乱を防ぐため、証明書の発行を例外的に 許可 するよう決定しました。ただし、SHA-1 証明書の発行に完全な透明性を確保し、SHA-2 への移行を目的としていることを条件としました。
この認可により、Worldpay のデバイスを長く運用させるため SHA-1 証明書が Symantec から発行できるようになり、Mozilla はその証明書発行を欠陥と扱わなくなります。この決定は Mozilla のルートプログラムのみに影響を与えるため、他のルートプログラムでは誤った証明書発行と扱われる可能性があります。
Web PKI を利用するしないにかかわらず、Worldpay の他にも同じく SHA-1 を必要とし続ける支払いサービス事業者がいることは把握しています。こういった団体が強度の弱い時代遅れのセキュリティ技術を利用することで、一般市民のデータがリスクにさらされてしまうのは残念でなりません。Web PKI で SHA-1 を必要とし続ける団体には、可能な限り状況が改善されるよう働きかけを行い、SHA-2 への移行策をできるだけ詳しく提供していきます。
【翻訳】現実の Web に向けた CSP
この記事は、2014 年 10 月 4 日付で Mozilla Security Blog に投稿された CSP for the web we have（筆者: Mark Goodwin）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。
イントロダクション
Content Security Policy (CSP) は、クロスサイトスクリプティング（XSS）を防ぐセーフティネットに適したものです。実際、CSP はとても良く作られており、新しい Web サイトの構築時には CSP をぜひ導入してほしいと思います。
CSP を導入するとデフォルトの制約がいくつか適用されるため、既存の Web サイトに CSP を導入するのは難しい場合があります。また、このような制約を考慮せずにコードが書かれていた場合でも、導入には労力が必要となってしまいます。これらの問題に対する回避策は確かに存在しますが、ポリシーを適用して得られる利益が回避策によって損なわれてしまい、本末転倒になりかねません。とりわけ、インラインスクリプトには注意が必要です。インラインスクリプトはよく使われていますが、もしポリシーでそれを許可してしまうと、もはや CSP の主な利益を享受することはできません。これまで CSP を効果的に利用するには、コードを書き直して既存のインラインスクリプト・スタイルを削除するしかありませんでした。
CSP を既存の Web サイトに適用する労力に最初は驚くかもしれませんが、その労力に見合うほどの利益をセキュリティに得ることができます。幸いにも、CSP 2 では既存サイトへの導入が容易になりました。
CSP 2 の機能
CSP 2 では hash-source と nonce-source という、本当に便利な機能が提供されています。これらの機能を用いると、コンテンツを差し込む隙を攻撃者に与えることなく、インラインのスクリプト・スタイルを使用できるようになります。
それではまず nonce-source の動作を確認してみましょう。
nonce-source を用いた CSP は次のような形をとります。
content-security-policy: default-src 'self'; script-src 'nonce-2726c7f26c'
そして対応するドキュメントには以下の script 要素が含まれています。
<script nonce="2726c7f26c"> alert(123); </script>
ここで注意すべきことが 2 つあります。1 つ目はレスポンスごとに nonce の値を変えることが重要だということ（先程の例では値が変わりません！）、2 つ目は nonce に対する予測困難性が重要だということです。
nonce は予測できない方法で変更されるため、攻撃者はどの値を nonce に入れればよいか分かりません。そのため、正しい nonce を持った script (style) 要素だけを許可することができ、コンテンツが差し込まれていないことを保障できるのです。
さて hash-source はどうでしょうか？先程と同様に、ドキュメント内の script 要素や style 要素が、CSP に指定された source と一貫性を持っていることが保障されます。しかし、動作の仕組みは異なります。hash-source の場合はドキュメント内の script 要素に属性値を指定せずに、許可したい script 要素のハッシュ値を計算し、その値を CSP の中に指定します。
従って次のような script 要素の場合、
<script> alert(123); </script>
hash-source を用いた CSP は次のような形をとります。
content-security-policy: script-src 'sha256-cLuU6nVzrYJlo7rUa6TMmz3nylPFrPQrEUpOHllb5ic='
すぐ分かるように、ドキュメントに含めたいスクリプト・スタイルのそれぞれについて hash-source を追加する必要があります。
どちらを使うべきか（そして使うタイミング）
ここで、なぜ 2 つの仕組みがあるのか（インラインのスクリプト・スタイルを許可するに際して、どのような場合を意図して設計されているのか）疑問に思うかもしれません。どちらを使えばよいのか悩むかもしれません。実際、これらのテクニックはインラインスクリプトを取り除くことができないケースのみを意図しているため、どんな場合でもこの仕組みを使おうとするのは避けるべきです。
nonce-source はシンプルなため、ほとんどの場合で nonce-source のほうが便利でしょう。インライン要素が数多く存在する場合でも、ポリシーに追加する source は 1 つだけで十分です。反対に欠点としては、nonce は一度だけしか使ってはいけないため、ページがロードされるたびに新しいヘッダ（と新しいドキュメント）を生成する必要があります。従って、動的に生成されるページに nonce-source は適していますが、静的なコンテンツには全く適していません。
hash-source はより複雑です。許可したいすべての要素ごとにハッシュ値を計算する必要があり… とはいえ、ハッシュ値は攻撃者に知られても問題ないため、毎回 CSP と script 要素に変更を加える必要がありません。従って、hash-source は静的なコンテンツを保護するのに役立つ仕組みといえます。
利用上の注意
これらの機能を動的に生成されたコンテンツに用いる際は気を付けてください。なぜなら、nonce 属性を設定した（または hash-source を計算する元となった）要素内に攻撃者がコンテンツを差し込めた場合、攻撃者はどのような制限も回避できてしまうからです。
機能上の制約
CSP によるインラインスクリプトの制限は、スクリプトを値にとる属性（DOM Level 0 イベントハンドラで通常用いられる onclick など）も含まれ、hash-source と nonce-source はこれらに対応できません。現在の CSP では属性値のスクリプトにディレクティブを適用できませんが、今後の動向に注目しましょう！
【翻訳】Mozilla Winter of Security-2015 MozDef: Virtual Reality Interface
この記事は、2016 年 2 月 5 日付で Mozilla Security Blog に投稿された Mozilla Winter of Security-2015 MozDef: Virtual Reality Interface（筆者: Jeff Bryner）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。
Mozilla では毎年 Winter of Security (MWoS) を開催しており、現在も開発が続けれらているセキュリティプロジェクトに対して、参加者の皆さんがコントリビュートするというイベントです。今年のグループは意欲的なテーマに取り組み、Mozilla が MozDef: The Mozilla Defense Platform と呼んでいる Elastic Search 用 SIEM オーバレイに、新しい視覚インターフェイスを構築 する ことがテーマとなりました（SIEM: Security Information Event Management）。
セキュリティ担当者には高いレベルの内容が要求されますし、アナリストのスキルセットもそのレベルを維持し続けるのは困難です。それゆえ私は、人々のセキュリティを向上させることに専念するのみならず、むしろセキュリティを人間の感覚に近づけることも必要だと固く信じています。今回のテーマ「分かりやすさと使いやすさを両立したインターフェイス」に投資する価値はあるでしょうし、このチームが制作した作品に私はとてもわくわくしています。
参加者の皆さんは、作品の素晴らしいデモンストレーションを発表してイベント全体を終えました。もしセキュリティの自動化ツールや代替のユーザインターフェイスに興味をお持ちになったら、air mozilla で彼らの成果をぜひご覧ください。
