この記事では、ペンテスターのチームを大規模プロジェクト「MyOffice」の開発サイクルに導入した経験を共有したいと思います。ロシア語の実際の症例と同様の主題の資料を見つけることはほとんど不可能です。ペンテスト、理論、実践、テクニック、ツールのファッショナブルな分野に興味があり、安全な開発のコンテキストで実際に脆弱性を発見した人は誰でも猫にようこそ。この記事には、理論的および実用的な資料への有用なリンクがたくさんあります。しかし、順番に見てみましょう。

免責事項：

この記事は2つの部分で構成されています。 最初の部分は組織であり、問題を特定し、一般的に侵入テストへのアプローチとタスクを解決する方法について話します（おそらく多くの人に知られている情報が含まれています）。 2つ目はより技術的で、発見されたツールと脆弱性の説明があります。

％username％（技術的な詳細など）の場合は、2番目の部分に進むことができます。

そしてもちろん、お茶をクッキーと一緒に忘れないでください。

収集して配布します

ペンテストアプローチのアイデア

ペンテストとその機能へのアプローチを説明する短い紹介から始める価値があります。さまざまなプロファイルのさまざまな企業をカバーする当社の経験に基づいて、次の部門が最適と思われます。

1回の侵入テスト

一部の組織（銀行や公的企業を含む）が侵入テストサービスを提供する会社に来て、ペンテスターにアドレスの範囲を発行するクラシックバージョン。作業を実行した後、実装チームは脆弱性の修正に関する推奨事項を提供します。

仕事の種類：

境界セキュリティ監査
境界セキュリティ監査
物理的セキュリティ
モバイルアプリ
コード分析
ソーシャルエンジニアリング
一般的に、あなたが思いつくことができるすべてのもの（しかし、参加する価値はありません）

複雑なプロセスと同様に、安全性には「特効薬」はありません。アンチウイルスソフトウェア、侵入検知システムなど、システムのセキュリティに完全な信頼を与える手段はありません。侵入テストについても同じことが言えます。侵入テストでは、それぞれにマイナスとプラスがあるため、普遍的なアプローチはありません。

一時的な侵入テストは、セキュリティの一般的な状態を評価するのに効果的です。ペンテスターは、資金が限られた攻撃者が短時間でシステムに侵入しようとする状況と、それが顧客の会社に与える損害をシミュレートします。

侵入テストNを年に1回繰り返します

このアプローチは、「1回限りのペンテスト」またはその個々の部分を繰り返します。この場合、セキュリティ監査は年に数回実行されます。作業の種類は、最初のアプローチと同じです。

一般的なセキュリティ問題の評価を伴う最初の監査の後、このアプローチにより、過去の監査で見つかった脆弱性に適用可能な修正、修正を適用する際に発生した問題（はい、また発生）、および次のチェックの結果に遅れずについていくことができます。

このオプションを使用すると、過去の侵入テストの結果に基づくサービスに対する認識が高まるため、監査人による会社の境界のより徹底的な調査が可能になります。

バグバウンティのアウトソーシング

このアプローチの本質は、オープン/クローズベースで独自のバグバウントプログラムを作成することであり、これは外部組織によって維持されます。このようなチームは、ペンテスターを恒久的に仕事に引き付け、脆弱性ごとに個別に支払いを行います。これは、研究者にとってさらなる収入の良い機会です。このアプローチの使用例は、アメリカの会社SYNACKです。

「これはHackerOneとどのように違うのですか？」という合理的な疑問が生じます。主な違いは、研究者の数と彼らのスキルです。このプログラムに参加するには、攻撃的な会社の仕事に応募するときのように、面接とテストタスクを行う必要があります。その結果、参加者は少なくなりますが、全体的なスキルレベルは高くなります（また、スキャナーレポートを投げるのが大好きなキャラクターがいないということもあります）。

作業の種類（このアプローチのフレームワーク内）：

境界セキュリティ監査
モバイルアプリ
バイナリ研究

このアプローチには、脆弱性に対する報酬に動機付けられた数十人の人間の「スキャナー」によるサービスの継続的な調査が含まれます。これにより、作業中により多くのカバレッジを提供できます。

