株式会社ミクシィ株式会社ミクシィ・ミクシィグループの公式企業サイトです。企業情報、IR・投資家情報、ニュースリリース、採用情報などを掲載しています。
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 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可能な脆弱性があった。 「猫」には、キャットタワー、キャットフー
mixiに報告した脆弱性1 - kusano-k’s blog
mixiの脆弱性報告制度で報告して、修正された脆弱性。報酬がもらえるかどうかが分かったら追記する。 nohanaのパスワードリマインダーのXSS 2013/10/02 報告 2014/02/14 修正完了 2014/03/25 報酬支払い対象外との連絡(´･ω･｀) http://nohana.parseapp.com/password_reminder/user_management.htmlにアクセスすると、 Right click here to save this page. Upload it to your own website and paste the URL in the "Parse Frame URL" app settings at Parse.com. と表示され、hereの部分がJavaScriptでwindow.locationへのリンクになっていた。 ht
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
特定条件下におけるOAuth 2.0の認可応答を奪取されるリスクとその対策について - r-weblife
こんにちは、ritouです。 やっと”なんちゃらAdvent Calendar”がおさまり、これからは”一年を振り返って(遠い目”みたいな記事が増えることでしょう。その間のタイミングを狙います。 何の話か mixi Platformが導入したっていうOAuth 2.0のCSRF対策拡張を使ってみた - r-weblife の最後にちょっと書いたんですけど、モバイルアプリでOAuth 2.0を使う際にやっかいな問題が残ってました。 今回は、「ネイティブアプリケーションからOAuth 2.0を使うとき、特定の条件下において、正規のClientではない悪意のある第3者に認可応答を持って行かれて、その結果Access Tokenを取得できちゃうリスクがあるよね。どうしようか。」っていう話です。 条件っていうのは、 OAuth 2.0のClientはネイティブアプリケーションであり、Client C
RSAとNSAとの秘密契約疑惑で揺らぐ暗号システム評価 - 雑種路線でいこう
RSAといえば代表的な公開鍵暗号アルゴリズムで、作者が暗号を商用化するために設立した会社の社名でもある。その老舗がNSAから1000万ドルを受け取って、同社の暗号ツールキットBSafeで、NSAが開発したバックドアを含む擬似乱数生成器Dual Elliptic Curveを標準設定にしたとロイターが報じた。事実であればRSAやBSafeのブランドだけでなく、Dual_EC_DRBGをSP 800-90Aとして標準化したNISTへの信頼も揺らぐ。 あるNSAメモは、大胆にもその進捗状況についてこう書いている。「暗号解読機能がオンラインで使えるようになった。これでこれまで捨てられていた大量の暗号化インターネットデータを活用できる」 (略) ReuterがNSAはRSAに1000万ドル払って欠陥アルゴリズムを使わせたと暴露したことによって話は変わってきた。NSAがある種の邪悪な黒幕で、人気のセキ
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
個人認証情報としての生年月日の利用とfacebookについて | 栗原潔のIT弁理士日記
ストーカー殺人事件の関係で、調査会社（探偵会社）の個人情報入手方法がちょっと話題になってます。ガス会社等々に電話をして、コールセンター担当者から個人情報を聞き出す手法などがニュースに載ってたりします。あまり報道すると真似する人が出てくることを懸念する人もいるかもしれませんが、どちらかというと手口を周知させた方が防止効果が生まれて望ましいと思います。たとえば、宅配便業者のふりをして、宛名が薄くて読めないので教えてくださいと電話をして、おおよその住所と電話番号から正確な住所を得る手口などは新聞雑誌記事等で読んで知識を得ていないとだまされてしまうかもしれません。 さて、これらの個人情報不法入手行為に注意している人・組織は多くなっていると思うのですが、自治体関係は結構甘いことが多く、探偵業界では「重宝」されているようです（参照ニュース記事）。この記事で特に衝撃だったのは以下です。 自治体からは簡単
CGI版PHPに対する魔法少女アパッチマギカ攻撃を観測しました
昨夜に、魔法少女アパッチ☆マギカ攻撃を観測しました。魔法少女アパッチ☆マギカとは、PoCのソースコードに Apache Magica by Kingcope とコメントされていることに由来しています（というか、私がそう訳しましたw）。 これは10月29日にPoCが発表されたPHP-CGI攻撃(CVE-2012-1823)の変種です。従来のPHP-CGI攻撃は、CGI版PHPが動作する環境で、PHPスクリプト（中身はなんでもよい）に対する攻撃でしたが、魔法少女アパッチマギカの方は、/cgi-bin/に置かれたPHP処理系（php-cgiなど）に直接攻撃するものです。 CGI版PHPを設置する方法は複数ありますが、よく使われる方法としてApacheのリダイレクトによりPHPスクリプトをPHP処理系に実行させる方法があります。この場合、/cgi-bin/php-cgiなどとしてPHP処理系を公開
Apache HTTPD: `Options -FollowSymLinks` は不完全 - ダメ出し Blog
シンボリックリンク攻撃を防ぐための Apache HTTPD モジュールの解説はこちら: Apache HTTPD: mod_allowfileowner https://fumiyas.github.io/apache/mod-allowfileowner.html 背景 ロリポップの共有 Web サービス下のサイト改ざん事件で、 攻撃手法の一つとして 「他ユーザー所有のファイルへのシンボリックリンクを自分のコンテンツディレクトリ下に作り、Apache HTTPD 経由でアクセスする」手順が利用されたらしい。 参考: http://blog.tokumaru.org/2013/09/symlink-attack.html 当社サービス「ロリポップ！レンタルサーバー」ユーザーサイトへの第三者による大規模攻撃について http://lolipop.jp/info/news/4149/#090
パスワードの定期的変更について徳丸さんに聞いてみた(2)
高橋: こんにちは、高橋です。前回に引き続き、徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: はい。よろしくお願いします。 高橋: 前回は、「オンライン攻撃に対する予防としてパスワードの定期的変更は意味がない」という結論でしたが、今回は、事後の被害軽減策として、パスワードの定期的変更に意味があるか、というテーマですね。 徳丸: はい。その事後の話ですが、2つの話題があります。まず、前回の続きで、パスワードハッシュ値が漏洩してオフライン攻撃で解読されるまでの時間稼ぎとして、パスワードの定期的変更に意味があるか、次に、パスワードそのものが漏れている場合の緩和策として、定期的変更に意味があるかです。 高橋: それでは、まずハッシュ値が漏洩しているケースについてお願いします。 徳丸: はい。まず、前提として「パスワードを3ヶ月毎に変
パスワードの定期的変更について徳丸さんに聞いてみた(1)
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、お伺いしたいことですが、パスワードを定期的に変更すべしという根拠には、どのようなものがあるのでしょうか? 徳丸: 大きく分けて2つの理由が挙げられていると思います。一つは、パスワードを定期的に変更すると、パスワードを破って侵入する攻撃の予防になるというもの、すなわち事前の予防策です。もう一つは、パスワードが漏洩した際に、被害を軽減できるというもので、事後の緩和策ということですね。 高橋: もう少し詳しくお願いします。 徳丸: まず、「事前」の方ですが、オンライン攻撃とオフライン攻撃があります。 高橋: オンライン攻撃とはどのようなものでしょうか? 徳丸: オンライン攻撃は、ネット経由でパスワード
360webscan攻撃（仮称）を観測しました
本日、HASHコンサルティング株式会社セキュリティ・オペレーション・センター(HASH-C SOC)では、奇妙な攻撃リクエストを観測しました。それは、以下のようなURLによるものです。 http://example.jp/?s=/abc/abc/abc/$%7B@print(md5(base64_decode(MzYwd2Vic2Nhbg)))%7D/ s=以下をパーセントデコードすると下記となります。 /abc/abc/abc/${@print(md5(base64_decode(MzYwd2Vic2Nhbg)))}/ { } で囲まれた部分はPHPのスクリプトのように見えますが、2箇所文法違反があります。 MzYwd2Vic2Nhbg がクォートされていない } の前にセミコロンがない このうち、MzYwd2Vic2Nhbgのクォートに関しては @ 演算子によりエラー抑止され、'MzY
パスワード保護されたアーカイブファイル内に自身のコピーを作成するワーム |
一般的にユーザがファイルを圧縮ファイルを作成する際は、便宜上、複数のファイルを1つのファイルにひとまとめにするか、または単に格納スペースに保存します。しかし、「TrendLabs（トレンドラボ）」は、パスワード保護された圧縮形式の圧縮ファイル内にさえ自身のコピーを作成するワームを確認しました。 トレンドラボは、特定の WinRAR のコマンドライン（図1参照）を利用して感染活動を行うワームの検体を入手。このワームは、トレンドマイクロの製品では、「WORM_PIZZER.A」として検出されます。コマンドが実行されると、このワームは、特に ZIP や RAR、RAR の 自己解凍型ファイル（拡張子SFX）などといった圧縮されたファイルの中に自身のコピーを作成することが可能になります。しかしこのワームは、圧縮ファイルからパスワードを取得することはありません。このコマンドラインは、通常のものであり
ヤフー株式会社様に「秘密の質問と回答」に関して要望します
拝啓、貴社ますますご清栄のこととお慶び申し上げます。日頃は格別のご高配を賜り、あつくお礼申し上げます。さて、さっそくですが、表題の件についてお願いがあり、ご連絡差し上げました。 私は東京都品川区在住の貴社サービスの一ユーザーです。Yahoo! IDの登録が2001年3月、Yahoo!プレミアムは2003年 2月からですので、十年来のユーザーと言うことになり、現在はヤフオクやYahoo! Boxを利用しております。どうぞ、お見知りおきのほど、よろしくお願いいたします。 さて、ご連絡差し上げたのは、表題に述べたように「秘密の質問と回答」に関する要望です。と言いますのは、報道などで「秘密の質問と回答」が漏洩したことを知ったからです。 ヤフーは２３日、今月１６日に不正アクセスで流出した「ヤフージャパン」のＩＤ２２００万件のうち、約１４９万件についてはパスワードと、パスワード変更のために使う「秘密の
Getting started with login verification
Every day, a growing number of people log in to Twitter. Usually these login attempts come from the genuine account owners, but we occasionally hear from people whose accounts have been compromised by email phishing schemes or a breach of password data elsewhere on the web. Today we’re introducing a new security feature to better protect your Twitter account: login verification. This is a form of
JSONをvbscriptとして読み込ませるJSONハイジャック(CVE-2013-1297)に注意
はせがわようすけ氏のブログエントリ「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき」にて、巧妙な罠を仕掛けることにより、別ドメインのJSONデータをvbscriptとして読み込み、エラーハンドラ経由で機密情報を盗み出すという手法が紹介されました。これは、IEの脆弱性CVE-2013-1297を悪用したもので、MS13-037にて解消されていますが、MS13-037はIE6～IE8が対象であり、IE9以降では解消されていません。 また、MS13-037を適用いていないIE6～IE8の利用者もしばらく残ると考えられることから、この問題を詳しく説明致します。サイト側の対策の参考にして下さい。 問題の概要 JSON形式のデータは、通常はXMLHttpRequestオブジェクトにより読み出しますが、攻撃者が罠サイトを作成して、vbscript
補足編：機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記」の補足編です。 結局、よくわからないんだけど。 よくわからない場合は、とにかく全てのレスポンスに X-Content-Type-Options: nosniff をつけましょう。 機密情報を含むJSONにX-Content-Type-Options:nosniffをつける理由はわかったけど、「あらゆる」コンテンツにつける理由はなぜ？ 機密情報を含まなくても、<script>のような文字列を含むコンテンツをIEで直接開いた場合にはXSSにつながる可能性もあります。どのようなコンテンツにX-Content-Type-Options:nosniffが必要かを考えるくらいであれば、全てのコンテンツに付与したほうが間違いがなくていいでしょう、ということです。 IEのためだけの問
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
