しゃおの雑記帳 - 携帯サイトセキュリティTODOリスト
前回のエントリ “携帯サイト開発者のためのセキュリティ再入門” が割と広範囲にお読みいただけているようです。ありがとうございます。ただあの記事は単に列挙しただけなので「何をまずやればいいのか」具体的なものが見えてこない気がしますのでメモとして再構成してみました。前回書いたように「契約者IDによるかんたんログイン機能を撤廃しよう」がすぐにできるのであればいいですが、なかなかできないのが現実でしょうから、「緊急度の高い対策」から順に扱っていこうと思います。 契約者ID(UID)で認証しているサイトはすぐにやろう キャリアのIP帯、User Agent、UIDのペアを確実に検証するようにする 例えばドコモのIP帯 + ドコモのUser Agent + X-DCMGUID でのみ認証できるようにします。 もし [携帯電話のIP帯 (各キャリアのリストをマージしたもの) + ドコモの User Ag
しゃおの雑記帳 - 携帯サイト開発者のためのセキュリティ再入門
通勤電車で周囲を見渡せば大抵数台のスマートフォンを見つけられるようなご時世ですが、現実は日本の伝統的な携帯電話が多数派です。今もそんなガラケー向けWebサイトの開発案件は衰えることありません。 そんなガラケーサイトの開発者の間で話題になっている「セキュリティ対策」について、ガラケー界の現状をふまえた上でまとめてみます。 携帯電話のIPからのアクセスであることを前提としたセキュリティ対策はすでに無駄 ソフトバンク3Gのプロクシ情報は検索すればすぐに出てきます イー・モバイルのEMnetに至っては公開情報です サイトのソースもFlashのswfも画像もPCから丸見えだと思うべきです 危険な「かんたんログイン」 かんたんログインで使う契約者IDはあなたのサイトにも他のサイトにも同じものが送出されてます 悪意をもった人が他人の契約者IDをヘッダに乗せてかんたんログインのアクションを呼び出したらどう
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Top 25 Nginx Web Server Best Security Practices
Nginx is a lightweight, high-performance web server/reverse proxy and e-mail (IMAP/POP3) proxy. It runs on UNIX, GNU/Linux, BSD variants, Mac OS X, Solaris, and Microsoft Windows. According to Netcraft, 13.50% of all domains on the Internet use nginx web server. Nginx is one of a handful of servers written to address the C10K problem. Unlike traditional servers, Nginx doesn’t rely on threads to ha
DNSリバインディング: かんたんログイン手法の脆弱性に対する責任は誰にあるのか - 徳丸浩の日記(2010-02-12)
_かんたんログイン手法の脆弱性に対する責任は誰にあるのか id:ikepyonの日記経由で、NTTドコモのサイトに以下のセキュリティ・ガイドラインが掲示されていることを知った。 iモードブラウザ機能の多様化により、機種によってiモードサイトにおいてもJavaScriptを組み込んだ多様な表現、CookieやReferer情報を有効に活用したサイト構築が行えるようになりました。 しかし、PC向けインターネットサイト同様に、セキュリティ対策が十分に行われていないサイトでは、そのサーバの脆弱性を突き（クロスサイトスクリプティング、SQLインジェクション、DNSリバインディングなど様々な攻撃手法が存在しています）、これらの機能が悪用される危険性があります。十分にご注意ください。 [作ろうiモード：iモードブラウザ | サービス・機能 | NTTドコモより引用] XSSやSQLインジェクションと並ん
Researchers identify command servers behind Google attack
VeriSign's iDefense security lab has published a report with technical details about the recent cyberattack that hit Google and over 30 other companies. The iDefense researchers traced the attack back to its origin and also identified the command-and-control servers that were used to manage the malware. The cyber-assault came to light on Tuesday when Google disclosed to the public that the Gmail W
論点の整理: 文字エンコーディングバリデーションは自動化が望ましい - 徳丸浩の日記(2009-09-18)
_文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不
ドラクエIXで改造データとのすれ違い通信に注意 スク・エニが警告
ニンテンドーDS用ソフト「ドラゴンクエストIX ～星空の守り人～」のすれ違い通信で、マジコンを使って改変した宝の地図が出回っているとし、スクウェア・エニックスがユーザーに注意を呼び掛けている。改変した宝の地図を開くと、プレイに悪影響が起きたり、ゲームが遊べなくなったりする恐れがあるという。 すれ違い通信は、無線通信機能を使ってユーザー同士が「宝の地図」を交換できる機能。通信を通じ、一部ユーザーが改変した地図が広がっている。こうした地図を使うと、最悪の場合、冒険の書が破損する可能性もあることがネット上で報告されている。 改造だと分かりやすいのは大魔王と戦える地図。8月末の時点で、正常なプレイで手に入る大魔王の地図は「バラモスの地図」「ムドーの地図」「ドルマゲスの地図」「竜王の地図」「デスピサロの地図」「ミルドラースの地図」のみ。これ以外の大魔王の地図は、「モンスターバトルロードII」との連動
OAuth Update: New Streamlined User Experience, and Revision A (Yahoo! Developer Network Blog)
Over the years, many developers have asked us to make our Auth UIs (the user interface for logging in and verifying user ID and password) less jarring and disruptive. Until today, all of our authorization services, including OAuth, OpenID, and BBAuth used a "redirect" UI, which required sites to redirect the user's browser over to Yahoo! to ask for the user's approval before sharing the user's dat
OpenSSHに深刻な脆弱性--英ロンドン大が詳細を公表
文：Tom Espiner（Special to CNET News） 翻訳校正：矢倉美登里、高森郁哉2009年05月20日 13時31分 ロンドン大学ロイヤルホロウェイ校の研究チームが、広く使用されている暗号化プロトコルOpenSSHに内在する脆弱性を明らかにした。 ロイヤルホロウェイ校Information Security Group（ISG）の研究チームによると、「Debian GNU/Linux」に含まれるOpenSSHのバージョン4.7に存在するこの脆弱性を突けば、32ビットの暗号化されたテキストを平文に変換することが可能になるという。 攻撃者が成功する確率は26万2144分の1だ。ISGを率いる教授のKenny Patterson氏は、CNET Newsの姉妹サイトであるZDNet UKに現地時間5月18日、今回の脆弱性はこれまでに発見されたOpenSSHの脆弱性よりも重大だ
乱数の使い方 - 飲み物だから太らない (2009-05-23)
k.inabaさんに久々に絡んでみようと思う。 http://www.kmonos.net/wlog/97.html#_2206090523 http://www001.upp.so-net.ne.jp/isaku/rand.html さらに、初期化ミスのため、例えば以下のプログラムを JAVA で実行すると、 public class RandTest { static java.util.Random r=new java.util.Random(); public static void main (String[] args) { double x,Min=1,Max=0; for (int i=0;i<1024;i++) { r.setSeed(i); x=r.nextDouble(); if (x>Max) Max=x; if (x結果は、 Min=0.675337775058
「OAuth」プロトコルに脆弱性--Twitterがサポートを一時停止
UPDATE ユーザーのログイン情報を利用する「補助キー」として機能するオープンソースプロトコル「OAuth」にセキュリティホールが発見され、「Twitter」や「Yahoo」などのサービスがOAuthのサポートを一時的に取りやめざるを得なくなったことが、米CNET Newsの調べでわかった。 Twitterが実装されたばかりのOAuthのサポートを取りやめたことに、一部の開発者は当惑していた。ブロガーのJesse Stay氏は自身のブログ記事で、Twitterの開発者向けアプリケーションプログラムインターフェース（API）に課された他のさまざまな制約について取り上げた上で、OAuthのサポート中止は、マイクロブログサービスのTwitterが最近になっていかに「開発者の足をすくって」きたかを示す数多くの事例の1つだと述べている。 CNET Newsでは、インターネットの安全性を守る見地から
OAuthのセッション固定攻撃について（翻訳） - ものがたり(旧)
Explaining the OAuth Session Fixation Attackという文章が興味深いものだったので翻訳してみた。何か解決策を思いついた人はOAuthのメーリングリストに送ってあげると良いと思う。って僕は参加してもいないのだけど。あと誤訳とかはコメントしてもらえれば対応します。ワタクシ実のところOAuthなんて使ったこともなかったりして。 （原文はリンク先にもある通り、Eran Hammer-Lahav氏からcc-by 3.0 usで提供されている。） 追記: 日本でもニュースになっていた: http://www.atmarkit.co.jp/news/200904/23/oauth.html 追記2: 元記事の画像がアップデートされていたので、追従して更新 以下翻訳: 先週、われわれが発見して対応したOAuthのプロトコルセキュリティ問題には語るべきことが多くある。
OAuth: 2009.1 OAuth Security Advisory
OAuth Security Advisory: 2009.1 23-April-2009 A session fixation attack against the OAuth Request Token approval flow (OAuth Core 1.0 Section 6) has been discovered. Impact All standards-compliant implementations of the OAuth Core 1.0 protocol that use the OAuth authorization flow (also known as ‘3-legged OAuth’) are affected. Details The attack starts with the attacker visiting the (honest) Consu
セキュアなハッシュ値を生成する方法 - 夜の Discovery
その昔、acts_as_authenticated という rails プラグインでは以下のようにしていたように思う。 require 'digest/sha1' str = Digest::SHA1.hexdigest(Time.now.to_s.split(//).sort_by {rand}.join) 最新の restful-authentication プラグインを取ってくると以下のようになっていた。 require 'digest/sha1' def secure_digest(*args) Digest::SHA1.hexdigest(args.flatten.join('--')) end def make_token secure_digest(Time.now, (1..10).map{ rand.to_s }) end どういう値のハッシュ値を取っているか、試しにロー
Adobe Flash & Facebook Platform samples | Adobe Developer Connection
Flash Player’s EOL is coming at the end of 2020. See the roadmap for Flash Player and AIR’s EOL: Adobe Flash Player EOL General Information Page The Future of Adobe AIR You can access the archived documents relevant to Flash Runtime even after the Flash EOL date. We are providing access to the archived documents for all the user/developers community to download. These documents are now no longer u
高木浩光＠自宅の日記 - MacユーザはIPv6を切るかnet.inet6.ip6.use_tempaddr=1の設定を
■ MacユーザはIPv6を切るかnet.inet6.ip6.use_tempaddr=1の設定を Mac OS Xの初期設定の危険性 私の周囲に物理的に近づくことのできる人は、私が使っているノート型コンピュータの無線LANインターフェイスのMACアドレス*1を知ることができる。たとえば、セミナー等で私が講演している会場に来れば、講演中に私が無線LANのスイッチを切り忘れていたなら、無線LANのパケットを傍受することで私のMACアドレスを知るだろう*2。それだけでは他の人のアドレスと混じって区別できないだろうが、別の場所で再び同じことをすれば、両方に存在したものが私のMACアドレスだ。 これはもう隠しようがないので、先に自ら暴露してしまおう。「00:1f:5b:d1:ec:bd」は私のMACアドレスだ（図1）。 これを暴露するのはリスクのある行為であり、お薦め出来ない。また、仮に他人のMA
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
教科書に載らないWebアプリケーションセキュリティ － ＠IT
http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html
パスワードをハッシュ化（暗号化）保存することを法律で義務化するくらいのことが必要だと思う