【注意喚起】Facebookで自分のニセモノが急増中 / 名前を似せて「なりすまし」友達申請しまくる
【注意喚起】Facebookで自分のニセモノが急増中 / 名前を似せて「なりすまし」友達申請しまくる GO羽鳥 2013年5月20日 Facebookを使っている人は要注意！ 現在、何者かが “自分になりすましたFacebookアカウント” を作り、自分の友だちリストに入っている友人たちに友達申請をしまくるという「ニセモノ」の手口が、ここ3日ほどで急増中だ。 ニセモノの特徴としては、「アイコンがディズニー系（もしくは写真なし）」だったり、「同姓同名」だったり「名前の漢字の1文字が微妙に違う」だったり、本物は女性でニセモノも女性名なのに「性別が男」だったり、いろいろある。実際に被害にあった私（筆者）の友人のニセモノは、以下のような特徴であった。 ・苗字は旧姓で登録（本人は旧姓欄に旧姓を入力していた） ・名前の漢字は1文字だけ漢字が違う（読み方は同じだけど違う漢字） ・アイコンはドナルドダック
PayPalアカウントを不正利用された話 - BitArts Blog
昨晩、PayPalから「上海花千树信息科技有限公司北京分公司様へのお支払いのご連絡」というメールが来た。 一瞬フィッシングかと思ったけど、ガチの不正利用でした。www.jiayuan.comって中国の婚活サイト？で、125ドルのstampを購入したことになってる。 PayPalの案内に従って問題解決センターに異議を提出。するとWeb上でクレーム対応状況などが見られるようになります。すぐに売り手に確認中というステータスとなり、今日、払い戻し決定となりました。 夜間でも対応は早かったし、対応状況の履歴なども見られるので安心な感じではありました。 この一件で怖いなと感じたのはPayPalからの支払いメールを見落とすことですね。僕の場合PayPalは年に1度くらいしか使っていないので、フィッシングだと思ってうっかりスルーしたり、迷惑メールフォルダに入ってしまったりすると、気づかないままになる恐れが
HttpsとTorで守れるデータ、守れないデータ – 電子フロンティア財団(EFF)の作成した図の読み方
HttpsとTorで守れるデータ、守れないデータ – 電子フロンティア財団(EFF)の作成した図の読み方 電子フロンティア財団が作った、HTTPSとTorを使った時に通信の何が守られるのかを表すダイナミック・チャートがよくできています。 図の登場人物に日本語の訳をつけてみましたが、リンク先で実際に左上の「HTTPS」と「To […] 電子フロンティア財団が作った、HTTPSとTorを使った時に通信の何が守られるのかを表すダイナミック・チャートがよくできています。 図の登場人物に日本語の訳をつけてみましたが、リンク先で実際に左上の「HTTPS」と「Tor」をオン・オフしてみて、httpsやTorでwebサービスにアクセスすることで、インターネットの途中の通信路にアクセスできる第三者に対して、あるいはアクセス先のwebサービスのサーバにアクセスできる人に対して、何を隠すことができるのか、を見る
金融機関の口座集約アプリの危険性について - プログラマでありたい
先日、銀行口座の口座集約のとあるiOSアプリの記事について、危険だよなぁと何気なく呟いたら中の人からリプを貰いました。Twitterで呟いているのですが、文字だけでは解りにくいのでまとめてみます。ただ、そのアプリ固有の問題ではなく、構造的な問題なのでアプリ名は開示しません。（安全なので安心ですという論調は、どうかと思いますが。。。） 口座集約アプリの構造 口座集約のアプリは、アカウント・アグリゲーション(Account aggregation)サービスと言われています。サービスの実体は、複数の銀行の口座情報とID,Passwordを預かり、代行でログインして結果のhtmlを解析（スクレイピング）して利用明細や残高を集約するものです。口座とID,Password情報、解析エンジンをどこに置くかで、クライアント型とサーバ型に分類されます。 サーバ型アプリケーション まずサーバ型アプリケーション
Googleアカウントの2段階認証を有効にする
Google アカウントでは不正ログインを予防するために 2 段階認証を利用することができます。ここでは Google アカウントの 2 段階認証を有効にする手順および 2 段階認証が有効になっている場合のログイン手順について解説します。 2 段階認証の設定は Google アカウント単位で行います。 2 段階認証を有効にしたい Google アカウントでログインしたあと、画面右上に表示されているプロフィール画像をクリックし、表示された画面の中の「Googleアカウントを管理」をクリックしてください。 「Googleアカウント」の画面が表示されます。画面左側の「セキュリティ」をクリックしてください。 「セキュリティ」の画面が表示されます。 2 段階認証を有効にするには「Googleへのログイン」の中にある「2段階認証プロセス」をクリックしてください。 「2段階認証プロセス」の画面が表示され
「イモトのWiFi」のグローバルデータ、不正アクセスでカード情報11万件流出 セキュリティコードや住所も
「イモトのWiFi」のグローバルデータ、不正アクセスでカード情報11万件流出 セキュリティコードや住所も タレントのイモトアヤコさんがCMキャラクターを務める「イモトのWiFi」など海外渡航者向け通信機器レンタルサービスを提供するエクスコムグローバルは5月27日、海外用データ通信レンタルサービス「GLOBAL DATA」（グローバルデータ）と、海外用レンタル携帯電話サービス「Global Cellular」（グローバルセルラー）のWebサーバがSQLインジェクション攻撃を受け、約11万件のクレジットカード情報やセキュリティコードが流出したと発表した。 同社によると、4月23日午後5時ごろ、契約先の決済代行会社から、クレジットカード情報が流出した可能性があると連絡を受け、サイトからの申し込みとオンラインでのカード決済を停止。サーバ内のクレジットカード情報を削除した。24日、専門調査会社Pay
オープンリダイレクト検査：Locationヘッダ編 - T.Teradaの日記
オープンリダイレクタを脆弱性とみなすべきかは議論が分かれるところです。Google等の一部のサイトは、自サイトのオープンリダイレクタを脆弱性としてはみていません。一方で、脆弱性検査の現場では、見つかれば脆弱性として報告することが多いと思います。 その辺の議論はおいておいて、オープンリダイレクタの検査は、ブラウザの特性もからんで意外とバリエーションが多くて面白いので、本日の日記で取り上げてみたいと思います。 大まかにいうと、リダイレクトは、302応答のLocationヘッダ、Refresh（HTTPヘッダ、METAタグ）、JavaScriptによるものがありますが、本日は302応答のLocationヘッダのリダイレクタについて取り上げます。 パターン1：サブドメイン部分に値が入る場合 以下のように、サブドメインの箇所が動的なケースです。 Location: http://{$u}.haten
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 をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
リセット後のパスワードをメール送信するパスワードリセット方式の注意点
先日のエントリパスワードリマインダが駄目な理由にて、現在のパスワードをメール送信する「パスワードリマインダ」がパスワードリセット方式に比べてリスクがある（リスクのコントロールが弱い）という説明をしました。その際に説明したパスワードリセット方式は、パスワード変更の画面URLをメール送信するというものでしたが、もう一つのパスワードリセット方式としては、サイト側でパスワードをリセットして、リセット後のパスワードをメール送信するという方式もあります。このエントリでは、後者の仕様上の注意点について説明します。 とあるサイトのパスワードリセット方式 あるサイトのパスワードリセットの仕様を確認したところ下記の通りでした。 パスワードリセット画面では、ユーザIDとメールアドレスを入力する ユーザIDとメールアドレスが共に該当するアカウントがないとエラーになる サイト側でパスワードがリセットされ、リセット後
Apache 2.4系でのモダンなアクセス制御の書き方
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 これまでのApache2.2系以前でのアクセス制御の書き方は賛否両論でした。僕はあまり好きじゃありませんでした。 過去のアクセス制御に関しては、以下の記事がとてもわかりやすくまとめられていると思います。 こせきの技術日記 – Apacheのアクセス制御をちゃんと理解する。 ここで、以下のように言及されています。 こんなバッドノウハウ、本当はどうでもいいと思う。Apache 3.0では、かっこいいDSL(VCL)で書けるようにする構想があるらしいのでがんばってほしい。 ということで、2.4系ではDSLとはいかないまでも、Require*というディレクティブを使ったモダンな書き方ができるようになったので、それを2.2系以前のアクセス制御の記述と比
パスワードリマインダが駄目な理由
昨日、某著名サイトのパスワードリマインダの方式が変更になっていることに気がつきました。 旧: 現在のパスワードをメールで送信する（パスワードリマインダ） 新: パスワード再設定の画面のURLをメールで送信する（パスワードリセット） 新しい方式（パスワードリセット）の方が優れていますが、それでは何故パスワードリマインダは駄目で、パスワードリセットの方がよいのでしょうか。このエントリではその理由について説明します。 パスワードリマインダのリスク 良く指摘されるように、パスワードリマインダの場合、２つの問題があります。 現在のパスワードをメール送信できるということは、パスワードをハッシュ値で保存していない証拠である メールは平文通信なので、パスワードを書いたメールが盗聴されると被害が甚大になる これらのうち、パスワードの保存方法については別稿にゆずるとして、このエントリでは盗聴のリスクについて検
ディノスに１００万回超の不正アクセス NHKニュース
東京・中野区に本社がある通信販売会社「ディノス」のホームページに対して、会員のパスワードを探ろうという不正なアクセスが、８日までに１００万回以上繰り返され、ディノスは１万５０００人分のパスワードが何者かに突き止められたことを明らかにしました。 不正なアクセスがあったのは、インターネットを通じて買い物ができるディノスのホームページで、ＩＤとパスワードの入力を試す行為が８日までの５日間におよそ１１１万回繰り返されたということです。 ホームページを管理するサーバーには、アクセスは中国と韓国の９か所から行われたという記録が残っていて、このうち１万５０００人分は実際にログインされてしまったため、パスワードを突き止められてしまったということです。 ８日、出勤したシステムの担当者が大型連休中に同じコンピューターから大量のアクセスがあったことに気付き、問題が明らかになったということで、ディノスは今のところ
Nginx、セキュリティ脆弱性を修正
Nginxの1.3.9から1.4.0のバージョンにバッファオーバーフローの脆弱性があることが明らかになった。これを受けてNginxの開発チームは問題を修正したNginx 1.4.1安定版およびNginx 1.5.0開発版を公開した。特定の細工されたリクエストを送信されると、パーサにおける不正チェックをくぐり抜けてスタックがバッファオーバーフローを起こすという脆弱性で、この脆弱性を利用されると任意のコードが実行される危険性がある。 Nginx 1.4.0はまだリリースされてからさほど時間がたっておらず、採用しているサーバの割合はかなり少ないものと想定される。多くの場合、ひとつ前の安定版である1.2系を採用している。1.2系はこの問題を持っていないため、そのまま運用することが可能。現在の1.2系最新版は1.2.8。 ただし、今後1.2系はレガシーなブランチとなり、安定版は1.4系となる。現在1
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
「パスワードでの保護は限界」と結論したGoogleが評価するセキュリティ技術
Googleは、2013年1月、セキュリティに関する研究結果を公表した。このレポートは「Authentication at Scale」というタイトルで、ユーザー認証技術についての評価報告である。Googleはこのレポートで、「パスワードとCookieで利用者を守ることはできない」と結論付け、新たな技術の導入を検討していることを明らかにした。 ユーザー認証にハードウエア・キーを利用 Googleが評価している技術の一つがYubiKey (ユビキー) という製品である。この製品は、Palo Alto (カリフォルニア州) に拠点を置く、Yubico (ユビカ) というベンチャー企業により開発されている。YubicoはRSA Conferenceに同社の最新技術を出展していた。 Yubicoのブースにおいて (上の写真、出展はすべてVentureClef)、John Salterから、製品デモ
iptablesで鉄壁？の守りを実現する3つのTips｜TechRacho by BPS株式会社
iptablesでサーバを守るときに知っておくと良いことを3つ紹介します 1. 接続回数を制限する(IPアドレスごと) hash_limitを使います これにより特定ホストからの大量アクセス、DoS攻撃を緩和することが可能です 例 2. 接続回数を制限する(サービスごと) limitを使って制限します これにより多数のホストからの攻撃、DDoS攻撃を緩和します limitを使った制限は全ホストが等しく制限を受けるため、ssh等に設定すべきではありません。 （攻撃を受けている間は自分たちも制限されるため） Webサーバが大量アクセスで落ちそうな場合は使えるんじゃないでしょうか？ 例 3. 接続IPアドレスを限定する IPアドレスの国別割り当てをAPNIC等から取得してコマンドを作ります この手のルールは長くなるので、ユーザー定義チェインにしたほうが見やすくなります 例 あとはこんな感じのスク
Module ngx_http_secure_link_module
The ngx_http_secure_link_module module (0.7.18) is used to check authenticity of requested links, protect resources from unauthorized access, and limit link lifetime. The authenticity of a requested link is verified by comparing the checksum value passed in a request with the value computed for the request. If a link has a limited lifetime and the time has expired, the link is considered outdated.
eBook Japanの発表資料に見るパスワードリスト攻撃の「恐ろしい成果」と対策
eBook Japanに対する不正アクセスについて、詳細の発表があり、いわゆる「パスワードリスト攻撃」であることが発表されました。 前回のご報告までは「複数のIPアドレスからログインページに対して機械的に総当たり攻撃等を行う大量アクセス行為（ブルートフォースアタック）」とご説明しておりましたが、詳細調査の結果、「不正の疑われる複数のIPアドレスからログインページに対して、予め持っていたログインIDとパスワードの適用可否を試行する大量アクセス行為」であることが判明いたしました。 つまり、大量アクセス行為を仕掛けてきた者は、当社以外の他のサービスなどで他のサービスのログインIDとパスワードを不正に入手し、ユーザーがログインIDとパスワードを共通に設定している可能性を狙って当社サービスに不正にログインしようとし、上記件数についてはログインに成功してしまったということです。 そのように判断した根拠
Firefox 23では、デフォルトでSSLページ内で非SSLコンテンツの読み込みをブロックする
Site Compatibility for Firefox 23 | MDN Firefox 23では、とうとうSSLページ内から非SSLコンテンツのロードをブロックするそうだ。 つまりとても簡単に言うと、httpsなページ内からhttpなURLで提供されるCSSやスクリプトやプラグインやiframeが読み込まれなくなる。しかし、Web FontやWebSocketにまで言及しているのに、何故か画像には言及していない。まさか画像だけは特別扱いするのだろうか。動画や音声も言及されていないがどうなのだろうか。 どうも、Nightlyの動作では、やはり画像だけは特別扱いのようだ。 ちなみに、Firefox 23は2013年の8月6日にリリースされる予定だ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
