HTTPS WebサービスがHTTPに切り替えられました。何がうまくいかないのですか？
最近、HTTPS接続があったウェブサイトにアクセスしました。これで、単純なHTTP接続のみとなり、認証方法がuser + passwordから「Googleアカウントで認証」に変更されました。
私は彼らに連絡して、なぜHTTPSを落としたのか尋ねたところ、「認証はGoogleで安全に保護されているので、もう必要ないため」と私に言いました。
ええと、私はセキュリティの専門家ではありませんが、返信する前に、何がうまくいかないのか知りたいのですが。
だから、私の少しの知識があれば、私はこう言います（私が間違っている場合は訂正してください）。
- クライアントとサーバー間の通信におけるプライバシーの喪失（攻撃者は交換された情報を読み取ることができ、クライアントがサーバーに投稿している可能性のある個人情報を含みます）。
- 攻撃者は、おそらく悪意を持って、クライアントのリクエストを変更する可能性があります。
- 攻撃者はCookieを読み取り、それを使用して、Googleのサービスを使用して最初に認証されたクライアントであるかのようにサービスにアクセスできます。
私は正しいですか？他に何がうまくいかないのでしょうか？
そうです、HTTPへの回帰は無意味です。
すべてのポイントは、攻撃者がクライアントとサーバー間のデータ転送にアクセスできる特定の種類の攻撃に適用されることに注意してください。これは、WiFiホットスポットの所有者、またはISPが man-in-the-middle として機能している可能性があります。あなたとサーバーの間に。 これはリモートの攻撃者にとって達成するのが難しい場合がありますが、公共のWiFiでは特に簡単です。
[〜＃〜] https [〜＃〜]がHTTPに追加するものは安全なデータ転送。 Webアプリケーション自体は完全に問題ありません。暗号化されていないチャネルを介して通信している場合、攻撃者は任意のデータを読み取り、変更し、リクエストとサーバーの応答に挿入することができます。キャプチャされたセッションCookieを使用すると、Cookieが有効である限り、偽装することもできます。
攻撃者ができないことは、Googleアカウントを乗っ取るか、後でGoogleで再認証することです。これは、Googleでの認証は常にSSLを介して行われ、付与されたトークンは一定時間後に期限切れになるためです。
そのため、すぐに資格情報を取得するよりも、状況は多少良くなります。ただし、あなたが言ったように、攻撃者は引き続きセッションを乗っ取り、ユーザーに代わって任意のアクションを実行することができます。
私は次の質問を提起します：
アプリケーションで認証を行うことのポイントは何ですか？
すべてのページに含まれるすべてのページがパブリックコンテンツであり、外部で検証できる場合（たとえば、パッケージがPGPを使用するdebianミラー）およびユーザーは第三者が訪問するものを精査していることを考慮して、ページはhttpsを必要としない場合があります。しかし、ログインでもありません。
認証を要求する一般的な理由は次のとおりです。
ユーザーがログイン中にのみ読み取ることができるいくつかのデータがあります
登録ユーザーは他の人にメッセージを送ることができます
自分だけが使用したアイデンティティを維持することで、ユーザーは評判を得ることができます
アカウントは外部で得られるいくつかの利点（有料コンテンツへのアクセスなど）を受け取ることができます
通信でhttpsの代わりにhttpを使用すること、およびログインを挿入する他のほとんどすべての理由によって、それらすべてが無効になります。パスワードが公開されていないという事実にかかわらず（確かにさらに悪いことになります）。
少し前に、証明書の購入の価格が議論されましたが、現在、無料で証明書を提供しているCAがいくつかあります。
†Nitpickerのコーナーでは、これによってセキュリティが損なわれない非常にまれなケースがいくつかあります。例としては、Megaがあります。これは、httpを介していくつかの一般的なJavaScriptをロードしましたが、httpsロードされたスクリプトは、実行する前にハッシュを検証しました。どこでもhttpsを設定するよりも壊れやすく複雑です。家でこれを試してはいけません、子供たち。
資格情報は安全ですが、セッションハイジャックが発生する可能性があります
1つの可能性は、攻撃者が中間者として機能しているときにSSLストリップ攻撃を行った可能性があり、その場合、HTTPS WebサイトはHTTPとして被害者に提供されます。しかし、あなたが彼らがそれを意図的にしたことをウェブサイトで確認したように、この可能性は打ち消されます。
現在、GoogleはoAuth2を使用しているため、GoogleとのハンドシェイクはHTTPS経由で行われ、その後HTTP経由でウェブサイトにリダイレクトされます（これは https://security.stackexchange.com/）と同じように行われます あなたがあなたのグーグルアカウントを使用している間）。あなたのウェブサイトはoAuthの後にセッショントークンを生成したでしょう。この場合のHTTPのリスクは、添付ファイルが非常に簡単にセッションを乗っ取り、あなたになりすましてWebサイトを閲覧することです。
あなたは完全に正しいです。 Googleログイン認証情報を除外すると、攻撃者はMITM攻撃を実行し、すべての被害者のリクエストを傍受できます。 SSLプロトコルを再実装してリスクを伝えることをお勧めします。
「問題が発生する可能性があります」：APIを使用してこれを行うと、iOS 9用に設計され、そのAPIを使用してiOS 9で実行されているすべてのiOSアプリケーションが動作しなくなります。
これは「App Transport Security」と呼ばれ、開発者がドメインの例外を作成しない限り、httpは受け入れられず、接続が十分に安全でないhttpsは受け入れられません。 APIはhttpsを使用していたため、既存のアプリはドメインに例外がないため、機能しなくなります。