構造化テキストの間違ったエスケープ手法について : 404 Blog Not Found
2010年09月22日21:30 カテゴリLightweight Languages 構造化テキストの間違ったエスケープ手法について 昨晩のtwitter XSS祭りは、ふだんもtwitter.comは使わない私には遠くの祭り囃子だったのですが、せっかくの自戒の機会なので。 Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について 正しいアプローチは、全てのルールを同時に適用することです。 これは残念ながら(おそらく)必要条件であっても十分条件ではありません。 こういう(かなりええかげんな)正規表現でtweetをparseしていたとします。 re_http = '(?:https?://[\\x21-\\x7e]+)'; re_user = '(?:[@][0-9A-Za-z_]{1,15})'; re_hash
Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について
昨日の Twitter の XSS 騒ぎは、まだ皆さんの記憶に新しいことと思います。いい機会なので、ツイートのような構造化テキストのエスケープ手法について触れておきたいと思います。 Twitter のメッセージは、単なる平文（プレインテキスト）ではなく、「@英数字」のような他のユーザーへの言及と「http://〜」のような URL を自動的にハイパーリンク化する構造化テキストです。 このような複数のルールをもつ構造化テキストを HTML 化する際には、どのようなコードを書けばいいのでしょう？ まず「@〜」をリンク化してから、URL をリンク化すればいいのでしょうか？ それだと、@〜 のをリンク化した A HREF タグの中の URL がさらにリンク化されていまいますね。 では、URL をリンク化してから @〜 をリンク化すればいいのでしょうか？ それだと、@ を含む URL があった場合に
携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
［はまちちゃんのセキュリティ講座］ここがキミの脆弱なところ…！：第1回 HTTPのしくみを復習しよう｜gihyo.jp … 技術評論社
こんにちはこんにちは ! ! はまちや2です！ 今日からぼくと一緒にWebプログラミングのセキュリティについて、ちょっぴり勉強してみませんか！今回はHTTPがどんなやりとりをしているのか、簡単におさらいしてみましょう！
高木浩光＠自宅の日記 - 新はてなブックマークの登録ブックマークレットは使ってはいけない
はてなブックマーク（以下「はてブ」）がリニューアルされ、ブラウザからブックマークレットでブックマーク登録（以下「ブクマ登録」）しようとすると、図1の画面が現れるようになった。「こちらから再設定をお願いします」と指示されているが、この指示に従ってはいけない。ここで提供されている新型ブックマークレットは使ってはいけない。（この指示には従わなくてもブクマ登録はできる。） 新型ブックマークレットを使用すると図2の画面となる。ブクマ登録しようとしているWebサイト（通常、はてな以外のサイト）上に、はてブの画面のウィンドウが現れている。これは、Ajaxと共に近年よく使われるようになった「ページ内JavaScriptウィンドウ」である。（ポップアップウィンドウとは違い、ウィンドウをドラッグしてもブラウザの外に出すことはできず、あくまでも表示中のページ上のコンテンツであることがわかる。）
ITproのセキュリティ検定がヤバイ | 水無月ばけらのえび日記
更新: 2008年11月7日1時55分頃 こんなのがあったのですね。「ITpro EXPO検定---全11分野で，あなたのIT理解度はいかに？ (itpro.nikkeibp.co.jp)」。 セキュリティ検定の解説もあったので見てみましたが、超難問が3問ほどあったので、独自に解説してみます。 Webブラウザを狙うクロスサイト・スクリプティングは，どのような問題点によって起こるでしょうか。 A） クライアントOSの弱点（ぜい弱性） B） Webブラウザを使うユーザーの油断 C） Webブラウザの弱点（ぜい弱性） D） Webサーバーの弱点（ぜい弱性） 以上、セキュリティ検定の解説【問題2】 より 「WebサーバやWebブラウザにもクロスサイトスクリプティング脆弱性がある」という知識を問う問題ですね。XSSというと普通はWebアプリケーションの問題ですが、WebブラウザやWebサーバに問題が
レスポンスヘッダ＋改行コード＝脆弱性？！
パーセントエンコードについていろいろ勉強したばかりのクウは、ユウヤに対して、HTTPでのパーセントエンコードについて熱弁を振るっていた。すると、その話に興味を持ったナツさんが話し掛けてきた。 ナツ 「なになに？ なんか面白そうじゃん？」 ユウヤ 「興味ないっていってるんですけどね……。ナツさん、こいつ引き取ってやってくださいよー」 クウ 「最近HTTPとか勉強してるんすよ。いま、パーセントエンコードについて語ってるとこっす！」 ナツ 「おー。なるほどなるほど」 クウ 「やっぱ基礎は大事すね！ 勉強してると実は意外といろいろ知らなかったなーって思って」 ナツ 「うんうん。そういうとこ把握しとくのは大事だよね。感心、感心♪」 ナツさんは、開発チームのリーダーで、分からないことがあると丁寧に教えてくれる、クウの尊敬する人の1人である。 クウ 「まだ基本でつまずいているようじゃ、まだまだナツさんの
ドコモさん，iモードでCookieをサポートしませんか？
Webサイトを作る側にとって，インターネットとiモードで決定的な違いがあるのをご存知だろうか。実は，iモード（NTTドコモ）ではCookieが使えない。このため，iモード向けのWebアプリは，インターネットでは当然の，Cookieによるセッション管理ができないのだ。 iモードは「危険」とされるURLでセッションを管理 Cookieによるセッション管理を簡単に説明しておこう。もともとWebアクセスに使うアプリケーション・プロトコルには「セッション」という概念がない。このため，インターネット向けのWebアプリは，WebサイトからWebブラウザにセッション情報を渡し，次回以降のアクセスではWebブラウザからWebサイトへセッション情報を送ってもらう。こうして，一連のWebアクセスを関連付ける。そのために今どきのWebアプリが使うのが，Cookieという名の短いテキスト・データだ。WebサイトはW
約1年で1000万円――モバイルSuicaの不正利用はなぜ起きた？
JR東日本は11月9日、盗難やスキミングしたクレジットカードの情報を悪用し、モバイルSuicaを不正に利用した被害が約1000万円あったことを明らかにした。 不正利用されたカードの枚数は合計65枚。最初の被害があったのは2006年12月で、2007年10月半ばまで続いた。不正利用分については、JR東日本が全額補償する。 なぜ不正利用が起きた？ モバイルSuicaは、交通乗車券・電子マネーの「Suica」をおサイフケータイで利用できるサービス。モバイルSuica用アプリをおサイフケータイにダウンロードして登録（会員登録）することで利用できるようになる（別記事参照）。 モバイルSuica用アプリに、クレジットカード情報や、オンラインバンクの口座を登録しておくと、そこからチャージ（入金）ができる仕組み。サービス開始当初、モバイルSuicaへの入金は、JR東日本が発行するクレジットカード「VIEW
高木浩光＠自宅の日記 - ケータイWebはそろそろ危険
■ ケータイWebはそろそろ危険 これまでの背景と最近の状況変化 「安全なWebサイト利用の鉄則」にある通り、フィッシングに騙されずにWebを安全に使う基本手順は、（パスワードやカード番号などの）重要な情報を入力する直前に今見ているページのアドレスを確認することなのだが、しばしば、「そのページにアクセスする前にジャンプ先URLを確認する」という手順を掲げる人がいる。しかし、それは次の理由で失当である。 ジャンプ先URLを確認する手段がない。ステータスバーは古来よりJavaScriptで自由に書き換えられる表示欄とされてきたのであり、ジャンプ先の確認に使えない。 ジャンプ先URLを事前に確認したとしても、それが（任意サイトへの）リダイレクタになっている場合、最終的にどこへアクセスすることになるか不明。 そもそも、アクセスする前から、アドレス確認の必要性を予見できるとは限らない。普通は、アクセ
高木浩光＠自宅の日記 - 銀行2.0はまだ来ない
■ 銀行2.0はまだ来ない 4月に、「IE7ユーザーにいまさらSSL2.0を使わせようとする銀行」というブログエントリを見かけた。それによると、Internet Explorer がバージョン7に移行し始めたことを契機に、「SSL 2.0を使用する」に設定変更するよう指示している銀行があるのだという。Internet Explorer 7がセキュリティ上の理由でSSL 2.0をオフに変更したにもかかわらずだ。 例えば武蔵野銀行は、4月の時点で図1の解説を掲示していた。 Internet Explorer7の場合は「SSL2.0を使用する」がチェックされていない場合が多いのでご注意ください。 他にも山形銀行が同様の解説を掲示していた。いったいどうしてこんなことになるのかと、問題点の指摘がてら、なぜ書いているのか聞いてみた（4月に電話で）。すると、だいたいこういうやりとりになった。 ある銀行：
Webアプリケーションを作る前に知るべき10の脆弱性 ― ＠IT
Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP（Open Web Application Security Project）は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日本語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ
はびこる「インジェクション系」のぜい弱性：ITpro
Webアプリケーションのぜい弱性を示す用語として，クロスサイト・スクリプティング，SQLインジェクションといった言葉の認知度はかなり高まった。ブログ・サイトなどでも活発に議論されている。しかし，Webサイトの実態はどうだろうか。 筆者の所属する京セラコミュニケーションシステムでは昨年（2006年），ぜい弱性診断を実施したWebサイトの統計情報「2007年版 Webアプリケーションぜい弱性傾向」を発表した。これによると，パソコン向けWebサイトの48%に致命的なぜい弱性が見つかった。このうちワースト1位はクロスサイト・スクリプティングで56％，2位はSQLインジェクションで11%と，どちらもインジェクション（注入）系のぜい弱性。これらのぜい弱性を持った危険なサイトは依然として存在するのが実情である。 これらWebアプリケーションのぜい弱性があまりなくならない理由はいくつかあるが，以前は「ぜい
2007-03-06
ケータイWebアプリの脆弱性問題は、私の専門分野であるので、もう少し突っ込んでみたいと思う。 高木浩光氏の高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか 携帯電話Webアプリのセキュリティが怪しいという話はいろいろな人から耳にするが、携帯の世界では秘密保持契約による縛りがあって、皆それらを話せない状態になっているようだ。その結果として、脆弱性の実態が明らかにならないばかりか、正しい実装方法の普及が進まない。 この問いかけに対して、技術論ではなく、脆弱性検査を実施した結果の統計情報で回答する。 というには、私の勤務先では、まさにケータイ向けWeb脆弱性診断をやっていて、昨年一年間の脆弱性傾向の統計を発表しているからだ。 https://www.kccs.co.jp/contact/paper_websecurity/index.html このホワイトペーパ
携帯業界の認証事情 - y-kawazの日記
巡回サイトの一つである高木浩光＠自宅の日記で以下のようなエントリーがあった。 高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか ここではいつもの高木氏の口調で、「携帯向けWEBアプリ開発では未だにGETパラメータでセッションIDを渡しており、それはこれまでも何度もいかんことだと言っている。」というような内容が語られている。 確かにWEB+DBの記事に対して高木氏が注釈で言っているように「IPアドレスによる制限に関して書いていない」という点に関してはWEB+DB側の落ち度だと思う。実際これを行わない限り端末IDやユーザID*1による認証が意味をなさなくなってしまうからだ。*2 但し、キャリア毎にIPアドレス制限をする限りにおいては端末IDやユーザIDは偽装不可能*3なので、むしろ他人でも入力可能なパスワード認証よりも強力な認証かもしれません。逆にいえばその認
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IEに依存した Webアプリケーション セキュリティ
IPA セキュア・プログラミング講座：Webアプリケーション編
http://neta.ywcafe.net/000727.html
ソーシャルブックマークユーザーのIDとPASSをいとも簡単に抜き取る手口*ホームページを作る人のネタ帳
メールアドレスから、mixiで住所と電話番号を調べられたそのカラクリ*ホームページを作る人のネタ帳
