多くのサイトでは、自分のサイトが何処からリンクされているか調べるためにアクセス解析を行っている。ユーザーのブラウザから送信されるアクセス元情報「Referer」をCGI等を利用して記録する訳だ。アクセス解析CGIはログ表示機能を実装している場合が多い。このログ表示機能を利用してサイト管理人のIPアドレスを抜く技を紹介しよう。RefererをProxomitronで書き換えて、アクセスログ表示ページからカウンターを呼び出させるのだ。
まず、「ヘッダ」の「Referer」で始まる行を選択し「複製」をクリックする。
次に「HTTPヘッダ(Key)」に分かりやすい名前をつけて、「置換するテキスト(Replace)」に自分のカウンターを呼び出すimgタグを記述する。
この状態でターゲットのサイトにアクセスすると、サイトのアクセスログにはカウンターを呼び出すタグが「アクセス元URL」として記録される。
従ってターゲットサイトの「アクセスログ表示ページ」にはこのようにカウンターが表示されることになる。
ターゲットがアクセスログ表示ページを一般公開していないならば、アクセスログ表示ページを見た人とはサイト管理人に他ならない。対策が取られていないアクセス解析ならばサイト管理人のIPアドレスを抜くことが出来るのだ。
ターゲットがアクセスログ表示ページを開くのを待って、カウンターのアクセスログを見ればターゲットのIPアドレスが記録されている、という訳だ。タグが無効化されるログ表示CGIを使っているサイトに対しては、JavaScriptを利用してみよう。アクセス元URLはAタグの中に記述されることが多いので、JavaScriptのonLoadイベント等を使えばタグを無効化しているログ表示CGI相手でもカウンターを呼び出させられる可能性が高い。
| [69] はじめまして！ |
マックに「品切れが続いていたナゲットですが販売再開しました」とか張り紙あって笑いました！ |
| yamada - Mozilla/4.0 (compatible; MSIE 6.0; Win32) |
| 2002/05/01 13:45:12 |
| [69] はじめまして！ |
マックに「品切れが続いていたナゲットですが販売再開しました」とか張り紙あって笑いました！ |
| yamada - 彼専用だけに赤いの |
| 2002/05/01 13:45:12 |
参考:「sanakiのホームページ」内「危険??なタグ?掲示板(POST/GET)攻撃」本文でタグを使えないなら。次に思いつくのは、例えば「名前」や「メールアドレス」といった項目でしょう。
メールアドレスに"（ダブルクオーテーション）が入ってないかどうかを、きちんとチェックしているでしょうか。これをチェックしないと、掲示板荒らしの格好の道具になってしまうことがあります。「名前」や「メールアドレス」にもこうした悪意に対する対策が施されていた場合。それでもUser-Agentが「掲示板CGIのセキュリティホール」になる場合もある。環境変数からUser-Agentを取得して書き込みログに吐くような掲示板を作るなら、User-Agentにも「(本文や名前やメールアドレスと同じように)内容が正当か判断するルーチン」を組み込む必要があります。という話でした。
名前を$name、メールアドレスを$emailという変数に入れている場合、恐らく「<a href="mailto:$email">$name</a>」と書くことでしょう。しかし、この$emailという変数にダブルクオーテーションが入っていたらどうなるでしょうか。
例えば掲示板荒らしが名前欄に「祭りだワッショイ」、メールアドレス欄に「baka@baka.baka" style="font-size:1000pt」などと書いたらどうなるでしょうか。「<a href="mailto:baka@baka.baka" style="font-size:1000pt">祭りだワッショイ</a>」となり、「祭りだワッショイ」という1000ポイントの巨大文字が掲示板を埋め尽くすなどという事態になります。応用次第ではもっと危険ないたずらだってできます。
※参考：超初級CGIクラックガイド(4)
「掲示板に好きなタグを使える」ということは「その掲示板を他の掲示板攻撃の踏み台にできる」ということでもあります。
※参考：小学生でも分かるIP抜き講座(4)
アクセスロギングCGIとの組み合わせで「掲示板を開いた人間のIPアドレスを取得する」ということも可能になります。
※参考（「正しい」方法でフルサイズ画像を呼び出す時）ブラウザはimgタグに記述されたURLをPostメソッドで（＝標準入力付きなどで）呼び出すことができない。ブラウザは「正しい」アクセス時にimgタグ内URLを通常のGetメソッドで読んでいる。ならば、そのGetメソッドによるリクエストを「正しくない」アクセス方法で行ってしまえばいい。
アダルトサイトで学ぶHTTP基礎(5)
通常我々がブラウザで行う「リクエスト」には「Referer」などの環境変数が（目に見えない場所で）付加されている。
アダルトサイトで学ぶHTTP基礎(6)
サーバーは、そうした情報を使って「それが正当なリクエストか（ダウンローダーなどから送られたリクエストではないか）をチェックしている。つまり、「正しい」アクセス時と同じリクエストを送信すれば「ダウンローダーでのダウンロード」は必ず可能である（上で軽く書いたRefererチェックによる規制もこの話の範疇です）。
※参考「フルサイズ画像リクエスト時に標準入力がチェックされる」でなく、Cookieを使い
超初級CGIクラックガイド(4)
Getメソッドで送信できるリクエストの形式など。
超初級CGIクラックガイド(5)
Postメソッドで送信できるリクエストの形式など。仮に「フルサイズ画像リクエスト時に標準入力がチェックされる」という仕組みがあればProxomitronでリンクを書き換えるのは困難になりますが、上述の理由でそれはあり得ない。「せっかく」Postメソッドを交えた規制を行っていても最終的に「フルサイズ画像を表示する」という段階がimgタグでは仕方がない。
重大な訂正があります。ただ、この記事を下敷きに訂正記事を書いているので、先にこの記事を読んだ上で「mixi非公開日記の画像を外部に晒す」を読んでいただくようお願いいたします（2006/12/04）。
「ウェブ魚拓 mixi 画像 "外部参照"」でググっても誰も言及していないようなので言及しておく。
あるレベルにおいて、mixiの画像が外部参照される問題は解決されていない。ただし、あるレベルでは解決されている。問題は「あるレベルにおいて」であり、その詳細に関して。
これまで外部からでも参照可能であったmixi日記の画像は、11月10日頃に外部からの参照が不可能になった。時間と共に画像のアドレスが変化するので、ある瞬間において有効だったアドレスが少し後には参照不能になる。故に現実的なレベルにおいて外部からの参照が不可能なのだ。・・・と、とりあえずmixiの仕様変更をおさらいすることから書き始める。
具体的に書くと、
という、この二つのアドレスは固定されており、時間と無関係にアクセス可能だが、セッション情報を求める。つまりmixi非登録ユーザーからは参照できないし、非公開日記の場合は閲覧権限のあるmixiIDでログインしていなければ参照できない。
は時間と共に変化する。
が変化していき、特に「外部参照をしてやろう」という人間からして問題なのは前者で、42桁のランダムな英数字なので、総当たりでは破れそうにない。ただし、上記「画像本体のURL」はセッション情報を求めない。その意味では（ある瞬間においては）外部に公開されている。
従って、画像本体のアドレスに関する（外部接続からの）キャッシュを生成することは可能です。
取得したアドレスの例はこちら。時間と関係なく、mixiログイン情報も必要なく、いつでも僕のmixi日記内の画像を参照することができます。
・・・と、まぁ、こんなことは正直ずっと前から分かっていたことなんだが、個人的に一つ分からないことがあり、その部分をずっと調べていた。即ち、上記は「あってはならないこと」なのかどうか、という点だ。そもそもにおいて、ウェブにアップされた画像は、誰かがダウンロードしてアップローダーなどに晒せば晒される。従って「mixi日記内画像の外部参照問題」というのは、どちらかと言えば「画像をお持ち帰りされないように右クリックを禁止してます！」といった話に近しく、ただしmixiが画像本体のGETにセッション情報を要求していないという点のみが「セキュリティ」の範疇である。・・・というポジションから考えると結構微妙な問題で時間が経ってしまった、という。
画像本体アドレスには「その画像がどの日記の中に使われていた画像か」という情報、日記IDが含まれている。従ってウェブ魚拓などを使って記録したキャッシュは「その画像がたしかにその日記に含まれていたものである」ということを示す。ただし、ユーザーIDを含んでいない。故に、「その画像が誰の日記に含まれていたものか」を示さない。削除された公開日記、或いは非公開日記においても「日記ID→ユーザーID」を変換する方法が存在すれば崩れるが、僕の理解する範囲では「魚拓されている画像が誰の日記に含まれていた画像か」は不明であり、例えば晒す人間が同時に書き込むであろう「これは○○の日記にあった画像だ」的な証言しか存在しない。これは「あるレベルにおける解決」だ（繰り返すが、「日記ID→ユーザーID」が本当に不可能であるのなら）。
最初にも書きましたが、この記事には訂正があります。「日記ID→ユーザーID」は繋がります。「変換」は無理ですが「ある日記IDの日記が、提示されたユーザーIDの日記であるか否か」を第三者が確認することは可能であり、「mixi非公開日記の画像を外部に晒す」で言及しています（2006/12/04）。
（その瞬間において有効な）画像本体のアドレスを知るためには、mixiにログインし、或いはその非公開日記を見る権利のあるIDでmixiにログインし、画像表示ページ（/show_diary_picture.pl）を開かなければならない。従って、その人間に「足跡」を残す可能性がある。ウェブ魚拓を使って外部参照可能となった画像は「&data=」の形で「そのページの取得日時」を吐いているので、足跡が残っていれば、ウェブ魚拓では、状況証拠として画像を晒した人間の正体を掴むことは可能だ（当該時刻少し前に足跡を残している人間が晒しの犯人だ）。ただし、ある人間の日記一覧ページ「/list_diary.pl?id=（ユーザーID）」へのアクセスは、足跡を残さない。ここらへんはmixiに強い人の言及をどーぞ。
という方法によって、足跡を残さずに他人の日記内画像を晒すことが可能となる。故に、これはどのレベルにおいても「解決」ではない。ただ、今後「/list_diary.pl」や「/show_diary_picture.pl」へのアクセスで足跡が残るようになる可能性は高い（その仕様変更はmixiにとってもたやすいはず）。この場合は、ウェブ魚拓以外の同種サービスを頼る必要がある。ウェブ魚拓と同様で、ただし取得日時を記録しないサービス。それが現時点において存在するのかは未調査だが、原理的には完全に可能なサービスであり、完全に可能な（存在しないことが「偶然」に過ぎない）サービスによって崩される以上、今後「/list_diary.pl」や「/show_diary_picture.pl」へのアクセスで足跡が残るようにmixiが仕様を変更したとしても、それはどのレベルにおいても解決ではない。
調べていた結果としては、mixiの画像外部参照に嫌悪感を抱くタイプのmixiユーザーは「画像が非mixiユーザー、自分と関わりのない他人の目に触れること」を問題としているような気が、僕には、した。つまり、「了解」とは、「非公開日記ならば、日記内の画像にアクセスする人間は完全に自分の（友人登録管理による）制御下/（足跡による）監視下にある」であるように、思えた。
・・・ので、ここまでを踏まえた上で、上記は一定のレベルで「問題」であるはずなので、一応エントリーとして公開しておく。うん、まぁ、分かってる人からすれば「何を大げさな」と言われそうな警告記事なんだけど、「マジで！？」と思う人もある程度いるような気がした、んですよね・・・。
前回の記事に訂正を行う。そしてこれによって、mixi内の非公開日記内画像を「その画像が確かにそのユーザーのアップした画像である」という証拠と共に外部に晒す方法が存在することが分かったので、警告しておく。
まず、おさらいすると、mixi日記内の画像本体アドレスは、閲覧にmixiログイン情報を要求しない。画像本体は外部参照可能なのだ。ただ、アドレスが時間と共に変わる仕組みなので、現実的なレベルでは外部参照できない（すぐに見れなくなる）。また、画像本体のアドレスにはユーザーIDが含まれていないため、外部掲示板に貼り付けた画像が誰の日記内の画像なのかは分からない。・・・と、ここまでが前回記事で書いた件。前回の記事を読んでない方は先にお願いします。
個人的に「mixi画像外部参照問題は部分的に解決された」と判断したのは、「画像を晒されても『それは俺の画像ではない』という言い逃れが可能」だと判断したからだった。もう一度書くが、そもそもにおいて、ウェブにアップした画像は誰かがダウンロードしてアップローダーなどに晒せば晒される。mixi非公開日記が「セキュア」である（べき）ポイントとは「顔＆免許証入りハメ撮りを公開しても晒されることがあり得ない」ではない。それは個人対個人とかの問題であって、ウェブサービスに求めるべきセキュリティではない（電子メールで送った画像だって、裏切られれば、不特定多数相手に晒される、だろ？）。非公開日記内の写真を誰かがダウンロードして別の場所に晒したとしても
この二つこそが、mixiが「守るべき」ポイントであった。即ち、顔や免許証が入っていないハメ撮り写真を外部に晒されても「え、それ俺じゃないですけど？どこのアダルトサイトから拾ったんすかｗ」と言い逃れられることが、「mixiというウェブサービス」が守るべきポイントだった。「アップローダーなどに晒された匿名の画像」と「その画像を（非公開）日記に載せた人のmixiID」は、繋がってはならない。
しかし、mixiの特定画像が特定個人IDの日記内に掲載されている/いたことを保証する方法は存在する。
画像本体のURLは
(画像ごとに固定された画像用サーバー).mixi.jp/p/(画像ごとに固定されていないランダムな文字列)/(時間と共に増えていく数字)/diary/(画像ごとに固定された数字)/(画像ごとに固定された数字)/(日記ID)_(画像を特定する数字).jpg
であり、内部に日記IDを含んでいる。故に画像本体のURL（をウェブ魚拓などでキャッシュ保存したURL）は「その画像がどの日記に含まれていたか」を示す。だが、ユーザーIDを含んでおらず、「その画像が誰の日記内に含まれていたか」を示さない。
個別日記ページのURL
mixi.jp/view_diary.pl?id=(日記ID)&owner_id=(ユーザーID)
にはユーザーIDが含まれている。「日記ID」は全ユーザーに関してユニークで、例えば
の両方が存在することはあり得ない。「id=1」は「全ユーザー内でID=1の日記」だ。この対応がおかしい場合、例えば日記ID=1はユーザーID=1の日記であるのに「id=1&owner_id=2」がリクエストされた場合は「この日記にアクセスできません」というエラーが表示される。問題は、これが、非公開日記相手であっても変わらない点。対応が正しく、自分がアクセスする権限がない非公開日記にアクセスしようとした場合は「友人までの公開のため見ることができません」であり、「view_diary.pl」にアクセスした場合の表示をまとめると
しかも、(※1)(※2)(※3)は、既に削除された日記であっても変わらない。
まとめよう。非公開日記内の画像を、その画像がたしかに当該ユーザーの非公開日記内画像だという証拠ととも外部に晒す方法は以下。
以後、「晒し」を見た掲示板内の匿名mixiユーザーが「その画像がたしかに当該ユーザーが非公開日記内で公開していた物だ」と確認する方法は以下。
これにより、非公開日記内の画像は外部に証拠を持って晒される。しかも、日記を削除しても無駄だ。
と、いうことで、当該日記を削除しても、画像は、その画像がたしかに当該ユーザーの非公開日記にあった物だという証拠と共に晒され続ける。
まぁ、エラーメッセージに余分な情報を込めるとクラックの糸口にされるよ、という良い例なんじゃないでしょうか。非公開日記を使っているmixiユーザーの方は注意してください。さすがにこの仕様（特に日記を削除してもエラーメッセージが「友人までの公開のため見ることができません」である点）は酷すぎるので、早期に改善されるとは思うんだけど・・・。
なお、特にこれ系の話に不慣れな人には細かくややこしい＆読みにくい記事になってる気がするんですが、んー、ひょっとしたら画像とか使った分かりやすい解説を作るかもしれませんが期待しないでください（誰か作ってくれないかなぁとも思いつつ）。
LivedoorReaderの、他人の記事未読数が取得できるという件なんですが、誰もお前にそんなに興味ないから大丈夫だと思うので、ネタで作ったUWSCスクリプトを公開しておきますね。一応1/26に更新して終了処理とログファイルの吐き方を変えてみた。多分もう二度と更新しない。
と、いうことで、ストーカーな人とかは気になるあの子のLivedoorIDを調べ上げて「何でLDR読む暇あるのにメールの返信くれないの？」とかメールを送ってみたりすると良いんじゃないかと思う。お前にストーカーなんか付かないよ。
一応動作画面も置いておきますね。
LDRStalk.exeを起動し、ターゲットのIDを入力し「OK」。
10秒ごとに未読数を取得し表示します。IEのプロクシ設定等々が生きてる。
未読記事数が減る、即ちターゲットがLDRを読むと赤表示になります。
その後も監視を続け、緑表示で最終閲覧日時を表示しています。終了は「Alt+L」。
ターゲットがLDRを閲覧したときに本体と同じフォルダに「Log.txt」を吐きます。中には閲覧時刻がリスト表示されています。mixiにアクセスすると最終アクセス時刻が記録されるのと同様にLDRの閲覧時刻を記録されるのは世界の常識ですが勝ち組な俺らは超安心ですね。
mixi動画をダウンロードするウェブサービス「mixivideodown」の超アルファ版を公開します。
まぁ正直色々と全く作り込んでないのですが、つまり「会員制でクローズドなサイトから動画ファイルをダウンロードさせるウェブサービス」というコンセプト提示用（というほどのものではない）、ということで……。月末くらいに（覚えていれば）もう少しちゃんと作ります。
と、いう、YouTube動画ダウンロード系のサービスで一般的な手法では、クローズドなサイトを対象としたダウンロードサービスを作ることができない。ムリヤリ作るならば、例えばmixiならmixiのアカウントを内部で持っておき
とやる訳ですが、これだと例えばmixi運営に（ダウンロードサービスが持っている）アカウントを消されてしまう（のでイタチごっこになる）。
……という背景の上で。
