全てのツイートが対象です。
サーバーの能力の問題もあり、「徳丸浩の日記」を以下のURLに移転致します。旧のコンテンツはそのままとし、新しいエントリから新ブログの方に書いていきます。 徳丸浩の日記 (blog.tokumaru.org) 新ブログの最初のエントリとして、「ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る」を書きましたので、ぜひお読みください。 _PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因 前回のブログ「PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合(脆弱性)あり」にて、PHP5.3.6(本エントリ執筆時点での最新版)からPDOにてサポートされた文字エンコーディング指定がWindows版では正しく動作しないことを報告しました。Linuxでは正常に動作するので不思議だなという話になっていたのですが、千葉征弘さん(@nihe
Cabezonとは カベソンは自己記述可能なPascalコンパイラです( 言語仕様、サンプル)。 カベソン・コンパイラは1パスのコンパイラで、Pascalのソースを 読み込んでMASMのアセンブリソースを出力することにより、8086の ネイティブ・コードを生成します。 以下のアーカイブにより、カベソンをダウンロードしてお使い下さい。 取りあえず、カベソンを試してみるだけなら、実行形式だけで十分です。 実行形式(60KB) ソース(75KB) マニュアル(20KB) ライブラリソース(34KB) これらのアーカイブの転載は自由です。但し、事後でも結構ですので、 転載の旨メールを下さい。カベソンに関する転載報告や要望質問等は、 ockeghem まで連絡下さいますようお願い致します。 カベソンの実行には、アセンブラとリンカが必要となります。Microsft MASM/LINKの組み合わせか、B
http://b.hatena.ne.jp/entry/www.tokumaru.org/d/201... ×62 : 19, 12, 12, 5, 3, 2, 2, 2, 1, 1, 1, 1, 1 http://b.hatena.ne.jp/entry/www.tokumaru.org/d/200... ×61 : 15, 6, 6, 5, 4, 3, 3, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1 http://www.fotolink.su/ ×8 http://b.hatena.ne.jp/entry.touch/www.tokumaru.org... ×7 : 5, 1, 1 http://php.designlinkdatabase.net/data/search_2000... ×7 : 1, 1, 1, 1, 1, 1, 1 htt
_PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因 前回のブログ「PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合(脆弱性)あり」にて、PHP5.3.6(本エントリ執筆時点での最新版)からPDOにてサポートされた文字エンコーディング指定がWindows版では正しく動作しないことを報告しました。Linuxでは正常に動作するので不思議だなという話になっていたのですが、千葉征弘さん(@nihen)が調べてくださった結果がtwitter上で発表されました(toggerによるまとめ「PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合にまつわる件」)。この件につき、当ブログでも報告します。 問題点の復習 PHP5.3.6以降のPDOでは、データベースに接続する際の文字エンコーディングを
_PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合(脆弱性)あり PHP5.3.6からPDO/MySQLにてデータベースの接続文字列にて文字エンコーディングが指定可能となりました。この機能を検証した結果、Linux上では正常な動作を確認しました。Windows版でも一見動作するようですが、動的プレースホルダ内部のエスケープ処理に不備があり、Shift_JISでデータベースと接続している際にSQLインジェクション脆弱性の可能性があります。 きっかけ @haruyamaさんのツイートがきっかけで、PHP5.3.6からPDOの文字エンコーディング指定が有効となったことを知りました。 PHP 5.3.6以降では PDO/MySQLのDSNでのcharset指定が有効になったようです. (MySQL 4.1.11以降, MySQL 5.0.7以降, もし
_問題点の概要 CodeZineから発表されている「PHPで作成する携帯会員サイトの基本」という記事はツッコミどころ満載で、既にいくつかの問題が修正されているのだが、まだ残っている問題があることや、修正内容にも疑問があるので、いくつか指摘してみたい。ざっと書いたところ、ものすごく長くなりそうだったので、小出しで「連載」の形で書く。忙しいので途中でやめるかもしれない。今回は、問題点の概要を報告する。 くだんの記事をざっと見たところ、以下の問題を見つけた。 IPアドレス制限のない「かんたんログイン」 Net_UserAgent_Mobileを用いて携帯電話の端末IDを取り出し、かんたんログインを実装しているが、ゲートウェイのIPアドレス経由であることを確認していない。以下のリストは、端末IDを取り出しているところ(4ページ目)。 $agent = Net_UserAgent_Mobile::s
Black Hat Japan 2007における金床氏のプレゼンテーションや金床本で、Javaアプレットに対するDNSリバインディングの手法が説明されている。ここしばらく、その追試を行っていた。結論としては、金床氏の方法にはJRE側で対策がとられていたので報告する。 金床氏が報告しているDNSリバインディングの手法とは以下のようなものだ(金床本に説明されている方法)。 被害者のユーザにワナのページをPROXY経由で閲覧させる ワナのドメイン(FQDN)に対するIPアドレスを変更する ワナページ上で数秒~数十秒のちにJavaScriptによりJavaアプレット用のHTMLをレンダリングする JREがアプレットをPROXY経由で*1ダウンロードする アプレットのダウンロード時点で既にDNSレコードは書き換わっているが、PROXYがDNSキャッシュしているため、アプレットは正常にダウンロードされ
_ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された twitterのケータイ版twtr.jpにおいて、DNS Rebindingによるなりすましを許す脆弱性が発見され、1/15に通報したところ、その日のうちに修正された。以下、その経緯について報告する。 経緯 今年の1月12日に読売新聞の記事が出たのを受けて、現実のサイトはどうなのだろうかと改めて気になった。 NTTドコモの携帯電話のうち、インターネット閲覧ソフト「iモードブラウザ2・0」を搭載した最新29機種を通じて、利用者の個人情報を不正取得される恐れのあることが、専門家の指摘で明らかになった。 同社は携帯サイトの運営者にパスワード認証などの安全対策を呼びかけている。携帯電話の機能が高機能化するにつれ、こうした危険は増しており、利用者も注意が必要になってきた。
_かんたんログイン手法の脆弱性に対する責任は誰にあるのか id:ikepyonの日記経由で、NTTドコモのサイトに以下のセキュリティ・ガイドラインが掲示されていることを知った。 iモードブラウザ機能の多様化により、機種によってiモードサイトにおいてもJavaScriptを組み込んだ多様な表現、CookieやReferer情報を有効に活用したサイト構築が行えるようになりました。 しかし、PC向けインターネットサイト同様に、セキュリティ対策が十分に行われていないサイトでは、そのサーバの脆弱性を突き(クロスサイトスクリプティング、SQLインジェクション、DNSリバインディングなど様々な攻撃手法が存在しています)、これらの機能が悪用される危険性があります。十分にご注意ください。 [作ろうiモード:iモードブラウザ | サービス・機能 | NTTドコモより引用] XSSやSQLインジェクションと並ん
_iモードブラウザ2.0のXMLHttpRequestでPOSTデータの扱いが困難になった このエントリでは、iモードブラウザ2.0の制限により、XMLHttpRequestでPOSTメソッドの利用が困難になっていることを確認したので報告する。 iモードブラウザ2.0のJavaScriptを試していて、POSTメソッドでデータが渡せていないことに気がついた。以下のようなプログラムで検証してみた。 【post.html】 <html> <head> <script> function test() { try { var requester = new XMLHttpRequest(); requester.open('POST', '/dumppost.php', true); requester.onreadystatechange = function() { if (requeste
_quoteメソッドの数値データ対応を検証する このエントリでは、PerlのDBI、PHPのPDO、MDB2にて用意されているquoteメソッドが数値データをどのように扱えるかを検証しました。結論としてMDB2が合格、それ以外は不合格で、とくにDBD::mysqlを使用した場合、脆弱性といってもよいような結果となりました。 概要 DBI、PDO、MDB2は、いずれもデータベースアクセスを抽象化したモジュール(クラス)であり、汎用的な記述によりさまざまなデータベースを利用できるように工夫されています。これらモジュール(クラス)にはquoteというメソッドが用意されています。DBIのquoteメソッドの呼び出し例を示します。 my $dbh = DBI->connect('DBI:mysql:dbname:localhost', 'user', 'pass'); print $dbh->quo
_文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト(言語、フレームワークなど)か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
_携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以来2ヶ月以上が経つものの、未だにJavaScript機能は利用できない状態のままだ。 実は、NTTドコモ社が慌てふためいてJavaScript機能を急遽停止
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く