トップページに戻る
tokix.netはネットワーク・セキュリティ周辺から半径rな雑文を垂れ流す不定期更新個人サイト>>このサイトについて

アダルトサイトで学ぶHTTP基礎

<<トップカテゴリー「NetChildren」に戻る

アダルトサイトで学ぶHTTP基礎(1) (>>この記事のみを表示)

グラフィカル・ユーザー・インターフェイス (graphical user interface)
ボタンやメニュー、アイコンに代表されるさまざまなグラフィカルな部品をマウスなどで制御して操作するユーザーインターフェイス。
複雑なコマンド名や構文などを覚えたり、いちいち入力することなく、システムを(直観的に)使うことができるので、特にコンピュータの初心者にとっては使いやすいインターフェイスといえる。
Insider's Computer Dictionary「グラフィカル・ユーザー・インターフェイス」より
インターフェイスというモノは「利用者にとって使いやすいように」を目標とします。それは逆に言えば「実際何が行われているのか見えにくいように」ということでもある。

例えばFLASHによって高度に動的に作られたウェブページ、とまで言わなくても普通に画像や文字や文字修飾で彩られたウェブページ。そうしたウェブページもまた「利用者にとって使いやすいように」を目標としている。直観的なマウスクリックだけで円滑なブラウジングができるように(だからこそ、例えば文字を目立たせるためリンク文字以外の部分に下線を引く行為は嫌われる)。

「閲覧者を騙す」ということを目的としたウェブサイトに辿り着いた時、我々は初めて「ブラウジングとは何なのか」ということを意識しないといけない。「本来想定されている巡回(=騙され迷う)」とは別の巡回(=騙されず迷わない)を行わなくてはいけないからだ。

「『閲覧者を騙す』ということを目的としたウェブサイト」。それは、例えばアダルトサイトだ。
(タイトルがタイトルだけに少しでも口調をカッコ良くしようとしたら何故か英語コラムを和訳したような口調になってしまいました。何故だ。)

「ブラウジング」とは、基本的に
  1. クライアント(閲覧者)がサーバーにファイルをリクエストする
  2. サーバーがクライアントにファイルを渡す
  3. そのファイルをクライアントのブラウザが表示する
という3段階の行為の連続です。クライアントからサーバーへのリクエストは時に閲覧者にとって自覚的に、時には非自覚的に行われます。

ちょっと例を挙げます。「http://www.tokix.net/index.html」というアドレスを閲覧者がブラウザの「アドレス」欄に打って「移動」を押した場合。
A1:クライアントがtokix.netサーバーに「/index.html」をリクエストする
A2:tokix.netサーバーが「index.html」をクライアントに渡す
A3:クライアントのブラウザが「index.html」を解釈する

B1:index.htmlには「<img src="title.gif">」という記述があるため、クライアントはtokix.netサーバーに「/title.gif」をリクエストする
B2:tokix.netサーバーが「title.gif」をクライアントに渡す
B3:クライアントは受け取った「title.gif」をindex.htmlに埋め込み表示する
A1はクライアントにとって自覚的でしょう。しかしB1のリクエストが自覚的かは微妙です。それでも殆どの(=ブラウザの「画像の表示」をオフにしていない)閲覧者は「index.html」を開く際に「title.gif」をもリクエストしている。

次に、閲覧者がブラウザのアドレス欄に「http://www.tokix.net/」というアドレスを打って「移動」を押した場合。
A1':クライアントがtokix.netサーバーに「/」をリクエストする
A2':tokix.netサーバーは「『/』をリクエストした人には『/index.html』を渡す」という設定になっているため、「index.html」をクライアントに渡す
A3':クライアントのブラウザが「index.html」を解釈する
(以下略)
A2'の「『/』をリクエストした人に何を渡すか」というのはサーバーサイドの設定です。例えばサイト管理人は.htaccessの「DirectoryIndex」で「何を渡すか」を設定できます。今回の連載は「クライアントのための連載」なので深くは触れませんが。
※参考:ミケネコの.htaccessリファレンス「ディレクトリ制御」
IEのアドレス欄に「www.tokix.net/index.html」と打って「移動」を押すと「http://」が勝手に補完されますよね。アレは「IEが足りない部分を勝手に補完している」ということです。しかし「http://www.tokix.net/」とアドレス欄に打った場合の「index.html」はクライアントによる補完ではない。サーバーによる補完です。

