サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
hoshikuzu.hatenadiary.org
ニュースを見てはため息をつく。責任能力と裁判について考えている。結論など容易く出ない。聖書学者である田川建三氏によるコメントを読んで感銘を受けたので長文の引用をあえて試みた。 近頃の刑事裁判とそれをめぐるマスコミの論調で、すでにかなりその傾向が強くなっていましたが、池田の小学校の事件でますますひどくなりました。 つまり、犯罪者が犯行の時点で 「責任能力」 （是非善悪を判断する能力）に欠ければ、無罪になる、という例の理屈です。 これは奇妙ではなかろうか。そのおかげで、少なくとも、精神病者に対する差別が、ひどくなっているのではないでしょうか。 考えてもみて下さい。汚職国会議員や汚職高級官僚は （もちろん、はっきり汚職として摘発されていない、うまく「合法的」 な格好をととのえて、ごまかしている連中の方がもっと罪深いのですけれども）、まさに 「是非善悪を判断する能力」に欠けていたから、平気であのよ
なお、私は今までの人生でカード決済をしたことがありませんし、当該カードを保有しておりません。放置したいと思います。以下、メールの内容。 お客様のSaison Card口座から、５７８１で終わるお客様の銀行口座へのご請求は送信され、現在処理段階です。 これはリアルタイム・トランザクションで、引き落としや振り込みが直ちにお客様の口座に反映されます。 午後６時前に手続きされた場合、同営業日に電信為替が送金されます。 この処理が完了するまで通常６〜８時間を要しますが、お客様の口座設定によることがございますので、ご了承ください。 この送金の変更や取り消しに関しましては、こちらをご覧ください:http://www.saisoncard.co.jp.netanswerplus.us/cgi-bin/welcomeSRS.pl?client_id=●●●●&session_id=●●●● お客様のご請求に
セキュリティに興味がある皆様、ぜひお読みください。コンピュータネットワーク世界が成立する前の古い時代からのサイドチャネル攻撃の事例など歴史も学べて非常に面白いです。 最新のテクノロジーではどこまで可能なのかについても。 すでに重要インフラについては防御戦が始まっていることについても。 戦争。塹壕。工兵隊が有線を地中に這わせ情報将校が電話で連絡を取り合い戦術をやりとりする。敵方工作員が遠隔から地中に電極を突き刺し通信を傍受する。 オフィスビルに向かいあうもうひとつのビル。スパイはそのビルから超高解像度の望遠鏡でガラス窓越しにあなたの瞳に反射する光の影を盗み出す。あなたはディスプレイをみつめていた… サイドチャネル攻撃の怖いところは、攻撃を受けている最中でもその痕跡を見出しえないというところにある。ログからの発見などできないのだ、基本的に。 私がパソコンに興味を持って使い始めたときには既にコン
XSS (Cross Site Scripting) Cheat Sheetなど、いろいろあるXSS対策まとめページで、しばしば、alert('XSS')の方法の変種について書いてあります。このページでも同様で、String.fromCharCodeを使えば、悪意ある文字列を仕込むときに引用符を使わなくてもいいじゃん？みたいなことが書いてあります。このほか、/xss/.sourceを使えるとかの解説も世に多いわけです。 でもちょっと待って！alert(/XSS/.source)や、alert(String.fromCharCode(88,83,83))などのバリエーションなぞ、本物の攻撃者はあんまり使わないんじゃないかな？どうです？…というのは、alert(0)が出来たらそれで終わりじゃないの？という気がするからです。文字列をalertじゃなくて、数字がalertできたらほとんど攻撃成立じ
続きです。Firefoxにおいては、注入するスクリプト断片に「()」を含まないようにしながら関数の実行が可能です。まず簡単のために、詰めXSS出題時に比べて制限をゆるめてみます。とりあえずalert(1)をしてみようとするものです。 <script> a setter = alert a = 1 </script> 上記でalert(1)が実行されます。この記法は、Firefoxの初期の実装でして、setter や getter の古い書き方です。また、既に廃止予定の記述方法です。近い将来無効になるかもしれません。 さて、さらに、location.hashがスクリプト注入時のペイロードになっているケースを想定してみましょう。Firefox3.0.11 で確認済みです。 <script> u setter = unescape e setter = eval e = u = location
たとえば以下のように、script要素の中に第三者の記述(=$userdata)が埋め込まれるとします。 <script type="text/javascript" > $userdata </script>防衛観点からみれば、こんなことが可能なようでは、まず駄目というのが定説です。まぁそれでもなんらかのフィルターがあればまだましだろう、という考え方もあろうかと思います。私はそのような隙のある考え方にはおおいに問題があるとかねてより考えております。ですから、強力なフィルターを脳内で考えてはそれを打破してみる、といった遊びを時々行うわけです。変なフィルターに頼ることだけでは駄目である、という事実を知りたいのですね。 記号だけでJavaScriptを実行するというid:hasegawayosukeさんの最近の素晴らしいアイデアにはほとほと感服しました。文字列を拾ってブラックリストにのっていれ
属性の中で記述されている『this』が一体全体何を指すのかということを理解することは初心者の私にはとても難しいです。以下、onmouseover属性中の『this.value』が何を指しているのかについての例をあげてみます。 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html lang="ja"> <!-- saved from url=(0008)http://a --> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta http-equiv="Content-Script-Type" content="text/javascript"> <link rel="contents"
はせがわようすけさんによる連載の記事、『［これはひどい］IEの引用符の解釈』が面白かったので手元の少々古めのOpera(9.02ぐらい)で試すことにしました。 <div id="div1"> <input type="text" value="ここに攻撃者の指定した文字列が挿入可能"> </div> <div id="div2"> </div> <script> document.getElementById( "div2" ).innerHTML = document.getElementById( "div1" ).innerHTML; </script>攻撃者の指定した文字列ですが、IEの場合には『``』などを含ませると結果的にDOM構造が壊れるとのこと、私が試した範囲ではOpera(9.02ぐらい)の場合には、『``』の替わりに『"』を入れるとDOMが壊れてしまいました。
これはなに 既にご存知の方がいらっしゃるかどうかも知りませんが今さっき関連文献に行き当たって驚愕したので念のためにメモを書いておきます。私はメーリングリストなどに加入していませんので論議が済んでいるかどうかも知らないのです。もしもウェブ上に解説記事があるようでしたら逆に私に是非とも教えてください。 JSONデータの先頭に JSONデータの先頭にwhile(1)を置いておくことで無限ループを発生させておいて、受動的攻撃のページの悪意あるscriptの実行を失敗させるというアイデアには欠点があるということを、先程とある文献から知りました。これはwhile(true)についても同様です。JavaScriptは柔軟で強力な言語ですから、ブラウザがJavaScriptエンジンをまじめに実装しているのであれば、アタックのチャンスを与えていることになります。しかしこれはブラウザの脆弱性とは捉えられません
ご存知のとおりＸ線は医学で多用されています。ただ少々被曝が気になるところではあります。Ｘ線といえども光にすぎないのですが日光に比べて人体にたいする破壊力が大変に大きいのですよね。 さて、量子相関（エンタングルメント）されたＥＰＲ対のように二つの光子をペアで生成し、片方の光子Ａは放置しておいて、もう片方の光子Ｂを人体撮影に使い透過してきたところで先ほど放置しておいた光子Ａとひきあわせます。細かいテクニックはさておいてこの突合せ方法を上手に設定すると、理論値では従来のＸ線の100万分の1の光量で充分に医学的所見が得られるのだそうです。すさまじい。まだまだ必要な機材の開発ができていないようですが。このオハナシは少し前の日経サイエンス誌の記事になっていました。ですからこうしたアーキテクチャの方向性は本当に実現しかねないのです。 こんな未来社会を考えてみませんか？街中いたるところで量子相関Ｘ線撮影機
id:hasegawayosukeさんによる、IEのinnerHTMLにおけるバッククォートバグ問題について脚光をあびていますが、私が最初にその問題について知ったのは以下の記事からです。2007年4月11日の長谷川さんの日記です。有益ですので当該日記のコメント欄も参照してください。 http://d.hatena.ne.jp/hasegawayosuke/20070411/p1 全ての文字をエスケープしようなどと非現実的なことは言わないけれど(とはいえMicrosoft Anti-Cross Site Scripting Libraryのようにほとんど全ての文字を実体参照に置き換えるものもあるので、あながち非現実的とも言えないのかも知れない)、エスケープ対象を「'」「"」「<」「>」「&」の5文字に限定しているのは何かこの記事に書かれていない理由があるはずだと思ったからです。 この5文字さ
うまく言えないけれど。エンコーディング上問題があるデータ列を用いてXSSを仕掛けられたとして防衛策は、出力時点のエスケープだけじゃ駄目だろうと予てからの感想。 入力時点でエンコーディングの整合性を見張っておいて、その上で処理を行ってから、出力時点でXSS対策としてのエスケープをするのが常道なんだろうなぁ。なので出力時点で不正な部分をカットしたりしているとキモい気がする。 うーん。全部過激にエスケープとかするときも、本来あっちゃいけない表現をエスケープするのってできるのかちゅうか。例えば。utf-8としてありえないデータをもらったのに出力時点まで放っておくとか変じゃないの？このあたり、書いてる文献ってどこかにありませんか？＞識者殿各位 教えてくれないと私、しばらくのあいだスネます。（嘘 追記:不正データによる終了時のステータスコードで悩む時 bakera.jpに興味深い論議が掲載されています
■不等式の証明(２) 昨日の日記の続き。 問題： 4つの正数、a,b,c,d が、 abcd=1 を満たすとき、 a^2 + b^2 + c^2 + d^2 + ab + ac + ad + bc + bd + cd は10以上であることを示せ。 tamoさんからもヒントがあったように相加平均相乗平均の関係を使うのが手っ取り早いです。題意にあわせて効率よく相加平均相乗平均の関係を使う方法の１例として以下のように考えることが出来ます。 正数 a b c d について abcd = 1 なので両辺を自乗して aabbccdd = 1 このことから以下の４つの式を導きます。括弧の意味はヒトククリということです。 (aa)(bb)(cc)(dd) = 1 ...(1) (ab)(bc)(cd)(ad) = 1 ...(2) (ac)(bd)(ac)(bd) = 1 ...(3) (ad)(ab)(
ジャーゴンでhogeとかfugaとかをコードの中に埋め込んだりしますよね？ 金床さんの「ウェブアプリケーション・セキュリティ」とかいう著書でもふんだんに使っていました。なんとなく楽しい表記です。このhogeなりfugaなりは、たぶん、fooとかbarとかの代用物だとは思うんですが、この表現を思いついた最初の日本人はとてもエライとか思います。 さて。一部九州地方にある方言で「ほがす（他動詞）」「ほげる（自動詞）」という言葉があります。意味合いとしては、穴を開ける、穴が開いているといったものです。私見ですがいわゆる標準語では恐らく「穿つ（うがつ）」に対応するものなのでしょう。ウガツは、日本の古い言葉において推定される「フガス」ないし「ホガス」あたりから、頭の「H」の子音が脱落したものと考えても良いのではと思うのです。その古い言葉が九州に残っていると考えているわけです。 現代沖縄方言では、「フガ
浅学なので不正確の極みなのでしょうけれど…HTMLを作成することの原初的かつ本源的な意味合いって、まず最初にテキストありき、からスタートすべきだと思っています。 ここにテキストがある。適切な形式でweb上でパブリックにしたい。そのためにはマークアップが必要だし便利だ。というわけ。 マークアップするに先立って、マークアップに必要な記号と元のテキストの文の符号とがぶつかってはまずいので、プレ処理として「一種のエスケープ」が必ず必要。HTMLの世界では文字参照というやりかたでテキストを前処理しておき、マークアップに備えるということですよね。 だから、いわゆる「適切な文字参照でXSSを防ぎましょう」というのは、本当のところオカシナ話なんですよね。XSS以前に適切な文字参照は必要なのであって。なんとならば、テキストそのままではマークアップできないからで。 HTMLについて以上のような勘所を知っていれ
…いろんなブラウザで変な現象が起きるので前から注目していたのですが、まさかIEで外部ドメインのcookieが取れてしまうとは…調査の深さが足りなかったなぁ＞俺 locationでページ遷移したらバシっと処理をぶった切ってほしいかも＞諸ブラウザ ええと、なんでもいいけど、なにかしらポップアップする系と併せてぐしゃぐしゃすると変な競合が起こりやすい模様。というのが今までの私の見解。 一番笑ったのが、ＡページでＢページへのリンクを踏んだ後Ｂページを表示後、Ａページへ戻りますか？という選択肢（Ａページ内のスクリプト）を出させることが可能とか。名づけて、ちょっと見たらスグに戻ってきてねリンク。でもcookieは取ってこれなかったんだよねぇ。コレ。 ドブロイ波の公式を実験的事実とみなし、古典的な実波動関数をあきらめて、複素波動であると決め付けて、満たすべき波動方程式を求めるとシュレーディンガー方程式が
たとえば、『ジェダイの復讐』という邦訳の題名があってもその意味をそのまま受け止めてはいけません。アレは、『ジェダイの帰還』が本当の訳出。 return という簡単な英単語を復讐と訳さずに帰還と訳せ、というだけなんだけれども。ま、わかっててあえてインパクト強い邦題にしているのだよね？＞関係者殿 というわけで、常温核融合の復讐。いや、帰還。『帰ってきた常温核融合』。 http://hardware.slashdot.org/article.pl?sid=08/05/24/0345245 http://www5b.biglobe.ne.jp/~sugi_m/page284.htm 検証に耐える再現性の高い、安価な簡単な実験装置を工夫してしまったところに素晴らしさがあるわけですね。 そもそも常温核融合はトンデモ科学じゃね？マッドサイエンスじゃね？とか言われ続けてきたわけですけれど。その表向きの原因
森の射手問題 神が森を創り、そこに人間を創造した。あなたは今、森で目覚め、神に創られた人間であることがわかっている。さらに、神の声によって次のことが教えられた。 １）「私は、二つの森のうちどちらか一方を作ろうと思った。どちらの森にも天使が一人住んでおり、人間を見つけると、ただ１人を、ただ１回だけ、弓矢で射る。さて、一つの森は、その天使のほかに、５人の人間を含んでいる。もう一つの森は、天使のほかに、500人の人間を含んでいる。人間たちは互いに出会うことはない。この二つの森の構想を抱いて私はサイコロを振り、どちらを創るかを決めた。そうして一方だけを創り、その結果、おまえとこの森は誕生したのだ」 神の声が消えてからしばらくして、木々のむこうから矢が飛んできて、あなたの肩に突き刺さった。ここで神の声がした。 「天使の矢に射られたな……。さて推測せよ、私はどちらの森を創ったのだと思うか？ ５人を含む
はじめに 眠り姫問題について私はずいぶんと長い期間考えてきました。しかし決定的な解を得られないままになっています。私なりの考えそのものは一段落しましたが、依然として頭の中がスッキリしないままです。一見簡単な確率問題のようですし場合によっては暗算で回答可能のようですので、皆さんのお知恵を拝借したいと思い、日記にアップしてみます。なお、皆さんの回答ないしご説明に当たっては、おそらく当日記のコメントごときでは書き足らないケースも出てくると思います。その場合にはどこかにアップしておいてリンクなりトラックバックなりをして頂けるとすごく嬉しいです。 なお、以下の問題文は、分析哲学者である三浦俊彦先生によるものです。できるだけ瑣末な余計なことを考えないですむように問題文を最適化してあるようです。 眠り姫問題 日曜日に、ある実験が始められる。まず、あなたは眠らされる。そのあとフェアなコインが投げられ、表か
XSS対策としてのいわゆるJavaScriptエスケープについての拙なる論考を、当日記で以下に記載したことがあります。 http://d.hatena.ne.jp/hoshikuzu/20071011#p1 さて、商用などでウェブアプリケーションを作成する場合には、おそらくHTMLでページを出力し、ピュアなXHTMLでページを出力することはほとんどないかもしれません。ユーザがIEを使っている限り、ピュアなXHTMLとして読んでくれないからです。 対策としてHTTPのrequestを参照してブラウザごとの判断をしてきまじめにコンテンツネゴシエーションしているかもしれませんが、それはさておき。 ところで、IEが進化してピュアなXHTMLの解釈をしてくれる時代が来たとしましょう。ウェブアプリケーション側にも、XHTMLでページを出力する試みをするものが出てくるかもしれません。 そんな時代には、場
朝ごはんをたべていたら思いついたのでどんなものなのか皆さんに伺ってみたくなりました。 ○クロスドメインアクセス対策例JSON、JSONP、JavaScriptで機密情報を配信する場合、クロスドメインアクセスの対策（＝クロスドメインアクセスを不可能にする対策）が必要になります。 以下にSea Surfers MLで議論されていた方法を紹介します。 (一部省略 by hoshikuzu) 方法２．while(1)、およびコメントアウト法サーバ側がデータの先頭にwhile(1) {}をつける、または全体をコメントアウトした状態で返し、クライアント側でこれを取り除いてevalする方法です。方法１と考え方としてはほとんど変わりません。while(1)の方法はGMailでも使われています。 ここでのコメントアウト法が果たして有効なのかどうか答えを知りたく思います。教えて君になっていますが、まことにすみ
なんのこと？ ●文字エンコーディングに起因する複数の XSS 脆弱性 http://www.mozilla-japan.org/security/announce/2008/mfsa2008-13.html 無修正とは？ ●当日記20080118に関連か… http://d.hatena.ne.jp/hoshikuzu/20080118 ISO-2022-JPの仕様とパッチ(どちらも広く公開されています)を読めば瞬間的に思いつきそうな変形版の攻撃 気になること ISO-2022系、Shift_JIS系以外のエンコーディングにおいても、非ASCII文字列の取り扱いに不備が「あった」と判断できること。今回のアドバイザリにはそれらが触れられていないこと。 いずれにせよ サーバサイドにしてみると業腹かもしれないが、エンコーディングにおいて不正なものはやはりHTMLの一部として埋め込まれてはいけない
JavaScriptで。文字列'al%65rt%28%22Hello%20World%21%22%29'をunescape()してやってその後にeval()に通せば、結果として「Hello World!」とalertされると思います。 この操作を、安直なXSS対策ブラックリストにおけるヨワヨワな守備の回避を目的に、JavaScriptの予約語（と言ってよいですか？）を、陽には一切、使わずに行ってみるという試みです。以下。 <script> ( (21)['c' + 'onstructor']['co' + 'nstructor'] ( ( ( (21)['con' + 'structor']['cons' + 'tructor'] ('retur' + 'n unesc' + 'ape') ) () ) ('al%65' + 'rt%28%22Hello%20World%21%22%29'
いや、本当にスパムかどうか微妙なんだけどね。摂理がカルトかどうか知らないんだけれどもね。でもねぇ・・・ http://www.setsuri.com/modules/news/clipping/8564.html 上のページからリンクが来てました。このページ浮いているんだよね。摂理としては。 ちょんみんそく？センセって美人女子大生とかをかたっぱしからだまくらかしてエロのエジキにしてるひとじゃなかったっけ？宗教の仮面をかぶってるのは許せん。たういつ教会にも関与していたっちゅうセンセじゃなかったっけ？ ・・・誹謗中傷かもしれんが、むかっぱらがたったので。 無論、いかなるリンクも基本的には拒否しないのが当日記の方針ではあるのdesu。でもねぇ。報道によれば摂理って、女子大生などのプロフィールを水着写真つきで整理整頓しておいて、ちょんみんそくセンセに閲覧していただいて、センセから祝福という名の性暴
今後はヘタをするとウイルス作成者は全員逮捕対象になるのだろうか。へんなものだ。実際に悪用した者のみが犯罪者であるべきはずだ。（感情論かもしれないが） 私がウイルスを作った経緯は次のようなものだった。 当時私が所属していた民間の会社内で、海外が起源のとある新しいタイプのExcelのマクロウイルスが大感染状態になった。会社ではなにかにつけてExcelで文書交換をするのが常であったのでほとんどすべてのパソコンが感染してしまっていたのだった。会社の方針でウイルス対策はもっぱらNECさんにまかせてしまっていて油断していたこともたしかだったが、しかたがない、後付で対策をとることになった。NEC製の独自のメールボックスを使っていたので圧縮が独特、したがってアンチウイルス製品が使えない事情もあり、かといってメールボックスをクリアするには時間もかかる（必要なメールは前もってサルベージしなければならないからだ
おくればせながら下記を拝見しました。 UTF-7 XSS Cheat Sheet Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. 上記のような対策を必要とするサイトでは放置しておけばUTF-7系のXSS以外でもXSSの危険性は存在しうると思われます。ですので… あと、ヤマガタさんの反応を読みながら思ったんですが、一般的なXSS対策で「<」「>」などを「<」「>」にエスケープするように、機械的に「+」を「+」にエスケープしてやれば、万が一のときでもUTF-7によるXSSを防げるような気もしたんですけど、あまり深く
IEのstyleで使われる？expression() についてのメモが机の中から出てきました。なにかの記事を読んであとで調べて見ようとメモしたものの忘却の彼方に・・・というメモ。 style="zoom:expression();" の括弧の中に、 this.style.zoom||() があって、そのまた括弧の中に this.style.zoom=1,alert('xss') とか書いてある風味でした。なんじゃこのメモは！ 最初に驚いたのは、expression()の中みをカンマでくぎる風味になっている風味なのであって、これにはちょっと驚きました。なるほど風味。 2番目に驚いたのは、ifの代わりに||を使っているあたり。盲点。 3番目に驚いたのは、これだと、alert('xss')が1回しか発動されないところなのでした。なるほどなるほど風味。でもどうしてこうなるのかわからない風味。 いず
出題編 alert(<>ABC</>); //firefox alert(/ABC/.source); alert(String.fromCharCode(65,66,67)); alert(String.fromCharCode(0x41,0x42,0x43)); CSRFのMLで登場した、（シングルやダブル）クォートを使わずに文字列を作る試み。このほか、documentオブジェクト,locationオブジェクトあたりから既にに存在している文字列をひっぱってきて加工するあたりもネライめ。 上記の解とは別の解があることに気がついたので、日記に書いてみます。 IE6とFirefoxとOperaとで共通の書き方でできました。 var x = "またきてね"; $userdata //ここでxの中身を書き換えます。 alert(x); 上記のように、$userdataがあって自由に書けるとき、「
http://d.hatena.ne.jp/hoshikuzu/20071018#p1 の続編。（私の中ではこちらを先に気がついたのですけれど。） Fileを読めるADODB.Streamを使って検証してみようというオハナシです。 16進の[0x8FD9EA59]というデータをもったテキストファイルを作成し、ローカルに保存します。これをADODB.streamで読ませます。読ませるにあたって、バイナリではなくテキストモードとし、エンコードを、EUC-JPとして指定したり、Shift_JISとして指定したりして、読みこんだ結果、ADODB.streamがそれを、どんなUnicodeとして解釈しているかを見ようというわけです。 Shift_JISとして読ませますと次のようになります。 [0x8FD9EA59]を、[0x8FD9]+[0xEA59]として２バイトずつに区切って理解し、Shift_
次のページ
このページを最初にブックマークしてみませんか？
『hoshikuzu | star_dust の書斎』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
