Search Result of csp

• 2022-09-30 XMLHttpRequest とはなんだったのか

  • 特に Ajax によるマッシュアップの隆盛が、 Origin を跨いだ連携を必要としながら、現実解が JSONP しかない状態は問題があったため、明示的に Origin を跨ぐ CORS が策定さていくことになるが、その仕様をそのまま HTML5 の仕様に追加していくのは実際かなり複雑だった。その後には、接続先を制限する CSP のマージも考えないといけない。
• 2021-12-08 Web のセマンティクスにおける Push と Pull

  • その価値は、 UI においては一層重要になる。Node.js でのプロセスは処理されなければプロセスが落ちるためすぐにわかるが、ブラウザは例外が捕捉されなかっただけでページをエラーにしたり、タブを落としたりすることはできない。また、ブラウザでどんなに例外が上がろうと、開発者は手元の `/etc/error.log` ファイルで監視できるわけでもなく、なんらかの方法で積極的に収集する必要がある。そうしたニーズに敏感なブラウザという環境は、 DevTools との Integration や CSP , Reporting などの標準を整備しつつあり、エコシステム側でもブラウザで起こっていることを知るためのサービスやツールが育ちつつある。
• 2021-01-31 Structured Field Values による Header Field の構造化

  • しかし、 Header Value の中身をどうパースするかは、それぞれのヘッダの仕様、ここでいう Cookie, CSP , Permission-Policy によって決められており、そのフォーマットはバラバラだ。
• 2020-12-25 AMP SXG 対応

  • 2020/12/23 20:04:15 Updating O CSP ; none cached yet.
  • 2020/12/23 20:04:15 Updating O CSP ; none cached yet.
  • 2020/12/23 20:04:15 Updating O CSP ; none cached yet.
  • 2020/12/23 20:04:15 Updating O CSP ; none cached yet.
  • 2020/12/23 20:04:15 Missing O CSP response.
  • github.com/ampproject/amppackager/packager/certcache.(*CertCache).readO CSP Helper
  • github.com/ampproject/amppackager/packager/certcache.(*CertCache).readO CSP
  • O CSP の情報が無いようだ。 Digicert で発行した証明書は自分のドメインのものと DigiCertCA.crt の 2 つがあったので連結したらいけた。
  • (最初、検証時に作らた `/tmp/amppkg-o csp ` の権限が起動ユーザのみに絞られており、 Systemd を別ユーザで起動すると既存のファイルにアクセスできずに失敗した。単純に消せばいい。)
• 2020-11-19 Web 技術の調査方法

  • 主にブラウザ API に関して策定される組織なため、 HTML や CSS から、 Service Worker や CSP といった様々な API が議論策定されている。ここは API が多岐にわたるため、探すのは少し慣れが必要だ。
  • 慣れない人に一番オススメなのは MDN の仕様へのリンクを見ることだ、例えば CSP のページを見てみるとこのように関連仕様へのリンクがまとまっている。
  • 
  • 
  • 例えば CSP で言うと、検索すると以下の様にいくつかの URL が見つかるかもしれない。
  • - https://www.w3.org/TR/2016/WD- CSP 3-20160913/
  • - https://www.w3.org/TR/ CSP 3/
  • - https://w3c.github.io/webappsec- csp /
  • CSP の場合は Feedback のところに `public-webappsec` と書かれていたが、これが W3C における Working Group になる。
• 2020-05-22 Site Isolation 及び Web のセキュリティモデルの更新

  • - `[SecureContext=Injection]`: CSP Strict + Trusted Types
• 2020-05-06 mozaic.fm v3 リリースと Podcast の PWA 化

  • - CSP v3 (not Report-Only)
  • blog.jxck.io の方に Analytics / Ad を入れたため、 3rd Party のコードが多く、 CSP の設定などもかなり複雑になった。
  • - CSP v3 (not Report-Only)
  • ### CSP v3
  • Origin ベースの CSP をやめ、 nonce と integrity ベースの CSP v3 に移行することにした。
  • ところが、 integrity ベースだと CSP のレポート収集を検証する点であまりうれしくない。
  • そこで、 CSP v3 のアンチパターンである固定 nonce でとりあえず導入することにした、値は integrity と同じである。
  • このサイト自体が CSP で防御するほど機能がないため、特に問題はないが、もし本番環境で導入する際は、必ず nonce を毎回ランダムに生成するようにするべきだ。
  • これも CSP の機能であり、特定の DOM API の操作を型によって保護する仕組みである。
  • 加えて CSP /Trusted Types を有効にした環境を Securer Context と定義し、そこではさらに強力な機能を有効にできるのではないかという提案がなされている。
