セキュリティ情報 - Yahoo!ケータイの一部端末に「かんたんログイン」なりすましを許す問題
文書番号HASHC2010052401 Yahoo!ケータイの一部端末に「かんたんログイン」なりすましを許す問題 HASHコンサルティング株式会社 公開日:2010年5月24日 概要 昨年11月24日づけアドバイザリにて、iモードブラウザ2.0のJavaScriptにより、携帯端末に割り当てられたID（以下、端末固有ID）を利用した認証機能（以下、かんたんログイン）に対する不正アクセスが可能となる場合があることを報告した。その後の調査により、同種の問題がYahoo!ケータイのブラウザ(通信事業者はソフトバンクモバイル)でも発生することを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者およびYahoo!ケータイ利用者には至急の対策を推奨する。 背景携帯電話のかんたんログインとは、ケータイブラウザに用意された端末固有IDを利用した簡易的な認証であり、ユーザがIDやパスワード
HASHコンサルティング徳丸浩の日記 - 自分でできる - 「かんたんログイン」DNSリバインディング耐性のチェック方法
■「かんたんログイン」DNSリバインディング耐性のチェック方法 このエントリでは、ケータイ向けWebサイトがDNSリバインディング攻撃に対する防御耐性があるかどうかをチェックする方法を説明します。ケータイ向けに「かんたんログイン」機能をもつWebサイトをチェック対象とします。 基本的な前提として、検査対象のWebサイトの管理者が自ら検査することを想定しています。 用意するもの チェック対象のWebアプリケーション(かんたんログイン機能あり) 携帯電話（かんたんログイン可能なもの） インターネット接続されたパソコン ステップ0:IPアドレスの調査 検査対象のWebサーバーのIPアドレスを調べます。一例として、検査対象サーバーのホスト名が mobile.example.com の場合、以下のコマンドでIPアドレスを調べることができます。 C:>nslookup mobile.example.
セキュリティ情報 - iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性
iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 HASHコンサルティング株式会社 公開日:2009年11月24日 概要 iモードブラウザ2.0のJavaScriptとDNS Rebinding問題の組み合わせにより、iモードIDを利用した認証機能（以下かんたんログイン）に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景携帯電話のかんたんログインとは、ケータイブラウザ（たとえばiモードブラウザ）に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送
HASHコンサルティング徳丸浩の日記 - 9月4日 PHPカンファレンス2009 ビジネスデイで発表しました - 発注者のためのセキュリティ
■発注者のためのセキュリティ こちらの日記はずいぶん後沙汰しておりますが、標記のように、PHPカンファレンス2009 ビジネスデイにて発表する機会をいただきました。関係者のみなさまありがとうございました。 主催者からのリクエストが、「発注側として気をつけるべきセキュリティ」ということでしたので、今さらXSSやSQLインジェクションの話をしてもしょうがないと思い、発注者視点での話をこの機会にまとめてみようと思いました。そのため、タイトルは「45分で分かる、安全なWebアプリケーション開発のための、発注・要件・検収」といたしました。 発表の中でも述べましたが、発注者がセキュリティに関与できる場面は、発注と検収の場面しかなく、検収は発注仕様に沿っているかどうかを確認するものですので、発注と要件（発注仕様）が極めて重要ということになります。しかし、従来、このセキュリティ要件をどのように書けばよい
ダウンロード - HASHコンサルティング株式会社
Copyright(C)2008 HASH Consulting Corporation. All Rights Reserved.
HASHコンサルティング徳丸浩の日記 - 発注者のためのWebアプリケーションセキュリティ入門(1) - 安全なWebアプリケーションのために発注者がなすべきこと
■安全なWebアプリケーションのために発注者がなすべきこと このブログでの連載開始にあたり、Webアプリケーションを発注する立場でのセキュリティに対する責任や、なすべきことを説明したいと思います。 Webアプリケーション発注者に脆弱性に対する責任はあるか そもそも非常に基本的な前提として、Webアプリケーションの脆弱性(SQLインジェクションなど)に対する最終的な責任は誰(どの会社)にあるかを考えてみます。具体的には、インターネット上のWebサイトを運営している、あるいはWebアプリケーションョンをパッケージソフトウェアとして市販しているが、開発は外部の開発会社に委託しているケースで、セキュリティ事故などが発生してお客様(Webサイトのユーザ、パッケージソフトの購入者)に迷惑を掛けた場合、その責任は誰にあるかということです。 結論から言えば、この責任はWebアプリケーションの発注者にあり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.hash-c.co.jp/archives/owasp-j-201206.html
ダウンロード - PHPカンファレンス2010 テックデイ 講演資料
http://www.hash-c.co.jp/archive/wasf2010.html
http://www.hash-c.co.jp/d/20080622.html