上記の利点にもかかわらず、このアプローチには欠点があります。

ペンテストへの古典的なアプローチと比較した作品の限られた範囲。この欠点は、すべての研究者のリモートワークとセキュリティトレンドの人気の結果です。
作業結果の支払いへの依存。多数の研究者が絶対に全員の関与を保証するわけではありません。報酬の大きさはプログラムの人気に大きな影響を及ぼします。
予算計画の難しさは、バグ報奨金プログラムの典型的な問題です。

セキュリティ分析は継続的に機能します

このアプローチについては、記事で詳しく検討します。その本質は、リリースからリリースまで開発された製品の継続的な研究です。

この場合の作業の種類のリストは、上記のアプローチよりもやや広範です。以下が含まれます。

境界セキュリティ監査
境界セキュリティ監査
モバイルアプリ
デスクトップアプリ
強化（安全なサーバー構成）
開発者トレーニング

デスクトップアプリケーションやHarderingなどのアイテムに関しては、タスクはバイナリの脆弱性を見つけることではなく（デスクトップについて説明する場合）、ネジを完全に締めることではありません（Harderingの場合）。主なものは、Pentester側からのシステムのビューです。

このアプローチの特徴は、内部からの保護を作成する企業の地元の警備員の仕事に可能な限り近いということです。

作業（特定の製品を研究する際にドキュメントと私たち自身の経験にアクセスするため）と内部サービスの開発（開発プロセスに影響を与え、タイミングを直接監視する能力）に対する高い意識。
開発した製品のソースコードへのアクセス。
建築の建設に参加する機会。これにより、コードを記述する前に脆弱性を見つけることができます。たとえば、CSRFトークン。トークンのような重要で単純なことを人々が単に忘れてしまうことがあります。リリースの展開後にこの問題が発生した場合、修正はコストと時間のかかる作業になる可能性があります（もちろん、すべてがシステムのサイズに依存します）。
研究した製品の高い関連性。新しいリリースをリリースするか、セキュリティに直接影響する重要なコード行をいくつか変更すると、すぐに変更を取得してすべてのテストを開始できます。

その結果、作業はもはや黒ではなく、私たちの愛する白い箱によって行われることがわかりました。

このアプローチは、アプリケーションのセキュリティを分析するための会社独自のリソース（セキュリティの専門家）の不足などの問題の解決にも役立つことに注意することが重要です。多くの研究者は、情報セキュリティのさまざまな分野で常に経験を積んでいるため、攻撃的な企業を好む傾向があります。

SDLCと彼の友人SecureSDLCについて少し

SDLC

定義から始めましょう。 SDLCは、アイデアが生まれてから実際に使用されるまでの間にアプリケーションを作成するために組織が使用するプロセスを定義する開発フレームワークです。

現時点では、多数のSDLCモデルがありますが、最も有名なものはWaterfall、Iterative、Agileです（詳細については、こちらを参照してください）。それらはすべて独自の長所と短所があり、それぞれの使用方法は非常に異なります。それはすべて、プロジェクトの規模、予算、人的資源の量、およびその他の機能に依存します。これらはすべて、6つの主要なステージの存在によって結合されています。

計画は、解決すべき問題が決定され、リソースとコストが計算され、代替ソリューションが求められるなどの主要なステップの1つです。
分析-要件の開発、実現可能性調査の実施など ~~あまり愛していないこと~~ 。
デザイン。この段階で、アーキテクチャが構築され、コンポーネント、モジュール、インターフェイスなどが選択されます。
開発と実装は最大かつ最も重要な段階です。ここでコードが記述され、プロジェクトの鉄の部分の構成と構成（ある場合）が行われます。
テストと統合-ここでは、結果がタスクにどのように対応するかを確認します。
システムのサポート。開発したシステムの関連性を監視します。これには、ハードウェアの交換とさまざまなソフトウェアコンポーネントの更新の両方が含まれます。

SecureSDLC

