キャッシュポイズニングの開いたパンドラの箱
キャッシュポイズニングの開いたパンドラの箱 Opened Pandora's box of Cache Poisoning 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) / English version 背景 Kaminsky 2008年、Dan Kaminsky 氏が TTL に影響されない毒入れ手法を発表した。 しかし、偽応答のAdditional Section で毒が入るとされたのは誤りだったことを2011年に鈴木が明かにした。 http://www.e-ontap.com/dns/bindmatrix.html Müller Bernhard Müller の "IMPROVED DNS SPOOFING USING NODE RE-DELEGATION", 2008.7.14 https://www.sec-consult.c
PHP: openssl_random_pseudo_bytes と mcrypt_create_iv の比較
PHP 5.5 でパスワードハッシュ関数が導入されるPHP: パスワードハッシュライブラリのコードスニペットPHP: PBKDF2 を使ってパスワードハッシュを生成するPHP: 疑似乱数の文字列を生成するPHP: openssl_random_pseudo_bytes で疑似乱数を生成するPHP: openssl_random_pseudo_bytes と mcrypt_create_iv の比較PHP: フォームに CSRF 対策のトークンを導入するPHP: フォームに CSRF 対策のトークンを導入する (その2)JavaScript: CSRF 対策のトークンヘッダーを送信する ランダムな文字列を生成するにはファイル関数を使って /dev/urandom に直接アクセスするやりかたがもっとも明快であり、OS のしくみを学ぶ機会を提供するので、教育的でもある。徳丸本でもそのやりかたが採
PHPで本気で安全なパスワードを生成する - espresso3389の日記
Twitterで PHPで、いわゆる安全な秘密鍵を生成する方法っていうのがネットにほとんど記述されてないという事実に愕然としている。みんな、暗号乱数ぐらい勉強してくれ・・・。— Takashi Kawasaki (@espresso3389) April 12, 2014 なんて発言をしたら結構反響があったので、責任を取って、これならまぁ許せるというサンプルを出しておく。エントロピーの無駄遣いなどというぐらいの理解がある人は自分で実装してください。マジ実装すると結構面倒なので諦めました。 コピペするならここからどうぞ <?php // パスワードに使っても良い文字集合 $password_chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'; $password_chars_count = strl
OpenSSLの脆弱性（CVE-2014-0160）関連の情報をまとめてみた - piyolog
HeartBleed(CVE-2014-0160)関係のリンク集、自分のメモ用なので不正確です。 HeartBleedの影響対象となるOpenSSLバージョン 以下のバージョンが影響を受けます。但し、システムによっては原因となっているheartbeat機能が無効化されている場合もあるため、バージョンが一致しただけで当該脆弱性の影響を受けるかは確定しません。 (1) OpenSSL 1.0.1系 バージョン名 リリース時期 CVE-2014-0160 OpenSSL 1.0.1 2012/03/14 脆弱性あり OpenSSL 1.0.1a 2012/04/19 脆弱性あり OpenSSL 1.0.1b 2012/04/26 脆弱性あり OpenSSL 1.0.1c 2012/05/10 脆弱性あり OpenSSL 1.0.1d 2013/02/05 脆弱性あり OpenSSL 1.0.1e
CentOS6＋NginxでECDHEを有効にしてForward Secrecy取得までのメモ - 不意に何かを残すブログ
昨日は鍵共有を甘く見て爆死したためCentOS＋NginxのサーバーをWindows環境に対応させてみる。 RPMに慣れていた都合上、主なサーバーにCentOS6を使っている。 CentOS/RHEL6.4では2013年10月時点で、標準のOpenSSLは1.0.0、Nginxは1.0系が導入される。Nginxには公式リポジトリもあるが、openssl-1.0.0を前提にビルドされている。 これらはコミュニティサポートのあるRPMで提供されているものの、NginxでHTTPSサーバーを建てようとすると、TLSはv1.0 まで、対応cipherはDHE-RSA-AES-SHAまでになり、QualsysのSSLテストでは色々と指摘される。 問題点 既存のパッケージで対策不能なのは、TLS1.2対応（兼BEAST対策）とRSA鍵共有。 BEASTは未対策のブラウザがTLSv1.0以前のCBCモー
自堕落な技術者の日記 : TwitterのPerfect Forward Secrecy(PFS)対応 - 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について、いろいろ趣味で調べているんですが
Webアプリ開発者のためのHTML5セキュリティ入門
The document discusses Amazon FSx for Lustre, a fully managed file system for high-performance computing workloads. It provides fast parallel access to data stored in Amazon S3. The presentation covers how FSx for Lustre delivers scalable throughput and IOPS using Lustre and SSDs. It also discusses how FSx for Lustre can be used to access data stored in S3 for compute workloads run on EC2, with da
さくらのVPSに来る悪い人を観察する その２
さくらのVPSにアタックしてくる人たちを、ハニーポットなど使いながらその行動を観察した記録です。観察日記。 今回のネタは以下2つです。 ＊SSH honeypot(Kippo)を使った悪い人の行動観察、アンケート ＊/cgi-bin/php (Apache Magica攻撃)の観察 なおこのスライドは、2013年12月7日のSecurity Casual Talks(すみだセキュリティ勉強会)での発表資料です。 http://ozuma.sakura.ne.jp/sumida/ またスライド中、動画は以下のURLで閲覧できます http://youtu.be/gp3SBjZNWHURead less
HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書
HTML5 は、WHATWG および W3C が HTML4 に代わる次世代の HTML として策定を進めている仕様であり、HTML5 およびその周辺技術の利用により、Web サイト閲覧者 (以下、ユーザ) のブラウザ内でのデータ格納、クライアントとサーバ間での双方向通信、位置情報の取得など、従来の HTML4 よりも柔軟かつ利便性の高い Web サイトの構築が可能となっています。利便性が向上する一方で、それらの新技術が攻撃者に悪用された際にユーザが受ける影響に関して、十分に検証や周知がされているとは言えず、セキュリティ対策がされないまま普及が進むことが危惧されています。 JPCERT/CCでは、HTML5 を利用した安全な Web アプリケーション開発のための技術書やガイドラインのベースとなる体系的な資料の提供を目的として、懸念されるセキュリティ問題を抽出した上で検討を加え、それらの問題
パスワードの定期的変更について徳丸さんに聞いてみた(2)
高橋: こんにちは、高橋です。前回に引き続き、徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: はい。よろしくお願いします。 高橋: 前回は、「オンライン攻撃に対する予防としてパスワードの定期的変更は意味がない」という結論でしたが、今回は、事後の被害軽減策として、パスワードの定期的変更に意味があるか、というテーマですね。 徳丸: はい。その事後の話ですが、2つの話題があります。まず、前回の続きで、パスワードハッシュ値が漏洩してオフライン攻撃で解読されるまでの時間稼ぎとして、パスワードの定期的変更に意味があるか、次に、パスワードそのものが漏れている場合の緩和策として、定期的変更に意味があるかです。 高橋: それでは、まずハッシュ値が漏洩しているケースについてお願いします。 徳丸: はい。まず、前提として「パスワードを3ヶ月毎に変
AWSにおけるセキュリティとコンプライアンスのベストプラクティスを読んでみた | DevelopersIO
AWSは今エンタープライズ祭り AWSと聞いて、ホームページを運営するためのレンタルサーバーぐらいに思っている方は認識を改めた方が良いかと思います。今、AWSをエンタープライズ分野で利用する企業が増えています。そこで、必ずといっていいほど出てくるキーワードが、セキュリティです。まぁ、自前でラックを用意して運用するよりも、AWSに預けた方が安全なのは明らかなのですが、セキュリティがザルなオンプレからクラウドに移行するにあたって、改めて考えてみようということで読んで頂ければと思っています。今回は、トレンドマイクロ社が公開しているホワイトペーパーを読みながら理解を深めます。 クラウドコンピューティングとは 毎度おなじみの用語の定義です。ここでは、NIST（The US National Institute of Standards and Technology）が定義するクラウドコンピューティン
パスワードの定期的変更について徳丸さんに聞いてみた(1)
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、お伺いしたいことですが、パスワードを定期的に変更すべしという根拠には、どのようなものがあるのでしょうか? 徳丸: 大きく分けて2つの理由が挙げられていると思います。一つは、パスワードを定期的に変更すると、パスワードを破って侵入する攻撃の予防になるというもの、すなわち事前の予防策です。もう一つは、パスワードが漏洩した際に、被害を軽減できるというもので、事後の緩和策ということですね。 高橋: もう少し詳しくお願いします。 徳丸: まず、「事前」の方ですが、オンライン攻撃とオフライン攻撃があります。 高橋: オンライン攻撃とはどのようなものでしょうか? 徳丸: オンライン攻撃は、ネット経由でパスワード
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
SSL/TLSでBEASTを恐れてRC4を優先するのは危ない - Tetsu=TaLowの雑記（はてブロ版）
前職のお仕事で電子政府推奨暗号リストの改定作業を行う暗号技術検討会の事務局をやってたのですが、それ関係の話。3/1付けで電子政府推奨暗号リストあらためCRYPTREC暗号リストが公表されたのですが… 電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）に対する意見募集の結果 今回の改定では、電子政府で広く使われているがすでに危殆化が始まっているものを「運用監視暗号リスト」にするということが行われたのですが、今回その扱いにされた暗号のうち代表的なものがストリーム暗号RC4です。この件、もう少し大きな話題になってもいいと思うのですが… 残った国産暗号はCamelliaとKCipher-2 他は消えたのではなく推奨候補暗号リストになった 今回のハイライトの一つはRC4の運用監視暗号リスト行きだと思うのだけど昨日のシンポジウムでは意外と話題にならなかったな / “1…”
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
hello
hello [ "::ffff:35.191.15.169", "GET", "/wp/?p=262", {}, { "host": "wate.jp", "user-agent": "HatenaBookmark/4.0 (Hatena::Bookmark; Analyzer)", "cache-control": "no-cache", "accept": "*/*", "x-cloud-trace-context": "f2b2c71e04db21b6017682e491266d0c/9480773545164747120", "via": "1.1 google", "x-forwarded-for": "153.120.13.138, 35.227.238.79", "x-forwarded-proto": "http", "connection": "Keep-Alive" }
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - phpseclib/phpseclib: PHP Secure Communications Library
Configuring Apache, Nginx, and OpenSSL for Forward Secrecy | Qualys Security Blog
hbstudy# 28 SELinux HandsOn 公開版
15分でわかるAWSクラウドで オンプレ以上のセキュリティを実現できる理由
