Content Security Policy 適用後の経過を観察する 2017年11月
投稿者: kem / 右記内 security / 投稿日:2017-11-23 ( 6 年, 7 ヶ月 ago) / 更新日:2017-11-23 ( 6 年, 7 ヶ月 ago) / コメント このブログに過去、Content Security Policy を reports-only で適用しました。 前回 ポリシーを変更してから3-4ヶ月が経過しましたので、再度レポートを集計し、定義を見直していきます。 結果を以下に記載します。 [TOC] 前回変更時の記事AMP HTML を作成後に、Content Security Policy (CSP) の report を 集計して、ポリシーを見直す | Monotalk 現在のポリシー定義 Content-Security-Policy-Report-Only: script-src 'self' 'unsafe-inline' 'u
Content-Security-Policyやらsubresource integrityなどに関するメモ - Sexually Knowing
最近、セキュリティに特に気をかけなければいけないサービスの開発をしていて調べた知見のメモ。 subresource integrity Subresource Integrity - Web security | MDN いわゆるチェックサムの仕組み。 integrity 属性に ${hashalgorithm}-${hashdigest} 形式の値を書いておき、フェッチしたファイルのハッシュ値が一致していなければブラウザが読み込みをブロックする。 これは、たとえばCDNが攻撃されるなどしてスクリプトなどが改竄された場合に有効。 JSやCSSはプリ・ポストプロセッサで処理し出力することがほとんどだろうが、subresource integrityとどうやって統合するかというとgulp-hashsumを使ってコンパイルしたファイルのハッシュ値をdigest.jsonに保存し、HTMLのレンダ
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
How HTML Injection Is Bad on Firefox OS
1101158.md How HTML Injection Is Bad on Firefox OS 「Firefox OS Advent Calendar 2014」と「脆弱性"&'<<>\ Advent Calendar 2014」の12月20日の記事です。 先月報告したFirefox OSのHTMLインジェクションバグ(Bug 1101158 )について紹介します。このバグはFirefox OS Simulatorを含む一部の環境ではまだ修正されていませんが、リスク評価の上、Mozillaよりちょうど本日(！！)、公開の許可を頂き掲載しております。 HTML Injection on Firefox OS (Bug 1101158) Firefox OS v2.1/v2.2には、端末のホームボタンを長押ししたときに表示されるカードビューに、HTMLインジェクションの可能な箇所がありま
CSP Lv.2の話
#ssmjp 2014/10 XSSの運用の話 間違いなどありましたら @yagihashoo まで。 ## 10/28 9:26追記 nonce-value、規格上はBase64だよ！という指摘をいただいたのでスライド18-19を修正しました。 詳細は以下をご覧ください。 http://www.w3.org/TR/CSP2/#source-list-valid-nonces ## 10/29 15:00追記 Path matchingの例示について間違いがあったためスライド14を修正しました。Read less
AVTOKYO 2014で「CSPが切り開くWebセキュリティの未来」という題で話してきた - 葉っぱ日記
AVTOKYO2014で、にしむねあさんといっしょに「はせむねあ」というユニット名でContent-Security-Policyをテーマに話をしてきました。 Future of Web Security Opened up by CSP from Muneaki Nishimura 内容はスライドのとおりで、攻撃者はFiddlerなどを使って任意のCSP違反レポートJSONを送信可能であること、Firefoxの場合にはCSP違反レポートのJSON内に「<」「>」などが含まれるので、違反レポートを表示する管理画面でのエスケープ漏れがあると違反レポートを通じて管理画面内でXSSする、などの話を行い、実際に管理画面でのXSSのデモを行いました。 デモはあんまり細かいことは考えてなかったんですが、アドリブ苦手なにしむねあさんがいい味を出してて、横で見ていても楽しかったです。ちなみに直前の打ち合わ
そろそろCSP Lv.2 nonceやろう - teppeis blog
tl;dr CSP Lv.2のnonceを使うと意外と簡単にCSPの恩恵を受けれるよ Firefoxはunsafe-inlineとの挙動がおかしいので注意 サンプル実装としてExpressで簡単にnonce対応できるconnectプラグインを書いた（デモあり） Violation Reportもブラウザによって細かい挙動の差異があるよ CSP Lv.2 nonceの登場と背景 CSPの特にunsafe-inlineはXSSに対して最終防衛線的に強力な効果がある。 しかし特にサーバーからの値の受け渡し部分などでどうしてもinline scriptを使いたくなるところがあり、unsafe-inlineを禁止するとDOM data等を使わざるを得ず、つらい感じだった。 @kazuho ですね。かといってDOM dataかー、、という感じではあるんですが、CSPでinline script禁止しち
Content-Security-Policy と nonce の話 - tokuhirom's blog
Content-Security-Policy の nonce を利用すると、XSS の脅威をかなり軽減できます。 そこで、Web Application Framework ではデフォルトで対応したほうがよいのではないか、という旨を @hasegawayosuke さんから教えて頂いたので、実装について考えてみました。 とりあえず CSP の nonce はどういうものなのかを考慮するために、コード例を探していたのですが、実際に動くサンプルというものが nonce 関連のもので見当たりませんでした。 そこで、実際に動くサンプルを用意しました。 https://github.com/tokuhirom/csp-nonce-sample 以下は Sinatra で書かれたサンプルコードです。 require 'sinatra' require 'securerandom' get '/' d
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
弊社のホームページにContent Security Policy(CSP)を導入しました
弊社のホームページにCSP(Content Security Policy)を導入しました。CSPについては、はせがわようすけ氏のスライド「5分でわかるCSP」がわかりやすいと思います。以下にスライドの一部を引用します。 具体的には、以下のように指定して使います。 Content-Security-Policy: default-src 'self' この結果、以下のようにJavaScriptの記述が制限されます。 外部のJavaScriptの読み込みは禁止 HTMLソースに記述した<script>...</script>のJavaScriptは禁止 イベント属性(onload="xxxx"など)は禁止 何も書けなくなるじゃないかと思われるかもしれませんが、JavaScriptは全て*.jsファイルに記述すればよい、ということです。 CSPは、JavaScriptのコードとデータを分離して
GitHub - github/secure_headers: Manages application of security headers with many safe defaults
SecureHeaders::Configuration.default do |config| config.cookies = { secure: true, # mark all cookies as "Secure" httponly: true, # mark all cookies as "HttpOnly" samesite: { lax: true # mark all cookies as SameSite=lax } } # Add "; preload" and submit the site to hstspreload.org for best protection. config.hsts = "max-age=#{1.week.to_i}" config.x_frame_options = "DENY" config.x_content_type_option
Firefox、XSS攻撃防止へ W3Cの仕様に対応
Firefoxがクロスサイトスクリプティング（XSS）やデータインジェクションなどの攻撃を防ぐための「Content Security Policy 1.0」をサポートした。 米Mozilla Foundationは6月11日、Webサイト経由の攻撃阻止を目的とした仕様「Content Security Policy（CSP） 1.0」をWebブラウザのFirefoxに実装したと発表した。 CSPは、クロスサイトスクリプティング（XSS）やデータインジェクションなど、攻撃の常套手段として使われる手口を検出して軽減するために使われる。仕様が確定する前段階のCSPは2011年3月からFirefox 4.0に実装されていた。 2011年11月にはW3CがCSP 1.0の草案を策定し、1年後に勧告候補の段階に到達。GoogleのChromeは2013年にリリースしたChrome 25でこれをサポー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - brianmhunt/knockout-secure-binding: Use Knockout without unsafe-eval / content security policy
GitHub - yandex/csp-reporter: Content Security Policy logs parser