荒川区ホームページ・ブログ制作･作成･アクセスアップSEOのマウンテンブック

無断リンクを制限する

Wed, 17 Oct 2007 08:14:34 +0900

自社のホームページが希望もしていないのに勝手に紹介されて、勝手にリンクが張られてしまう。もちろん、ネットの世界は基本的にリンクは自由だと思いますが、紹介文の中に頻繁に更新する情報などが含まれる場合は要注意です。条件が変更となり自社の情報を変更しても以前の情報が世の中に公開されたままです。例えば求人情報など。アクセス数が欲しいという理由で個人が、求人サイト系をから情報を抜き出し、リンクを張るカタチで情報発信しようとします。紹介文には募集条件が掲載され、その中に本家求人サイトへのリンクが張られます。確かに、このようなサイトを構築すれば少ないなりにもアクセス数が稼げます。しかし、求人サイトから見たら自社媒体ではない、コントロール外のサイトに求人情報の条件が掲載されます。もし、求人掲載企業が条件を変更した場合、自社媒体だけであればスグに情報を反映できますが、契約も交わしてない外部サイトに条件が掲載されていたら変更のしようがありませんし、わざわざ変更して下さいとお願いするわけにもいきません。ただ、こういったサイトの運営者は公開されている情報を集めているだけだから問題ないと持論を唱えます。交渉はややこしくなります。そういった場合の対抗策として、技術的に防ぐ方法がリファラによる制限です。 100%完璧な方法ではありませんが、例えば「arubaito..com」というドメインで求人サイトを公開している場合、求人詳細ページはトップから行けば「arubaito..com」というリファラ経由で来るハズです。それが、全く違うドメイン、サイトから直接求人詳細ページへ来た際に制限をかけてブロックするのがリファラによるリンク防止策です。この手法は一部ブログ運営企業のブログ内画像に対して行われています。外部からブログに掲載されている画像にアクセスしようとしても表示されません。ブログが画像置き場になるのを防いでいるのです。このリファラアクセス制限ですが、制限したいフォルダに.htaccessを設置します。中身は以下のような感じです。 SetEnvIf Referer "^http://www\.netmania\.jp" ref_ok order deny,allow deny from all allow from env=ref_ok 参照：http://www.shtml.jp/htaccess/referer.html 上記、.htaccessを設置したフォルダ以下は、リファラーにwww.netmania.jpがない限りエラーが発生し、トップページへ飛ばされます。勝手に個別ページへリンクされたくない場合に効果的です。例えば、無断で情報収集している場合、個別ページへのリンクが不可であれば紹介するのも難しくなるでしょう。この.htaccessによる制限だけでもかなり効果があります。但し、良い面だけではありません。リファラーを送信しないブラウザを使ったユーザーも排除されてしまうからです。その場合は特定のサイトからのみリンクを禁止する設定にする方法があります。これならば、リファラーを送信しないユーザーへの影響は軽微です。 SetEnvIf Referer "hoge.com" ref01 order allow,deny allow from all deny from env=ref01 hoge.com の部分に禁止したいサイトのドメインの一部を書きます。これで、hoge.comからのリンクのみ許可されなくなりました。複数のサイトを制限したい場合は以下のようにして下さい。 SetEnvIf Referer "hoge.com" ref01 SetEnvIf Referer "hoge.net" ref02 Order Allow,Deny Allow from all Deny from env=ref01 Deny from env=ref02

サーバー上のファイルを見られない様にする方法

Mon, 01 Oct 2007 07:09:19 +0900

ネットマニアさんで「サーバー上のファイルを見られない様にする方法」と言う記事を発見しました。その方法とはファイル名の頭に#を加えると言う方法のようです。サーバーにファイルをアップしたが、まだ見せたくないと言う時に有効ですね。例）index.html　→　#index.html フォルダにも有効のようです。例）mountainbook.net/file/　→　mountainbook.net/#file/ 実践したらレポート書きます。ネットマニア

