プロキシサーバーを使用してFacebookなどのサイトに入るusername
とpassword
を取得することは可能ですか?
シナリオは次のとおりです。
1。私のラップトップはネットワークに接続されています。
2。プロキシサーバーを使用してインターネットに接続するように設定されています。
3。自分の資格情報を安全なサイトに入力します。
上記のシナリオで他のユーザーが資格情報を取得することは可能ですか?
URLがSSLを使用しており(つまり、https://
)、プロキシをトランスポートのみに使用する場合、いいえ、プロキシは暗号化されたデータのみを認識し、それを覗くことはできません。 (プロキシが偽造された証明書をユーザーに提供しようとしない限り、マシンに協調CAを事前にインストールする必要があります。これは、敵がローカルのsysadminである作業環境で発生する可能性があります。)
マシンを出るときに接続が保護されていない場合は、はい、当然のことながら、プロキシは送受信されるすべてのバイトを確認します。これは、すべてのプロキシテクノロジーに当てはまります。
プロキシ自体が何らかの認証を要求する場合や、プロキシ自体とターゲットサーバーとの間でSSLをネゴシエートする場合は、状況がさらに複雑になる可能性があります。技術的に注意を怠ると、入力したパスワードが実際にどこに行くのかを知るのが少し難しくなることがあります。 If:
www.facebook.com
であり、www.facebook.com.sdjygsdb.com
のようなものではありません) ;その後:
それ以外の場合:
場合によります。
プロキシには、主にHTTPとSOCKSの2つのタイプがあります。
HTTPプロキシは、その名前が示すように、実際にはHTTPトラフィックのみを処理できます。あなたはそれにリクエストを送信し、それをターゲットページに転送し、結果をあなたにプロキシします。このトラフィックはすべてプレーンテキストで送信されるため、傍受して変更することが可能です。ただし、これらのプロキシの一部でHTTP CONNECTを実行して、HTTPトラフィックをTCP=トンネルに変えることができます。そこから、そのトンネルでSSLを使用して保護を行うことができます。ほとんどのタイプのスニッフィング攻撃に対して、プロトコル全体がHTTPSで動作することを除いて、HTTPSプロキシと呼ばれる別のタイプのHTTPプロキシは同じように機能します。
反対側にはSOCKSがあります。SOCKSは単なるトンネルとして機能します。メッセージがプロキシに送信されてターゲットサーバーへの接続が作成され、プロキシはユーザーとサーバーの間ですべてを転送します。現在使用されているSOCKSには、SOCKS4、SOCKS4a、およびSOCKS5の3つの主要バージョンがあります。 SOCKS4a仕様では、プロキシがクライアントの代わりにDNSルックアップを実行するように、IPアドレスの代わりにドメイン名をターゲットパラメータとして渡す機能が追加されました。これにより、以前はクライアントからのDNSルックアップトラフィックを傍受し、アクセスしているサイトを特定することができたため、クライアントがDNSルックアップ自体を実行できない問題の修正に役立ち、プライバシーの改善にも役立ちました。 SOCKS5はプロトコルをさらに拡張し、IPv6とUDPのサポートに加えて、認証を改善しました。ただし、実際のSOCKSトラフィックはプレーンテキストであり、クライアントはトンネル接続内で独自のトランスポートセキュリティを提供する必要があります。
一般に、プロキシを使用することは、トラフィックを自分で送信するのと同じくらい安全であると考える必要があります。プレーンテキストの情報は引き続きプロキシに送信され(HTTPSプロキシでない限り)、盗聴される可能性があります。トンネルが作成された後も、HTTPSまたは同様の安全なプロトコルを介してターゲットサーバーと通信していない限り、トラフィックを傍受できます。
興味深いケースは、プロキシのオペレーターが悪意のある場合に発生します。プレーンテキストのトラフィックは、関係なく盗聴、盗用される可能性がありますが、悪意のあるプロキシがアクティブな攻撃を実行する可能性があります。たとえば、コンテンツをトラフィックに注入したり、他のサーバーにリダイレクトしたりする可能性があります。 HTTPSを使用すると、プライバシーと安全性は向上しますが、攻撃者がSSLハンドシェイクを妨害することでSSLを「ダウングレード」したり、SSLをバイパスしたりできる可能性があります。すべてのトラフィックを密かに復号化しながら、偽造された証明書をユーザーに返し、ターゲットサーバーであると主張することさえあります。
簡単に言えば、プロキシは危険な場合があるため、信頼できるプロキシのみを使用する必要があります。
主なケースは2つあります。http://facebook.com
に接続する場合、またはhttps://facebook.com
に接続する場合( [〜#〜] http [〜#〜] vs [〜#〜] https [〜#〜] )。ところで、FacebookはデフォルトでHTTPSにリダイレクトします。
HTTPでは、すべての通信が平文です。サーバーとの間のインターネットインフラストラクチャを少しでも制御している人は誰でも、通信を傍受して資格情報を取得できます。プロキシを指定したかどうかは関係ありません。プロキシは transparent にすることができ、プロキシがなくても、誰かがまだリッスンしている可能性があります。
実際には、ISPは顧客をスパイしません。雇用主は時々従業員をスパイします。また、wifi接続を使用している場合、他のローカルwifiユーザー あなたをスパイできる可能性があります 。
ところで、資格情報はユーザー名とパスワードだけではありません。接続を確立すると、セッションはCookieによって識別されます。攻撃者があなたのcookieを取得した場合、それらはあなたに(少なくともあなたが接続を閉じるまで)パスすることができます。
HTTPSでは、基本的な答えは「いいえ」であり、資格情報は安全であり、接続は安全です。これらの条件がすべて満たされていれば、接続は安全であることがわかります。
facebook.com/
または接続しているサイトで始まります(facebook.com.evilhackers.com/…
のような別のサイトが表示された場合、間違ったサイトに安全に接続されています)。最後のポイントは会社が発行したコンピューターに関連します。一部の雇用主は独自の証明機関をインストールするため、会社のプロキシを使用して作成されたブラウザーはすべての接続を正規のものとして受け入れます。お住まいの国に応じて、これは合法である場合とそうでない場合があり、通知する必要がある場合とない場合があります(100ページに及ぶITポリシーでは細かい表記で)。
HTTPSが安全に使用されていると仮定すると、プロキシは、暗号化されたバイトを前後にのみ中継できます。接続先のサイトは認識しています(パケットの送信先を認識している必要があります)が、アクセスしている完全なURL、ページのコンテンツ、またはフォームで送信するデータは認識できません。
これは、暗号化されていないWebサイトを使用する場合に非常に可能ですが、SSLを使用するとかなり困難になります。
SSLを使用すると、中間者攻撃(MITM)がそのデータを明らかにする可能性があります。これには、プロキシがWebサイトと証明書をネゴシエートし、それをブラウザでネゴシエートする必要があるため、自分とプロキシの間でデータが暗号化され、復号化されてから、再暗号化されてFacebookに送信されます。
SSLサイトから証明書エラーを受け取ったときに、それがどこから来たかを知らずに自動的に例外を追加しないようにしてください。
他の回答に追加
Sslストリッパーと他のいくつかのスニッフィングツールを使用することで可能です。いくつかのsslストリッピングツールを使用して、ネットワークでこのケースをテストしました。パスワードやユーザー名を簡単に取得できます。Squidサーバーを使用しています。 FacebookとGmailはhttpsで使用していますが、私はそれを手に入れました。したがって、セキュリティは単純な冗談です。最大限の保護を提供できますが、それだけではありません。