SecureSDLCは同じSDLCですが、Secureプレフィックスが付いています。プレフィックスを追加するだけで、すべてが安全になります（いいえ）。このすべての本質は非常に簡単です。インターネットの美しい写真からわかるように、セキュリティ関連のアクション（リスク計算、静的/動的コード分析、ファジング、トレーニングなど）が各開発段階に追加されています。

従来のSDLC実装では、セキュリティテストはテストフェーズに限られていました。

拡張された実装の目的は次のとおりです。

既存の/検出された脆弱性の修正の永続的な監視。
開発の初期段階で脆弱性を見つけることにより、脆弱性を修正するコストを削減します。
アプリケーションの詳細な分析による開発の品質の向上。開発者自身のためのセキュリティトレーニングに取り組みます。

すべては何に基づいていますか？

現在、多くの企業が安全な開発を実践しています。たとえば、Microsoft、Cisco、Dellなどの大規模で有名なものです。今日、自尊心のあるベンダーは意思決定のセキュリティを監視しています（しかし、これは常にうまくいくとは限りません）。各メーカーには独自のアプローチがあり、開発の内部機能に基づいて形成されます。

スケルトンとして、安全な開発を構築する場合、多くの人が世界で一般的に受け入れられている慣行を使用します。

OWASPによるオープンセキュリティ保証成熟度モデル（ OpenSAMM ）
マイクロソフトセキュリティ開発ライフサイクル（SDL）。プロセスガイダンス

インターネットの次の写真では、ビジネス機能とセキュリティ対策の対応を見ることができます。

タスク条件

現在、大規模なプロジェクト（詳細と機能-以下）を実施しており、2つの大きな領域で開発を行っています。開発された製品の「最高」とバイナリ研究です。この記事では、ペンテスター部分に焦点を当てます。

最初に、このプロジェクトの脆弱性を検索するプロセスは、単一のペンテストからペンテストまでの段階を経て、年に数回、外部境界サービスと開発中の製品の両方で繰り返されました。私たちの意見では、これらのアプローチは、継続的にセキュリティを分析するプロジェクトとは異なり、それほど効果的であると証明されていません。

古典的なアプローチで私たちに合わなかったものは何ですか？ 1回限りのペンテストにはいくつかの欠点があります。

作業の事実に関する多数の報告。 Pentesterのレポートを見たことがあるなら、それは巨大で平均100ページかかることを知っています。その作成には、人的および一時的なリソースの魅力が必要です。脆弱性を検索する代わりに、研究者はレポートを作成します。
開発者との相互作用がうまく調整されていません。後者は、ペンテストの終了後にのみ見つかった問題への対応を開始できます。ただし、多くの場合、発見された脆弱性の重大性とそれらを修正する方法について理解しており、これはペンタスターとは異なる場合があります。
調査対象システムの内部機能に関するペンテスターの認識が低い。研究者は安全性を分析している会社の従業員ではないため、開発プロセスのすべての機能を知ることができず、文書やソースコードへのアクセスがまったくない。
監査役ローテーション。他の1回限りのプロジェクトまたは進行中のプロジェクトが存在するため、そのプロジェクトが最後に調査したペンタスターによって処理されていないという状況が発生する場合があります。このため、以前の侵入テストの枠組みで既に研究されているサービスの一般的な認識は低下しています。

開発中の製品の内部機能についての監査人の認識が低く、コンポーネントによる分離がないため（ペンテスターの場合、製品は特定のアドレスパッケージ、モバイルアプリケーションパッケージ、またはデスクトップアプリケーションバイナリのように見えます）、製品のリストは多くの本を含む本棚のように見えます欠落している名前-目は豊富なサービスから逃げ出します。

このため、時間の割り当ての問題が発生します。これはプロジェクト全体に割り当てられ、コンポーネントにあまり注意を払うことができません。リソースの割り当ては非効率的であり、製品の詳細な調査には適していません。したがって、製品を条件付きコンポーネントに分割することが決定されました。

製品のリストを収集します

私たちの場合、ドキュメントの共同編集、ファイルの保存、メールシステム、メッセンジャーのプラットフォームであるMyOfficeという製品で、New Cloud Technologies社と協力しています。これらすべてのために、モバイル版とデスクトップ版の両方があります。

