Covert Redirect Vulnerability with OAuth 2
tl;dr Covert Redirect Vulnerability is a real, if not new, threat when combined with Implicit Grant Flow (not Code flow) This Covert Redirect Vulnerability in OAuth 2 is an interesting one. There’s a couple of defending arguments that this isn’t a flaw in OAuth itself. While I agree that it isn’t a flaw in the protocol, I think the threat is a real one, combined with a) a loose validation on redir
自堕落な技術者の日記 : DHE - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 SSL/TLS CipherSuiteウォッチャーの@kjurです。 TechCrunch JPに昨日こんな記事が掲載されました。 Twitterが将来の暗号解読を防ぐため全サイトにわたってPerfect Forward Secrecyを採用 (2013年11月23日) http://jp.techcrunch.com/2013/11/23/20131122twitter-enables-perfect-forward-secrecy-across-sites-to-protect-user-data-against-future-decryption/ 最近、SSL/TLS のCipherSuiteについて、いろいろ趣味で調べているんですが
私が愛した openssl (SSL/TLS 編) - してみんとて
id:blooper:20120907 の続きですが、皆様におかれましては既に証明書が好きで好きでたまらなくなって、HTTPS を利用したサイトに行くと証明書の拡張まで読んだ後でなくては証明書の内容が気になってサイトの本文が読めなくなっているかと思いますが如何お過ごしでしょうか。 SSL は Secure Sockets Layer の頭文字で Netscape Communications が 1995 年に、ってのは wikipedia:Secure_Sockets_Layer でも見れば載ってるので見てね。で、RFC にしようってことで SSL は Netscape のでしょ? ってことで TLS (Transport Layer Security) に改名した、と記憶してるんだけど本当だっけな。ハンドシェイク時のレコードのバージョン見ると SSLv3.0 は 3.0 TLSv1.0
（緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年5月30日更新）
--------------------------------------------------------------------- ■（緊急）キャッシュポイズニング攻撃の危険性増加に伴う DNSサーバーの設定再確認について（2014年4月15日公開） ～問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨～ 株式会社日本レジストリサービス（JPRS） 初版作成 2014/04/15（Tue） 最終更新 2014/05/30（Fri） （対策に関するDNS運用者向け文書へのリンクを追加） --------------------------------------------------------------------- ▼最近の状況 最近、日本の大手ISPにおいてカミンスキー型攻撃手法によるものと考えら れるキャッシュDNSサーバーへのアクセスが増加している旨、JP
OpenSSL マジヤバいっす！ ～ Heartbleed 脆弱性を試してみたよ - モラトリアムこじらせた
実際にデータが漏れる様子を見たい方はコチラ→あ、何か漏れてる… OpenSSL Heartbleed 実験その２へどうぞ。 さて ネット上の通信の大部分において「安全」を担保していた OpenSSL なのですが... でっかい穴 が空いていたことが明らかになったようです。いわゆる Heartbleed バグ。トホホです。 「ネット上のサービスで OpenSSL を使っている(いた)サイトは、もしかしたらこのバグを知っていた悪い人からサーバー上の情報を盗まれていたかもよ？ しかも盗んだ形跡は残らないんだぜ？」 ということになります。 サーバー上の情報というのは、例えば パスワード、メールアドレス 自分で登録した名前とか住所とか もちろん自分で入力したクレジットカード番号とか… などなど。 Mashableによると、有名なサービスでヤバイのは、 Facebook Tumblr Google Y
インターノット崩壊論者の独り言 - 開いたパンドラの箱 - 長年放置されてきた DNS の恐るべき欠陥が明らかに
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 本日、JPRS がようやく重い腰をあげて注意喚起を発してくれましたが、その内容は危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません。 一方で注意深い攻撃者が探せば、ネット上にはすでに深刻な攻撃を行うのに必要な情報は十分に流れています。特に、JPRS が3月に慌てて co.jp などにこっそり入れた署名付き TXT レコードは大きなヒントに見えます。 DNS に詳しい攻撃者であれば、攻撃手法に辿りつくのは時間の問題でしょう。(すでに攻撃は行われているかも知れません) 長く秘密にしておくことは得策ではないと判断し、防御する側の心構えと手助けにし
強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
SSL/TLSでBEASTを恐れてRC4を優先するのは危ない - Tetsu=TaLowの雑記（はてブロ版）
前職のお仕事で電子政府推奨暗号リストの改定作業を行う暗号技術検討会の事務局をやってたのですが、それ関係の話。3/1付けで電子政府推奨暗号リストあらためCRYPTREC暗号リストが公表されたのですが… 電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）に対する意見募集の結果 今回の改定では、電子政府で広く使われているがすでに危殆化が始まっているものを「運用監視暗号リスト」にするということが行われたのですが、今回その扱いにされた暗号のうち代表的なものがストリーム暗号RC4です。この件、もう少し大きな話題になってもいいと思うのですが… 残った国産暗号はCamelliaとKCipher-2 他は消えたのではなく推奨候補暗号リストになった 今回のハイライトの一つはRC4の運用監視暗号リスト行きだと思うのだけど昨日のシンポジウムでは意外と話題にならなかったな / “1…”
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
mixiに報告した脆弱性2 - kusano-k’s blog
mixiの脆弱性報告制度（すでに終了している）で報告して、修正された脆弱性。 youbrideの有料機能を無料で使える問題 2014/03/12 報告 2014/03/18 修正完了 2014/03/24 75,000円のAmazonギフトが届いた youbrideはmixiの子会社の株式会社Diverseが運営する婚活サイト。一時、制度の対象だった。 youbrideでは無料ユーザーはプロフィールの公開条件は「全体に公開」しか選べない。 ChromeのDeveloper Toolで他の選択肢を有効にしたら、「全体に公開」以外の公開条件も選べてしまった。 mixiワードのXSS 2014/03/31 報告 2014/03/31 修正完了 2014/04/09 125,000円のAmazonギフトが届いた mixiワードにXSS可能な脆弱性があった。 「猫」には、キャットタワー、キャットフー
Norikra+FluentdでDoS攻撃をブロックする仕組みを作ってみた ｜ Developers.IO
Norikraとは Norikraとはリアルタイム集計プロダクトです。イベントストリームに対してSQLライクな言語で処理を書くことが出来ます。 例えば、ApacheのアクセスログをNorikraに流し込み、1分あたりのアクセス数やレスポンスタイムの最大値をリアルタイムに集計することが出来ます。 Norikraの利用例は作者であるtagomorisさんのブログで紹介があります。 今回は、Norikraを使ってDoS攻撃をブロックする仕組みを作ってみました。 DoS攻撃ブロックの仕組み アクセス元はApacheのアクセスログから取得し、ログの受け渡しにはFluentdを利用しました。 ブロックの手順は以下のようになります。 アクセスログをFluentdのin_tailプラグインで取得。 Fluentdのout_norikraプラグインで、アクセスログをNorikraに流し込み。 Norikra
ユーザー認証の手抜き - 方向
Webアプリ作っているといろんな局面でユーザー認証が必要になる局面がある。まじめにつくると果てしなく面倒だし、適当につくるとセキュリティ上問題になるので、要件に応じて適切に手抜きする必要がある。 適当なやつからしっかりしたやつまでなんとなくソートしていくとこんなかんじだと思う。 認証なし IPで弾く Basic認証（ソースコード、設定ファイルにパスワードベタ書き） Basic認証（DBにUserテーブルをつくってパスワードを保存。追加はcliとかで手動） login/logout画面作成。cookieなりmemcacheなりにセッションを保存 webからユーザーを追加できるように password変更機能 OAuth OpenID mailを送ってリンクをクリックさせてメールアドレスの所有確認 メールアドレス変更機能 メールを使ってのパスワードリセット機能 OAuthで作ったアプリへの後か
新たなDNSキャッシュポイズニング手法、第一フラグメント便乗攻撃について - 仙豆のレシピ
以前IPv6 summitに参加したときに聞いたお話の中にあった、昨年(2013年）8月に発表された新たなDNSキャッシュポイズニング手法「第一フラグメント便乗攻撃」について興味がわいたのでいろいろ調べたり実際にできるのかを試したりしてみました。（もちろん自分の管理するクローズドな環境で） 第一フラグメント便乗攻撃をグーグルで検索しても個人のブログ等が出てこないのでこれが第一「第一フラグメント便乗攻撃」便乗エントリです（別にうまくない） 攻撃コード等ありますが、けっして自分の管理する環境以外に使用しないでください 第一フラグメント便乗攻撃とは 第一フラグメント便乗攻撃とは、DNS応答がフラグメントされた場合DNS応答の同定に使える要素（UDPポート番号、問い合わせID、問い合わせ名）が一つ目のフラグメントにしかないことを利用し、二つ目のフラグメントを偽装することによって毒入れをするというD
1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記
最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty
PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
ラック、日本でも発生した『水飲み場型攻撃(＊)』に対して注意喚起（2013年10月 9日）| 株式会社ラック
ラック、日本でも発生した『水飲み場型攻撃(＊)』に対して注意喚起 ～マイクロソフト社のセキュリティ向上に協力し、企業の安全確保を支援～ 2013年10月 9日 | プレス 株式会社ラック（本社：東京都千代田区、代表取締役社長：髙梨 輝彦、以下ラック）は、日本の企業や団体に的を絞り行われ、当社が発見したマイクロソフト社のInternet Explorerの未知の脆弱性を悪用した悪質なサイバー攻撃に関する注意喚起情報を公開しました。 一連の事案で行われたサイバー攻撃の手法は、「水飲み場型攻撃」として呼ばれるもので、不特定ユーザーまたは特定のユーザー層（組織、業界、地域等）が閲覧するWebサイトに攻撃者が不正なプログラムを仕込み、それの閲覧者に不正プログラム（コンピュータウイルス）を感染させるなどの被害を与えるものです。 このたび確認された「水飲み場型攻撃」は以下の特徴があり、極めて悪質なもので
Apache HTTPD: mod_allowfileowner - ダメ出し Blog
mod_allowfileowner って何? Apache HTTPD 用のフィルターモジュールです。 静的コンテンツファイルの所有者をチェックして、 指定のユーザーが所有していればアクセスを許可し、 そうでなければ拒否します。 静的コンテンツファイルをオープンした後、それを指すファイル記述子に対して fstat(2) を行ないファイル所有者をチェックする実装になっているため、 TOCTOU (Time Of Check to Time Of Use) 問題はありません。 何が嬉しいの? 共有 Web サーバーサービスにおいて、一部のシンボリックリンク攻撃を防ぐことができます。 この攻撃は Options -FollowSymLinks や Options SymLinksIfOwnerMatch 設定では完全には防ぐことはできません。 参考: Apache HTTPD: Options
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeNA Engineering - DeNAエンジニアのポータルサイト
(PDF) ウェブサーバの暗号アルゴリズムの選び方