何となく気持ち悪くなってきませんか?我々の制御下にあるのは「どのようなリクエストをサーバーに送信するか」という点だけなんです。時にはリクエストしたのとは別のファイル(「/」をリクエストしたら「/index.html」)が渡される。そして「制御下にある」と言ってもそれは100%ではない。時には明示的にリクエストしていないファイル(例えばimgタグで呼び出される画像ファイル)へのリクエストが勝手に行われる。
アダルトサイトで学ぶHTTP基礎(2)
アダルトサイトで学ぶHTTP基礎(3)
アダルトサイトで学ぶHTTP基礎(4)
アダルトサイトで学ぶHTTP基礎(5)
アダルトサイトで学ぶHTTP基礎(6)

アダルトサイトで学ぶHTTP基礎(2) (>>この記事のみを表示)

アダルトサイトで学ぶHTTP基礎(1)
「ブラウジングにおいてクライアントはサーバーにファイルをリクエストする」と書いたところで、普段我々はその「リクエスト」を手動で行ってはいません。ブラウザの「アドレス」欄に「http://www.yahoo.co.jp/」等と打ち込んで「移動」を押すだけです。・・・人によっては「アドレス」欄を非表示にしハイパーリンクとブックマークのみでブラウジングを行っているため「URL」というモノにすら触れていないかもしれません。

では、「ブラウザ」とは何なのか。
本来、ブラウジングとメール送受信とFTPによるファイル送受信と・・・は全て同じアプリで行うことが可能です。telnet。しかしtelnetによってそうした様々な行為を行うためにはコマンドラインによる操作が必要となる。
※参考:ASH Multimedia Lab内「telnetでブラウズ(HTTP)」
そこでブラウジングならブラウジングに特化されたGUIアプリ、メール送受信ならメール送受信に特化されたGUIアプリ・・・が開発される。前者が「ブラウザ」で後者が「メーラー」。こうしたアプリは「利用者にとって使いやすい」。そして「実際何が行われているのか見えにくい」。
GET /~joe/prog/cgi/env01.cgi HTTP/1.0
User-Agent: Telnet [ja] (Linux)
Host: ash.jp
ASH Multimedia Lab内「telnetでブラウズ(HTTP)」より
これがクライアントからサーバーへの「リクエスト」の具体例です。ブラウザの「アドレス」欄にURLを打ち「移動」を押した時サーバーに対し行われているリクエスト。

何でこんな話をしたのか。

普通のサイトでは、「PROFILE」とか「PROFEEL」とか「アタシの全てを知って☆」とかいうリンク文字を押せば管理人個人情報ページが開かれる。「DIARY」とか「DAIARY」とか「アタシの赤裸々日記☆」とかいうリンク文字を押せば管理人私生活ページが開かれる。
ちょっと踏み込んだ書き方をすれば
<a href="profile.html">アタシの全てを知って☆</a>
というリンク文字を押すと、そのページと同一ディレクトリ内の「profile.html」が開かれる。
<a href="diary.html">アタシの赤裸々日記♪</a>
というリンク文字を押すと、そのページと同一ディレクトリ内の「diary.html」が開かれる。

ここで止まらないで欲しいからです。
<a href="profile.html">アタシの全てを知って☆</a>
このリンク文字を押した時に起こることは「そのページと同一ディレクトリ内のprofile.htmlのリクエスト」です。
<a href="diary.html">アタシの赤裸々日記♪</a>
このリンク文字を押した時に起こることは「そのページと同一ディレクトリ内のdiary.htmlのリクエスト」です。

即ち、リクエスト通りのファイルが渡されるかどうかは分からない。
「movie.html」に移動したつもりがランキング投票画面になっていたり、「sexmovie.mpg」をダウンロードしたつもりがQ2接続ソフトをダウンロードしていたり。

普通のサイトではこんなことは考えなくていい訳です。何故なら普通のサイトは「訪問者を迷わせない(=行きたいページに迷わず行けるようにする)」ことを目標としているから。別に「一つのウェブページは一つのhtmlファイル(とそこから呼び出される画像やらCSSやらファイル)で構成されている」ということすら知らなくても普通のサイトで迷うことなんかないでしょう。というか迷わせないサイトが「良いデザインなサイト」でしょう。「閲覧者を迷わせランキング投票とかを行わせる」ということを目的としたアダルトサイトはその対極にある。