MyOfficeのような大規模な製品で作業を開始する前に、メインのモジュールとパーツ（一見分割できないように見えます）を強調表示して、まったく同じ本棚が機能しないようにする必要があります。これは、アプリケーションの内部プロセスとチームリソースの割り当てをよりよく理解するために必要です。

次のようになりました。

Webは実際のSPAアプリケーションであり、js / css / htmlファイルのみです。このコンポーネントに含まれるサービス：メール、カレンダー、連絡先、ディスク、ドキュメントエディター、管理者コントロールパネル、ロゴ（メッセンジャー）。
モバイルアプリケーション-プラットフォームごとに3つのアプリケーション（ドキュメントエディター、メールクライアント、ロゴ-メッセンジャー）-iOS、Android、Tizen（はい、驚かないでください）。
Linux、OS X、Windowsの3つのプラットフォーム用のデスクトップアプリケーション（ドキュメント、メール、メッセンジャー）。
サーバーAPI、公開されています。
相互に通信する内部サービス（Redis、Swiftなど）。

これはすべて、研究者にとって非常に興味深いものです。これまでにない前例のない技術を研究する機会と、すでに研究されたトピックをさらに活用する機会の両方です。

スプリント計画

このような製品の開発プロセスにシームレスに統合するには、グローバルな計画サイクル、この場合はリリースサイクルに適応する必要があります。「MyOffice」の新しいバージョンのリリースは3か月ごとに行われます。したがって、私たちはわずか3か月間だけスプリントを生きます。私たちの理解におけるスプリントとは何ですか？

私たちにとってのスプリントは、可能な限り作業を計画しようとする時間のセルです。大きなスプリントの内部には、より小さな測定単位、つまり1週間に相当するスロットがあります。利用可能な製品を入手し、それらのサイクルと変更の条件を確認し、これらの製品の監査を必要な順序でスプリントのスケジュールに入れて、スロットに分割します。

当然、開発日を控えめに言っても、非常にひどい結果になることがわかっているため、「期限が来たらどうするの？」という正当な質問が予想されます。

ここで、古い子供向けのゲームが助けになります-「タグ」。他のチップを移動できる空のセルがあり、それによってボックスを離れることなく順序を変更できることを覚えていますか？私たちの場合、ボックス-これは「スプリント」です。

さまざまな「予定外の」作業、開発された製品で使用されるサードパーティソリューションのレビュー、およびプロジェクトに関連する他の作業があるため、空のスロットの数を増やすことが決定されました。したがって、私たちは計画を立てて移動し、空のスロットはいつでも満たすことができます。

スプリントの1つの例（最初の数字はスプリントの週番号です）：

コンポーネントWebアプリケーション（メール、連絡先、カレンダー）
コンポーネントWebアプリケーション（メール、連絡先、カレンダー）
Android、iOS、Tizen用のネイティブモバイルアプリ
Android、iOS、Tizen用のネイティブモバイルアプリ
認証サーバー Webアプリケーションバックエンド
ファイルサーバーバックエンド、Webダッシュボード、および管理API
ドキュメントエディターWebパネル、Beckendエディター
ファイルサーバーのデスクトップクライアント
メール、カレンダー、連絡先、ドキュメント用のデスクトップクライアント
Web、MacOS、Win、LinuxおよびそれらのAPI用のメッセンジャー
ミス
ミス
ミス

Miscはこれらの空きスロットにすぎず、その存在は非常に重要です。 , , ( , API-), (10 ). Misc security- .

, (, , , - , , ). , , .

- , . , . “” .

スタンド

, , . , , «» , , , . , — , “ ”.

— , , , -.

JIRA ( , ), , HackerOne:

役職
—

, , - IT.

.

: , - . , , - .

プロローグが開いているようです。セキュリティ分析自体に直接行きましょう（歓声、技術的な詳細）。

経験豊富なペンテスターの仕事の興味深い要素の1つは、ファッショナブルで最新のテクノロジーの使用です。それらを見てみましょう。始める前に、もちろん、Webを見て、同時に名前を登録しました。

'“><svg onload=alert(1)>{{7*7}}

