開発者として、私たちは機能、修正、期限と常に格闘しています。しかし、潜んでいる問題は驚くほど見落とされてきました。それは、脆弱な Log4j および Spring Framework バージョンが多くのプロジェクトで継続的に使用されているということです。 Log4Shell および Spring4Shell の脆弱性が大々的に暴露されたにもかかわらず、驚くべき数のアプリケーションが依然としてこれらの時限爆弾上で実行されています。これは単なる小さな見落としではなく、大きなリスクです。私たちは本質的に建設業者ですが、建物の安全性を確保することも建築の一部です。
開発者として、私たちは新しい機能の推進と既存のプロジェクトと機能の維持のバランスを常に保っています。それは私たちの時間と全認知帯域幅を必要とするバランスのとれた行為です。すべてのプロジェクトの依存関係を追跡しながら最新の状態に保つことは、特に新しい機能を提供するというプレッシャーがかかっている場合には、困難な戦いのように感じることがあります。このやりくり行為の中で、過失ではなく、私たちが毎日管理する膨大な量のタスクが原因で、Log4Shell や Spring4Shell などの重大な脆弱性がすり抜けてしまうことがあります。ただし、エキサイティングなアプリケーションの安全性とセキュリティは、今日のソフトウェア開発の重要な側面であることを認識することが不可欠です。
Log4Shell を覚えていますか? 2021 年に発見された Apache Log4j の厄介な脆弱性は、攻撃者が特別な文字列をログに記録することでサーバー上でコードを実行できる可能性がありますか?攻撃者は、LDAP プロトコルで JNDI ルックアップを使用して、コンパイル済みのクラス ファイルを挿入し、悪意のあるコードを実行する可能性があります。 Java の新しいバージョンでも、この脆弱性により逆シリアル化攻撃による損害が発生する可能性があります。この重大な脆弱性の攻撃の複雑さは非常に低いと考えられているため、脅威は通常よりもさらに高くなります。問題の詳しい内訳については、ブログ投稿をご覧ください。
現在、多くの企業がプロジェクトの 1 つに、古くて脆弱なバージョンの Log4j ライブラリをまだ使用しています。本番コードの脆弱性をスキャンしているすべての Snyk 顧客のうち、21% が依然として Log4Shell に対して脆弱なプロジェクトを抱えています。つまり、60,000 を超えるプロジェクトが、2 年以上前に公開され修正された脆弱性によって依然として侵害される危険にさらされているということです。それはすごいですね！これらの企業はすでにセキュリティ ツールを使用しており、遭遇するセキュリティ問題を積極的に軽減していることがわかっているため、実際に世に出ている脆弱な log4j バージョンの数はこれよりもはるかに多くなるでしょう。その考えだけでも怖いだけでなく、非常に不安になります。
もう 1 つの悪名高い例は、2022 年 3 月に公開された Spring4Shell です。spring-beans の脆弱性は、悪意のあるリモート コード実行につながる可能性もあります。攻撃の複雑さは低く、特定のケースに対するエクスプロイトはありましたが、その影響は Log4Shell ほど大きくありませんでした。詳細については、専用のブログ投稿をご覧ください。
2022 年 4 月に新しいエクスプロイトを使用してこの脆弱性を Glassfish に拡張することで、Snyk チームは、この脆弱性が非常に重大であり、Tomcat の最初のエクスプロイト以外の多くのケースで悪用される可能性があることを証明しました。
Log4Shell と同様に、Spring4Shell は現在でも実際に適用できることがわかりました。当社の顧客の約 35% のプロジェクトの 1 つに依然として脆弱性が存在します。 Spring4Shell の侵害のリスクは Log4Shell のリスクほど重大ではありませんでしたが、Snyk チームは、Glassfish のエクスプロイト概念実証 (POC) を特定して開発することで、さまざまな潜在的なエクスプロイトを実証しました。これは、一見危険性が低いように見えても、依然として重大なセキュリティ脆弱性につながる可能性があることを証明しています。エクスプロイトがまだ公開されていないという事実は、アプリケーションが脆弱性によって侵害されないことを意味するものではありません!
さらに、多くの Spring アプリケーションが古いフレームワーク バージョンに依存しており、既存のアプリケーションの更新やサービスが重要ではないと考えられていることがわかります。しかし、私たちは心の底ではこれが時限爆弾であり、今にも爆発する可能性があることを知っています。
これを簡単かつ要点に留めましょう。自分のコードが最終的に問題なく実行されたときの誇らしい気持ちは誰でも知っています。特にライブラリの更新などの愚かな目的で、コードを元に戻していじることは絶対に避けたいものです。しかし問題は、これらの Log4Shell と Spring4Shell の脆弱性は自然には修正されないということです。そして正直に言うと、それらは無視できる単なる小さなバグではありません。それらはアプリケーションの壁にぽっかりと穴を開けています。 Log4Shell や Spring4Shell などの脆弱性がランドスケープ内にまだ存在する場合、重大度の高い攻撃に対して不必要に脆弱になります。
Snyk は、アプリケーションのセキュリティ脆弱性を検出して対処することで、これを支援します。 Git リポジトリ、コマンド ライン インターフェイス (CLI)、既存の継続的インテグレーション (CI) パイプラインなど、さまざまな方法で開発ワークフローと統合されており、開発者はセキュリティ リスクが大きな問題に発展する前に、開発サイクルの早い段階でセキュリティ リスクを特定できます。登録は無料で、その機能にすぐにアクセスできます。ただし、本当の価値は、発見された脆弱性が識別後にどのように管理および解決されるかにあります。
私たちはここで責任を負わなければなりません。単に簡単なパッチを見つけたり、簡単なアップデートでうまくいくことを期待したりするだけではありません。場合によっては、脆弱なライブラリを削除または置き換えるという難しい判断が必要になることがあります。そうですね、それは私たちの仕事を少し遅らせるかもしれません、そしてそれは私たちの仕事の中で最もエキサイティングな部分ではありませんが、それは非常に重要です。それは、今日だけでなく長期的にもコードが確実であることを保証することです。
ですから、他の人がこれらの問題を解決してくれるのを待つのはやめましょう。適切なツールがあれば、これらの脆弱性を早期に発見できますが、行動を起こすのは私たち自身でなければなりません。防御を強化し、脆弱性を修正し、アプリケーションを安全かつ健全に保つのは私たちの責任です。プログラマーとしてだけでなく、自分の仕事を可能な限り安全に保つために立ち向かう人々として、それに取り組みましょう。
以上が持続的な脅威: Logell や Springell などの主要な脆弱性が依然として重要な理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
