あなたのアプリケーションをハッキングするよりも簡単かもしれない

TLドクター
私は、私のコーヒーショップの購読から毎週の電子メールで怪しいふるまいに気がつきました;それは、私が専用のリンクを通して私の好みを直接編集することを提供していました.私はクッキーと認証トークンをバイパスすることができた(パスワードなしでアカウントの詳細パネルに到達することができた/アカウントのメールなど)本質的に店は厳しい認証と認証の問題にさらされていたIDOR of PII (個人情報の公開).その上に、コーラもCSRF 緩和は、1つのクリックアカウントの乗っ取りにつながる悪意のあるリンクを作成できるように、場所にあった.
免責事項:私は誰も明確な同意なしに任意のテストを行うことを示唆していません.私は、私のお気に入りの店の1つの幸せな顧客としての脆弱性に気づいて、私の口座がどれくらい簡単に操作されることができたかに興味をそそられました.そこから、さらにバグを見つけるために私を連れて行った好奇心がありました.私は、できるだけ少数の「攻撃的な」行動を維持しようとして、彼らがリスクを軽減するのを援助するために、詳細にすべてを店に報告しました.

どのようにすべて開始

私は、ロンドンで最高の喫茶店の1つへの予約をします.私は、豆や配達スケジュールの設定を変更することを示唆しているメールとともに、週に一度新鮮なローストビーンズの袋を送っています.
私は何度もリンクを使いました私は配信をスキップするか、それを転送したいときに私のアカウントに迅速かつ容易にアクセスされた.いいえ、ログイン障害や干渉-滑らかで簡単な顧客体験.
何かの理由で、先週、私がコーヒーから出ていたので、以前の出荷に私の好みを更新した後、私は何か奇妙に気づいた:偶然のリンクのトークンの1文字を削除しなかった問題ではなかった.私はまだ私の好みの内容を表示することができました、変更を行い、私のアカウントを更新します.

# Original request leading to the panel
https://coffee.shop/api/recurring/customers/<user-hash>/?token=1111111

# Using a different token (any token or none at all for that matter)
https://coffee.shop/api/recurring/customers/<user-hash>/?token=qqqqqqq

少しの背景:店はRubyを使用する非常によく知られている電子商取引プラットホームに基づくウェブアプリケーションです.ウェブサイト自体は私が見たslickestではありませんが、それは仕事を取得します.基本的なユーザー管理と非常に簡単でカスタマイズ可能な方法で配信の私の好みを変更する便利な方法.
物語に戻る:私はトークンを削除していただけでなく、私は私のアカウントの配信の設定に到達することができ、私は匿名のブラウザからもそれに到達することができます.本質的にクッキーの検証を意味していません.それで私はGET そのトークンとクッキーから要求し、どこからでも情報をつかむことができた.これは、脆弱性番号1:この特定のエンドポイントの認証の欠如です.
言うことが重要です、バグはどんな顧客にも見えません.非定期的なアカウントへの変更(自動化された週の定期的な注文なしで)、および未登録のユーザーに認証プロセスを通過します.それはリンクのこの端点でした.そして、それは定期的な注文で購読された支払い顧客をサポートするために準備されました.そして、彼らに変化への速いアクセスを与えました.エンドポイントは次のようになります.

https://coffee.shop/api/recurring/customers/<unique-hash>/?token=<token>

この時点で私は心配している顧客から攻撃者への私の考えをシフトしようとしました.
私はedit 私が詳細を変えることができたフォームに私を導いたセッティングメニューのリンク:name , ホームaddress , phone_number , そして、確かにemail アドレス(!)私が電子メールアドレスを強調している理由は、これが通常アカウント乗っ取りに通じる分野であるということです.個人情報は決して漏らされるべきではありません、しかし、保護されていないメール変化をしている間、それは常にセキュリティバグとみなされません.メールアドレスは事実上のWebアプリケーションアカウント識別子です.場合は、アカウントのメールアドレスを制御する場合は、それを所有している.アドレスを制御するパスワードをリセットし、基本的にアカウントを制御するために使用することができます.
メールアドレス保護に関する重要な注意.より正確に-電子メールアドレス更新保護.アカウントのメールアドレスの変更はパスワードで保護する必要があります.ユーザが既に認証されてログインしていても、はい.上記の理由で正確に.APIは絶えず変化しています、そして、彼らの大部分は若干の点で何かを公開しています.それは、パスワードと電子メールの変更に保護の別の層を置くために一般的で良い練習です.一旦これらが保護されるならば、ユーザーが「本当の」ことを確実とするために、彼は個人のメールボックスの変化を確認するよう頼まれます.これらがパスワードかメール変化であるかどうかにかかわらず、我々はメールアドレスとパスワードの両方のコントロールがユーザーの信憑性のための良い識別子であると思います.
私の“旅”を続ける私のメールアドレスを変更する要求を行った+1 ユーザ名にアカウントを制御できないようにする+1 は、アドレスを変更するか、同じメールボックスで複数のアカウントを使用することです).確かに、リクエストが通過し、私のアカウントが更新されました.これは、この“コーヒー好みの更新”リンクを持つ誰でも、私のアカウントの詳細を引き継ぎ、私のクレジットカードで欲しいものを購入することができます.
それではどのように私はそれを利用するのですか?私は、POCを示すことによって、店のオーナーにリスクを説明しようとしました.攻撃を利用するには、何らかの種類のHTMLフォームを作成し、それを顧客に送る必要があります.しかし、フォームが代わりにCSRFトークンを持っていなかっただけでなく、私はそれが全く検証されていなかったことを思い出しました.
そこにはコルスのヘッダーもなかった.これは、どこからでも誰でもPOST を使用してショップのAPIへの要求recurring/customer/edit ハッシュを与えられたアカウントへの変更を行うリンク.通常、CSRFは危険を通じて利用されるので、これは大規模ですGET リクエスト.悪用するPOST 変更要求は、1つの攻撃を連鎖させる必要がありますstored XSS (この場合、アプリケーションで悪意のあるリンクを表示するコードインジェクションのフォーム).
Check out my post on CSRF attacks and mitigation
クッキーはここでは何の役割もなかったので、それはすべて問題ではなかった.これは、クッキーの検証だけでは防弾ソリューションではないことを示すことです.それは上に実装されるべき異なるセキュリティ層へのベースラインです.