・・・と、まぁ二回に渡りウェブの恐ろしさ(というほどのモノでもない気はするが)を書いてきました。次回からもうちょい「アダルトサイト巡回マニュアル」っぽい話になります。
アダルトサイトで学ぶHTTP基礎(3)
アダルトサイトで学ぶHTTP基礎(4)
アダルトサイトで学ぶHTTP基礎(5)
アダルトサイトで学ぶHTTP基礎(6)

アダルトサイトで学ぶHTTP基礎(3) (>>この記事のみを表示)

アダルトサイトで学ぶHTTP基礎(1)
アダルトサイトで学ぶHTTP基礎(2)
例えば今アダルトサイトのトップページにいる。その目的は何なのか。

目当てのファイル(画像や動画)を落とすこと

アダルトサイトで学ぶHTTP基礎(2)までの言い方を引き継ぐなら

目的のファイルのリクエストを行うこと

ということになりますね。
「アダルトサイト」の実体は・・・というか「ウェブサイト」の実体は、どこかにあるPC(=サーバーマシン)の一ディレクトリ(と、その子ディレクトリ)内のファイル群であり、そのどこかに「目的のファイル」がある訳で。
アダルトサイトは、我々に「必要のないリクエスト」を行わせようとする。広告であったりランキング投票であったり。閲覧者に「必要のないリクエスト」をさせる方法はたくさんあります。たくさんありますが、根は一つです。
何故、閲覧者は「必要のないリクエスト」を行うのか。「閲覧者」と「(閲覧者が使用する)ブラウザ」の間の意志の疎通がうまくいかないからです。
<a href="profile.html"><img src="profile.gif"></a>
何てことはない。画像を使ったプロフィールページへのリンクです。この「profile.gif」のリクエストが行われなかったならば、それは「閲覧者」にとってマイナスになる。「行きたいページに迷わず行ける(=次にリクエストするべきファイルを迷わずリクエストできる)」という点でマイナスになる。だから、ブラウザはimgタグで呼び出されるファイルへのリクエストを(閲覧者が「画像の表示」設定をオフにしないなら)自動的に行う。
<a href="http://***.com/rank.cgi?id=******"><img src="http://***.com/banner.cgi"></a>
閲覧者にとっては「ページが重くなるだけ」のランキング投票へのリンク。この場合もimgタグで呼び出されるファイルへのリクエストは自動的に行われてしまう。
「閲覧者」と「(閲覧者が使用する)ブラウザ」の間の意志の疎通がうまくいかない
その原因の一つは「ブラウザが『閲覧者の利便さ』のために余計なリクエストまで行ってしまう」ということです。

では、余計なリクエストをブラウザに行わせないためにはどうすればいいのか。ブラウザのリクエスト制御権を制限するしかない。
□1:ブラウザの設定によって
画像・スタイルシート・JavaScript・・・そうした全ての設定を切る。自分が自覚的に(=「アドレス」欄にURLを書いたりリンク文字を押したりして)行ったリクエストのみが行われるようにする。
しかし、これは「リクエスト」の制御権を完全に自分の物にしてはいません。
  1. クライアント(閲覧者)がサーバーにファイルをリクエストする
  2. サーバーがクライアントにファイルを渡す
  3. そのファイルをクライアントのブラウザが表示する
問題は3です。「***.html」というファイルをブラウザが表示したその時、「ブラウザによるファイルの解釈」は行われている。行われているからこそ、例えば「<s>今おすすめな映画は聖石傳説</s>」が「今おすすめな映画は聖石傳説」になる訳で。その「解釈」の中で、例えば「imgタグで呼び出される(画像)ファイルをリクエスト」という処理が行われていないだけです。
JavaScriptを切っているIEにJavaScriptを強制実行させる
時にはこのようなブラウザのセキュリティホール(=バグ)によって「リクエスト」は行われる。ブラウザに「解釈」を任せるというのはつまりそういうことです。
□2:ブラウザによる解釈を行わせないことによって
IEのアドレス欄に

view-source:http://www.tokix.net/index.html

