数日前、有名なSaaS=プロバイダーのWebサイトにログインしようとしました。ブラウザーでパスワードマネージャーを使用したので(ユーザー/パスが正しい))、NoScriptプラグインを使用しましたサイトに許可が制限されていたため、一部のJSがブロックされました。交換全体はHTTPS経由で行われました。
応答は、以下のようなURLを使用してログインサイトに戻るリダイレクトであり、login_password
データもpassword
入力の値に入力されていました。
.../[email protected]&login_password=REDACTED&remember_me=on
これは、カスタマーサポートで提起される弱いアプローチおよび悪い習慣として分類されますか、それともセキュリティの脆弱性として報告されますか?
同社は、元の問題が再現されないようにする応急処置で対応しました。
間違いなく問題があり、報告する価値があります。
HTTPSが [〜#〜] hsts [〜#〜] および preloading で適切に保護されている場合、トラフィックを監視している脅威アクターはGETを見ることができません。内容。しかし、HSTSはまだいくらか珍しいため(そして、GETにプレーンテキストのパスワードを入れている場合、おそらくHSTSのような他のベストプラクティスを認識していません)、傍受/ダウングレードのリスクはおそらく多少高くなります。
それとは別に、HTTPS設定の状態に関係なく、リモートHTTPサーバーはほとんどの場合、完全なGETコンテンツをサーバーのログに記録します。そのため、これらのプレーンテキストのパスワードもおそらくサーバーに記録されます。
[編集: vakusの答え は、残りの攻撃ベクトルをより完全にカバーしています!]
これはすぐに報告する必要があります。
ユーザーアカウントの侵害につながる可能性のある攻撃が多数あります。
GETパラメータとして表示されるパスワードは、 [〜#〜] owasp [〜#〜] による脆弱性だけでなく、それらが悪用される可能性がある多くの方法があります。
一般的な脆弱性により、SQLインジェクションなどの攻撃経路を介して保護されたパスワードの盗用が可能になります。保護されたパスワードは、ログ、ダンプ、バックアップなどのアーティファクトから盗まれる可能性もあります。
( March Ho のコメントからの引用とリンク)
そのようなポリシーは能力の欠如を示しているので、私は別のサービスを見つけることを検討するまでさえ行きます。
以下は、レポートに含めることができるいくつかのハイライトです
ログファイル
GETパラメータによって送信されたパスワードは、ログファイルに記録されます。これは、サービスの管理者がパスワードをプレーンテキストで表示できるようになったことを意味します。これは、パスワードをプレーンテキストでデータベースに保存するのと同じくらい悪いです。管理者または特権者が悪意のあるユーザーになり、ユーザーのパスワードを使用して他のサービスにアクセスしないことをユーザーに保証するものはありません。そして、誰もが知っているように、パスワードの再利用は一般的ではありません。
これは、システムが侵害された場合、攻撃者はデータベースをクラックするのではなく、ログファイルを読み取るだけでよいことも意味します。これは大きな脆弱性であり、多くのユーザーアカウントが多くのプラットフォームで危険にさらされます。
最近、Twitterにも同様のことが起こりました 。パスワードは、内部ログファイルの1つにプレーンテキストとして保存されていました。 Twitterは、すべてのユーザーにパスワードを変更するよう促しました。これには、ユーザーが同じパスワードを使用した他のWebサイトも含まれますが、このバグの侵害や悪用の証拠はありませんでした。これは、サーバーが危険にさらされると、ユーザーに深刻な影響を与える可能性があることを示しています。
ショルダーアイピッキング
近くにいる人はだれでもあなたのパスワードを平文で見ることができ、それを書き留めることができます。パスワードは多くの場合サービス間で再利用されるため、そのパスワードは他のサービスを侵害するために使用される可能性があります。
ブラウザ履歴
パスワードはWebブラウザーの履歴の一部として保存されます。つまり、コンピューターとWebブラウザーにアクセスできる人なら誰でも、パスワードを知らなくてもアカウントにログインできます。これは、公共のコンピューターを使用している場合にのみ悪化します。
この結果、履歴にアクセスできるすべての人がパスワードとログインをコピーして、他のサービスを侵害することもできます。
[〜#〜] https [〜#〜]
ウェブサイトはHTTPSを使用して動作しているとのことですが、ただし、Webサイトがプリロードと [〜#〜] hsts [〜#〜] を使用しているという保証はありません。
HSTSは、HTTPS接続を介してWebブラウザーにWebサイトを強制的にロードします。
WebサイトがHSTSを使用していない場合、WebサイトはHTTPS接続にアップグレードできない可能性があります。これは、すべてのHTTPSリンクをHTTPに変換するSSLストリップを介して実行できます。 WebサイトがHSTSを使用している場合、WebブラウザーはHTTPS経由でWebサイトを自動的にロードしようとし、できない場合はHTTPによる接続を拒否します。ただし、WebサイトがHSTSを使用している場合でも、対象のWebブラウザーでWebサイトが開かれたことがない場合、SSLストリップ攻撃は機能します。Webブラウザーは、このWebサイトがHTTPS経由でのみロードされることをまだ認識していないためです。
これを防ぐために、ウェブサイトはプリロードを使用します。プリロードの場合、WebブラウザーにはWebサイトの組み込みデータベースがあり、HTTPS経由でロードする必要があり、HTTPでロードすることはできません。これはHTTPS ダウングレード攻撃を効果的に防止します。
セキュリティ監査
パスワードがログファイルの一部として保存されているという事実は、企業がセキュリティ監査を実行していない可能性が高いか、そうである場合、企業としてのセキュリティにそれほど重点を置いていないことを示しています。
HTTPリファラー
Mr Llama のコメントで述べたように
GETパラメータは、HTTPリファラーヘッダーにも表示できます。ページからロードされたオフサイトのリソースは、リファラーヘッダーを介して資格情報を送信することもできます。
リンク共有
何らかの理由でウェブサイトへのリンクを他の誰かに提供する必要がある場合。同僚、あなたはそれをコピーしてその人に送るだけではありません。これにより、他のプラットフォーム上のアカウントへのアクセスに使用できる、アカウントとログインおよびパスワード情報へのアクセス権がこのユーザーに再び付与されます。
スパイダーを検索
検索スパイダーは基本的に、Webサイト上の可能な各リンクをたどり、それを索引付けしています。可能性は低いですが、GoogleやBingのような検索スパイダーは、公開されたリンクをインデックスに登録して、Webサイト検索の一部として表示することができます。これは、ユーザーがGoogleまたはBingからあなたのアカウントにログインできることを意味します。
私はできる限り緊急に会社に連絡を取ります。これによるセキュリティへの影響は非常に大きく、多くのユーザーに影響を及ぼします。
SaaSプロバイダーを可能な限り変更することを検討します。会社がレポートに準拠しない場合は、プレーンなパスワード違反を公に恥じるべきです。