タグ

ブックマーク / ockeghem.hatenablog.jp (6)

  • XMLHttpRequestから送られてくるHTTPリクエストヘッダ - ockeghem's blog

    以下のようになります。CGIでHTTP_で始まる環境変数を列挙したものです。 HTTP_USER_AGENT=DoCoMo/2.0 P07A3(c500;TB;W24H15) HTTP_COOKIE=≪Cookie値≫ HTTP_X_UE_VERSION=1 HTTP_HOST=≪ホスト名≫これは、通常のリクエストと全く同じで、XMLHttpRequestを区別するためのリクエストヘッダはありません。 追記(2009/11/18) PCのブラウザの場合、もう少しヘッダが多くつくことと、際だった違いとして、Refererが付与されることがあります。なぜ付与しないのですかね。ちなみに、SCRIPT要素のSRC属性で呼び出した場合はRefererが付与されます…なんて書いたらSCRIPT要素からのRefererも削除されかねませんな。

    XMLHttpRequestから送られてくるHTTPリクエストヘッダ - ockeghem's blog
    teruwyi
    teruwyi 2009/11/25
  • 正規表現で「制御文字以外」のチェック - ockeghem's blog

    一般に、セキュアコーディングの基として入力値の検証(Validation)をせよということになっていますが、これが変な方向に行くといわゆる「サニタイズ」のような手法になってしまいます。以前も指摘したように、アプリケーションとしてのValidationは仕様に従って行うべきものです。 ですが、概ねどの場合でも行うべき検証として以下があると思います。 文字エンコーディングの妥当姓 制御文字(\x00〜\x1f, \x7f)のチェック 文字列長のチェック このうち後ろ二つを正規表現として書くにはどうすればいいかを考えていました。つまり、「制御文字以外の文字でm文字以上n文字以下」というようなチェックです。m文字以上、n文字以下は、{m,n}で書けるので、問題は「制御文字以外の文字」です。これはtextタイプのinput要素で、かつアプリケーション仕様としては文字種の制限をしない場合を想定してい

    正規表現で「制御文字以外」のチェック - ockeghem's blog
  • i-mode2.0は前途多難 - ockeghem's blog

    既に発表されているように、NTTドコモの夏モデルからi-modeの仕様が大幅に拡張され、JavaScriptCookie、Refererに対応するようになった。これら仕様変更はセキュリティの面からも影響が大きいため、私は夏モデルの中から、P-07Aを発売開始日(5月22日)に購入した。そして、リリースどおりJavaScriptCookie、Refererが動作することを、実機にて確認した。 ところが、P-07Aと同日に発売開始されたN-06Aは、その日のうちに一時販売停止のお知らせが出る。 この度、弊社の携帯電話「N-06A」において、iモード接続時の不具合が確認されましたので、販売を一時見合わせさせていただきます。 なお、事象に伴い、日発表いたしました「N-08A」の販売開始日につきましても、5月28日から延期となります。 「N-06A」の販売再開及び「N-08A」の販売開始時期

    i-mode2.0は前途多難 - ockeghem's blog
    teruwyi
    teruwyi 2009/05/29
  • 「なぜPHPアプリにセキュリティホールが多いのか?」のセキュリティホール - ockeghem's blog

    大垣靖男さんの連載から 第21回 文字エンコーディングとセキュリティ(3):なぜPHPアプリにセキュリティホールが多いのか?|gihyo.jp … 技術評論社 一見この動作は無害のように思えるかもしれませんが,ブラウザなど,“\”がエスケープ文字になっているシステムでは重大な問題となります。 <div height="<?php echo addslashes($height); ?>" width="<?php echo addslashes($width); ?>"> この記事が公開された当初,上記のechoが抜けていた。しかし,echoがないと,プログラムの正常系としても動作しない。どこかから,突っ込みが入ったのであろう,その後echoが追加された。 しかし,まだ根的におかしい。 なぜなら,以下の部分が間違っているからだ。 ブラウザなど,“\”がエスケープ文字になっているシステム

    「なぜPHPアプリにセキュリティホールが多いのか?」のセキュリティホール - ockeghem's blog
    teruwyi
    teruwyi 2009/02/20
  • hiddenのあまりにも馬鹿げた使い方 - ockeghem's blog

    これは面白い yohei-y:weblog: ステートレスとは何か では、ステートレスな場合はどうなのか。 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ハンバーガーセットをポテトでお願いします 店員: ドリンクは何になさいますか? 客: ハンバーガーセットをポテトとジンジャーエールでお願いします 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします 店員: 以上でよろしいですか? 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上 店員: かしこまりました 引用元には明記されていないが、客の延々とした繰り返し部分は、ホストからhiddenフィールドで渡されてきたものを返し

    hiddenのあまりにも馬鹿げた使い方 - ockeghem's blog
  • XSS対策:JavaScriptのエスケープ(その4) - ockeghem's blog

    XSS対策:JavaScriptのエスケープ(その3) - ockeghem(徳丸浩)の日記にて、JavaScriptのリテラルを動的生成する場合のエスケープ方法について検討したが、id:hoshikuzuさんから、考慮がもれているという指摘を受けた(http://d.hatena.ne.jp/hoshikuzu/20071011#p1:TITLE=2007-10-11 - hoshikuzu | star_dust の書斎 - JavaScriptエスケープについて論考)。 上記は長いエントリーではあるが、要約すると、特定文字エンコードの特定のバイト●に対して、特定ブラウザにおいて「●\」が一文字「■」として解釈されるため、「"」に対するエスケープ「\"」が破綻するという意味に解釈した。 興味深い内容であるので、以下に考察してみよう。 なぜエスケープが破綻するのか 上記のようなケースはさ

    XSS対策:JavaScriptのエスケープ(その4) - ockeghem's blog
  • 1