という文字列を打って「移動」を押してみて下さい。メモ帳だかが起動してtokix.netトップページのソースが表示されるはずです。この時ブラウザによるhtmlファイルの解釈は一切行われていない。
参考:「ヒトゴミ。」内「右クリック禁止についてとソースの覗き方。
本来、ブラウジングとメール送受信とFTPによるファイル送受信と・・・は全て同じアプリで行うことが可能です。telnet。しかしtelnetによってそうした様々な行為を行うためにはコマンドラインによる操作が必要となる。
そこでブラウジングならブラウジングに特化されたGUIアプリ、メール送受信ならメール送受信に特化されたGUIアプリ・・・が開発される。前者が「ブラウザ」で後者が「メーラー」。こうしたアプリは「利用者にとって使いやすい」。
「利用者にとって使いやすい」動作を行うはずのブラウザと自分の意志の疎通がうまくいかないならば、ブラウザの「GUIアプリとしての機能性」を下げるしかない。画像もCSSも読み込まれないプレーンなhtml表示から「次にリクエストすべきファイル」を迷わず見つけ出すことは困難でしょう。メモ帳に表示されたhtmlソースから見つけ出すことはさらに困難でしょう。(というか、それが困難だからこそブラウザはhtmlファイルを解釈して画像やらファイルを勝手にリクエストし表示する仕様になっている。)
アダルトサイトで学ぶHTTP基礎(4)
アダルトサイトで学ぶHTTP基礎(5)
アダルトサイトで学ぶHTTP基礎(6)

アダルトサイトで学ぶHTTP基礎(4) (>>この記事のみを表示)

アダルトサイトで学ぶHTTP基礎(1)
アダルトサイトで学ぶHTTP基礎(2)
アダルトサイトで学ぶHTTP基礎(3)
何故前回アダルトサイトで学ぶHTTP基礎(3)で「view-source:」を持ち出したのかには訳があります。

呪文のように唱えられる台詞。「アダルトサイトではJavaScriptを切れ」。
この台詞が意味することは即ち「アダルトサイトではブラウザによるJavaScriptの解釈と処理の実行をオフにさせろ」ですね、ここまでの書き方を引き継げば。

では、「JavaScriptによる処理」にはどのような事が含まれるのか。
  • ステータスバーに無意味なメッセージを流す
  • 宣伝窓を開く
  • 本気で危険なスクリプト
おそらく上記の台詞「アダルトサイトではJavaScriptを切れ」はこのような前提で発せられています。しかし当たり前ですがJavaScriptは「ページ制作者の悪意を満たすためにのみ存在する言語」ではない。
  • 利用者にとって使いやすいように
を満たすために使用されるJavaScriptも当然存在する。・・・別に「親切なアダルトサイトもある」という話ではありません。一つの例を。
main.html
<script src="js.js">
外部定義JavaScriptファイルの参照
(中略)
<a href="jamp.cgi" onClick="move(1)">むーびーのぺーじ☆</a>
後述
js.js
function move(i){
if(i==1){
window.open('movie.html',,);
}
}
move(i)関数にi=1が代入され呼び出された時movie.htmlを別ウインドウに表示する
Aタグのhrefにダミー(=jamp.cgi)を置きonClickイベント(JavaScriptによる制御)で発動するJavaScript関数によってメインページ(=movie.html)を表示する。
A1:main.htmlソースを読む
A2:move()関数がmain.htmlで定義されていないため外部ファイル「js.js」をリクエストしソースを読む
A3:js.js内move()関数を読みi=1で開かれるmovie.htmlをリクエストする
B1:「むーびーのぺーじ☆」をクリックする
A1〜3がJavaScriptをオフにし(てページの解釈を閲覧者が自分で行っ)た場合。B1がJavaScriptをオンにし(てページの解釈をブラウザに任せ)た場合。明らかにBの方が楽でしょう。こうしたJavaScriptを僕はこの連載で「利用者にとって使いやすいように使われているJavaScript」と呼びます(し、この呼称が不自然にならないようにここまで書いてきたつもりなんですが伝わってますかね・・・)。
このアダルトサイトはとりあえず「親切」ではないですね。「movie.htmlを開く時にjamp.cgiも開く」というのがこのアダルトサイトの「本来想定されている巡回方法」です。それに反する(=jamp.cgiは開かない)巡回を行おうとするならばA1〜3の方法を使わなくてはいけなくなる。

さて。これは俗に「concon問題」とか言われ結構有名だったと思うんですが、Win95/98には「imgタグのsrcに複数のMS-DOSデバイス名が含まれるとWindowsが強制終了される」というセキュリティホールがありました。
参考:「JWNTUG」内「concon バグによる使用不能攻撃
コレは怖い。たしかに怖い。そこでブラウザによる画像の表示をオフにする。他にもこうしたセキュリティホールはあるし、別の問題として全ての文字をsize=7とかmarqueeとかで表示されたら簡易ブラクラだ。そこでブラウザにhtmlの解釈をやめさせる。全てのウェブページを「view-source:」でリクエストする。htmlソースをメモ帳なりで読んでグラフィカルなウェブページを頭に描く。Aタグなどを読み「次にリクエストすべきファイル」を考える。

