i-mode2.0は前途多難 - ockeghem's blog
既に発表されているように、NTTドコモの夏モデルからi-modeの仕様が大幅に拡張され、JavaScript、Cookie、Refererに対応するようになった。これら仕様変更はセキュリティの面からも影響が大きいため、私は夏モデルの中から、P-07Aを発売開始日(5月22日)に購入した。そして、リリースどおりJavaScript、Cookie、Refererが動作することを、実機にて確認した。 ところが、P-07Aと同日に発売開始されたN-06Aは、その日のうちに一時販売停止のお知らせが出る。 この度、弊社の携帯電話「N-06A」において、iモード接続時の不具合が確認されましたので、販売を一時見合わせさせていただきます。 なお、本事象に伴い、本日発表いたしました「N-08A」の販売開始日につきましても、5月28日から延期となります。 「N-06A」の販売再開及び「N-08A」の販売開始時期
書籍『Ajaxセキュリティ』に関する残念なお知らせ - ockeghem's blog
昨年の10月に刊行された書籍Ajaxセキュリティは，発刊直後に購入したが，しばらく積ん読になっていた。最近になって読み始めたのだが，いささかあきれる結果となった。HPの現役エンジニア2名の著作，一人は元SPI Dynamics社(WebInspectの開発元，HPが買収)出身，GIJOE氏の監訳ということで期待していたのだが，残念である。 残念だと思う主要な理由は，脆弱性への対策が十分に示されていないことだ。Ajaxであってもインジェクション系脆弱性が発生する可能性があること，むしろ従来型のWebアプリケーションよりもその可能性が広がることは説明されているが，肝心の対策が不十分だ。 本書第四章の後半には，対策として入力検査（バリデーション）が示されている。 4.6 適切な入力検査 4.7 リッチなユーザ入力のバリデーション しかし，入力検証だけでは，任意の文字入力を許す場合の対策はできない
「\%foo」から始まる文字列を検索するクエリをハードコーディングする - ockeghem's blog
SQLのエスケープと聞いてやってきましたよ。2008-07-10 - T.Teradaの日記から 例えば、「\%foo」から始まる文字列を検索する場合には、どのようなSQL文を書けばよいのでしょうか。 条件は以下の通りです。 1. DBMSソフトはMySQL 2. ESCAPE節は使わない 【中略】 「\%foo」から始まる文字列を検索するSQL文は、以下のようになります。 mysql> SELECT 123 FROM dual WHERE '\\%foo456' LIKE '\\\\\\%foo%'; MySQLの場合、文字列リテラルのエスケープとLIKE述語のワイルドカード(「%」、「_」)に対するエスケープの両方に「\」を使うので、こういうややこしいことになりますね。T.Teradaさんが書かれているように、以下のように考えるのがよいと思います。 LIKEに与える文字列のエスケープ処
コメント masa (2008/02/29 18:31) - パスワードの定期変更は「神話」なのか? - ockeghem(徳丸浩)の日記
ITProの記事が契機となって、PCIDSS（PCIデータセキュリティ規準）およびパスワードに関する規定が話題となっている*1。 「パスワードは90日ごとの変更」が義務づけられる！？ | 日経 xTECH（クロステック） それに対して，PCIDSSは表現が具体的である。現在のバージョン1.1ではパスワードについて下記のような規定がある。 ■要件8.5.8 グループ、共有または汎用のアカウントとパスワードを使用しないこと。 ■要件8.5.9 ユーザー・パスワードは少なくとも90日ごとに変更する。 http://itpro.nikkeibp.co.jp/article/OPINION/20080220/294287/ このうち、要件8.5.9「ユーザー・パスワードは少なくとも90日ごとに変更する」に関して疑問を持った。これはいわゆる「セキュリティの常識」という奴の一つではあるが、実際のところ、
これはMITMですか - ockeghem's blog
ITproにWebメール狙うサイド・ジャッキング | 日経 xTECH（クロステック）と言う記事が。 7月末に米国・ラスベガスで開催されたセキュリティ・カンファレンス「BlackHat USA2007」で，無線LAN越しにWebメールのセッションをハイジャックするデモが行われた。端的に言えばHTTPの通信の盗聴である。 ちょっと気になった点があるので、備忘録的に書いてみます。 特徴は，無線LANの通信パケットをキャプチャし，人がデータの内容を盗み見て解析する点である。いわゆるMan in the Middle（中間者）攻撃だ。 サーバーとクライアントの通信に割り込む訳ではないので、中間者攻撃とは言わないと思います。 中間者攻撃の権威ある定義・解説は中々見当たらないのですが、例えば、産総研の脚注で見つけた以下の解説。 ◆ 中間者攻撃 (Man-in-the-middle Attack) クラ
クイズ:XSSとCSRFはどこにありますか? - ockeghem's blog
先の日記(XSSはブラウザ上でスクリプトが動き、CSRFはサーバー上でスクリプトが動く - ockeghem(徳丸浩)の日記)は、仕込んだネタがあたって多くの方に読んでいただいた。細かい内容については、頂戴した批判や反省もあるが、このテーマに対して多くの関心を集めることができたのは良かったと思う。今回も、手を変え品を変えて、XSSとCSRFの違いを説明しよう。ということで、今回はクイズ仕立てにしてみた。 といっても、非常に簡単なクイズだ。 認証を必要とする会員制サイトmaitter.comで、個人情報を入力する画面がある。典型的な、入力(A)-確認(B)-登録(C)という画面遷移（下図）を想定した場合、 XSSが発生しやすい画面を一つあげよ CSRFが発生しやすい画面を一つあげよ というものだ(入力画面は初期入力のみ想定)。エラー時の挙動などは指定されていないので想定しないものとする。 解
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