• 2020-03-27 Scroll to Text Fragment を用いたサイト内検索の実装

  • このサイトを ` CSP ` というキーワードで検索した場合を考える。
  • > Feature Policy のモチベーションおよび適用方法について、類似する CSP や iframe sandbox と合わせて解説する。
  • #:~:text=Feature Policy のモチベーションおよび適用方法について、類似する-, CSP ,-や
  • サイト右上のアイコンから遷移するページから利用でき、キーワードとして CSP を検索した場合は以下のような URL になる。
  • - https://blog.jxck.io/searches?q= csp
  • - `CSP` が `O CSP ` という単語に部分的にヒットした場合
  • - `CSP-` や `# CSP ` のように、フラグメントで意味を持つ記号が続いてる場合
  • そして、多重防御として他のページとは別運用にし、 CSP などのヘッダをガチガチに固め、 Report-Only も外している。
• 2020-01-31 3rd Party Cookie 調査のための Web 広告導入

  • - CSP
  • - human.txt や ads.txt が CSP に違反するケース
  • - CSP や Feature Policy に 3rd Party Cookie などに関する directive が増えるのかどうか
  • - CSP 対応
  • ### CSP 対応
  • 本サイトでは、長らく CSP -Report-Only を運用している。
  • - [Content Security Policy( CSP ) 対応と report-uri.io でのレポート収集](https://blog.jxck.io/entries/2016-03-30/content-security-policy.html)
  • しかし、 nonce + strict-dynamic にしても、 AdSense のスクリプトが生成するどこかの `<script>` タグが CSP に違反してしまい、うまく適用ができなかった。
• 2020-01-18 ブラウザで何が起こっているのかを知る Reporting API と ReportingObserver

  • 筆者の観測では発端は CSP からだ。
  • CSP で定義したポリシーに違反があった場合、その原因をブロックすると同時に、違反があったことを知りたいという要望があった。でなければその問題に対して認識/対応ができないからだ。
  • そこで、 CSP ヘッダに指定するためのディレクティブとして、 Report を送信する先を指定する `report-uri` が定義された。
  • CSP は JS の実行をブロックする場合があるので、その Report は JS で収集するより、ブラウザが直接送信する方が理にかなっている。
  • 上記の例は、 endpoint を 1 つ持つ `default` グループと、 CSP 用に 2 つのエンドポイントを持ち、負荷分散とフェイルオーバーを構成した `cap-endpoint` の 2 つがある。
  • CSP や Feature-Policy は、明示的に Report-To を指定する。
  • つまり、 CSP や Crash ではなく deprecation/intervention など軽微な Report を取得する。
  • ### CSP Violation
  • 以前から report-uri/report-to で対応していた CSP の violation も、 ReportingObserver で取得できるようにする Intents が出ているが特に進んではいないし、 Report-To で集めれば良い。
  • - [Intent to Implement and Ship: CSP violation reports observable by ReportingObserver](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/dBc_epXL-r4/XhhajwQVBQAJ)
  • 例えば、本サイトでは [CSP Report を 4 年ほど収集](https://blog.jxck.io/entries/2016-03-30/content-security-policy.html) しているが、ほぼ純粋な静的サイトであるにも関わらず、日々かなりの CSP Report が日々送られてくる。
  • - 全部入れず CSP など効果のあるところから入れるのも手
• 2019-01-27 安全な文字列であると型で検証する Trusted Types について

  • ## CSP trusted-types
  • TrustedTypes は CSP により Opt-In で利用する。
  • 先のように `createPolicy('application-policy')` で定義した Policy を利用するためには、必ず CSP に「利用を許可する Policy の名前」の指定が必要だ。
  • これをしなければポリシーを利用した時点で CSP エラーとなる。
  • // CSP で dummy が定義されていなければ使えない
  • ここで定義した Policy 名の `dummy` は、 CSP で指定されていないため使うことができない。
  • CSP で有効にした時点で、対象となる全ての処理にフックが入る設計となっている。
  • 対応すれば、 CSP Report Only でもデプロイできるようになることが想像されるため、導入の敷居は下がるだろう。
  • ### CSP 無効での利用
  • CSP によって有効になるのは、型が違う場合にエラーをあげることだけだ。
  • つまり Policy のメソッドを経由して DOMString を TrustedTypes に変換することは、 CSP で有効にしなくても可能だ。
  • 他の CSP と同様 TrustedTypes をデプロイすることは、多くの拡張や bookmarklet などの DOM への介入を一括して阻害する可能性がある。
  • 従って他の CSP と同様に、テストやステージングで有効にし、違反が無いかを Reporting などで検出する、対応したら Report-Only でデプロイすることで様子を見るのがしばらくは良さそうに感じた。
  • あとは、ビルド時の静的な型検査、ステージングなどでのランタイム検査の恩恵を受ければ、 CSP Report Only や off でデプロイでも一定の効果は予想され、当面はそこが現実的な気もする。
• 2018-12-01 WebPackaging の Signed HTTP Exchanges

  • ファイルは CBOR 形式で、証明書チェーン、 O CSP 、 SCT を含む必要がある。
  • # 本来は o csp の指定が必要だが、自己証明書なので適当な値を指定する
  • echo "o csp " > tmp
  • ./bin/gen-certurl -pem cert.pem -o csp tmp > cert.cbor
• 2018-10-26 Cookie の性質を利用した攻撃と Same Site Cookie の効果

  • [[ CSP 3] Suggestion for COOKIE directive](https://lists.w3.org/Archives/Public/public-webappsec/2018Oct/0029.html)
• 2018-07-18 Monthly Web の作り方 2018 年版

  • - セキュリティ対策ヘッダ( CSP etc)
• 2018-03-27 Certificate Transparency の仕組みと HPKP から Expect-CT への移行

  • ### O CSP
  • O CSP の情報に SCT を含む方式。これも CA 側の対応が必要。
  • [Include SCT receipts in O CSP responses #592](https://github.com/letsencrypt/boulder/issues/592#issuecomment-262036049)
  • Expect-CT のディレクティブは、基本的に CSP と同じような設計になっている。
  • - `report-uri`: CSP レポートの送信先
  • また、他の CSP のように `Expect-CT-Report-Only` は定義されておらず、 `enforce` を付けずに `report-uri` のみとすれば、レポートだけが飛ぶ。
  • 百歩譲って、 SCT を「透かし」と捉えることもできなくはないかもしれないが、 SCT は証明書に埋め込むだけでなく、ハンドシェイクや O CSP で渡しても良い。
• 2018-03-08 Feature Policy による Permission Delegation

  • Feature Policy のモチベーションおよび適用方法について、類似する CSP や iframe sandbox と合わせて解説する。
  • それを踏まえた上で、類似する API である iframe sandbox とその CSP 版も合わせて、これら API について解説する。
  • ## CSP
  • これを HTTP ヘッダで適用できるように、 CSP 2 では sandbox ディレクティブが追加された。
  • - https://w3c.github.io/webappsec- csp /#directive-sandbox
  • まず、他の CSP ディレクティブと違い、「何をブロックしたい」というブロックリストではないため Reporting の対象では無い。
  • CSP のように、ブロックリスト方式を取っていれば、制限したい項目を増やしオプトインで適用していけるため、拡張に対して開いた設計となるのは、後から判明したのだろう。
  • 設定する際は、 CSP の sandbox を基準とし、許可したいものを `allow-*` で、追加で制限したいものを Feature Policy で行うことになるだろう。
• 2017-12-31 2017 年を振り返る

  • - [CSP powerful security steroid](https://speakerdeck.com/jxck/ csp -a-powerful-security-steroid) @ [#chromejp](https://developers-jp.googleblog.com/2017/01/chrome-tech-talk-night-9.html)
  • - [CSP real world reporting](https://speakerdeck.com/jxck/ csp -and-real-world-reporting) @ [#rtechnight](https://atnd.org/events/85028)
• 2017-02-21 Monthly Web 2017/02

  • - CSP レポートは kibana とかの方がいいね、 report-uri.io はダメだ。
  • - 1/31: [Security and Frontend Performance](http://www.oreilly.com/webops-perf/free/security-and-frontend-performance. csp )
  • - Web のパフォーマンスとセキュリティをあえて一緒に扱う書籍。 CSP , HSTS, ResourceHints, SW など
• 2017-02-13 CSP Report 収集と実レポートの考察

  • # [csp][security] CSP Report 収集と実レポートの考察
  • このブログで CSP レポートの収集を開始してもうすぐ 1 年になる。
  • 今回は、収集した実際のレポートを例に、攻撃ではないと思われるレポートとしてどういったものが送られて来たかを中心に、その内容やレポーティングサーバ、 CSP の運用に関する現時点の考察についてまとめる。
  • CSP の基本は、意図しないリソースの読み込みや、 Inline Script の実行を防ぐことにある。
  • しかし、本質的な CSP の責務は「*ポリシーに照らし合わせた違反のブロック*」であり、その「*ポリシーの違反が攻撃とは限らない*」という点には注意が必要だ。
  • 実装によっては、これらがサーバ側で定義された CSP ポリシーに違反する場合もあるだろう。しかし、だからといってこれらをブロックしてしまっては、ユーザに不便を強いる可能性がある。
  • しかし、実際どういったポリシーがどういったユーザに不便を強いる可能性があるのかは、 CSP をデプロイしてみないとわからない。
  • そこで、比較的に技術リテラシーの高いユーザが閲覧していると予想される本サイトに対して、去年の 3 月から CSP を適用しレポートの収集を実施することにした。
  • [Content Security Policy( CSP ) 対応と report-uri.io でのレポート収集 | blog.jxck.io](https://blog.jxck.io/entries/2016-03-30/content-security-policy.html)
  • つまり、このサイトで収集した CSP 違反のレポートは、ほとんどが設定ミスかユーザの閲覧環境に起因するものであるだろうと推測できるため、ここから、リアルワールドにおいて本質的に攻撃では無いポリシー違反がどの程度発生するのかを知る上で参考になると考える。
  • `labs.jxck.io` だけは( CSP に違反するデモを含む)、脆弱性デモを含む様々なデモを置いているため、対象外として扱う。
  • CSP は全て Report-Only で HTTP ヘッダから適応しており、 CSP レポートを収集している。
  • report-uri https://jxck.report-uri.io/r/default/ csp /reportOnly
  • 以下が CSP をデプロイしてから、今月までのレポート発生のグラフである。
  • 
  • 一例として、以下のレポートは、 CSP の指定範囲外オリジンから jQuery を埋め込んだことによるレポートと思われる。
  • " csp -report": {
  • " csp -report": {
  • 
  • " csp -report": {
  • これはもちろん悪意のあるポリシー違反でないため、本サイトではこの種のコンテントタイプのページへは CSP を適用しないこととした。
  • Firefox ではソースを表示すると、オリジンが `view-source://~` となるため、このページが CSP 違反となりレポートが上がる。
  • 
  • " csp -report": {
  • CSP のレポート収集サービスとして、 [report-uri.io](https://report-uri.io) がよく紹介され、本サイトでもこれを用いてレポートを収集していた。
  • - 意図しないリクエストを `content-type: csp -report` で間引きたくなるが、[準拠してないクライアント](https://www.tollmanz.com/content-security-policy-report-samples/) もあるようなので注意が必要
  • report-uri から report-to への変更で、 CSP 以外も含めたレポート送信が Reporting API に統合される。
  • CSP によるブロックは、かなり堅牢な防御となる一方、多くのユーザに影響を与えるもろ刃の剣でもある。
  • それでも、 [github](https://github.com) や [twitter](https://twitter.com) は既に Report-Only 無しで CSP を運用しているため、ユーザのフィードバックを反映しながら、ポリシーの精度を向上し徐々に適用していけば、 Report-Only なしの運用も決して無理ではないだろう。
  • そこで、 Report-Only を外すことを目的にポリシーを緩めるのではなく、厳しい CSP を Report-Only で運用する方針も決して無くはないだろう。
  • そもそも CSP は、それのみで攻撃を防ぐのでは無く、従来通りのセキュリティ対策を行った結果、意図せぬ漏れを埋めるために追加で行う対策である。
  • - [CSP による防御とリアルワールドレポート収集](https://speakerdeck.com/jxck/ csp -and-real-world-reporting)
  • - [CSP a Powerful Security Steroid (上の拡充版)](https://speakerdeck.com/jxck/ csp -a-powerful-security-steroid)
• 2017-01-27 Monthly Web 2017/01

  • - [bugzilla.mozilla.org が CSP 適用予定](https://emceeaich.dreamwidth.org/201211.html)
• 2017-01-10 mixed contents 対応を促進する CSP ディレクティブ

  • # [csp][mixed contents][upgrade-insecure-request][block-all-mixed-contents] mixed contents 対応を促進する CSP ディレクティブ
  • 本エントリでは mixed contents の正しい理解と、その検出や解消に利用できる可能性のある、 CSP の `Upgrade-Insecure-Request` および、 `Block-All-Mixed-Contents` を解説する。
  • ## CSP による Mixed Contents 対策
  • Mixed Contents に対して、対策となりえる CSP のディレクティブを解説する。
  • CSP の `Upgrade-Insecure-Request` を付与した場合、ブラウザは HTTPS コンテンツに埋め込まれた `http://` スキームのリンクを、 `https://` に読み替えて発行する。
  • この場合は、 CSP の `Block-All-Mixed-Contents` を有効にすることで、 Passive でも Active 同様にブロックし、改ざんされたコンテンツが表示されることを防ぐことができる。
  • また、 CSP の reporting に対応しているため、 block が発生した場合にそのことを指定した URI にレポートすることができる。
  • CSP のいくつかは、こうした問題への対応や、状況を把握することによるリスクの分析を可能にする。
• 2016-04-09 Public Key Pinning for HTTP(HPKP) 対応と report-uri.io でのレポート収集

  • [ CSP ](https://blog.jxck.io/entries/2016-03-30/content-security-policy.html) 同様、まずは Report-Only を設定し、
  • `report-uri` には CSP 同様 [report-uri.io](https://report-uri.io) を設定する。
  • 今回はあくまで実験であるため、 CSP 同様に Report-Only での運用とする。
  • ということで CSP と違い、よほどのことがない限りレポートは上がらないはずであると考える。
• 2016-03-30 Content Security Policy(CSP) 対応と report-uri.io でのレポート収集

  • # [csp][security] Content Security Policy( CSP ) 対応と report-uri.io でのレポート収集
  • CSP Report については、 [report-uri.io](https://report-uri.io) を用いて収集することにした。
  • Content Security Policy( CSP ) とは、 Web におけるセキュリティを向上させる非常に強力な仕組みである。
  • - [Content Security Policy Level 2](https://www.w3.org/TR/ CSP /)
  • - [draft-gondrom-websec-csp-header-00 - HTTP Header Content Security Policy](https://tools.ietf.org/html/draft-gondrom-websec- csp -header-00)
  • ## CSP の設定
  • CSP を有効にするには、 Content-Security-Policy ヘッダを付与し、その引数にポリシーを指定する。
  • [CSP におけるポリシーのディレクティブ - Web セキュリティ | MDN](https://developer.mozilla.org/ja/docs/Web/Security/CSP/ CSP _policy_directives)
  • ## CSP の注意点
  • Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://example.com/ csp -report
  • ブラウザは、 CSP に違反した実行を検出した場合、違反レポートを生成し `report-uri` に指定した URI に対して自動的に送信する。
  • CSP の違反レポートは以下のような JSON データである。
  • " csp -report": {
  • content-security-policy-report-only: default-src 'self' https://*.jxck.io https://www.google-analytics.com ; child-src https://www.youtube.com ; report-uri https://xxx.report-uri.io/r/default/ csp /reportOnly
  • content-security-policy-report-only: default-src 'self' https://*.jxck.io https://www.google-analytics.com https://cdn.ampproject.org ; style-src 'unsafe-inline' ; report-uri https://xxx.report-uri.io/r/default/ csp /reportOnly
  • 今後も収集したレポートを解析、それを元にコンテンツやポリシーの修正を実施し、ある程度影響が見えてから実際の CSP の適用を再検討したいと考えている。