まだまだあるクロスサイト・スクリプティング攻撃法

Tue, 17 Apr 2007 19:30:31 +0900

狙われるWebアプリケーション【第3回】 前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。引用サイト

クロスサイトスクリプティング

Wed, 07 Mar 2007 16:28:03 +0900

クロスサイトスクリプティングとは何か クロスサイトスクリプティング（別名 XSS）はウェブアプリケーションがユーザーから悪意をもってデータを収集する際に発生します。データは通常、悪意のあるコンテンツを含んだリンクのフォーム内に集められ、ユーザーは大抵の場合他のウェブサイトや掲示板、電子メール、インスタントメッセンジャーからこのリンクをクリックしてしまうものと考えられます。通常、攻撃する側はサイトへのリンクの悪意のある部分をHEX（またはその他の方法で）エンコードしているため、クリックする際にユーザーにはそれが疑わしいものには見えません。データがウェブアプリケーションに集積されると、独自に送信する悪意のあるデータを含んだページをユーザーに向けて作成しますが、ウェブサイトから送られる正しいコンテンツにある程度偽装してあります。 どうやって対策をすればいいでしょうか？ 簡単に答えます。ユーザー・インプットを信用せず、常にメタキャラクターにフィルターをかけましょう。これで XSS 攻撃の大半を振り落とすことができます。スクリプトの出力には「<」と「>」を「<」と「>」に置き換えることもお勧めします。XSS セキュリティホールを悪用されれば損害を受けますし、高くつくものになることには留意してください。アタッカーはセキュリティホールを公表することもあります。これによりあなたのサイトがセキュリティやプライバシーの保護といった面で顧客と世間の信頼を損ねることになりかねません。「<」と「>」をフィルタリングするだけでは全てのクロスサイトスクリプティング攻撃への解決となるわけではありません。「(」と「)」も同じく「(」と「)」に変更して出力することをお勧めします。

http://lovemorgue.org/xss.html

クロスサイトスクリプティング対策

Thu, 01 Mar 2007 17:30:23 +0900

ここまで、いろいろな文字化けパターンについて考察してきました。これらの多くは（マイナー）ブラウザのバグによるもので、「仮に圧倒的多数である Windows版IEユーザーがまともに見ることができるならば、他のブラウザで見た場合に多少文字化けしたところで、構わない」というスタンスもありえなくありませんでした。また、実際、そういうサイトも多いです。ところが、実は文字コードの処理を誤ると思わぬセキュリティホールが起こりえます。代表的なものはクロスサイトスクリプティングです。クロスサイトスクリプティングについて簡単に説明しますと、ユーザー入力などにより動的に生成されるページがあったとします。「田中　太郎」という入力値であれば問題ありませんが、「田中　太郎」という入力値の場合、どうなるでしょうか？
もし、名前を表示する側のプログラムで適切な処理（HTMLタグやJavascriptコードの無効化。『サニタイジング』と呼びます。）を行っていなかった場合、そのままHTMLタグが実行されますので、赤い文字で名前が表示されます。これぐらいの話であれば、「裏技」ということで処理できるでしょうが、実際はセッション・ハイジャックなどの危険性があります。Javascriptもそのまま実行されるためです。クッキーを利用したセッション管理はよく見られる手法ですが、このHTMLタグの無効化処理の失敗による脆弱性を利用することで（クロスサイトスクリプティング Cross Site Scriptingと言います。略してCSS問題とも呼びますが、スタイルシートのCSSと紛らわしいので、XSS問題とも呼びます。）、他人のクッキーを盗み出すことが可能です。何も知らないユーザーAが、悪意のあるユーザーBが巧妙に仕組んだURLをクリックすると、そのサイトで発行されているクッキーが、Bの管理するリモート・サーバに送信させることが可能になるのです。仮にクッキーだけで認証しているとするならば、後は、Bは自力でそのクッキーを焼いて、そのサイトにアクセスすれば、Aになりすますことが可能になります。詳しくは、下記のサイトを参照してください。