たしかにコレは一つの答えです。しかしそんなことをしている人がどれだけいるのかは疑問です。そしてとりあえず、この方法を使うには一つの必要条件がある。「htmlタグを理解していること(=ブラウザに解釈を行わせなくても自分の頭で解釈できること)」。

「アダルトサイトではJavaScriptを切れ」

根本的には同じレベルの台詞です。ブラウザと自分の間の意思の疎通がうまくいかないためブラウザによる言語の解釈をやめさせる。この方法を使うための必要条件は「自分がその言語(=JavaScript,html)を理解していること」。
「JavaScriptを切ってアダルトサイトを巡回すること」が「html表示を切って巡回すること」とは違うとすれば、それは「『利用者にとって使いやすいように使われているJavaScript』が『利用者にとって使いやすいように使われているhtml』よりも少ない」「『本気で危険なhtml』が『本気で危険なJavaScript』より少ない」という「程度の問題」にすぎない。

時にはJavaScriptもまた「利用者にとって使いやすいように」を目標として使用される。それは「実際何が行われているのか見えにくいように」でもあり、「実際何が行われているのか見えなくても使いやすいように」ということで。それを切るということは「実際何が行われているのか見なくてはいけない」ということに他ならない。
アダルトサイトで学ぶHTTP基礎(5)
アダルトサイトで学ぶHTTP基礎(6)

アダルトサイトで学ぶHTTP基礎(5) (>>この記事のみを表示)

アダルトサイトで学ぶHTTP基礎(1)
アダルトサイトで学ぶHTTP基礎(2)
アダルトサイトで学ぶHTTP基礎(3)
アダルトサイトで学ぶHTTP基礎(4)
とある「アングラサイト」の記述によれば「アダルトサイトでは基本的にJavaScriptはオフ、ただしJavaScriptを切ると巡回できないサイトもあるから、そういう場合はオンにしろ」ということです。ここらへんを掘り下げていきましょう。

閲覧者(のブラウザ)はサーバーに対してリクエストを行う。普段、閲覧者は「リクエスト」を意識していない。それはブラウザが何らかの言語を解釈し閲覧者に「リクエスト」という行為を意識させないからだ。「ブラウザによる言語の解釈をやめさせる」ということは「リクエストを手動で行わなくてはいけない」ということである。これは同値関係だ。

と、いうことは。
「巡回(=htmlやらムービーやらファイルのダウンロード)」をブラウジングの目的とするならば、この世には「JavaScript必須サイト」なんてものは存在しません。存在するのは「JavaScriptを切ったら手動でリクエストを行わなければいけなくなるサイト」だけです。
ここを誤解していませんでしたか?「JavaScript必須サイト」とは「JavaScriptを切ると巡回できなくなるサイト」ではないんです。何故なら、JavaScriptをオンにしたとしてもその処理に従ってサーバーに対しリクエストを行うのはクライアント(のブラウザ)だから。「JavaScriptをオフにすると変わる点」というのは「ブラウザがJavaScriptを解釈してくれないから閲覧者が解釈しないといけなくなる」ということ(だけ)です。

そして最後に「リクエスト」に関するもう少し踏み込んだ解説をしてこの連載を終えようと思います。

「リクエスト」とは端的に言えば以下のような意味を持った文字列です。

「俺IPアドレス*****でこんな感じなお客様だけどお前のとこの*****が欲しいからよこせ」
こんな感じなお客様だけど
「リクエスト」には「自分が使っているブラウザの種類」や「自分が現在どこにいるか(=どのページから目的のファイルをリクエストしようとしているか)」を加えることができます。前者は「User-Agent」で後者は「Referer」。こうした情報群は「環境変数」と呼ばれます。例えばサーバーは「リクエスト内のUser-Agentを参照して特定のブラウザを使っている人にしかファイルを渡さない」「リクエスト内のRefererを参照して正当なページからのリクエストでなければファイルを渡さない」といった処理を行うことが可能です。
参考:「68user's page」内「環境変数
我々の制御下にあるのは「どのようなリクエストをサーバーに送信するか」という点だけなんです。
アダルトサイトで学ぶHTTP基礎(1)で書いたこの文章は二つの意味を持っている。
  • 「リクエストの結果クライアントに何が渡されるか」はサーバーサイドの問題だ。だから、例えば「サーバーが環境変数を参照してファイルを渡したり渡さなかったりする」ということは可能だ(※)。
  • 「リクエスト」はクライアントの制御下にある。

