今週のトップ3の出版物に入ったcodebyで最初の記事を公開した後、次の記事を書くことに非常に意欲的でした。 ただし、11年生では、試験およびオリンピックの準備のための自由時間に制限が課されます。 したがって、2回目は
この出版物は、あるリソースで見つかった脆弱性が、他の複数のサイトでそれらを見つける連鎖を伴う興味深いケースについて語っています。
始まり
それはすべて、鍛造製品の大手メーカーのサイトをチェックすることから始まりました。 ユーザーの個人アカウントは存在せず、脆弱性検索エリアは広すぎませんでした。
注文送信フォームをテストすると、多くの脆弱性が発見されました。
第一に、これはバイヤーのデータに格納されているかなり標準的なXSSであり、このもつれが引き伸ばされています。 XSSは標準であり、Cookieに「httponly」フラグがないことは明らかに標準ではありません。 多くの場合、さまざまなサイトからCookieを受け取りましたが、認証を受けたことはありませんでした。XSS攻撃のリスクを大幅に減らすため、「httponly」フラグを使用しないサイトが存在することを疑い始めました。 大企業のサイトでこのようなイベントに出会ったことは、さらに驚くべきことでした。 しかし、結局のところ、この監視を許可したサービスは、私が予想したよりもはるかに大きかった。 しかし、その後の詳細。
受け取ったcookieを置き換えて、サイトシステムのcrmアカウントにログインしました（初めて幸運だったので、抵抗できませんでした）。 権限は管理者ではありませんでしたが、注文に関する統計にアクセスするには十分でした。 および顧客データ。
脆弱性の存在を証明するためにスクリーンショットを作成し、レポートを送信しました。 1週間以上が経過し、私はもはや答えを待っていませんでした。 統計によると、3日以内に回答がなければ、そのことを忘れることができます。 しかし、8日後、予想外の答えが来ました。 さらに、発見された脆弱性に対して最初に支払いをしてくれました。
注文送信フォームのテストに戻ると、domain.ru / shop.phpのPOSTリクエストでパラメーター「json_order [0] [price]」および「json_order [0] [total]」を編集することで注文価格を変更できるiDOR脆弱性も見つかりました。 。 json_order [0] [href]フィールド内の同じリクエスト内の注文リンクを置換すると、RFIが発生しました。
新しい発見に関するメッセージへの返信がありません...
継続
そのcrmサイトでは、システムは自己記述型ではないことが判明しましたが、1つの有名なサービスによって支払いのために提供されました。 クッキーの間違いの後、他の脆弱性があると仮定することは論理的でした。
注文フォームから送信されたスクリプトが機能する場合、目的のサイトとcrmシステムの両方でフィールド検証は行われていません。 x2。 したがって、トライアルアカウントを受け取った私は、xssに対して脆弱なフィールドを正確に検索することから始めました。
大規模なcrmシステムを長旅した後、検証が不十分な12個以上のフィールドが特定されました。 どこかで、スクリプトタグを直接挿入できます。どこかで「onmouseover = alert（）」タイプのインラインスクリプトを使用する必要がありました。 また、一部の場所ではスクリプトを埋め込むことができましたが、一部の場所では、一部の場所ではフィルタリングを追加し、他の場所ではフィルタリングを追加することで、どのようなロジックに導かれるのでしょうか？ フィールドの論理的な目的の観点から、私はパターンを見ませんでした。 ほとんどの人が行かない場所では、すべてが正常に機能しましたが、たとえば、相手の名前にフィルタリングを追加することはありませんでした。
ほとんどの脆弱なフィールドは、外部から影響を受けることはありません。 従業員だけがそれらを使用してシステム内の権利を強化できましたが、これも重要です。
これでxssが終わったので、もっと面白いことに進むことができました。
CSRFの脆弱性を探したことがありません。テストしたサイトは、フィッシングを使用するクラスに属していませんでした。 したがって、私自身や、決して使用されることのない脆弱性を持つサイト所有者に、これを気にかけたくありませんでした。 それは根本的に異なるケースでした。 このcrmシステムは人気があり、大規模なオンラインストアでも使用されていました。また、小売オフラインポイントのキャッシュデスクを接続する機能があったため、セキュリティの問題がさらに重要になりました。
驚いたことに、CSRFに対する保護はありませんでした。 リクエストを送信することは可能で、チェックはどこでも実行されませんでした。
-アカウント情報を変更しますか？ -お願いします
-商品の名前と価格を変更しますか？ -質問なし
同時に、クッキーには「csrftoken」と呼ばれるものが含まれていました。
それから、csrfトークンをcookieに入れる意味は何だと思いましたか？ グーグルで、クッキーにトークンを入れてcsrfから保護し、トークンをサーバーに保存する必要のないポストリクエストで複製するかなり便利な方法があることを発見しました。 詳細はこちら 。
しかし、私たちの場合、作業の半分しか行われず、トークンはCookieに置かれ、サーバーへのリクエストにはトークンがありませんでした。 さらに、Cookieから完全に削除しても何も変わりませんでした。 なぜ追加されたのですか？
発見されたcsrfと連携して、以前は外部からアクセスできなかったxssがセカンドライフを取得します。 結局のところ、脆弱なフィールドを編集するためにアカウントにアクセスする必要はありません。
さらに、ファイルのMIMEタイプを置き換えることにより、任意のファイルをサーバーにアップロードすることができました。 しかし、サーバーは正しく構成されており、phpスクリプトはそこで実行されませんでした。
さらに興味深い。 オンラインストアがcrmから取得した商品に関するすべてのデータ。 つまり 名前、説明、写真。 製品イメージへのリンクは「yyyy.domain.com/file/get/id=xxx」でした。 オンラインストアで画像を撮影できるようにするには、すべてのユーザーに読み取り権限が必要です。 122。
他のプライベートファイルが保存されているパスを確認すると、同じURLが表示されました。 驚くべきことではないようですが、おそらく他のアクセス権があります。 間違いなく022以上。 しかし、現実はわずかに異なることが判明し、許可されていないユーザーにも無料でアクセスできました。
-注文データをexelファイルにインポートするようにリクエストしましたか？ -素晴らしい、今では誰でもダウンロードできます。
おそらくidが「yt5bjFb54hb＃HJ％$ p」のように見えて、ブルートフォースに屈しなかったのでしょうか。 いいえ、どちらも。 すべてのidファイルは数値形式で、数千の範囲でした。 ブルータスに対する保護、私も気づかなかった。 1から10000の障害物のすべてのIDをスキャンしても、一致しませんでした。 さらに数回繰り返して、誰もそのような活動に興味がありませんでした。
彼らは私のレポートに3日で答えました。
フラグの欠如に関して、httponlyには「PHPバージョンが更新されてからかなり前のことです」と書かれていませんでした。 同じ日にオンになりました。
xssによると、彼らは誰もが夏の初めにフィルタがオフになったことを知っていると言いました（その時点ではすでに8月でした）、これはもちろんどこかにフィルタリングがあった理由を説明していませんが、どこかにフィルタリングしていないが、私たちはこれに気付かなかったふりをしましょう矛盾。 彼らはまた、フィルターが数日で起動することを保証しました。 実際、数か月でそれが判明しました。 しかし、ここで私はそれらを完全に理解しています：私も、数日で試験の準備を開始する予定です...
任意のファイルをサーバーにアップロードすることは、サーバー上では実行されないため、ほとんど心配する必要はありません。つまり、心配する必要はありません。 記事を書いている時点でのみ、crm以外のホストに既にあるサイトがストアフロント用の製品のイメージを取得しようとしているが、phpスクリプトを受け取っている場合、それを実行しますか？ または、imgタグを対象としているという事実により、画像としてのみ処理されますか？ または、サーバーの設定に依存しますか？ 知識のある人に答えてください。
csrfレポートへの応答は非常に興味深いことが判明しました。 彼らは質問で答えました：「csrf攻撃に対する保護のトークンは何だと思いますか？」実際、私は何について話しているのですか？
彼らは、この瞬間を考慮しなかったファイルへの無料アクセスについて述べた。 すぐに閉じました。
現金報酬を受け取ることが本当に期待されたのはこれだけだったと言わなければなりません。 サイトは大規模ですが、crmを除き、もう1つの有料プロジェクトはありません。 人気のオンライン雑誌。 しかし、彼は言葉による感謝だけを受けました。
私は彼らに感謝しなければなりません、私は支払いの問題についてさらに冷静になりました。 感謝の気持ちを込めてどんな形で働いても、最終的には何ももたらされません。 あなたはどんな賞賛や他の名誉にも慣れ、満足をもたらすのをやめるでしょう。 そして、あなたが彼らのためにすべてをしたならば、何かをする意味は失われます。 そして、あなたはあなたの活動のプロセスの喜び、新しい問題の解決、新しい何かの創造を失うことはできません。 どんなに些細なことでも、仕事のために働きます。 時間の経過、太陽が地平線を越えていくだけでなく、そのために再び昇る方法に気づかない仕事。
'' '
私たちは小さなことに満足しています、幸せは大きなお金ではありません
「好きなことをしてください」は、私たちのサークルで高く評価されています。
'' '©Kolya Manyu-毎日
終了
前のサイトの技術サポートでは、サードパーティのチケット受付システムUserEchoが使用されました。 私はそれを確認し損ねませんでした。 もちろん、私の夢では、個人のチケットを読むことはできました。 当然、私は成功しませんでした。 私は少しで満足しなければなりませんでした。
チケットで動作するAPIをテストするとき、最初は異常は認められませんでした。他の人を調べたり、サブスクライブしたりする権利はありませんでした。 しかし、サイトをさらに調査すると、開発者が小さな欠陥を作ったことが判明しました。
プロファイルには、チケットの管理に関するセクションがあります。これは、サブスクライブしたか、以前にサブスクライブしたものを示しています。
他の人のチケットの購読を解除するリクエストを送信すると、予想どおり、このアクションに対する権利がないことが通知されます。 しかし同時に、以前に購読したチケットの1つとして、チケットのリストに入力されます。 したがって、「ticket_name_name_in_translate」形式の名前とURLを見つける機会があります。 もちろん、この害はありませんでした。 非常にまれなケースでは、名前から重要で価値あるものを学ぶことが可能です。 しかし、何も残さないよりはましでした。
数週間後、バグは修正されました。
最後まで読んでくださった皆さんに感謝します！