ファイルがアップロードされ、メールが送信され、モバイルアプリケーションがインストールされ、全体として、すべてがどのように機能するかを調べました。

その後、開発チームに行き、キャビネットの壁にはほとんど収まらないA1の大きなシートでサーバーアーキテクチャの図を作成しました。ここには挿入しませんが、一般的にはすべてがかなり標準的でクールです：

ユーザーは2つのポートを使用できます（80および443）。それらの背後にあるものはすべて、クラスターおよび信頼ゾーンと見なされます。
クラスター-これは、無制限の数のサーバーマシンにすることができます（インストールでは-2）。これは、多数のマイクロサービス（java、go、c ++-エディター、データベース、SWIFTなどのコア）を実行します。
一部のサービスはRPMパッケージから提供され、一部はdockerコンテナです（追加の分離を提供します。これはドキュメント変換で作業する場合に特に重要です）。

Web

クライアント部分は、AngularJSとサーバーAPIからの明示的な松葉杖のない本格的なSPAです（「そして、ここでバックエンドからフォームを提供します！」など）。

サーバー側-さまざまな方法で、フロントとしてnginxを使用し、その後にクライアント要求を処理する多くのjava / golangサービスが続きます。

SPAアプリケーションの分析は非常にクールで非常に便利です。要求と応答の観点から見ると、すべてが論理的で折り畳まれています。 SPA自体の脆弱性を見つけることは、もちろん、かなり難しい作業です。

げっぷスイート

はい、秘密はありません。多くの人がそうであるように、Burp（Larry Lauなし、ライセンスのみ）とそのモジュールを使用して、さまざまな種類の脆弱性（インジェクション、 IDOR 、 SSTIなど）を検索します。このツールがなければ、何もありません。

また、開発者は私たちに尋ねてプロセス全体を伸ばす代わりに、脆弱性を修正した後、それを使用して結果を確認できます。これには、無料版とProxyとRepeaterの2つのタブで十分です。

また、多数のカスタムスクリプトを使用しています。そのうちの1つを検討してください。

すでにご存知のように、当社が調査した製品にはメールがあります。ここで最も強力な攻撃の1つは、電子メールのXSSです。また、レターでは、HTMLを使用してプレーンテキストだけでなく企業スタイルの美しいレターを作成できるという事実によって、依然として複雑です。開発者は、送信者がJavaScriptを埋め込むことができないようにHTMLを使用できるようにするという課題に直面しています。

セキュリティの世界には、Googleなどのさまざまな大規模サービスでXSSを見つけることに多くの時間を費やした研究者のMario Heiderich @ 0x6D6172696F （.mario）がいます。そして最も重要なこと-彼は彼女のために自動テストを公開しました。これはさまざまなトリックとブラウザとHTML5の巧妙さを使用しています。 JSを実装する可能性についてメールサービスをテストするための理想的なソリューション。

→デモとテストへのリンク

→ そして、HTML5の特別なベクターを忘れないでください

私たちは何をしましたか？通常はHTMLをWebクライアントから送信することはできず、メールサーバーに直接送信するだけで、同時にブラウザーで文字を開くため、これらのテスト（+いくつかのシークレットビンを追加）を取得し、PythonスクリプトでIMAPサーバーに10行で送信しました JSを実現しましたか？チケットを開始します。

ユーザーがレターの画像（imgタグ）を使用してレターの開始を検出できることは誰もが知っていますが、他のタグを使用してこれを行うことができます。ここでも、 Cure53リポジトリが役立ちます。これにより、ユーザー情報をマージするタグを検出できます。

いくつかのタグのスキームの制限、たとえば、同じ "img src"のfile：///を使用できない理由（詳細についてはValdikSSのリンクを参照）は、開発中にすぐに考慮されました。

次の問題は添付ファイルです。 XSS-loadを使用して、さまざまな形式の添付ファイルを必ずテストしてください。ここでそれらを取得できます。これにより、添付ファイルをサーバーが文字で保存および提供する方法を確認します。

モバイルアプリ

各プラットフォームのすべてのアプリケーションは、従来のネイティブアプリケーションです。

