YAPC::Asia Tokyo 2014 で話したスライドです。 http://yapcasia.org/2014/talk/show/cc57f3ca-01b8-11e4-b7e8-e4a96aeab6a4
![OAuth/OpenID Connectを用いてID連携を実装するときに気を付けること #yapcasia](https://cdn-ak-scissors.b.st-hatena.com/image/square/5258ef0b89d9d4f2b3f5c29986726256d5790e09/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fc8f0f10012420132ea3636ee7b6c2ab8%2Fslide_0.jpg%3F3452637)
1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、9つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの9つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み(の一部)を知りたい方はお読みください。 2. OpenSSLの脆弱性
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
(2015/1/30 追記)時期は不明ですが、現時点のgithub.comはEd25519鍵にも対応しています。 (2016/5/31 追記)「GitHubにバグ報告して賞金$500を頂いた話」で紹介した通り、既に弱い鍵はGitHubから削除され、新規登録もできなくなっています。 GitHub APIを利用して、GitHubの31661アカウントに登録されているSSH公開鍵64404個を取得してみました。抽出方法*1が適当すぎて偏りがあるような気もしますが、面白い結果が得られたと思うのでまとめてみます。 SSH鍵の種類 鍵の種類 個数 割合 RSA鍵 61749 (95.88%) DSA鍵 2647 (4.11%) ECDSA鍵 8 (0.01%) 約6万個の鍵のうち、8個だけECDSA(楕円DSA)鍵が見つかりました!常用しているのか試しに登録してみただけなのかはわかりませんが、何にせよ
LINEが使用している「独自の」暗号化手法について、情報が一部開示(参照:LINEの暗号化について « LINE Engineers' Blog)され、Twitterでもやりとりをしたので、まとめてみる。 ■なぜTLSを使わないか TLSではなく、1パスのメッセージ暗号化を使っている理由については、Adopting SPDY in LINE – Part 2: The Details « LINE Engineers' Blogに以下のような記載があり、TLSを使うことによるレイテンシの増加を懸念しているためと考えられる。 3G mobiles networks normally operate at slow speeds. (中略)If the connection changes modes when the user sends a message, we are forced t
監査の意義 一般的に監査は以下の目的で実施される。 権限管理の実装に関する問題の検出 不審なアクティビティの調査・検出 不正行為をおこなっていない証明 不正行為の未然予防(心理的障壁) コンプライアンス要件への対応(監査レポート提出など) 監査というと不正をチェックするものとの認識が多いと思うが、その他にも管理者や社員の身の潔白を証明するためにも利用できる。とくに大きな権限を持つ管理者は、Database Vaultなどを利用した管理者自身の権限の制限(厳格な職務分掌)をおこない、かつ整合性が確保された監査証跡を残す必要がある。 Oracle Databaseでは、監査機能、標準監査、ファイングレイン監査、DBA監査という3つの監査機能を提供している。まずはこの3つの監査の特徴とTIPSを紹介する。詳細な設定方法に関しては、それぞれのリンク先を確認してほしい。 標準監査 標準監査は指定した
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
追記 (5/7 20:30): 本文中に「まともなブラウザーであれば、そのフラグメントを URI の一部にするようなことはないから、オープン・リダイレクターには送られない。」とありますが、少なくとも Chrome と Firefox はリダイレクト時に URI フラグメントをそのまま保つ (i.e. 不十分な redirect_uri チェック & オープン・リダイレクター & インプリシット・フローの場合、アクセス・トークン入りの URI フラグメントを、ブラウザーがそのままリダイレクト先へのリクエストに用いる) とのことです。続報があり次第追記します。 追記2 (5/7 23:50): John Bradley 氏自身によるフォローアップを訳しました。 Covert Redirect and its real impact on OAuth and OpenID Connect を、と
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
2014年4月15日に公開されたJPRSの緊急注意喚起に続き、中京大学の鈴木常彦教授によるDNSキャッシュポイズニングに関する技術情報が公開されました。 今回公開された技術情報に書かれている内容には、DNSの本質につながるさまざまな要素が関係しており一回で書ききれるものではなく、また、書いている側(私)も、それぞれの要素技術について勉強しながら理解しつつ進めていかないと混乱してしまうということが良くわかったため、これから数回に分けて徐々に書いて行くことにしました。 ということで、今回はまず、そもそもDNSキャッシュポイズニングとは何かということと、JPRSの注意喚起に書かれているUDPソースポート番号のランダム化(ソースポートランダマイゼーション)の概要、そしてなぜそれが重要なのかという点について解説します。 DNSキャッシュポイズニングとは インターネットで通信を行うとき、各機器同士は通
Angularとサーバーサイドテンプレートの混在 先日リリースされた某サービス(他社)がAngularを使っていて、XSSがボロボロ出てくるだとか、{{var}} な形式で値を入力するとng-template側でテンプレーティングされるだとかの話がありました。 詳しくは見ていないので、今回の話とまったく同じかは把握していませんが、サーバーサイドテンプレートを混在させると、次のようなことが起こりえます。 例えばejsとAngular サンプルとしてスカスカなControllerを用意します。 angular.module('app', []).controller('AcmeCtrl', function($scope) { $scope.foo = 'bar'; }); ejsは次のようなテンプレートになっているとします。
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現(あるいは中間者攻撃) 秘密鍵の漏洩により、(過去のものを含む)パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する(他のユーザーのパスワードやセッションキーを含む)データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
The ordering of cipher suites in the Old configuration is very important, as it determines the priority with which algorithms are selected. OpenSSL will ignore cipher suites it doesn't understand, so always use the full set of cipher suites below, in their recommended order. The use of the Old configuration with modern versions of OpenSSL may require custom builds with support for deprecated ciphe
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く