HTML::StripScriptsでXSS対策をする - Kentaro Kuribayashi's blog
先日公開した「はて☆すたアンケート」にて、アンケートの説明文をはてな記法で書けるよう、機能追加を行った。その際、Template::Plugin::Hatenaを用いた。これは、はてな記法パーサであるText::Hatena（正確には、そのヴァージョン0.16以下）を、Template::Toolkitのプラグインとして使えるようにしたものである。 はてな記法は、それ自体で全ての文書構造を表現できる、あるいは、はてなダイアリのシステム自体は、はてな記法のみしか許容しないというものではなく、たとえば画像を貼る際には、普通にimg要素を書く必要があるし、また、その他の要素についても、記法が用意されていないものについては、「はてなダイアリーのヘルプ - はてなダイアリー利用可能タグ」に掲載されているものに限り、自分でタグを書くことができる。これは自由度を高める反面で、XSSを誘発し得る潜在的なリ
Atom や RDF を利用したXSS - 葉っぱ日記
Internet Explorer の悪名高い Content-Type: 無視という仕様を利用すると、Atom や RDF/RSS を利用してXSSを発生できることがあります。条件的に対象となるWebアプリケーションは多くはないと思いますが、それでもいくつか該当するWebアプリケーションが実在することを確認しました。以下の例では Atom の場合について書いていますが RDF/RSS でも同様です。 例えば、http://example.com/search.cgi?output=atom&q=abcd という URL にアクセスすると、「abcd」という文字列の検索結果を Atom として返すCGIがあったとします。 GET /search.cgi?output=atom&q=abcd Host: example.com HTTP/1.1 200 OK Content-Type: ap
迷惑メールを「削除」してはいけない - ワークスタイル - nikkei BPnet
迷惑メールを「削除」してはいけない （須藤 慎一＝ライター） 迷惑メールを識別して、「迷惑メールフォルダ」に自動的に振り分ける機能の付いたメールソフトを使っている人は多いだろう。このとき、迷惑メールフォルダにたまった迷惑メールを、無意識に「削除」していないだろうか？ この操作はやめなければいけない。迷惑メールフォルダが備えている安全対策機能を無にしてしまうからだ。 「受信トレイ」を未処理メールの保管場所として使い、処理を済ませたら「削除」する。こういうメール整理術を採用している人がとくに危ない。このタイプの人は、過去メールが必要なったとき、「削除済みアイテム」を探すことが多いからだ。 削除済みアイテムは、迷惑メールフォルダほど安全対策が徹底していない。迷惑メールをかき分けながら必要なメールを探すとき、ついうっかり迷惑メールを見る（開く、あるいはプレビューする）というのはマズいこと
Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル
« Japanize - IE 系の User JavaScript エンジンに対応しました | メイン | 安全な JSON, 危険な JSON (Cross-site Including?) » 2007年01月04日 クロスサイトのセキュリティモデル あけましておめでとうございます。 昨年、社内で「XMLHttpRequest は何故クロスサイトで使えないのか。画像や SCRIPT タグは使えるのに」という疑問 (というより試問) を耳にしました。おもしろい話なのでブログネタにしようと思っていたのですが、新年早々 GMAIL の事例がスラッシュドットされていたので、自分の現時点での理解をまとめてみることにしました。文書を確認して書いているわけではないので、間違いがあれば指摘してください。また、よい参考文献をご存知の方がいらっしゃいましたら、教えていただければ幸いです。 ウェブブラウザ
T.Teradaの日記 - ログイン直後のレスポンスの返し方
多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう？というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して（HTTP1.1では303応答）、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ
hoshikuzu | star_dust の書斎 InternetExplorer6::base要素のstyle属性が全要素に効くのでJavaScriptも記述し放題
下のソースでローカルにHTMLファイルを作りIE6で開く。一行目はおまじないなので省略しない。img要素とかbr要素とかが泣ける。 <!-- saved from url=(0014)about:internet --> <html> <head> <title>nandakore</title> </head> <body> <base id="b00" style="width:expression(setTimeout(this.innerText,0))"> <pre> resizeTo (400, 400); </pre> <img> document.title='areare'; </img> <br> var hoge = 'foo'; </br> <blockquote> window.status = hoge; </blockquote> </body> </html
PHPセキュリティチェックリスト:phpspot開発日誌
Checklist for Securing PHP Configuration | Ayman Hourieh's Blog Inside is a check list of settings that are intended to harden the default PHP installation.PHPセキュリティチェックリスト。 PHPの設定ファイルによってはセキュリティ的によろしくない場合もよくあることなので、そのチェックを行うためのリスト。 allow_url_fopen、register_globals など、一連のphp.iniに関する設定のチェックする際に役立ちます。
PHPで安全なセッション管理を実現する方法
_ 残り容量が数十Mバイトになっていた PCがなんかくそ遅いなーと思ってふと空きディスク容量をみたら、残り数十Mバイトまで減っていた。Folder Size for Windowsで各ディレクトリ単位のディスク使用量をながめてみたところ、 Thunderbirdでimapでアクセスしているアカウントのデータフォルダに、なぜか1GバイトオーバーのINBOXファイルがあった。なにこれ？ 削除したけど別に動作には支障はなし。 puttyのlogが無限に追記されたよ……。数Gバイト。 昔ダウンロードしたCD/DVD-ROMのisoイメージファイルが、そこかしこに消されず残ってたよ。10Gバイトオーバー。 あと、細かいテンポラリディレクトリの中身とか消したら、30Gバイトくらい空いた。そこまでやって久しぶりにデフラグを起動したら、表示が真っ赤（ほとんど全部断片化されている）だったので、最適化実行中。
【PHPカンファレンス2006】PHPで書かれた実際のアプリケーションに潜む危険なコード
「（PHPで書かれたアプリケーションには）アバウトなコードが多い」。エレクトロニック・サービス・イニシアチブの大垣靖男社長は，2006年8月19日に開催されたPHP関連イベント「PHPカンファレンス2006」の講演「危険なコード」で，PHPで書かれたアプリケーションに存在する危険なコードを指摘した。講演の中では，実際に存在するアプリケーションの名前を出し，そのソースコードからセキュリティ上危険な個所を挙げていった。「安全なコードを書くには悪い例も知っておかなければならない」というのが同氏の主張である。 大垣氏はまず，「セキュリティのリスクはサブシステムとの境界の部分で発生する」と指摘した。サブシステムとは，データベース，メール・システム，ユーザーのWebブラウザといった外部のシステムのこと。「境界で入力時にきちんとバリデーション，出力時にきちんとエスケープ処理（フィルタリング）を行えば，か
XSS - 表示系パラメータに存在する盲点 :: ぼくはまちちゃん！
こんにちはこんにちは！！ クロスサイトスクリプティングの時間です！ XSSというと…！ まっさきに思いつくのが、入力データ送信 → 確認表示の部分での無害化漏れですよね！ たとえばこんな感じのフォームから受け取ったパラメータを、 確認として表示するページとか！ (入力) <form action="register.cgi" method="post"> タイトル：<input type="text" name="title"> ← 「ぼくはまちちゃん！」を入力 本文：<input type="text" name="body"> ← 「こんにちはこんにちは！！<script>alert(1)</script>」を入力 </form> (確認) <p>この内容で登録していい？</p> <p> タイトル： ぼくはまちちゃん！<br> 本文： こんにちはこんにちは！！<script>alert
USBメモリを用いたソーシャル・エンジニアリング
ソーシャルエンジニアリングの第一歩は、「組織内の人に化けること」にある。イーサン・ハントみたく化けの皮を被る必要もない。もっと重要なのは、機密ではないが、組織内の人しか知りえないような情報を知っていること。例えば座席表やビルドサーバの名前だとか。 ひとたび組織内の人に化ける情報を得たならば、攻略はぐっと楽になる。「欺術」を参考に潜入を進めることができる（ホントにやっちゃダメよ）。ここでは、USBフラッシュメモリを使って最初のハードルを効率的に超える方法を考えてみよう。 オフィスの受付窓口の片隅や、社員食堂（外の人も入れる）の廊下でUSBメモリを拾ったら、どうするよ? USBメモリなんてありふれているし、最近じゃオサレな奴やカワイイ系まで出回っているぐらいだ。誰かが落としたんだろうな… で、何が入っているのだろうか? で、自分のPCに挿してみる…が、すぐに覗けない。それぐらい知ってるって、し
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
インターネット殺人事件 : 日記 : 2006-03 - 人を殺してはならない
インターネット殺人事件 日記 2006-03 02日(木) : ◆愚かさ2.0 05日(日) : ◆[読書]『金春屋ゴメス』(西條奈加、新潮社) 12日(日) : ◆人を殺してはならない 19日(日) : ◆漫画雑記 2006-03-19 / ◆地虫十兵衛は戦場の芋虫ジョニー 21日(火) : ◆Google Dystopia、或いは言葉狩り2.0 25日(土) : ◆Bloginfluence の殺し方 31日(金) : ◆余は如何にして鍵括弧使いとなりし乎 「草稿。」 愚かさ 2.0 とは。 「愚かさは配信される」 blog に愚かなことを書くと数日間で地球全国津々浦々まで配信されちゃうよ、というお話。 RSS と Google キャッシュと Weyback のおかげで、大抵の文章は Web 中にコピーがばらまかれてしまう。 Winny でのデータ流出に似ていて、そろそろ歯止めが効かな
■ - hoshikuzu | star_dust の書斎
■はてなダイアリー本体のXSS脆弱性 background 属性の XSS 脆弱性について::はてなダイアリー日記 あれ？いつからはてなダイアリーではHTMLの意味でのbackground属性が使えるようになったのでしょう。background属性でXSS脆弱性が発見されたようですけれど。 はてなダイアリーはHTML4.01を採用しています。background属性はbody要素でのみ有効なはず。はてなダイアリーでは当初、background属性など許可されていなかったはずです。だって、スタイルシートが使えるのが売りですしね。background属性など必要ないでしょう。悲しみながら調べてみます。 更新履歴-はてなダイアリー利用可能タグとは::はてなダイアリー 更新履歴-はてなダイアリー利用可能タグとは::はてなダイアリーから引用すると、どうも以下のようです。 ■更新履歴 (snip) 利
俺の「パスワード：*****」って何でしたっけ？ ― ＠IT
俺の「パスワード：*****」って何でしたっけ？ ～アプリケーションのパスワード調査編～：ツールを使ってネットワーク管理（5）（1/6 ページ） パスワード再発行ばかりが仕事じゃない 律子さんの会社では、基本的に1人1台マシンが支給されているのですが、プロジェクトの都合やリース期間切れなどで、意外と頻繁にマシンの変更が行われます。 そんなこともあってデータの移動は手慣れたものですが、つい忘れてしまうものがあります。パスワードです。 特にメールのパスワードなんかは最初に管理者に渡されたものを設定して（設定さえ管理者に任せっ切りの人もいますが）、それをアプリケーションに記憶させている人がたくさんいます。もちろんそういう人はマシンを移動するときにはパスワードは頭の中からすっかり抜け落ちているのです。一度しか打ち込んでいないので仕方ありませんが、そういう人に限って、なぜか渡されたパスワードが書かれ
mixiという幻想の共和国、そこは内ではなく外である - ガ島通信
「ブログはちょっと怖いからやっていないけど、ミクシィならやってますよ」という言葉を聞く事が多くなりました。「招待制」というシステムだからか、まだ、十分にマナーが確立していないインターネットという荒野の「内側」にいるような安心感があるのですが、冷静に考えれば「外」なわけです。招待制、インターフェイス、雰囲気…、いろいろなことが重なり「外」を忘れさせる装置となっているのでしょう。 なぜこのようなことを書くかと言えば、リテラシーという言葉を口に出すのも、あまりに無防備な利用方法がまかり通っていることに驚かされたからです。いくつかあったのですが、例えば、あるコミュニティには、某企業グループで別会社への出向希望が募集されたことがトピックとして上げあられ、どの会社に行くのがいいかの相談が行われていました。『こういうとこで公開してしまうのはまずいのでは』など注意した人がいましたがスルーされ、議論は進行し
fladdict.net blog: MIXIを使った、トラフィックの個人追跡システム
というのが可能だと考え付いて、ちょっと愕然とした。 自分のサイトに、隠しiframeでMIXIの自ページを読み込ませておくの。 そうすると、自分のサイトを訪れたログイン中のMIXI会員は、足跡がついちゃうの。あとは定期的に足跡キャッシュする。誰がウチのサイトを見てるかバレバレ（注：実装してないよ）。 一見、アホネタだけど。これ凄いシリアスな問題だよな。だってさ、エロサイトとかにそういう仕組みがあったら、最悪の場合一瞬で個人情報特定されるぜ？サイトのクッキーと、MIXIのアカウントとかが結びつけられた日には、何がおこるかわかったもんじゃないですよ。 １００万超過の巨大コミュニティとなった今、MIXIの持っていた知り合いとの人間関係を担保とした安全性ってのは、もうとっくに崩壊してる。さらにザバサーチのようにネット上に分散する情報をかき集めれば、かなりの精度で個人情報が筒抜けになる危険性も増して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[openmya:035806] IE における "expression" の過剰検出による XSS の 誘因
はてな外のサイトからはてなダイアリーが閲覧できていた件につきまして - はてなダイアリー日記
サービス終了のお知らせ