どちらのアプローチも、自動化された手動のiOSとAndroidの調査に使用されます。 Tizenの場合-マニュアルのみ。自動化について-MobSFは、「ぶら下がっている果物」の除去に大いに役立ちます。

一般的な問題を自動的に収集し、受信者、サービスなどのレビューを行うことができます。 Androidでの事柄や、ソースコード分析の一部の類似性さえ実行します（逆コンパイル後）。また、コンパイル時にフラグ（スタックスマッシング保護、PIE ...）もチェックします。

手動分析-Android（+ルート）、iOS +ジェイルブレイク（現時点では、iOS 9.3.3で利用可能な最新のジェイルを使用しています）。

しかし、Tizenの使用はそれほど簡単ではありません。彼自身は非常に奇妙で珍しいです。このシステムは、HTML5をサポートする1つの大きなブラウザであり、長い間開発が続けられており、セキュリティ研究者にとっても興味深く、新しいものや研究されていないものです。

そもそも、質問は-TizenOSでどのくらいの電話を持っているのですか？このプラットフォームに同数の記事とセキュリティツールがあります。私たちは開発者の道を進みました-Tizen SDKをダウンロードし、電話に接続してアプリケーションをデビューしました。このモードでは、ファイルシステムを表示したり、デバッグコンソールを取得したり、セキュリティの問題を見つけるのに役立つその他の操作を実行したりできます。残念ながら、機能はかなり制限されており、OSにコンソールから直接アクセスすることはできません。

このツールはTizenの公式Webサイトにあります。このオペレーティングシステムに精通したい場合は、エミュレータを使用できます。

Tizenプラットフォーム自体には現在、多数のセキュリティ上の欠陥があります。プラットフォームとこの出版物の 40のzerodeyに関する最近のニュースを思い出すことができます。また、TizenOSも影響を受けたSmartTVのいくつかの脆弱性についてBeLove - presentationに語った。

デスクトップ

デスクトップアプリケーション「MyOffice」については、バイナリファジングに関する記事が別にあります。これらの作品のフレームワーク（ペンテストなど）で、ファイルシステムとの相互作用（一時フォルダー、それらに対する権利など）、DLLハイジャック、ネットワーク（安全なチャネルを介したデータの送信-TLS）、ストレージなどの領域トークンなど。

多くのデスクトップアプリケーションはElectronに基づいて記述されており、GitHub、Slack、Discordなどが作成されています。 Electron自体はオープンプロジェクトであり、ウェブビュー、つまり、ネイティブアプリケーションと視覚的に区別できない小さなブラウザです。

サードパーティ製品の研究。 DOMPurifyとSafariはどこで

多くの場合、製品のセキュリティを調査する際に、脆弱性が見つかった場所が常に透明で明確ではないため、問題が発生します：顧客のカスタム記述コードまたはサードパーティ製品、ライブラリ、開発で使用されるフレームワーク。そのようなケースもありました。

コンポーネントの1つを調べると、クライアント部分のかなり重大な脆弱性、つまりJSコードの導入、またはXSSの導入が見つかりました。当初、このコンポーネントがXSSから保護するために同じJSライブラリDOMPurifyを使用したため、これが発生した理由は明らかではありませんでした。

DOMPurifyは、DOM専用のツールであり、HTML、MathML、およびSVG（Gitaからの説明の一部）用の超高速で、非常に寛容なXSS消毒ソリューションです。 MathMLは、数学記号と数式を表すためのXMLベースのマークアップ言語です。もちろん、これはすべてHTML5チップのコンテキストで機能します。つまり、この製品には最新で最新のものがすべて含まれています。

JavaScriptで記述されており、すべての一般的なブラウザーで動作します。

サファリ
オペラ（15+）
Internet Explorer（10以降）
Firefox
クロム
BlinkまたはWebKitを使用するすべてのもの

このツールは、Cure53、特にMario Heiderich @ 0x6D6172696F （.mario）によって開発されており、 @ filedescriptorや@shafigullinなどの有名人が貢献します。最もクールなWebセキュリティ研究者のこのようなチームは、クライアント側の脆弱性から保護するためのオープンソースツールに取り組んでいることがわかりました。

