Webアプリケーションの普遍的に低いセキュリティは、開発されたコードの品質と選択されたプログラミング言語からWebサーバー側で使用される構成に至るまで、多くの要因によるものです。 Webアプリケーションのセキュリティが一般的なセキュリティ戦略とは別に保たれているという事実は、火に燃料を追加します。 構造部門のマネージャーはビジネス開発プロセスを開始しますが、これはWebテクノロジーに基づいた何らかの方法です。 同時に、平均的な企業の情報セキュリティ管理サービスは、取得したソリューションに脆弱性が含まれている可能性があるという事実に目をつぶっているようです。 さらに、実施された作業の経験から、ロシア企業の情報セキュリティ部門の半数以上は、誰がそのセキュリティに関与しているのかは言うまでもなく、外部の公式ウェブサイトの責任者を疑っていません。 Webアプリケーションはスレッドでハッキングされるためです。
最近のペンテストは、これらの議論を明確に示しています。 Webアプリケーションの脆弱性を使用している五pent星のグループがオペレーティングシステムの命令に達したとき（彼ら自身の優位性の喜びに加えて）、ここに私たちだけではないという合理的な感覚が生まれました。
お客様のサイトでのペンテストの1つで、将来サーバー上でコマンドを実行できる可能性のあるいくつかの重大な脆弱性が見つかりました。 ただし、長期間使用することはできませんでした。 秒は数分に、分は時間に変わり、目標は非常に近かったが、すべての努力は失敗した。 周りを見ると、目の前にあるのは大規模なホスティングのサイトの1つにすぎないことがわかりました。 調査対象のサイトとその近隣のページで同じマルウェアが発見されたことを考えると、攻撃者が分析対象サイトの脆弱性を気にすることはほとんどないと想定することは非常に論理的です。 確かに彼は抵抗が最も少ない道にいて、隣人に殺到した。 しかし、ペンテストの制限により、そのような偉業を繰り返すことはできません。 一方、努力は無駄ではなく、脆弱性のカスケードを使用して、顧客のサイトは防御に合格しました。 さらに、従来の情報の収集の代わりに、マルウェアがこのリソースのページにどのように到達したかを調べる必要がありました。
次のストーリーでは、Pentestのゼロデイ脆弱性の使用について説明します。 私たちの前に別のオフィスがあります。 完全に安全なJoomlaコンテンツ管理システム上の別の顧客のサイト。 表面をサーフィンすると、脆弱なモジュールが目にさらされます。この情報は、まだ公開されていない脆弱性に関する情報です。 先日、指定されたモジュールの大量充填が行われたという情報も知られています。 そして、それは奇妙ではないので、すでに手元にありました:)）さらに、ハリウッド映画のように。 ターゲットを導入し、走り、塗りつぶし、喜ぶ））その後、「誰がここにいるのか」という質問に答える必要がありましたか？ そして、答えはすぐに来ました。 まるでevalとbase64のシェルは非常に薄いです。
今日お話ししたい最後の話は、他の話と同じくらい明らかになっています。 私たちの天国の友人の言語のバックドアが、有名で愛されているロシアの銀行の外部サイトの1つにインストールされているのは冗談でしょうか？ さらに、日付は、バックドアが1年以上前に殺到し、この間ずっと気付かれないことを示しました！ Webサーバーが配置されているオペレーティングシステムが銀行のActive Directoryの企業ドメインの一部であるという事実も、話をより深刻にします。 銀行自体のIS管理サービスによって後で発見されたように、常に1つのリクエストのみが記録され、実際にバックドアを設定しました。 今回はちょうど幸運です。 ちなみに、Tomcatの下のバックドア（ala web shell）は本当にだまされていることが判明し（貯金箱に追加しました）、Tomcat管理インターフェースのデフォルトを介してインストールされました。
では、そのような脅威から身を守る方法は？
まず、外部ホスティングにサイトを展開する予定がある場合、顧客のサイトを保護するために必要な手順をホストに尋ねます。 別の話がこの主題について思い出されます。 私たちはどういうわけか私たちの広大な故郷の地域の1つに位置するサイトを分析しました。 SQLインジェクションを修正し、それを解き始め、文字通り30分後にホストからメッセージが表示されます:)しかし、このストーリーで最も注目すべきことは、ホストが発見した脆弱性の仮想パッチをすぐに提供したことです。 一方、ホスティング事業者を選択することで、ホスティング事業者にあまり期待する必要はないかもしれませんが、サービスを提供するときに基本的なセキュリティメカニズムを提供する必要があります。
第二に、どこでも、特に外部Webアプリケーションでは、強力で一意のパスワードを使用します。 サイト管理インターフェイスには、信頼できるIPアドレスのリストのみにアクセスしてください。 ところで、これらの2つの単純なルールは、データベースと対話するユーザーの最小限の特権とともに、SQLステートメントの導入などの脆弱性がある場合に損害を大幅に減らすことができます。
最後に、ゼロデイ攻撃から身を守るときは、提供する防御メカニズムが多いほど、そのような不幸からサイトを保護する可能性が高くなることを忘れないでください。 おそらく、アプリケーションコードの愚かな脆弱性を利用して、標的型攻撃から身を守ることはできないでしょうが、大規模な攻撃から身を守ることは可能です。 そして、これは十分ではありません！
それでは、セキュリティのファジングやソースコード分析に頼らずに、サイトをゼロデイ攻撃から保護するには何が必要ですか？ 私の意見では、少なくとも以下を実装する必要があります。
-すべてのインターフェイス（ftp、管理セクションなど）で使用される識別子への強力なパスワード。
-すべての管理インターフェイスは、信頼できるIPアドレスでのみ使用可能にする必要があります。 オプションで、可能な限り2要素認証を使用します。
-すべてのコンポーネントの特権の最小化。
-アクセス制御テーブルが正しく構成されている（ファイルシステムから開始し、コンテンツ管理システムを使用したアクセス制御で終了します（そのような機能を提供する場合））。
-Webサーバーとその環境のセキュアな構成（たとえば、セキュアなPHP構成）。
-予防制御メカニズム（Webアプリケーションファイアウォール）の使用。
-Webアプリケーションから他のネットワークコンポーネントへのネットワークアクセスの制限。 隔離されたネットワーク環境（別名個人DMZ）でWebサーバーをホストします。
これらのアプローチに従うと、Webアプリケーションのセキュリティが大幅に向上します。 私はあなたが向こう側の善との絶え間ない戦いで成功することを望みます:)