[PR]小規模ECサイトに最適なWAF、SiteGuard Lite
徳丸浩の日記
2010年01月18日
_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 (requester.readyState == 4) {
onloaded(requester);
}
};
requester.setRequestHeader("Content-Type" , "application/x-www-form-urlencoded");
requester.send("aaa=bbb&ccc=ddd");
} catch (e) {
res = requester.responseText;
document.getElementById('result').innerHTML = e.toString();
}
}
function onloaded(requester) {
res = requester.responseText;
document.getElementById('result').innerHTML = res;
}
</script>
</head>
<body>
<input type=button value="go" onclick="test()">
<div id="result"></div>
</body>
</html>
【dumppost.php】
<?php
echo "aaa=" . htmlspecialchars($_POST['aaa'], ENT_QUOTES, 'Shift_JIS') . "<br>";
echo "ccc=" . htmlspecialchars($_POST['ccc'], ENT_QUOTES, 'Shift_JIS') . "<br>";
?>
実行結果は、以下のようになった。まずはChromeのものだが、IEやFirefoxでも同等の結果だ。
次に、ドコモP-07Aによる結果
ドコモの場合を検証するために、Webサーバーに来ているリクエストをキャプチャしてみた。
POST /dumppost.php HTTP/1.1 X-UE-Version: 1 Host: XXXXXXXXXXXXX User-Agent: DoCoMo/2.0 P07A3(c500;TB;W24H15) Content-Type: text/xml Content-Length: 15 aaa=bbb&ccc=ddd
ご覧のようにPOSTデータそのものは送信されてきているが、Content-Typeがtext/xmlになっているために、Webアプリケーション側で受け取れないようだ。
JavaScript側では、この値をapplication/x-www-form-urlencodedに変更しているが、P-07AでもJavaScriptが再開され、あらたな制限がみつかったで報告したように、setRequestHeaderが無効化されているために、この設定が無視されていることが原因のようだ。
これは明らかに、setRequestHeader無効化の副作用であるが、その代償は大きいように思う。PHP以外に、ASP/ASPX、J2EE(JSP)にこのデータを入力してみたが、いずれも値を読み取ることはできなかった。一方、PerlのCGIモジュールでは、POSTDATAという名称のデータとして、POSTデータ全体を読み取ることができた。Perl以外の場合でも、Webサーバーにデータ自体は到達しているのだから値を利用する手段はあるかもしれないが、私が調べた範囲では分からなかった。
上記の結果として、AjaxでPOSTメソッドを扱うには、標準的でない方法を用いる必要があるわけだが、その方法を検討してみた。
- POSTをあきらめてGETを使う
- Perlのように、text/xml形式のデータを読み出せる言語を選択する
- DOMにより、IFRAME内にFORMを作成してSUBMITする
このうち、上記1.については、セキュリティ上の問題が発生し得る。Ajaxのセキュリティ対策として、「GETメソッドを拒絶する」という方法があるからだ。具体的には、SCRIPT要素を使ってSame Origin Policyを回避してAjaxデータを読み出す手法に対抗して、SCRIPT要素では必ずGETメソッドになることから、POSTのみを許容することで対策するという方法だ。既存のアプリケーションがこのような手法によりセキュリティ対策されている場合に、安易にGETメソッドを許容してしまうと、セキュリティホールが混入することになりかねない。
3.については、私が試した範囲ではうまくいっていない。JavaScriptからIFRAME内のFORM操作がうまくいかないのだ。これも、ひょっとすると制限を掛けているのかもしれない。アドホックな方法ならありそうだが、まだ十分に検証できていない。
一つの疑問は、このような情報がインターネット上に見あたらないことだ。AjaxでPOSTメソッドが使えないというのはとんでもないことだが、検索してもそのような情報がみあたらないのだ。iモードブラウザ2.0のAjaxを誰も使っていないのか、それとも事業者が恐ろしくて口をつぐんでいるのか。
しかし、このような技術情報が流通していかない限り、iモードブラウザ2.0のJavaScriptを使ったコンテンツは普及していかないだろう。NTTドコモにはさらなる情報開示を期待したいし、ケータイWebの開発者にも、もっとブログなどでの情報公開を期待する。
- https://www.google.co.jp/ ×424
- http://www.tokumaru.org/ ×27
- http://neta.ywcafe.net/001221.html ×9
- https://www.google.com/ ×9
- http://d.hatena.ne.jp/ockeghem/20100804/p1 ×7
- http://neta.ywcafe.net/001144.html ×6
- http://neta.ywcafe.net/ ×3
- https://www.bing.com/ ×2
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×2
- https://search.yahoo.co.jp/ ×2
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×1
- https://www.google.com/url?sa=t&rct=j&q=&esrc=s&so... ×1
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×1
- https://www.google.de/ ×1
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×1
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×1
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×1
- https://www.facebook.com/ ×1
- http://www.tokumaru.org/d/20100118.html ×1
- http://www.sogou.com/sogou?query=XMLHttpRequest2.0... ×1
- http://websearch.excite.co.jp/?q=iモード javascript a... ×1
- http://search.smt.docomo.ne.jp/result?search_box=ポ... ×1
- http://search.mobile.yahoo.co.jp/onesearch/?sbox=S... ×1
- http://search.fenrir-inc.com/?q=XMLHttpRequest mod... ×1
- http://search.babylon.com/?q=php post 内容がない Conten... ×1
- http://neta.ywcafe.net/2012/06/ ×1
- http://melma.com/backnumber_151235_5954175/ ×1
- setRequestHeader imode ×4 / imodeブラウザ javascript ×2 / i-mode browser 2.0 javascript ×2 / jsp postデータ 全体 ×1 / post application/x-www-form-urlencoded ×1 / setRequestHeader ServletRequest java ×1 / Application POST ×1 / imode javascript http ×1 / XMLHttpRequest imode sendできない ×1 / php ドコモ POST ×1 / 携帯 メソッド対応 POST ×1
[PR]小規模ECサイトに最適なWAF、SiteGuard Lite
HASHコンサルティング株式会社
最近の記事
- 2011年08月30日
- 1. RSSフィードをリダイレクトします
- 2011年07月01日
- 1.
- 2011年03月29日
- 1. PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因
- 2011年03月22日
- 1. PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり
- 2011年01月27日
- 1. CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
- 2011年01月04日
- 1. escapeshellcmdの危険な実例
- 2011年01月01日
- 1. PHPのescapeshellcmdの危険性
- 2010年10月03日
- 1. 問題点の概要
- 2010年09月27日
- 1. 文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
- 2010年07月25日
- 1. ツッコミSPAM対策で、ツッコミ抜きのRSSフィードを用意しました
- 2010年07月01日
- 1. ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
- 2010年04月06日
- 1. PROXY（プロキシ）経由でのDNSリバインディングと対策
- 2010年04月05日
- 1. JavaアプレットのDNSリバインディングはJRE側で対策済みだった
- 2010年03月29日
- 1. DNSリバインディングによる無線LANパスフレーズの読み出しに成功
- 2010年03月25日
- 1. DNSリバインディングによるルータへの侵入実験
- 2010年02月22日
- 1. ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された
- 2010年02月12日
- 1. かんたんログイン手法の脆弱性に対する責任は誰にあるのか
- 2010年01月18日
- 1. iモードブラウザ2.0のXMLHttpRequestでPOSTデータの扱いが困難になった
- 2009年10月19日
- 1. quoteメソッドの数値データ対応を検証する
- 2009年10月14日
- 1. htmlspecialchars/htmlentitiesはBMP外の文字を正しく扱えない
- 2009年10月09日
- 1. htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
- 2009年09月30日
- 1. htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか
- 2009年09月24日
- 1. SQLの暗黙の型変換はワナがいっぱい
- 2009年09月18日
- 1. 文字エンコーディングバリデーションは自動化が望ましい
- 2009年09月14日
- 1. 既にあたり前になりつつある文字エンコーディングバリデーション
- 2009年08月05日
- 1. 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性
- 2009年03月28日
- 1. IPAは脆弱性の呼び方を統一して欲しい
- 2009年03月27日
- 2009年03月11日
- 1. U+00A5を用いたXSSの可能性
- 2008年12月22日
- 1. JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性
formのactionに直接パラメータを積むとか？
xml形式のデータをsubmitしたら読み取れる?
masaさん、twkさん、コメントありがとうございます。
formのactionにパラメータ積んだら、それは実質的にGETということになりませんか?
xml形式のデータをSUBMITというのは、実はやってみたのですが、PHP、ASP/ASP.NETなどではうまく受け取れていません。やり方があるのかもしれませんが、私は知りません。
PHP なら、php://input でデータを取得できるのではないでしょうか？
file_get_contents('php://input');
http://www.php.net/manual/ja/wrappers.php.php
Kenjiさん、コメントありがとうございます。php://inputというものがあるのですね。確認したところ、確かにデータを取得できました。
サーバサイドJavaの場合、ServletRequestのgetInputStreamからストリームとして取得できます
ASP.NETの場合なら、HttpContext.Current.Request.InputStreamから読めると思います。
ストリームとして取得して自分で分解する方法で対応しようと思えば出来る状況だとしても、（それまでに比べて）手順がフクザツなので、「あきらめてGETを使う」に流れてしまう開発者も多そう。setRequestHeaderが少なくとも"Content-Type"に対しては今までどおり動作するように再改修されることが望まれますね。。
記事とは関係ないコメントですいません
http://nat-q.jp/ctg3/q_detail.php?no=10340
ユーザ同士で質問を回答するサイトの1ページなのですが
iモードブラウザ2.0ブラウザによる乗っ取りなのでしょうか?
自分では判断できないので検証していただきたいです
(ちがうなら、あたしの勘違いでいいのですが
あたりなら実害が出ているとドコモなどへ報告していただきたいです)
姫さん
質問を見てみましたが、これはご本人がドコモショップに相談に行くのがよいと思います。あくまで想像ですが、のっとりなどではないような気がします。
最近は携帯電話を購入すると、必要のないコンテンツを購入させられて「いらなければ直ぐに解約してください」と言われることがよくあります。そのたぐいの話で、ショップの店員が説明していなかったとか、説明を聞き漏らしていたとか、理由は無数に考えられます。
コメントいただいた皆様、ありがとうございました。
さすがに、言語毎に方法はあるのですね。
ですが、あまり知られていない方法を使わないといけないこと、そのための説明などがドコモの解説などにないことから、やはりPOSTデータの扱いは「困難」だなと思います。
この問題は引き続きウォッチしたいと思います。ありがとうございました。