通常、例えばIEを使って「http://www.tokix.net/index.html」内のリンク文字をクリックし「http://www.tokix.net/adult.html」を開こうとしたならば
  • User-Agentは「Mozilla/4.0 (compatible; MSIE 6.0; Win32)」
  • Refererは「http://www.tokix.net/index.html」
といった情報を含めた「リクエスト」が行われる。ブラウザが自動的に(閲覧者の目に触れない場所で)そうした情報を含めた「リクエスト」を行っている。しかしブラウザのアドレス欄に直接「http://www.tokix.net/adult.html」と打ち込んで「移動」を押した場合Refererは「なし」になってしまう。
アダルトサイトで学ぶHTTP基礎(4)で挙げた例のように、JavaScriptを使ってページを開くサイトの場合コレが問題になります。JavaScriptをオンにしていれば問題はない。しかしオフにしてソースから「次にリクエストすべきファイル」を探しアドレス欄に打ち込んで「移動」しても「Refererが不正だ」と開かれなかったりする訳です。
アダルトサイトで学ぶHTTP基礎(6)

アダルトサイトで学ぶHTTP基礎(6) (>>この記事のみを表示)

アダルトサイトで学ぶHTTP基礎(1)
アダルトサイトで学ぶHTTP基礎(2)
アダルトサイトで学ぶHTTP基礎(3)
アダルトサイトで学ぶHTTP基礎(4)
アダルトサイトで学ぶHTTP基礎(5)
「User-Agent」や「Referer」もまたクライアントの制御下にあります。IEを使ってブラウジングを行っていると「制御下にある」ということを意識しないはずですが、それはIEというアプリのインターフェイスの問題です。IEがそうした情報を勝手にサーバーに送信しているから我々は普段そのことを意識していない。
例えばtelnetを使えば「User-Agent」や「Referer」を自分で設定しつつリクエストを行うことが可能です。
GET /~joe/prog/cgi/env01.cgi HTTP/1.0
User-Agent: Telnet [ja] (Linux)
Host: ash.jp
ASH Multimedia Lab内「telnetでブラウズ(HTTP)」より
アダルトサイトで学ぶHTTP基礎(2)で紹介したこのリクエストは、「User-Agentは『Telnet [ja] (Linux)』な俺様だけど/~joe/prog/cgi/env01.cgiよこせ」という意味だったんです(このリクエストではRefererは省略されていますが、勿論Refererを記述することも可能です)。

telnet使わなくても、例えばダウンロード支援ツールでもいいんですよ。httpダウンロードが可能なIrvineの場合なら「フォルダ設定」内「HTTP (2)」で設定できます。telnetよりはこっちの方が使いやすいですかね。
「使いやすい」と軽く書きましたが、telnetとIrvineの差はあくまで「インターフェイスの差」であって根本的には同じだ、ということを分かってもらえているでしょうか?
ついでにもっと言うなら、IE等多くのブラウザには「User-AgentやRefererを閲覧者が自分で設定しつつファイルをリクエストする」という機能が実装されていない(一部タブ型ブラウザ等を使えばUser-Agent設定いじれますけどね)ためtelnetやIrvineを紹介しているだけであって、根本的にはIEもtelnetもIrvineも「やっていること」は同じです。

上記の設定で例えば「http://www.tokix.net/adult.html」を落とそうとしたなら
  • User-Agentは「Mozilla/4.0 (compatible; MSIE 6.0; Win32)」
  • Refererは「http://www.tokix.net/index.html」
という情報を含めた「リクエスト」が行われる訳ですね。もしtokix.netが「Refererがhttp://www.tokix.net/index.htmlでなければadult.htmlを渡さない」「User-AgentがIEかNNでなければadult.htmlを渡さない」といった制限をかけていたとしてもこうすれば潜れる。

「巡回(=htmlやらムービーやらファイルのダウンロード)」をブラウジングの目的とするならば、我々閲覧者が行わなくてはいけないのは「サーバーに対する適切なリクエスト」だけです。ブラウザにその「リクエスト」を任せないならば閲覧者が「リクエスト」・・・「適切なリクエスト」・・・を行わなくてはいけない。逆の言い方をすれば、「適切なリクエスト」さえ行えば「ブラウザによる言語の解釈を切ったら巡回できないサイト」などこの世には存在しない。論理的に存在しえない。
dammy

Credit

SeeAlso

OtherSubCategory

Footprint

Navigation