Geetへのリンク。

少し考えてみると、脆弱性は実際には開発されたアプリケーションではなく、接続されたJSライブラリにあるという結論に達しました。

次に、最新バージョンのDOMPurifyの脆弱性を確認し、Safariの下でのみこのような単純なペイロードが何のトリックもなく機能することに非常に驚きました。

 Payload: <svg onload=alert(document.domain)>

彼らはすぐに脆弱性を修正し、DOMPurifyをバグバウントプログラムの管理下に置いたFastMailは、「ビールのために」少しお金を払ってくれました。

しかし、これで終わりではありませんでした。穴はSafariでしか機能しなかったため、その方向を少し掘り下げた結果、DOMParser関数が正しく機能せず、htmlページを解析するときにJSが実行されることがわかりました。 IE）、Appleで報告しました。

 Payload: new DOMParser().parseFromString('<svg onload=alert(document.domain)>', 'text/html');

そして先日、AppleはCVE-2017-7038を発行しました。これはUXSSの脆弱性に非常に似ていますが、 SOPをバイパスしません。考えられるすべての脆弱な機能の詳細については、おそらくいつか別の記事で説明します。

その結果、SVGタグを処理しなかったDOMPurifyライブラリの接続により、MyOfficeアプリケーションでXSSが可能になりました（そうする必要があります）が、エラーで実装された標準のブラウザー関数DOMParserに直接与えました。

このように長い間、私たちはクライアントの脆弱性を修正しただけでなく、世界を少し安全にしました。

本当の脆弱性

大きなものを書いてバグを防ぐことは不可能です。そのような方法論はありません。したがって、いくつかの実際の脆弱性を高レベルの重大度で分析します。

外部XMLエンティティの埋め込み

ドキュメントの保存と編集があるため、必要に応じて何らかの方法でドキュメントをユーザーに描画し、変更する必要があります。ご存知かもしれませんが、現代のオフィスドキュメントは、アーカイブにパッケージ化されたXMLファイルのコレクションです。そして、XMLパーサーを使用しないドキュメント編集

各WebブラウザはすぐにXXEについて考えます。この場合、この脆弱性がどのように動作しているのかを確認するには

ドキュメントをダウンロードする
サーバーはアーカイブを解凍します
XMLを内部形式に変換しようとします
サーバーに目的の形式で保存します

ステップ3は危険です。これは、外部エンティティを接続できるオープンソースライブラリを使用して実行されます。私たちは何をしましたか：

有効な.docxドキュメントを作成しました
開梱
追加されたxmlファイルの1つ

 <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> … <foo>&xxe;</foo>

パックバック、.docxに名前変更
サーバーにアップロードされました

そして、処理後、/ etc / passwdの内容を見ました。ただし、この脆弱性を使用すると、サーバー上のファイルを読み取ることができません。

何らかの方法で、すべての解析は隔離されたコンテナ（docker）で行われるため、重要なものを読み取ることができませんでした。この脆弱性はすぐに解決されました。

ところで、ツールを使用してこのようなファイルを生成し、XXEを確認できます。その助けにより、一部の研究者はバグバウントプログラムでもXXEを発見しました。

ELインジェクションを介したリモートコマンド実行

また、正直なRCE-サーバーでのOSコマンドのリモート実行についても説明します。一部のマイクロサービスは、Springの使用を含め、Javaで記述されています。 Springのこの種の脆弱性（ EL Injection ）（だけでなく）は、{{7 * 7}}をサーバーに送信すると、ページの応答で49に等しい数学関数を取得する場合、ファジングに非常に役立ちます。

さらに、あなたはすでに言語の機能を実行し、さらに以下でコマンドを実行しようとすることができます：

 ${T(java.lang.Runtime).getRuntime().exec("ls")}

Spring Boot Oauthモジュールの同様の脆弱性の詳細については、こちらをご覧ください。そしてgitのチケット。この場合、コードの実行を引き起こした問題を説明します。

