개발자로서 우리는 기능, 수정 사항, 기한을 끊임없이 조정하고 있습니다. 그러나 숨어 있는 문제는 놀랍게도 간과되어 왔습니다. 바로 많은 프로젝트에서 취약한 Log4j 및 Spring Framework 버전을 계속 사용하는 것입니다. Log4Shell 및 Spring4Shell 취약점이 세간의 이목을 끌었음에도 불구하고 충격적인 수의 애플리케이션이 여전히 시한폭탄을 안고 실행되고 있습니다. 이는 단지 사소한 실수가 아니라 중대한 위험입니다. 우리는 본질적으로 건축업자이지만 건물의 일부는 구조물의 안전을 보장하는 것입니다.
개발자로서 우리는 새로운 기능을 출시하는 것과 기존 프로젝트 및 기능을 유지하는 것의 균형을 끊임없이 유지합니다. 이는 우리의 시간과 전체 인지 대역폭을 요구하는 균형 잡힌 행위입니다. 모든 프로젝트의 종속성을 추적하면서 최신 상태로 유지하는 것은 힘든 싸움처럼 느껴질 수 있으며, 특히 새로운 기능을 제공해야 한다는 압력이 가해질 때 더욱 그렇습니다. 이러한 저글링 작업 중에 Log4Shell 및 Spring4Shell과 같은 심각한 취약점이 부주의로 인한 것이 아니라 매일 관리하는 작업의 엄청난 양으로 인해 때때로 실패할 수 있습니다. 그러나 흥미로운 애플리케이션의 안전과 보안이 오늘날 소프트웨어 개발의 중요한 측면이라는 점을 인식하는 것이 중요합니다.
Log4Shell을 기억하시나요? 2021년에 발견된 Apache Log4j의 불쾌한 취약점으로 인해 공격자가 특수 문자열을 기록하여 서버에서 코드를 실행할 수 있습니까? 공격자는 LDAP 프로토콜과 함께 JNDI 조회를 사용하여 사전 컴파일된 클래스 파일을 주입하고 악성 코드를 실행할 수 있습니다. 최신 버전의 Java에서도 이 취약점은 역직렬화 공격으로 인해 피해를 입을 수 있습니다. 이 중요한 취약점의 공격 복잡성은 매우 낮은 것으로 간주되므로 위협이 평소보다 훨씬 더 높아집니다. 문제에 대한 전체 분석 내용을 보려면 블로그 게시물을 확인하세요.
오늘날에도 많은 기업의 프로젝트 중 하나에 오래되고 취약한 Log4j 라이브러리 버전이 남아 있습니다. 프로덕션 코드에서 취약점을 검사하는 모든 Snyk 고객 중 21%는 여전히 Log4Shell에 취약한 프로젝트를 보유하고 있습니다. 이는 60,000개 이상의 프로젝트가 2년 전에 공개되고 수정된 취약점으로 인해 여전히 침해될 위험이 있다는 것을 의미합니다. 엄청나네요! 이들 회사가 이미 보안 도구를 사용하고 있으며 직면하는 보안 문제를 적극적으로 완화하고 있다는 사실을 알면 실제로 취약한 log4j 버전의 실제 수는 그보다 훨씬 많을 것입니다. 그 생각만으로도 무섭고 불안하기도 합니다.
또 다른 악명 높은 사례는 2022년 3월에 공개된 Spring4Shell입니다. spring-beans의 취약점은 악성 원격 코드 실행으로 이어질 수도 있습니다. 공격 복잡도가 낮고 특정 사례에 대한 익스플로잇이 있었지만 그 영향은 Log4Shell에 비해 덜 중요했습니다. 자세한 내용은 전용 블로그 게시물을 확인하세요.
Snyk 팀은 2022년 4월 새로운 익스플로잇을 통해 이 취약점을 Glassfish로 확장함으로써 이 취약점이 매우 중요하며 tomcat에 대한 첫 번째 익스플로잇 외에도 더 많은 경우에 오용될 수 있음을 입증했습니다.
Log4Shell과 유사하게 Spring4Shell도 여전히 현장에서 적용 가능하다는 것을 알았습니다. 고객 중 약 35%가 여전히 프로젝트 중 하나에 취약성을 갖고 있습니다. Spring4Shell 위반 위험이 Log4Shell만큼 심각하지는 않지만 Snyk 팀은 Glassfish에 대한 공격 개념 증명(POC)을 식별하고 개발하여 다양한 잠재적 공격을 시연했습니다. 이는 겉보기에 덜 위험해 보이는 경우에도 여전히 심각한 보안 취약성이 발생할 수 있음을 증명합니다. 아직 공개된 익스플로잇이 없다는 사실이 애플리케이션이 취약점으로 인해 침해될 수 없다는 의미는 아닙니다!
게다가 많은 Spring 애플리케이션이 오래되고 오래된 프레임워크 버전에 의존하며 기존 애플리케이션을 업데이트하고 서비스하는 것이 중요하지 않은 것으로 간주된다는 것을 보여줍니다. 그러나 우리는 이것이 곧 폭발할 수 있는 시한폭탄임을 알고 있습니다.
간단하고 요점만 설명하겠습니다. 우리 모두는 코드가 문제 없이 실행될 때 느끼는 자부심을 알고 있습니다. 특히 라이브러리 업데이트와 같은 어리석은 일에서는 다시 돌아가서 코드를 엉망으로 만들고 싶지 않습니다. 하지만 문제는 Log4Shell 및 Spring4Shell 취약점이 저절로 해결되지는 않는다는 것입니다. 그리고 솔직히 말해서, 그것들은 우리가 무시할 수 있는 단지 작은 버그가 아닙니다. 그들은 우리 애플리케이션의 벽에 구멍을 뚫고 있습니다. Log4Shell 또는 Spring4Shell과 같은 취약점이 여전히 존재한다면 심각도가 높은 공격에 불필요하게 취약한 것입니다!
Snyk는 애플리케이션의 보안 취약성을 감지하고 해결하도록 지원함으로써 이를 도와드릴 수 있습니다. Git 리포지토리, 명령줄 인터페이스(CLI) 또는 기존 CI(지속적 통합) 파이프라인 등 다양한 방법으로 개발 워크플로와 통합되므로 개발자는 보안 위험이 더 큰 문제로 발전하기 전에 개발 주기 초기에 이를 식별할 수 있습니다. 등록은 무료이므로 해당 기능에 즉시 액세스할 수 있습니다. 그러나 실제 가치는 발견된 취약점을 식별 후 관리하고 해결하는 방법에 있습니다.
여기서 우리는 책임을 져야 합니다. 단지 빠른 패치를 찾거나 간단한 업데이트만으로 효과가 있기를 바라는 것이 아닙니다. 때로는 취약한 라이브러리를 제거하거나 교체하기 위해 어려운 결정을 내려야 하는 경우도 있습니다. 네, 우리의 속도가 약간 느려질 수도 있고 우리 일에서 가장 흥미로운 부분은 아니지만 매우 중요합니다. 이는 오늘뿐 아니라 장기적으로 코드를 견고하게 유지하는 것입니다.
그러므로 다른 사람이 이러한 문제를 해결할 때까지 기다리지 마십시오. 적절한 도구를 사용하면 이러한 취약점을 조기에 발견할 수 있지만 조치를 취하는 사람은 바로 우리 자신이어야 합니다. 방어력을 강화하고, 취약점을 패치하며, 애플리케이션을 안전하고 건전하게 유지하는 것은 우리의 몫입니다. 코더로서가 아니라 작업을 지지하는 사람들로서 가능한 한 안전하게 작업을 수행해 봅시다.
위 내용은 지속적인 위협: Logell 및 Springell과 같은 주요 취약점이 여전히 중요한 이유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
