タグ

ブックマーク / www.hash-c.co.jp (6)

  • http://www.hash-c.co.jp/archive/wasf2010.html

  • セキュリティ情報 - Yahoo!ケータイの一部端末に「かんたんログイン」なりすましを許す問題

    文書番号HASHC2010052401 Yahoo!ケータイの一部端末に「かんたんログイン」なりすましを許す問題 HASHコンサルティング株式会社 公開日:2010年5月24日 概要 昨年11月24日づけアドバイザリにて、iモードブラウザ2.0のJavaScriptにより、携帯端末に割り当てられたID(以下、端末固有ID)を利用した認証機能(以下、かんたんログイン)に対する不正アクセスが可能となる場合があることを報告した。その後の調査により、同種の問題がYahoo!ケータイのブラウザ(通信事業者はソフトバンクモバイル)でも発生することを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者およびYahoo!ケータイ利用者には至急の対策を推奨する。 背景携帯電話のかんたんログインとは、ケータイブラウザに用意された端末固有IDを利用した簡易的な認証であり、ユーザがIDやパスワード

  • WASF2008

    Copyright © 2008 HASH Consulting Corp. 1 SQLインジェクション対策再考 2008/07/05 HASHコンサルティング株式会社 代表取締役 徳丸 浩 http://www.hash-c.co.jp/ WAS Forum Conference 2008 Developers Day Copyright © 2008 HASH Consulting Corp. 2 アジェンダ • 日の構成 – 正しくないSQLインジェクション対策の今昔 – SQLインジェクション対策の考え方 – SQLインジェクション対策の実際 • 議論の焦点 – 入力値検証とは何か – SQLのエスケープ方法詳細 – 数値項目の対策 – 最近のトピックス Copyright © 2008 HASH Consulting Corp. 3 第1部 正しくないSQLインジェクション対

  • セキュリティ情報 - iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性

    iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 HASHコンサルティング株式会社 公開日:2009年11月24日 概要 iモードブラウザ2.0のJavaScriptDNS Rebinding問題の組み合わせにより、iモードIDを利用した認証機能(以下かんたんログイン)に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景携帯電話のかんたんログインとは、ケータイブラウザ(たとえばiモードブラウザ)に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送

  • セキュリティ情報 - UTF-8を利用したIDS/IPS/WAFの検知回避技術

    UTF-8を利用したIDS/IPS/WAFの検知回避技術 HASHコンサルティング株式会社 公開日:2009年3月23日 概要 レポートでは、ASP.NET(1.1)をUTF-8文字エンコーディングにて利用しているサイトにおいて、不正な文字エンコーディングを利用したIDS/IPS/WAF回避の可能性について報告する。 背景 株式会社ラックが2008年10月に「【CSL】CSL緊急注意喚起レポート~新手のSQLインジェクションを行使するボットの確認~」と題するホワイトペーパーを発表した。いくつかの新種の攻撃手法が説明されている中で、不正なパーセントエンコードを利用した検知回避テクニックについて言及している。具体的には、以下のような方法だ。 Active Server Pages(ASP)では、「DEC%LARE」のようにパーセント記号に続く2文字が16進数でない場合、パーセント記号を

  • HASHコンサルティング徳丸浩の日記 - 発注者のためのWebアプリケーションセキュリティ入門(1) - 安全なWebアプリケーションのために発注者がなすべきこと

    ■安全なWebアプリケーションのために発注者がなすべきこと このブログでの連載開始にあたり、Webアプリケーションを発注する立場でのセキュリティに対する責任や、なすべきことを説明したいと思います。 Webアプリケーション発注者に脆弱性に対する責任はあるか そもそも非常に基的な前提として、Webアプリケーションの脆弱性(SQLインジェクションなど)に対する最終的な責任は誰(どの会社)にあるかを考えてみます。具体的には、インターネット上のWebサイトを運営している、あるいはWebアプリケーションョンをパッケージソフトウェアとして市販しているが、開発は外部の開発会社に委託しているケースで、セキュリティ事故などが発生してお客様(Webサイトのユーザ、パッケージソフトの購入者)に迷惑を掛けた場合、その責任は誰にあるかということです。 結論から言えば、この責任はWebアプリケーションの発注者にあり

  • 1