_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
ブックマーク / www.tokumaru.org (12)
-
hasegawayosuke 2010/01/18
-
論点の整理: 文字エンコーディングバリデーションは自動化が望ましい - 徳丸浩の日記(2009-09-18)
_文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不
-
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
-
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機能を急遽停止
-
文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
-
書籍「はじめてのPHPプログラミング基本編5.3対応」にSQLインジェクション脆弱性 - 徳丸浩の日記(2008-10-29)
id:hasegawayosuke氏にそそのかされるような格好で、「はじめてのPHPプログラミング基本編5.3対応」という書籍を購入した。 本書は、ウノウ株式会社の下岡秀幸氏、中村悟氏の共著なので、現役バリバリのPHP開発者が執筆しているということ、下記のようにセキュリティのことも少しは記述されているらしいという期待から購入したものだ。 目次から抜粋引用 07-07 Webアプリケーションのセキュリティ [セキュリティ] 08-04 データベースのセキュリティ [SQLインジェクション] 09-13 セキュリティ対策 [セキュリティ] 本書をざっと眺めた印象は、「ゆるいなぁ」というものであるが、その「ゆるさ」のゆえんはおいおい報告するとして、その経過で致命的な脆弱性を発見したので報告する。 問題の報告 それは、本書P280に登場する「SQLインジェクション対策用の関数(dbescape)」
-
XSS: 今こそXSS対策についてまとめよう - 徳丸浩の日記(2008-08-22)
_今こそXSS対策についてまとめよう 沢出水（さわ いずみ）さんからトラックバックを頂戴した。 元々はホワイトリスト方式の優位は神話というエントリでホワイトリストはどう作る?を引用(批判)した事が発端の模様です。 一見真っ向対決しているようなので興味深く読ませていただいたのですが、正直、両者の主張の違いがわかりません。 どちらもXSS等インジェクション系の対策としてはアプリケーションで入力値が正しい形式の範囲内かチェックし、出力時に必要なエスケープ処理を行う、という結論に思えるんですけど… [ホワイトリストとブラックリストより引用] ご指摘の通りで、XSS対策は入り口でのバリデーションと表示(HTML組み立て)時のエスケープだ。しかし、元ブログの主題はホワイトリストとブラックリストの比較なので、「ただ、表面的に文章を追っただけでは『何をホワイトリストと呼ぶのか』という部分がだいぶ違う印象を
-
ホワイトリスト: プログラミングではホワイトリスティングが基本ではない - 徳丸浩の日記(2008-08-20)
_プログラミングではホワイトリスティングが基本ではない 大垣さんのブログにて反論をいただいた。 プログラミングではホワイトリスティングが基本 ホワイトリストはどう作る? 長文のエントリで、「暇な方だけお付き合いください」と書かれている。あいにく締め切りを抱えていて暇ではないのだが、名指しで反論されている以上、放置するのも失礼なので、簡潔にコメントしたい。 私は、一応セキュリティの専門家の端くれのつもりで、XSS Cheat Sheetをはじめ、大垣さんや金床さんの本にも目を通している。しかし、大垣さんの上記2エントリは、私にはさっぱり理解できない。以下、プログラミングの局面で、XSS向けのホワイトリストが作成可能なのかというポイントに絞って議論する。 プログラミングの基本は仕様に忠実であること 大垣さんが具体的な「ホワイトリストの作り方」を提示してくれないので、どのようなホワイトリストをイ
-
複文が利用できるデータベースの調査(2): SQL Serverが狙われるにはまだまだ理由がある - 徳丸浩の日記(2008-06-27)
_SQL Serverが狙われるにはまだまだ理由がある 徳丸浩の日記 - 複文が利用できるデータベースの調査 - SQL Serverが狙われるには理由があるにおいて、SQLインジェクションで別のSQL文を注入するためには、複文のサポートが必要で、SQLインジェクションの文脈でこれが可能であるDBMSはMS SQL ServerとPostgreSQLであることを示した。 ここで、複文を記述するには、セミコロン「;」で複数のSQL文を区切ると説明していたが、マイクロソフトの公表している文書によると、SQL Serverにおいては、複文の区切りにセミコロンは必要ないことが分かったので報告する 注意 複数の SQL ステートメントを区切るのに、セミコロンは必ずしも必要ありません。必要かどうかは、ベンダまたはインプリメンテーションによって異なりますが、Microsoft SQL server では
-
アンチ「サニタイびんぷ」: 画像版サニタイズ言うな(2) - 徳丸浩の日記(2007-08-21)
_ 画像版サニタイズ言うな(2) 前回のエントリーの後、mod_imagefightのコマンドライン版を作ったりして、検証してみました。まだ検証途中ですが、今回はBMP形式についてのアンチmod_imagefightについて紹介します。 まず、BMP形式のヘッダは以下のようになります(カッコ内はバイト数)。 0000:MARK(2) ='BM' 0002:ファイルサイズ(4) 0006:予約1(2) =0 0008:予約2(2) =0 000A:ビットマップ開始位置(4) 000E:ヘッダサイズ(4) =0x28 0012:イメージ横幅(4) 0016:イメージ高さ(4) 001A:プレーン数(2) =1 001C:ピクセルあたりのビット数(2) 1,4,8,24 001E:圧縮形式(4) =0,1 0022:圧縮後のイメージサイズ 0026:水平解像度(4) 002A:垂直解像度(4)
-
オブジェクト指向プログラム言語としてのJavaScript
このページでは、JavaScriptのオブジェクト指向言語としての側面を研究します。 JavaScriptは、HTMLの拡張という側面が注目されていますが、 プログラム言語として見た場合にも、興味深い独自の特徴がたくさんあります。 このページでは、これらJavaScriptの言語としての特性、 特にオブジェクト指向言語としてJavaScript を見た場合の特徴について詳しく研究を試みます。 JavaScriptは、ほぼ完全なオブジェクト指向言語です。プログラマによるクラス定義、プロパティ定義、メソッド定義ができます。継承は、言語の基本機能としては用意されていませんが、基本機能の組み合わせにより実現できます。 メソッドのバインディング(binding)はレイトバインディング（late binding）です。これは、JavaScriptが変数の型のない言語だからです。 JavaScriptに
-
オブジェクト指向プログラム言語としてのJavaScript
このページでは、JavaScriptのオブジェクト指向言語としての側面を研究します。 JavaScriptは、HTMLの拡張という側面が注目されていますが、 プログラム言語として見た場合にも、興味深い独自の特徴がたくさんあります。 このページでは、これらJavaScriptの言語としての特性、 特にオブジェクト指向言語としてJavaScript を見た場合の特徴について詳しく研究を試みます。 JavaScriptは、ほぼ完全なオブジェクト指向言語です。プログラマによるクラス定義、プロパティ定義、メソッド定義ができます。継承は、言語の基本機能としては用意されていませんが、基本機能の組み合わせにより実現できます。 メソッドのバインディング(binding)はレイトバインディング（late binding）です。これは、JavaScriptが変数の型のない言語だからです。 JavaScriptに
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました