hidekiy blog

もしあなたの所に Twitter の DM経由などでユーザー名・パスワード ペアを盗む怪しいフィッシングサイトへ誘い込むリンクが届き、そのサイトがまだブロックされていないことを見つけた場合、以下の手順でレポートすると速やかに (数時間以内程度) ブロックされるようになるようです。 攻撃サイトが転送URLを利用している場合は、Twitter の場合 t.co でブロックされることを期待して、初段と終段を登録すると良いように思います。 Google Chrome Google Chromeの設定 (右上のレンチ) > ツール > 問題の報告 > 問題が発生した箇所(フィッシング) スクリーンショット付きを推薦 Internet Explorer 9 ツール (右上の歯車ボタン) > セーフティ > 安全でないWebサイトを報告する Firefox こちらのフォームに入力: フィッシング サイトの報告 ただし、Googleのデータを使っているのでChromeでレポートすれば不要 Opera 11.61 メニュー (左上Opera) > ページ > 開発者ツール > セキュリティ情報 > フィッシング・マルウエア防止機能

徳丸さんに 直々にプレゼント していただいた 安全なウェブアプリケーションの作り方 を読んだ感想について書かせていただきます。 まず基本的な構成として、手を動かして学ぶことを意識した、とても実践的な内容になっているように思いました。仮想環境のセットアップ、デバッグ用プロキシ Fiddler のセットアップから始まっていて、具体的な通信内容を見て確認していく構成が素晴らしいと思います。 自分が特に興味深く読ませていただいたのは、セッション ID、CSRF トークン、自動ログインなど、Web アプリケーションを作るときは避けて通れない機能について、きっとこんな感じじゃないかな？という怪しげな実装になりがちな部分について、脆弱性が生まれるパターンを様々に例示して説明されているおかげで、正しい実装について深く学べる内容になっていると思いました。 セキュリティの話はどの話も全体のごく一部のような感覚があり、全体像がぼんやりともつかめない辛さがありましたが、この本は徹底的に網羅されているので、少しずつ読み進め理解を深めることで、理解しているつもりの方々とは一線を画す知識が得られると思います。内容がかなり盛りだくさんなので、最初から通して読もうとはせず、同じテーマの部分を繰り返し通して読むことで理解が深まりました。 Amazon.co.jp: 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 大型本 - 2011/3/3 徳丸浩 (著)

Snowflake とは Twitter の新しい Status ID 生成アルゴリズムの名前です。これは ID 生成サービスをスケーラブルなものにするために、生成サーバーの ID (workerId, datacenterId) と時刻 (timestamp) と、それらが重なった場合に増加させるカウンタ (sequence) に基づいて生成される 64bit 符号なし整数です。 したがって、この Snowflake ID をくっつける前の状態に戻すと元の要素に分解することができるので、それを作ってみました。JavaScript では Snowflake ID は大きすぎて数値として扱えないので、 BigNumber という多倍長整数演算ライブラリを使っています。 snowflake decoder textarea を書き換えると ID らしきものを抽出して詳細が表示されます。 リンク Twitter Engineering: Announcing Snowflake Twitter IDs, JSON and Snowflake src/main/scala/com/twitter/service/snowflake/IdWorker.scala at master from twitter/snowflake - GitHub はてな匿名ダイアリー - snowflakeの実際 mofigan's tumblr. - Twitterのstatus_idの生成アルゴリズムはsnowflakeなので、ビット演算をすれば投稿... PFIセミナー - ツイートID生成とツイッターリアルタイム検索システムの話

ポータブル Wi-Fi ルーターに Android 端末を繋いで使っていると、頻繁に自宅に連れ戻される症状に大変困っていました。これは周辺に他のアクセスポイントがない場合に、Wi-Fi 位置情報によりポータブルルーターの位置を引いてしまい、普段ずっと使っている自宅を現在位置と認識するためのようです。 2011/11 に Google により発表された Wi-Fi位置情報システムからのオプトアウト方法 に従って、SSID の変更を 2011/11/16 に行い、オプトアウトの完了を 2012/1/8 に確認しました。位置情報データのアップデートは月に1回程度行われるようです。 SSID の末尾に _nomap を付ける変更後、電波出力を 100% にして、より多くの Android 端末に捕捉されるようにしてみました。オプトアウト完了後は Google Map を使っても頻繁に現在地が自宅に戻る不愉快な動作もなく快適に利用できています。そもそも、移動するノードはすべて出荷時デフォルトが _nomap で良いと思います。 Google 側の更新を待てないお急ぎの方は、アクセスポイントを SSID ステルス設定にして使うと、Wi-Fi 位置情報クライアントがそれを認識し、近隣のアクセスポイントとして送信されなくなり、_nomap によるオプトアウト完了後相当の測位結果になるのでお試しください。 なぜ SSID ステルスモードへの変更でオプトアウト出来ないのか？ Google の位置情報サービスの説明 にあるように、位置情報サービスは公共に発信され、誰でも得ることができる情報 (広告されている ESSID, BSSID, 電界強度) のみに基づきサービスを運用しているので、送信される近隣アクセスポイント一覧には SSID が広告されているアクセスポイントのみの情報が含まれ、自分が繋いでいる SSID ステルスなアクセスポイントについての情報は送信されません。 したがって、サーバー側から見た場合、あるアクセスポイントが SSID ステルスモードに変化したのか、電源を落とされたのかは区別できず、電源の落ちているアクセスポイントの自動削除などは行われないため、SSID ステルスに変更する前の情報が記録されたままとなります。 この状況を改善するためには、