しかし、特定の状況では、Webサーバーにリクエストを送信するときに引用符がURLエンコードを通過し、Springが特殊文字として認識しなかったため、このようなペイロードの単純な送信は機能しませんでした。この状況で何をすべきか？すべてが非常に簡単です。標準言語ツールを使用して、java.lang.Character.toString（）関数を使用して数値から文字にエンコードし、すべての文字を連結できます。このトリックについてはこちらをご覧ください。

その結果、大きくて恐ろしいペイロード（/ etc / passwd /を読む）を得ました：

 ${T(org.apache.commons.io.IOUtils).toString(T(java.lang.Runtime).getRuntime().exec(T(java.lang.Character).toString(99).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(116)).concat(T(java.lang.Character).toString(32)).concat(T(java.lang.Character).toString(47)).concat(T(java.lang.Character).toString(101)).concat(T(java.lang.Character).toString(116)).concat(T(java.lang.Character).toString(99)).concat(T(java.lang.Character).toString(47)).concat(T(java.lang.Character).toString(112)).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(115)).concat(T(java.lang.Character).toString(115)).concat(T(java.lang.Character).toString(119)).concat(T(java.lang.Character).toString(100))).getInputStream())}

RCEはドッカーコンテナ内にもあり、保護のために作成されたわけではありませんが、何らかの分離を提供していることに注意してください。

おわりに

さて、ここで記事の終わりです。ここで、アプローチが従来の侵入テストとどのように異なるかをまとめましょう。

監査員は、製品開発プロセスと運用をよりよく知っています。認識は、ドキュメントへのアクセスと開発のペースを監視する機能によって達成されます。
アーキテクチャの構築に参加する機会。これにより、計画段階で問題や脆弱性を見つけることができます。
ソースコードへのアクセス。
ブラックボックスからホワイトボックスへの作業オフセット。この点で、通常のテストは通常非常に制限されています。
大規模なレポートを生成する問題の解消。
監査人リソースの適切な割り当て。すべては週ごとにスケジュールされ、時間は効率的に使用され、コンポーネントの内部機能を知っている人は常にプロジェクトに参加します。
多数のさまざまなサービスの研究により、専門知識のレベルが向上します。
開発に使用されるサードパーティ製品の脆弱性を検索し、世界を「よりクリーンで楽しい」ものにする能力を持つ。
システムのより詳細な調査。表面的な「低垂れ果物」の収集から各コンポーネントの個別調査への移行により、より複雑な脆弱性を検索することが可能になりました。

各アプローチを改善する必要があります。全体像を把握するために、高度に専門化されたスペシャリストのチームを拡大し、開発者にさらにアクティブなアクションを追加し、セキュリティの分野でトレーニングを行うことができます。

もちろん、このアプローチは製品の安全性に100％の信頼を与えるものではありませんが、従来の侵入テストよりも系統的で広範囲に渡ります。最も迅速な対応、新しいコードのリリース、および可能な限り早い段階での脆弱性の排除を目的としています。

あなたがあなた自身のために何か新しいものを引き出すことができ、大規模なプロジェクトの脆弱性を見つけるための作業がどのように行われるかを理解できたことを願っています。

便利なリンク

7つの基本的な開発テクニック。
OWASPによる Open Security Assurance Maturity Model（ OpenSAMM ）。
マイクロソフトセキュリティ開発ライフサイクル（SDL）。プロセスガイダンス
DOMPurify 。
XSS ベクトルと DOMPurify デモ。
HTML5のXSS ベクトル。
さまざまなHTMLタグを使用してユーザーを追跡します。
添付ファイル用のXSSベクトルを持つファイル。
ファイルスキーマによるWindowsユーザーの匿名化。
モバイルアプリケーションの脆弱性を自動的にチェックするタルサ。
Tizen Developer Toolkit。
Tizenの40のブドウ栽培者に関する投稿。
Tizen OSのバグに関する投稿。
脆弱性SmartTV 。
外部エンティティを実装する脆弱性。
XXEベクトルを使用したファイルの自動生成用のタルサ。
スプリングブートRCE 。
スプリングブートRCEトリック。

PS BeLoveマテリアルの準備にご協力いただきありがとうございます。

大規模プロジェクトの開発プロセスにセキュリティを統合します