2008-08-06 5 views
3

私はHttpServerを制御できますが、そこにあるApplicationServerまたはJavaアプリケーションを制御することはできませんが、それらのアプリケーションの特定のページへの直接アクセスをブロックする必要があります。正確には、ユーザーが適切なサーブレットに直接GET/POST HTTPリクエストを発行するフォームへのアクセスを自動化することは望ましくありません。HTTP_REFERERを使用してサイトの内部へのユーザーアクセスをブロックします

したがって、HTTP_REFERERの値に基づいてユーザーをブロックすることにしました。結局のところ、ユーザーがサイト内をナビゲートしている場合は、適切なHTTP_REFERERを持っています。まあ、それは私が思ったものでした。

私が言うの.htaccessファイルに書き換えルールを実装:私はサイトをナビゲートしますが、「にservlet1」に直接GETリクエストを発行していないユーザーへのアクセスを禁止することが期待または「

RewriteEngine on 

# Options +FollowSymlinks 
RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC] 
RewriteRule (servlet1|servlet2)/.+\?.+ - [F] 

servlet2 "サーブレットを使用します。しかし、正規表現(servlet1|servlet2)/.+\?.+がまったく動かなかったので私の期待は突然終了しました。

私はその表現を(servlet1|servlet2)/.+に変更すると本当に失望し、サイトを操作したかどうかにかかわらずユーザーがブロックされてしまったようにうまくいきました。

私の質問は次のとおりです。アプリケーションを変更するアクセス権や特権/時間がない場合、特定のページに直接アクセスできる「ロボット」を許可しないでください。

答えて

2

これを一度に解決できるかどうかはわかりませんが、必要に応じて前後に進むことができます。

まず、私があなたが言っていることを繰り返し、私が明確であることを確認したいと思います。サーブレット1とサーブレット2へのリクエストを拒否したいのですが、リクエストに適切なリファラーがなく、にはにクエリ文字列がありますか?あなたがservlet1と2の下でファイルを要求しているように見えるので、私は(servlet1 | servlet2)/.+\?.+を理解できないのか分かりません.PATH_INFO( "?"の前)とGETクエリ文字列( "?"の後)。 PATH_INFO部分は動作しますが、GETクエリテストは動作しません。私はscript1.cgiとscript2.cgiを使用して私のサーバー上で簡単なテストを行い、あなたが求めていることを達成するために以下のルールが働いていました。彼らは明らかに私の環境に合うように少し編集されています

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC] 
RewriteCond %{QUERY_STRING} ^.+$ 
RewriteRule ^(script1|script2)\.cgi - [F] 

上記はscript1.cgiとクエリ文字列を使用してデータを提出しようとしたscript2.cgiするすべて間違っ-リファラ要求をキャッチ。ただし、path_infoを使用してデータを送信し、データを送信することもできます。あなたが作業を取得しようとしていた例に基づいて

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC] 
RewriteCond %{QUERY_STRING} ^.+$ [OR] 
RewriteCond %{REQUEST_METHOD} ^POST$ [OR] 
RewriteCond %{PATH_INFO} ^.+$ 
RewriteRule ^(script1|script2)\.cgi - [F] 

、私はこれがあなたが望むものだと思う:私は間違ったリファラで使用されている3つの方法のいずれかのから保護するためにこのフォームを使用し

RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC] 
RewriteCond %{QUERY_STRING} ^.+$ [OR] 
RewriteCond %{REQUEST_METHOD} ^POST$ [OR] 
RewriteCond %{PATH_INFO} ^.+$ 
RewriteRule (servlet1|servlet2)\b - [F] 

これは少なくとも、あなたの目標に近づけることを望みます。それがどのように機能するか私達にお知らせください、私はあなたの問題に興味があります。

(ところで、私はリファラブロッキングが貧弱なセキュリティであることに同意、私はまた、あなたがすでに認めているように見えるれ、時にはそのrelaity力不完全と部分的なソリューションを理解しています。)

1

解決策はありませんが、参照元に頼ることは決してうまくいきません。ユーザーエージェントは、それをまったく送信しないでください。

0

私はあなたがスクリーンスクレイピングを防止しようとしていると思いますか?

私の正直な意見では、HTTP_REFERERの値をチェックすることで解決して解決しようとするのは厳しいものです。提出を自動化することに迷惑を掛けている人は誰でも、自分の「オートマトン」から正しいリファラーを送るほど精通しているでしょう。

レートリミットを試みることはできますが、実際にアプリを修正していなくても、ある時点で何らかの人間の検証(CAPTCHA)を強制する必要はありません。

1

ユーザーと悪意のあるスクリプトをhttp要求で区別することはできません。しかし、どのユーザーがあまりにも短い時間であまりにも多くのページを要求しているのかを分析し、IPアドレスをブロックすることができます。

1

Javascriptは、画面スクレイピングを防止する(または少なくとも遅らせる)ための便利なツールです。ほとんどの自動化されたスクレイピングツールにはJavascriptインタプリタがないので、隠しフィールドの設定などの作業を行うことができます。

編集:this Phil Haack articleの行に沿って何かがあります。

1

リファラーの使用は検証方法として非常に信頼性がありません。他の人が触れたように、それは簡単に偽装されています。

あなたはCAPTCHAを使用することもできますし、ユーザーが最後に訪問したページを追跡するCookieまたはセッションCookieを設定することもできます(セッションはスプーフィングするのが難しいでしょう) )、ページビューの履歴を記録し、ブロックするページにアクセスするために必要なページを閲覧したユーザーのみを許可します。

これは明らかに、しかし、それが最も確実な方法ですが、問題のアプリケーションへのアクセスを持ってする必要があります(私の意見では「十分」ではない完全に、しかし。)

0

検索を防ぐためにしようとしている場合エンジンのボットが特定のページにアクセスしないようにするには、適切にフォーマットされたrobots.txtファイルを使用していることを確認してください。

HTTP_REFERERの使用は、easily fakedであるため、信頼性がありません。

もう1つの方法は、ユーザーエージェントの文字列で既知のボットをチェックすることです(これにはコードの変更が必要な場合があります)。

0

物事はもう少し明確にする:

  1. はい、私はHTTP_REFERERを使用して、完全に信頼できない、やや幼稚であることを知っているが、私が学んだ人というかなり確信している(多分私から?) Excelでオートメーションを作成するVBAは、時間内にHTTP_REFERERをどのように破壊して最終的な解決策を得るかを知りません。

  2. アプリケーションコードを変更するためのアクセス権と特権がありません。政治。貴方はあれを信じますか?だから、権利者が私が要求した変更を行うまで待つ必要があります。

  3. 以前の経験から、要求された変更が生産に入るのに2ヶ月かかることがわかりました。いいえ、それを捨てるアジャイル方法論頭の中の本は何も改善しませんでした。

  4. これはイントラネットアプリケーションです。だから私は多くの若者が私の威信を弱体化しようとしていません。しかし、私は若くて、「インドから来た非常に素晴らしいグローバルコンサルタントサービス」の威信を損なうように努力していますが、不思議なことにそこに働くインディアンは一人もいません。

これまでのところ、最良の答えは「Michel de Mare」です:IPに基づいてユーザーをブロックします。まあ、私は昨日やった。今日私はカンガルーユーザーが(IPアドレスから別のアドレスにジャンプする)VPNやDHCPを使用しているため、より一般的なものを作りたいと思っていました。

0

あなたは抗を使用することができるかもしれませんCSRFトークンを使用して、あなたが何をしているかを達成します。

この記事で詳しく説明します:Cross-Site Request Forgeries

関連する問題