セキュリティ情報 - iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性
HASHコンサルティング株式会社 公開日:2009年11月24日 追記日:2010年1月21日 概要 iモードブラウザ2.0のJavaScriptとDNS Rebinding(DNSリバインディング)問題の組み合わせにより、iモードIDを利用した認証機能（以下かんたんログイン）に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景 携帯電話のかんたんログインとは、ケータイブラウザ（たとえばiモードブラウザ）に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送出される。現在、iモ
i-mode2.0セキュリティの検討: 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 - 徳丸浩の日記(2009-08-05)
_携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以来2ヶ月以上が経つものの、未だにJavaScript機能は利用できない状態のままだ。 実は、NTTドコモ社が慌てふためいてJavaScript機能を急遽停止
携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
Don'tStopMusic - Rails のセキュリティガイド , RubyGems が Ruby 1.9 でテストが通ったようです
_ [Rails] Rails のセキュリティガイド QuarkRuby: Ruby on Rails Security Guide では、Rails でアプリを開発する際にセキュリティ面で気を付けなければいけないことを簡潔にまとめています。 いま社内向けに Rails のセキュリティガイドラインをまとめているので参考になります。上記のページに、OS コマンドインジェクションとセッション固定化、HTTP ヘッダインジェクションを追加すれば一般的な脆弱性は大体カバーできますね。 なお、Rails のセキュリティについて興味のある方は、前田さんのWebアプリケーションセキュリティフォーラム発表資料は必読です。 追記 自分の備忘録として脆弱性に関してまとまった情報があるサイトや資料を挙げておきます。 QuarkRuby: Ruby on Rails Security Guide : 簡潔な一覧
NICT、認証結果を複数機関で共有する実験に成功
この記事は会員登録で続きをご覧いただけます申込は簡単3分！ 今すぐ会員登録（無料） 会員の方はこちら 【この画面が表示された方限定】 会員登録（無料）で14日間有料記事が読み放題 ※14日間試読付き登録会員のお申し込みはお1人様1回限り
SSH への総当たり攻撃(brute force attack)と防衛 - World Wide Walker
SSH への総当たり攻撃(brute force attack)と防衛 Posted by yoosee on Debian at 2005-11-08 23:42 JST1 SSHに対するブルートフォース攻撃への対策sshd へのパスワード総当たり攻撃は今年の前半くらいから非常に増えていて、「実際に guest や test などのアカウント名を乗っ取られた」と言うケースも実はそこそこの頻度で聞いている。仕事では既に防御スクリプトを仕込んでいるサーバもあるが、無防備なサーバに実際にどれくらいの攻撃が来ているのか、ログを見てみた。2 存在しないユーザへの攻撃sshd へのアクセスが失敗すると、少なくとも FreeBSD や Debian では /var/log/auth.log にメッセージが残る。上が存在しないユーザ、下が存在するユーザへの総当たり攻撃ログの例Nov 8 11:29:47
まちがった自動ログイン処理
Last Updated on: 2018年8月20日問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考：自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保存さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shareで落とした割れエロゲのsetup.exe踏んで個人情報が流出される:【2ch】ニュー速VIPブログ(`･ω･´)
架空の個人情報を生成する「疑似個人情報ジェネレータ」発売 
高木浩光 - ニコニコ
安全なWebサイト設計の注意点