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という仕様が提案されて
【セキュリティ ニュース】プロクシー利用時に影響受ける脆弱性「FalseCONNECT」 - OS XやiOSは修正済み（1ページ目 / 全2ページ）：Security NEXT
プロクシー経由でインターネットへアクセスする際に、中間者攻撃を受けるおそれがある脆弱性が「FalseCONNECT」として公表された。WebKitを用いるブラウザでは、任意のスクリプトを実行されるおそれがあるという。 セキュリティ研究者のJerry Decime氏が公表したもの。 同氏によれば、プロクシーにおける認証機能の実装に問題があり、プロクシ経由で接続する際に認証情報を詐取されるおそれがあるという。 同氏は今回の脆弱性について「FalseCONNECT」と名付け、ウェブサイトを公表した。 具体的には、HTTPS通信においてもプロクシーに対する接続要求「HTTP CONNECT」が平文で送信されるため、アクセス先が秘匿されないほか、さらに平文により応答があり、これを「HTTP 407 Proxy Authentication Required」へ置き換えることで、認証情報を詐取するマン
httpoxyでAffected指定されているけどPoCが無いフレームワークで再現試験をした話
はじめまして。HASHコンサルティングでエンジニアをしている一ノ瀬と申します。 ご存知の通り、現在HASHコンサルティングは現在も積極的にセキュリティエンジニアを募集しています。従業員も少しずつ増えてきましたので、今回の投稿から弊社の代表である徳丸と共に従業員もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。 というわけで、従業員の投稿第1弾は2016/7/19に公開され話題となったhttpoxyの話です。 httpoxyは警視庁による注意喚起もされており、非常に注目を集めています。 “[PDF] CGI 等を利用するウェブサーバの脆弱性（httpoxy）を標的としたアクセスの観測について - 警察庁 (平成28年７月20日)” https://t.co/DE7LG7MwQC — 徳丸 浩 (@ockeghem) 2016年7月20日
米Google、検索サイトに「HSTS」実装 危険URLを自動変換
HSTSではインセキュアなHTTP URLを自動的にセキュアなHTTPS URLに変換することによって、ユーザーによるHTTP URLの参照を防止する。 WebサイトのHTTPS接続を推進している米Googleは7月29日、転送中のデータの保護を一層強化する目的で、「www.google.com」のドメイン上で「HTTP Strict Transport Security」（HSTS）を実装したと発表した。 Googleによると、HSTSではインセキュアなHTTP URLを自動的にセキュアなHTTPS URLに変換することによって、ユーザーによるHTTP URLの参照を防止する。ユーザーはアドレスバーにHTTPのURLを入力したり、他のWebサイトのHTTPリンクをたどったりして、そうしたHTTP URLにアクセスしてしまうことがあるという。 「転送中のデータの暗号化は、ユーザーやユーザー
「httpoxy」の脆弱性発覚 PHP、Go、PythonなどのCGIアプリに影響
PHP、Python、Goを使ったCGIベースのアプリケーションで脆弱性が確認されたほか、影響を受ける恐れのある多数のアプリケーションがあると推定される。 PHP、Go、Pythonなどの主要なプログラミング言語に影響するCGIアプリケーションの脆弱性が発覚した。発見者はこの脆弱性を「httpoxy」と命名し、7月18日に詳しい情報を公開。悪用は極めて簡単とされ、米セキュリティ機関もパッチまたは回避策の適用といった対策を直ちに講じるよう呼び掛けている。 httpoxyの情報サイトや米CERT/CC、SANS Internet Storm Centerなどによると、この問題はWebアプリケーションにおけるHTTP「Proxy」ヘッダの不適切な使用に起因する。CGIまたはCGIのようなコンテキストで運用されているWebサーバでは、クライアントにリクエストされたHTTP Proxyヘッダが「HT
「常時SSL」の疑問に答えよう、どうすればできるか
簡単に解説すると、安価な証明書はそのほとんどが「ドメイン認証」であり、通常は個人利用が多い。その次が法的な実在証明を行う証明であり、一般企業の多くがこの方式を採用している。最も厳格なものは以前にも解説したが「EV SSL」だ。「物理的実在証明」と呼ばれている。安全な場合はWebブラウザのアドレスバーが緑色に変化するので、初心者が見ても分かりやすいと評判だ。 EV SSL証明書は価格が少し高いものの、顧客の安全を考慮するなら、十分に検討に値するものだろう。定価ベースで年間に約7万～10万円ほど高いだけだ。月1万円にも満たない価格差でより大きな安心感を得られると思えるが、あまり普及していないのは残念である。証明書の処理については、確かに厳密な確認を行うものであるほど時間がかかると想定される。だが、体感ではユーザーが全く気付かない場合がほとんどだろう。 また、「証明書失効リスト」（CRL）をチェ
HTTP接続は「安全でない」と明示すべし――Googleが提案
HTTPSを使ったセキュアな接続の普及を目指す米Googleが、ユーザーエージェント（UA）の仕様を段階的に変更して、通信が暗号化されないHTTP接続に対して「安全でない」と明示することを提案している。 この提案の狙いは、「HTTPには情報セキュリティ対策が施されていない」という事実を、もっとはっきりユーザーに示すことにあるとGoogleは説明。「Web上のデータ通信はすべてセキュアでなければならない。情報セキュリティが存在しない場合はそのことを明示して、ユーザーが情報を得たうえで対応を決められるようにしなければならない」と主張する。 背景として米国家安全保障局（NSA）などがネットの監視活動を行っていると伝えられた事例を列挙し、「Web上では改ざんや監視などの攻撃が、理論上ではなく実際に横行している」とした。 具体的にはセキュリティ状況を3段階に分類し、有効なHTTPSなどを使っている場
「SSL証明書無償配布」がもたらすWebの変革、企業ネットの管理にも影響
2015年の夏以降、Webアクセスの姿が大きく変わる可能性が出てきた。現在主に使われている「HTTP（HyperText Transfer Protocol）」の代わりに、SSL（Secure Sockets Layer）やTLS（Transport Layer Security）を用いて通信を暗号化する「HTTPS（HTTP over SSL/TLS）」を利用したWebサイトやサービスが一気に増えることが予想されるからだ。 なぜHTTPの代わりにHTTPSを使うWebサイトやサービスが増えるのか。それは、HTTPSを利用するために必要となる「SSLサーバー証明書」（以下SSL証明書）を誰でも無償かつ簡単に入手できるようになるからである。これまでは、年間数千円から数万円程度の料金をベンダーに支払ってSSL証明書を取得する必要があった。2015年夏以降、これがタダで“も”入手できるようになる
HTTPSを使っているのにCookieに「secure」属性を設定していない危険なサイトが話題に | スラド セキュリティ
最近SSL関連の脆弱性がたびたび話題になったが、これに関連してか、HTTPSを利用しているのにCookieのsecure属性を設定していないサイトについてが話題になっているようだ（セキュリティ研究家高木浩光氏によるTogetterまとめ）。 Cookieのsecure属性については、2004年に高木浩光氏がまとめた「安全なWebアプリ開発の鉄則 2004」の「CookieにSecure属性を」以下が分かりやすいが、この属性をセットしておくと、HTTPSでの通信時にのみそのCookieが送信される、というもの。secure属性が設定されていない場合、HTTP通信の際にもそのCookieが送信されるため、通信内容を傍受するなどでセッションIDなどが盗まれる可能性がある。 高木氏が検証したところ、secure属性が設定されていないサイトとしては全日空やニコニコ動画、OCNメールなどがあった模様。
HTTP/2における明示的プロキシ(Explicit Trusted Proxy)について
先日Jxckさんがセッションオーナーを務めた次世代Webセッション@CROSS2014に参加してきました。 セッションではSPDYやHTTP/2(その当時はまだHTTP/2.0だったかな)について主にリソース転送をどうよくするかについて話がされ、QUICなど”Post-TCP”な話も出て非常に興味深く楽しみました。 そこで「僕が考える次世代Web」というお題でブログを書けとJxck先輩から宿題をいただいて、何の話を書こうかなとずーっと思っていたのですが、最近のIETFの議論で個人的にはとても大切だと考えるトピックがあったので紹介＋僕の思いを書きたいと思います。 [訂正] 私がドラフトを読み違えていたのが問題なのですが、このExplicit Proxyの仕組みはhttp schemeの場合だけ適用され、httpsでは適用されません。そのため、httpsについては引き続き安全だと言えます。 し
HTML5カンファレンス2013 WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策 の参加メモ #html5j
HTML5カンファレンス2013 WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策 の参加メモ #html5j HTML5カンファレンス2013（http://events.html5j.org/conference/2013/11/）の13:00〜13:45、ルーム6Aの「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」のメモです。 NTTコムの小松さんのセッションです。 SPDY周りの話 10年前はたった一つのプロトコル、HTTP。マイナーバージョンは変わったがずっとこれ。 これがHTML5という言葉が出てきて、続々と新しいプロトコルが出てきた。 ・WebSocket ・SPDY（→HTTP/2.0） ・WebRTC ・Row Socket API これらはTCPという通信プロトコルの
非暗号化HTTPはもうすぐ消える？
非暗号化HTTPはもうすぐ消える？ 2013年を通して、米国家安全保障局（NSA）の情報収集活動に関する驚くべき事実が数多く明るみに出た。本質的な信頼性の基盤として長年使われていたプロトコルの、その信頼性が失われていることを受け、インターネット標準化コミュニティは暗号化の必要性に注目するようになった。とりわけ「HTTP 2.0」ではデフォルトで暗号化するべきとの議論が持ち上がっている。トレンドマイクロは、「これは全体的に見て好ましい傾向だが、考慮すべき課題がある」としてブログで主に以下の4点を指摘した。
今夜つける HTTPレスポンスヘッダー （セキュリティ編） - うさぎ文学日記
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です） SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこ
HTTP/2.0のALPN利用に伴うSSL負荷分散装置の不具合にご注意下さい - ぼちぼち日記
1. はじめに、 ただ今IETF-88@バンクーバーの開催が真っただ中です。スノーデン事件の余波もあり、インターネット技術（特にセキュリティ関連）の議論は熱くなっています。 ちょうど今朝未明（バンクバーでは11/5朝）に HTTP/2.0の標準化を進める httpbis ワーキンググループとセキュリティエリアの合同セッションが開催されました。合同セッションでは、ヘッダ圧縮技術(HPACK)のセキュリティや、HTTP接続(HTTPSではない）で通信の暗号化を行ったらどうか、といった興味深い議論が行われました。このうち将来HTTP/2.0の展開に重要な ALPN(Application Layer Protocol Negotiation) は、このミーティングで最終的な仕様を確定させる段階での議論でした。議論の中で、ALPNの導入によってブラウザから既存の実サービスへの接続に(少なからず)影
Top 25 Nginx Web Server Best Security Practices
Nginx is a lightweight, high-performance web server/reverse proxy and e-mail (IMAP/POP3) proxy. It runs on UNIX, GNU/Linux, BSD variants, Mac OS X, Solaris, and Microsoft Windows. According to Netcraft, 13.50% of all domains on the Internet use nginx web server. Nginx is one of a handful of servers written to address the C10K problem. Unlike traditional servers, Nginx doesn’t rely on threads to ha
Webアプリケーションを守るApacheモジュール「ModSecurity」
ModSecurityとは Breach Security, Inc.は9月24日(米国時間)、ModSecurityの最新版であるModSecurity v2.5.10をリリースした。 ModSecurityはWebアプリケーションファイアウォール(WAF)のひとつで、Apacheのモジュールとして動作する。リクエストヘッダや引数・表示するコンテンツなどから攻撃や脆弱性を検出し、悪意あるユーザの攻撃からWebアプリケーションを守ることができる。セキュリティフィルタは最初から用意されているもの以外にも、Luaを使用して自分で作成することもでき、柔軟な設定をおこなうことが可能だ。 v2.5.10でのおもな変更点は次のとおり(CHANGES_2.5.10.txtより一部を抜粋) Windowsビルドでのmlogcをクリーンアップ フィルタ中の詳細なメッセージを"Unknown error"に置
mod_securityでWebサーバを守る(第1回)
一体、Webサイトを持たない組織は今どれくらいあるでしょうか。 Webサーバを自前で持つ、ホスティングサービスを利用する、など運用形態はさまざまですが、Webサイトを持たない組織はほとんどないと思える程に Webは普及しています。 ファイアウォールはほとんどの組織で導入済みであり、多くのWebサーバはファイアウォールの中で運用されているのが一般的です。 しかしながら、最も普及しているファイアウォールはIPアドレス、ポートレベルでのフィルタリングです。この方法でのフィルタリングでは、許可していないサービスが持つ脆弱性を狙った攻撃を阻止できるため有用ではありますが、HTTPを許可している場合Web自体への攻撃に対して無力です。一方で、HTTPを不許可にした場合にはWebサイトへアクセスできなくなってしまうため本来の目的を達成できません。しかもここ数年、Webサイトを狙ったワームや不正アクセスは
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
JVNVU#94916481: HTTPS レスポンスから暗号化されたデータの一部を推測可能な脆弱性 (BREACH)
圧縮された HTTPS レスポンスの長さを観測することで、攻撃者は HTTPS ストリームの暗号文から、ウェブサイトの認証鍵など (secret) を推測することが可能です。 Salesforce.com の Angelo Prado 氏は、下記の通り報告しています。 Extending the CRIME vulnerability presented at Ekoparty 2012, an attacker can target HTTPS responses to recover data from the response body. While the CRIME attack is currently believed to be mitigated by disabling TLS/SSL/level compression, compressed HTTP respons
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