報告

私は書くことで自分を教育しようとしているbetter vulnerability reports , それで、私は店のオーナーに私ができるすべてをきれいに明らかにしました.私は、技術的な詳細が進められると仮定しました、それで、脆弱性が影響する影響と危険を強調することは重要でした.これは私に“なぜそれは問題”の部分をもたらします.

なぜそれが重要！

インターネットは大規模で,指数関数的に成長する.それは、両方のユーザーとアプリケーションの成長しているとはい-バグ.開発者として、共通のリスクを知ってどのようにそれらをテストするには、コミュニティより良い(そして安全な)顧客をサポートするためのより良いアプリケーションを構築する私たちを助ける.このケースのように、誰もどんな害も意図しませんでした、しかし、顧客経験を完璧にするために、開発者と製品所有者は彼らの功績の衝撃とともにリスクを保つべきです.
As a smart woman once said :

Hackers are the internet's immune system.

私は自分自身を呼び出すことはできませんが、非常に熟練した研究者とそこに高品質のバグの豊富なプラットフォームがたくさんあります.私は、リソースをチームに奨励したいと思っています、そして、個人的に、または、プラットホームで彼らのプログラムを開くことを考慮することを意味します.レバレッジ(と補償)プロのスキルをセキュリティホールを見つけて、それらを修正します.
私は、このポストが彼らの顧客を保護するために他の心の光をきらめくことを望みます.私はまた、これはユーザーが彼らが信頼できると考えているサービスプロバイダと通信している方法についてのオープンアイを維持するための行動のためのコールであることを願っています.最後に、私はウサギの穴を下に行くために何かに気づいたと思う人を呼んで、報告します.最悪のシナリオは何も起こりません.一方、あなたは情報漏えい、横領と拡張によって生命を救ったかもしれません.

脆弱性のためのテスト

開発者はしばしばセキュリティパイプライン、QAシステム、および独自のインポートライブラリを信頼しています.これらはリリースプロセスのすべての機能層であるが、開発者は自分の作成に対してどのように基本的なテストを考え、実行するかを知るべきである.
思考過程は次のようなものである.

悪質な俳優が特定の要求をするのを防いでいるセキュリティメカニズムは、何ですか?

私がハッカー(またはあまりに自由な時間がある好奇心の強いエンジニア)であるならば、どのように、私はそれを回避するでしょうか?

私は単にクッキーを使用することはできますか?認証ヘッダーを削除できますか?クッキーを操作できますか.リクエストのエンドポイント/ヘッダー/ボディ/パラメータを操作するだけで、ロールを変更できますか?

誰かが意図されなかった方法でシステムを使うことができる他の創造的であるが、明らかな方法がありますか?

これは任意の開発者は、特にユーザーアカウントを構築し、保護するときに尋ねる必要があります質問の部分的なリストです.新しい認証ライブラリを追加?テストします.クッキーの暗号化を変更?あなたのアプリケーション管理システムに追加の役割?変更をテストし、システムを操作しようとすると、それは楽しいだけでなく、健康です.それをさらに一歩踏み出して、自己保安のためにスプリントで半日を捧げてください.私は私が私の技術を鋭くした方法であったということを知っています、そして、かつて、我々のシステム(家で、そして、サービスを提供しているクライアントに建てられた)は妥協可能でした.しかし、これは別のポストのための別の話です.
読んでくれてありがとう!