이 문서의 버전은 인포시큐리티 매거진에 게재되었습니다. 여기에 업데이트되고 신디케이트되었습니다.

‍

지난 2 년 동안 은 불에 의해 다소 세례되었습니다, 잘, 모든 사람, 하지만 대부분의 조직에 대한 사이버 보안 청사진은 우리 중 많은 사람들이 거의 하룻밤 원격 작업 모델에 떨어졌다으로 테스트에 넣어. 우리는 전염병이 시작된 이후 보고 된 사이버 범죄가 300 % 급증하는 필사적 인 위협 행위자의 여파로 특히 업계로 적응해야했습니다.

우리는 모두 몇 가지 교훈을 배웠고, 일반적인 사이버 보안이 더 심각하게 받아들여지고 있다는 사실에 위안을 얻었기 때문에 코드 수준 소프트웨어 보안 및 품질도 마찬가지입니다. 소프트웨어 공급망 확보에 대한 Biden의 행정 명령은 특히 SolarWinds 대량 유출의 여파로 중요한 문제를 초래했습니다. 우리 모두가 보안에 더 많은 관심을 가지고 측정 가능한 보안 인식을 통해 취약점을 줄이기 위해 노력해야 한다는 생각은 분명히 대화의 큰 부분입니다.

즉, 사이버 범죄자에 맞서 싸울 때, 우리는 예방 적 사고 방식으로 놀이터를 선점하면서 가능한 한 그들과 함께 해야합니다. 

내년에 파도를 일으키기 시작할 수 있다고 생각합니다.

메타버스는 새로운 공격 표면입니다.

메타버스는 인터넷의 다음 진화일 지 모르지만, 대부분의 산업이 소프트웨어와 디지털 환경을 보호하는 방식에 접근하는 방식에서 유사한 변화는 아직 실현되지 못하고 있습니다. 

피싱 사기와 같은 일반적인 사이버 보안 함정은 피할 수 없지만 (모두가 메타 버스로 발을 찾는 동안 가능성이 풍부함), 이 몰입형 가상 세계를 가능하게하는 실제 인프라 및 장치는 안전해야합니다. 스마트폰이 온라인 생활을 하는 데 도움이 된 방식과 마찬가지로 VR 헤드셋과 같은 주변 기기는 사용자 데이터의 산에 대한 새로운 관문입니다. IoT 가젯을 안전하게 만들기 위해서는 점점 더 복잡해지는 임베디드 시스템 보안이 필요하며, 주류 VR/AR의 용감한 새로운 세계도 예외는 아닙니다. Log4Shell 악용에서 보았듯이 코드 레벨의 간단한 오류는 위협 행위자의 백스테이지 패스로 피어날 수 있으며 시뮬레이션된 현실에서 모든 움직임은 도난당할 수 있는 데이터를 생성합니다.  

초기 단계에 있는 동안 성공적인 메타버스는 암호 화폐 (최신 밈 동전의 무작위 비장뿐만 아니라)의 실질적인 채택을 요구할 것이며, NFT와 같은 가치 항목은 실제 부, 정체성, 데이터 및 생계가 잠재적으로 사람들을 위험에 빠뜨릴 수있는 새로운 "와일드 웨스트"로 열립니다. 엔지니어들이 서사시적인 기능과 향상된 기능으로 미쳐 가기 전에 이 새롭고 광대한 공격 표면을 처음부터 최소화하는 것이 우선순위가 되어야 합니다.

Log4Shell의 여파로 법률

혼란에 던져 진 개발자의 점수에 대 한, 어떤 인스턴스가 있는지 찾기 위해 스크램블, 또는 종속성, 널리 사용 되는 Log4j 로깅 도구의 악용 버전, 휴가 기간 즐거운 시간 되었을 것 이라고 생각 하지 않습니다. 

이 제로 데이 공격은 기록상 최악의 공격 중 하나이며, Log4Shell과 6 년 후에도 여전히 악용되고있는 파괴적인 Heartbleed OpenSSL 취약점 을 비교합니다. 이 타임라인이 가야 할 것이라면, 우리는 앞으로 오랫동안 Log4Shell 숙취를 다룰 것입니다. 적어도 가능한 한 빨리 패치를 출시하고 구현해야 한다는 측면에서 Heartbleed에서 얻은 교훈에도 불구하고 많은 조직이 스스로를 보호하기에 충분히 빨리 행동하지 않는다는 것은 분명합니다. 회사의 규모에 따라 패치는 매우 어렵고 관료적일 수 있으며, 부서 간 문서와 구현이 필요합니다. IT 부서와 개발자는 사용 중인 모든 라이브러리, 구성 요소 및 도구에 대한 백과 사전 지식이 없으며 중단 및 응용 프로그램 중단 시간을 최소화하기 위해 엄격한 배포 일정에 방해를 받습니다. 이 작업 방법에 대한 타당한 이유가 있습니다 (읽기 : 아무도 작품에 스패너를 던져 뭔가를 깰 싶지 않습니다), 하지만 너무 느리게 패치하는 것은 앉아 오리가 될 것입니다.

SolarWinds 공격이 소프트웨어 공급망의 게임을 변경한 것처럼 Log4Shell의 여파로 비슷한 일이 일어날 것으로 예상됩니다. 일부 중요한 산업에는 이미 패치 관리 명령과 권장 사항이 있지만 광범위한 법안은 또 다른 이야기입니다. 예방 소프트웨어 보안은 항상 긴급한 보안 패치를 완전히 피할 수 있는 가장 좋은 기회이지만 보안 모범 사례는 패치가 협상할 수 없는 우선 순위 측정이라고 규정합니다. 나는 이것이 화제가 될 것이라고 생각하고, 신속하고 자주 패치하는 미묘한 권장 사항으로 이어질 것입니다. 

아키텍처 보안에 더 중점을 두다(개발자는 준비가 되지 않았습니다)

새로운 OWASP Top 10 2021 에는 몇 가지 중요한 새로운 추가뿐만 아니라 주입 취약점이 상위 권에서 3 위로 떨어지는 놀라운 점이 있었습니다. 이러한 새로운 추가 는 안전한 코딩 및 보안 모범 사례에서 개발자의 여정에 대한 "2 단계"에 대해 이야기하며, 슬프게도, 대부분은 제대로 훈련되지 않는 한 여기에 위험을 줄이는 데 긍정적 인 영향을 미칠 준비가되어 있습니다.

코드에서 일반적인 보안 버그에 대처하기 위해 개발자가 보안 숙련되어야 한다는 것을 한동안 알고 있으며 조직은 개발자 중심예방의 전제에 더 잘 대응하고 있습니다. 그러나 안전하지 않은 디자인 이 OWASP Top 10에 속하고 단일 유형의 보안 버그가 아닌 건축 보안 문제의 범주이기 때문에 개발자는 이를 마스터한 후에는 기본 을 넘어서야 합니다. 보안 팀의 지원으로 위협 모델링을 포괄하는 학습 환경은 개발자가 성공적으로 숙련되면 심각한 압박을 가하지만 대부분의 소프트웨어 엔지니어에게는 상당한 지식 격차입니다.

이에 대응하여 "마을을 취합니다", 조직은 자신의 워크 플로우에 큰 혼란을 일으키지 않고 호기심을 초대, 개발자를위한 긍정적 인 보안 문화를 만드는 역할을 할 수 있습니다.

이 문서의 버전은 SC 매거진에 등장. 그것은 수정 및 여기에 신디케이트되었습니다.


도둑에 의해 집이 부서진 적이 있다면, 뭔가 잘못되었다는 초기 가라앉는 느낌과 실제로 도난당하고 위반되었다는 것을 깨닫게 됩니다. 그것은 일반적으로 지속적인 불편 귀착됩니다, 포트 녹스에 필적 것 보안 조치에 피벗은 말할 것도없고.

도둑이 스스로 열쇠를 만들었기 때문에 이제 당신의 집이 침해되었다고 상상해보십시오. 그들은 주위를 기어 다니고, 오고, 그들이 원하는대로 가고 있지만, 발견되지 않은 상태로 유지하도록주의합니다. 그런 다음 어느 날, 냉동실에 숨어있던 보석이 사라지고 금고가 비어 있고 개인 소지품이 약탈당했다는 것을 너무나 늦게 알 수 있습니다. 이것은 조직이 제로 데이 사이버 공격의 희생자가 되면 직면하는 것과 동등한 현실입니다. 2020년 Ponemon Institute의 연구에 따르면 성공적인 데이터 유출의 80%가 제로 데이 악용의 결과이며, 슬프게도 대부분의 기업은 이 통계를 크게 개선하기 위해 제대로 갖추지 못하고 있습니다.

제로 데이 공격은 정의에 따라 개발자에게 위협 행위자 먼저 얻었기 때문에 악용될 수 있는 기존 취약점을 찾고 패치할 시간을 제로로 제공합니다. 손상이 완료되고 소프트웨어와 비즈니스에 대한 평판 손상을 모두 해결하기 위한 미친 출격입니다. 공격자는 항상 우위를 점하고 있으며 가능한 한 그 가장자리를 닫는 것이 중요합니다. 

아무도 원하지 않는 휴일 선물 - Log4Shell - 현재 이 치명적인 자바 취약점의 영향을 받는 것으로 전해지는 10억 개가 넘는 장치가 인터넷을 폭파하고 있습니다. 그것은 기록에 최악의 0 일 공격까지 형성, 그리고 우리는 단지 시작. 악용이 공개되기 며칠 전에 시작되었다는 일부 보고서에 도 불구하고 2016 년 Black Hat 컨퍼런스에서 발표 된 프리젠 테이션 은 이것이 한동안 알려진 문제임을 시사합니다. 아야. 더 나쁜 것은 악용하기가 고통스럽고, 지구상에 있는 모든 스크립트 키디와 위협 배우는 이 취약점으로 페이더트를 쫓고 있습니다.

그렇다면 소프트웨어 개발 과정에서 놓친 취약점은 말할 것도 없고 미끄러운 사악한 위협에 맞서 방어할 수 있는 최선의 방법은 무엇일까요? 살펴 보자. 

큰 대상에 대한 제로 데이 공격은 드물고 비용이 많이 듭니다.

어두운 웹에 악용에 대 한 거 대 한 시장, 그리고 제로 일 꽤 페니에 대 한 이동 하는 경향이, 이 문서에 대 한 나열 된 한 예와 함께 $2.5 M 쓰기의 시간에. 애플 iOS의 악용으로 보고, 그것은 보안 연구원의 요구 가격은 지붕을 통해 놀라운 일이 아니다; 결국, 이것은 실제로 수백만 개의 장치를 손상시키고, 수십억 개의 중요한 데이터 레코드를 수확하고, 발견되고 패치되기 전에 가능한 한 오랫동안 할 수 있는 관문이 될 수 있습니다.

하지만 어쨌든 누가 그런 종류의 돈이 있습니까? 일반적으로 조직 된 사이버 범죄 신디케이트는 특히 인기있는 랜섬웨어 공격에 대해 가치가 있다고 판단되면 현금을 마련할 것입니다. 그러나 글로벌 정부와 국방부는 위협 인텔리전스에 사용할 수 있는 악용을 위한 고객 중 하나이며, 보다 긍정적인 시나리오에서는 회사 자체가 재해를 완화할 수 있도록 제로 데이 의 잠재적 인 악용의 구매자일 수 있습니다. 

2021년 생 방송 제로데이 악용 검색에 대한 기록이 깨졌으며, 약점에 대해 조사할 위험이 가장 큰 조직, 정부 부처 및 인프라입니다. 제로 데이 공격의 가능성에서 완전히 안전 할 수있는 방법은 없지만 관대하고 잘 구조화 된 버그 현상금 프로그램을 제공함으로써 다소 "게임을 플레이"할 수 있습니다. 어두운 웹 마켓플레이스에서 소프트웨어 성에 대한 열쇠를 제공할 때까지 기다리지 말고, 합법적인 보안 강화 효과를 얻고 윤리적 공개 및 잠재적 수정에 대한 적절한 보상을 제공합니다.

그리고 만약 그것이 단지 그렇게 머리를 기르는 제로 데이 위협이 될 경우, 그것은 당신이 아마존 기프트 카드 보다 더 기침 해야 합니다 가정 하는 것이 안전 (그리고 그것은 그렇게 하는 동안 가치가 있을 것입니다).

툴링은 보안 담당자에게 책임이 될 수 있습니다.

성가신 보안 툴링은 오랫동안 문제가되어 왔으며, 평균 CISO는 보안 무기고 에서 55개에서 75개의 도구를 관리합니다. 포네몬 연구소의 연구에 따르면 , 세계에서 가장 혼란스러운 (은유적인) 스위스 육군 칼이 아닌 53%의 기업이 효과적으로 일하고 있다고 확신하지 못합니다. 또 다른 연구에 따르면 CISSo의 17%만이 보안 스택이 "완전히 효과적"이라고 생각했습니다.

소진, 수요를 충족하기 위해 보안 숙련도가 부족한 사람, 민첩성이 필요한 분야의 경우 보안 전문가가 막대한 도구 집합의 데이터, 보고 및 모니터링 의 형태로 정보 과부하를 처리해야 하는 것은 부담스러울 수 있습니다. 이것은 정확히 그들이 중요한 경고를 놓칠 수 있습니다 시나리오의 유형입니다, 잘 제대로 약점에 대한 Log4j를 평가에 올 때 되었을 수 있습니다. 

예방 보안에는 개발자 기반 위협 모델링이 포함되어야 합니다.

코드 수준 취약점은 종종 개발자가 도입하는 경우가 많으며, 안전한 코딩 기술을 구축하기 위해서는 정밀 지침과 정기적인 학습 경로가 필요합니다. 그러나 차세대 보안 개발자는 소프트웨어 생성 프로세스의 일환으로 위협 모델링을 배우고 연습할 수 있는 기회를 얻었습니다.
‍
자신의 소프트웨어를 가장 잘 아는 사람들이 거기에 앉아서 그것을 만든 개발자라는 것은 놀랄 일이 아닙니다. 사용자가 상호 작용하는 방법, 기능이 사용되는 위치, 보안에 충분히 인식할 때 중단되거나 악용될 수 있는 잠재적 시나리오에 대한 강력한 지식을 보유하고 있습니다.

Log4Shell 악용으로 다시 가져오는 경우, 안타깝게도 전문가 및 복잡한 도구 집합에 의해 치명적인 취약점이 탐지를 벗어난 시나리오가 있지만 라이브러리가 사용자 입력을 소독하도록 구성된 경우 전혀 발생하지 않았을 수 있습니다. 그렇게하는 것에 대한 결정은 추가 편의를위한 모호한 기능인 것 같지만 악용하기가 고통스럽게 쉬워졌습니다 (SQL 주입 수준을 생각하면 확실히 천재적인 것이 아닙니다). 보안에 정통한 개발자 그룹이 위협 모델링을 수행했다면 이 시나리오가 이론화되고 고려되었을 가능성이 높습니다.

훌륭한 보안 프로그램은 인간이 만든 문제를 해결하는 중심에 인간의 개입과 뉘앙스를 가진 감정적 인 구성 요소를 가지고 있습니다. 위협 모델링은 소프트웨어 및 응용 프로그램의 아키텍처 수준에서 코딩 및 구성을 보호하는 것처럼 공감과 경험이 효과적이도록 합니다. 이것은 개발자가 하룻밤 사이에 던져져야하는 것이 아니라이 중요한 작업에 대한 보안 팀의 압력을 취할 수있는 수준으로 업 스킬을 제공하는 명확한 경로는 이상적입니다 (그리고 양 팀 간의 교감을 구축 할 수있는 좋은 방법입니다). 

제로 데이는 n-일로 이어질

제로 데이를 다루는 다음 부분은 취약한 소프트웨어의 모든 사용자가 가능한 한 빨리 적용하고 공격자가 먼저 도착하기 전에 지옥처럼 기대하면서 가능한 한 빨리 패치를 얻는 것입니다. Log4Shell을 사용하면 수백만 개의 장치에 내장되어 소프트웨어 빌드전반에 걸쳐 복잡한 종속성을 생성하는 데 직면하여 내구성과 힘에 Heartbleed를 가리킬 수 있습니다.

현실적으로, 완전히 교활한 공격의이 유형을 중지 할 수있는 방법은 없습니다. 그러나 모든 길을 사용하여 품질, 보안 소프트웨어를 만들고 중요한 인프라와 동일한 사고 방식을 사용하여 개발에 접근하려는 약속으로 우리는 모두 싸울 기회를 가질 수 있습니다.

개발자는 다양한 방법으로 자체 코드를 만들고 테스트합니다. 이러한 방법 중 하나는 단위 테스트입니다 - 자신의 코드의 가장 작은 부분을 테스트하는 매우 인기있는 방법. 단위 테스트를 잘 작성하면 코드 품질을 개선하고 비용과 개발 시간을 줄이는 데 도움이 될 수 있습니다. 테스트 기반 개발(TDD)의 일부로 수행되든 그렇지 않든, 단위 테스트는 현대 개발 관행의 핵심 부분이며 그 중요성은 많은 테스트 프레임워크를 만드는 데 이어졌습니다.

그러나 적절한 테스트 프레임워크와 지침이 없는 경우 초점이 품질과 가독성이 아닌 커버리지와 수량으로 전환함에 따라 단위 테스트가 복잡하고 읽을 수 없게 될 수 있습니다. 이는 많은 단위 테스트를 갖춘 크고 활성 코드베이스에서 특히 그렇습니다.

좋은 테스트 프레임워크는 간단하고 품질 테스트에 중점을 둔 읽기 쉬운 좋은 테스트를 만드는 데 도움이 됩니다. 또한 코드를 사용하는 방법도 문서화하는 데 도움이 됩니다. 이러한 프레임워크 중 하나는 AssertJ입니다.

AssertJ는 Java에서 단위 테스트를 작성하기 위한 유창한 API입니다. 컨텍스트 인식 자동 완성과 함께 영어처럼 읽는 테스트 어설션을 작성할 수 있습니다. 많은 수의 테스트가 있고 가독성을 개선해야 하는 경우 모든 테스트를 AssertJ로 마이그레이션하고 향후 모든 테스트가 AssertJ를 최대한 활용하고 있는지 확인할 수 있습니다.

그러나 완전한 마이그레이션은 수동으로 수행하는 데 엄청난 노력과 시간이 걸릴 수 있으므로 다른 개발 작업에 대해 건너 뛰거나 연기되는 경우가 많습니다. 그래서 우리는 만들었습니다. Sensei - AssertJ를 사용하기 위해 현재 단위 테스트를 마이그레이션하고 모든 미래의 테스트를 올바른 방법으로 작성할 수 있도록 하는 매우 사용자 정의 가능한 IntelliJ 플러그인. 이것은 이미 당신을 위해 만든 조리법 (규칙)의 숫자로 이루어집니다 Sensei'개발 팀. Sensei 일회성 마이그레이션을 수행하거나 한 번에 한 번 테스트하는 AssertJ로 증분 마이그레이션을 수행하는 방법을 쉽게 수행할 수 있습니다. AssertJ로 이동하면 개발자가 단위 테스트를 작성할 때 개발자가 단위 테스트를 작성할 때 빠른 수정 사항을 적용하는 데 계속 도움이 되므로 전체 코드베이스에서 단위 테스트가 균일하고 표준적이며 일관성이 유지됩니다.

‍

약 Sensei

Sensei 수백 개의 다운로드 가능한 코드 변환 및 마이그레이션 레시피(규칙)와 직접 제작할 수 있는 내장 된 기능으로 입력할 때 바람직하지 않은 코드를 스캔하고 수정할 수 있는 매우 사용자 정의 가능한 IntelliJ 플러그인입니다. 와 Sensei개발자는 잘못된 코드 패턴을 입력할 때 품질 코드를 더 빠르게 제공할 수 있도록 수정하고 궁극적으로 팀과 프로젝트 전반에 걸쳐 일관되고 표준적인 방식으로 작성할 수 있습니다.

다음은 샘플 마이그레이션의 예입니다. Sensei AssertJ를 사용하기 위해 단위 테스트를 마이그레이션하는 것이 고통스없이 만듭니다.

AssertJ가 단위 테스트를 작성하는 데 큰 프레임워크인 이유

이 JUnit 어설션과 같은 테스트를 작성하는 대신 다음과 같습니다.

AssertJ로 이 글을 쓸 수 있습니다.

즉, 영어 문장처럼 왼쪽에서 오른쪽으로 주장을 읽을 수 있으며, 어떤 것이 기대인지 분명합니다(이 경우 크기 3). 이런 식으로 몇 번이나 주장을 잘못된 방법으로 작성했습니까?

이것은 단지 간단한 예입니다. 검사와 어설션이 복잡할수록 AssertJ가 더 많아서 테스트를 간단하고 읽을 수 있습니다. IDE의 자동 완성과 잘 어울린다. 입력하자마자 다음을 수행합니다.

myResult의 유형에 따라 확인할 수 있는 모든 것들로 나타납니다. 컬렉션인 경우 특정 값이나 형식이 포함되어 있는지 여부 등 해당 내용, 크기를 확인할 수 있습니다.

밖으로 나온 AssertJ는 기본 및 박스형, 원자 유형, 컬렉션, 배열, 지도, 날짜, java.time, 선물, 파일/경로, 입력스트림, Throwable및 URL을 지원합니다. 그리고 당신은 Hamcrest에 대한 좋아하는 사용자 정의 매치러가있는 경우, 당신은 HamcrestCondition를 통해 AssertJ와 함께 사용할 수 있습니다.

읽기 쉬운 단위 테스트를 통해 개발자는 일반 영어로 코드를 쉽게 읽을 수 있으므로 실수를 쉽게 발견하고 커버리지를 늘릴 수 있으므로 AssertJ는 좋은 Java 단위 테스트를 위한 필수 프레임워크가 됩니다.

레거시 단위 테스트를 AssertJ로 이동하는 레시피

AssertJ와 일관된 코드를 작성하는 데 도움이 되는 쿡북을 작성했습니다. JUnit 3, JUnit 4, JUnit 5 및 FEST-Assert와 같은 이러한 프레임워크에서 AssertJ로 어설션을 마이그레이션하는 데 도움이 될 수 있습니다.

이 쿡북은 Sensei 즉시 사용및 당신은에 대한 설치 지침을 찾을 수 있습니다 Sensei 여기.

코드로 더 나은 단위 테스트를 작성 - JUnit 품질을 점진적으로 개선

Sensei AssertJ용 쿡북은 다른 프레임워크에서 마이그레이션하는 데 도움이 되지 않습니다. 그것은 당신이 당신의 테스트 쓰기를 개선하는 데 도움이 될 수있는 몇 가지 조리법이 있다, 오래된 습관을 깰, 더 특색 AssertJ 테스트를 작성.

예를 들어 다음과 같은 테스트를 작성했다고 가정해 보겠습니다.

아마도 당신은 이 JUnit 스타일의 어설션에서 위의 마이그레이션 레시피 중 하나를 사용하여 마이그레이션할 수도 있습니다.

Sensei AssertJ용 쿡북에는 이 오래된 어설션 스타일을 감지하고 이를 변환할 수 있는 레시피 가 있습니다.

또 다른 레시피 는 다음을 변환할 수 있습니다.

이에 대해 다음과 같은 작업을 수행합니다.

팀 간 일회성 마이그레이션 및 균일한 코딩 관행- Sensei

위의 예제에서 AssertJ를 사용하는 단위 테스트의 수동 마이그레이션에는 더 나은 테스트를 작성하는 데 가장 많은 노력과 시간이 포함될 수 있습니다. 사용 하 여 Sensei단위 테스트를 AssertJ로 쉽게 마이그레이션할 수 있습니다. 일회성 마이그레이션을 수행하거나 개별 테스트를 AssertJ로 마이그레이션할 수 있습니다. Sensei 이러한 유형의 유연성을 제공하여 코드 마이그레이션을 덜 고통스럽게 만듭니다.

단위 테스트 마이그레이션은 여러 가지 방법의 한 예에 불과합니다. Sensei 프로젝트 간에 일관된 코드를 작성하는 데 사용할 수 있습니다. 항상 풀 요청에서 자주 발생하거나 자신을 코딩할 때 자주 발생하는 패턴 방지 또는 특정 수동 코드 변환을 경계할 수 있습니다. 개발자가 자주 놓친 코딩 지침 집합이 있는 경우 가이드라인을 레시피로 변환하여 개발자가 승인된 코드 변환을 자신있게 적용할 수 있습니다.

질문이 있으시면, 저희는 여러분으로부터 듣고 싶습니다! 슬랙에 우리와 함께 : sensei-scw.slack.com

코드 마이그레이션(읽기: 레거시 코드)은 재미가 없습니다. 그것은 라인을 가로 질러 그것을 얻기 위해 계획과 노력의 엄청난 금액이 필요합니다. 개발자에게 가장 흥미롭거나 동기부여가 되는 작품은 아니지만 레거시 코드를 새 라이브러리 버전으로 마이그레이션하는 데 대한 결정과 올바른 환경이 필요합니다. Joda-Time to java.time은 세심한 계획과 실행이 필요한 마이그레이션 중 하나입니다.

Java 프로젝트가 Java SE 8 이전에 생동감이 뛰어나고 날짜/시간 처리를 사용하는 경우, SE 8 이전에 날짜 및 시간 기능을 처리하기 위한 우수한 라이브러리와 사실상표준인 Joda-Time을 사용했을 것입니다. 프로젝트가 여전히 Joda-Time을 사용하지만 java.time으로 마이그레이션하려는 경우 계속 읽으십시오.

Java SE 8의 릴리스에는 java.time(JSR-310)이라고 하는 새롭고 향상된 표준 날짜 및 시간 API가 포함되어 있습니다. 이제 Joda-Time 프로젝트는 Java.time(JSR-310)으로 마이그레이션하는 것이 좋습니다.

java.time(JSR-310)은 조다 타임에서 크게 영감을 받았지만, 거꾸로 호환되지 않으며 개념과 용어가 변경되었습니다. 그렇기 때문에 Joda-Time에서 java.time로 마이그레이션하려면 변경되는 모든 코드 줄에 주의해야 합니다. 이것은 시간이 많이 소요될 수 있으며 마이그레이션하기가 쉽고 자동화된 방법이 있었으면 좋겠다는 것을 거의 알 수 있습니다.

마이그레이션하는 더 좋은 방법이 있으며 이를 사용하여 마이그레이션했습니다. Sensei - 자동으로 당신에 의해 정의 조리법 (규칙)에 따라 코드 변환을 수행하는 IntelliJ 플러그인. 반복적인 마이그레이션 작업을 수행하는 대신 재사용 가능한 레시피를 정의하는 데 시간을 할애합니다. 자동화는 레거시 Joda-Time 코드를 변환할 뿐만 아니라 팀이 새 코드를 작성할 때 IDE에서 바로 지침을 따르는 데 도움이 됩니다.

당신이 머리를 시작할 수 있도록, 우리는 공개를 만들었습니다 Sensei 자바 시간 (JSR-310)에 요리 책 표준화는 덜 고통스러운 방법으로 조다 시간에서 자바 시간으로 마이그레이션하는 조리법을 포함한다. 이것은 우리가 더 많은 조리법과 더 많은 범위를 추가하기 위해 확장을 계속 하는 조리법의 성장 세트입니다.

다음은 샘플 마이그레이션의 예입니다. Sensei 레거시 코드를 마이그레이션하는 것이 고통스없이 만듭니다.

반복적인 수동 마이그레이션에서 자동화된 코드 변환까지

Joda-Time에서 java.time으로 단일 코드 줄을 마이그레이션할 때 몇 가지 숨겨진 트랩을 보여 주는 새 DateTime을 만드는 예를 살펴보겠습니다. 그런 다음 우리는 우리의 중 하나를 볼 것입니다 Sensei java.time(JSR-310) 요리책에 대한 표준화의 레시피와 이 모든 정보를 캡처하는 방법을 보여 주므로 모든 개발자가 동일한 마이그레이션을 반복해서 사용할 수 있습니다.

이 예제에서는 DateTime 필드의 값을 나타내는 7개의 int 인수에서 Joda-Time DateTime을 생성하고 있습니다.

어떻게 이것을 java.time 에 상응하는 것으로 마이그레이션합니까?

이 생성자의 조다 타임의 자바독은 다음과 같은 말합니다.

기본 표준 시간대의 ISOChronology를 사용하여 날짜 시간 필드 값에서 인스턴스를 생성합니다.

처음에는 java.time에 DateTime 클래스가 있다고 가정할 수 있지만 그렇지 않습니다. 당신이 구글 경우 '자바 시간으로 조다 시간에서 마이그레이션' 당신은 가장 가능성이 스티븐 콜본의 블로그 게시물 조다 시간에서 자바.time로 변환 찾을 수 있습니다.

이것은 당신에게 좋은 시작을 제공하고, 자바.time.zonedDate시간 또는 java.time.OffsetDateTime을 사용하는 방향으로 우리를 가리킵니다. 다음은 어떤 질문을 사용합니까? 아마 존다데이트는 스티븐의 의견에 근거를 둔다.

ZonedDateTime 자바도크를 살펴보면 생성자가 전혀 표시되지 않습니다. 스티븐의 블로그 게시물로 돌아가서 우리는 더 아래로 읽었습니다.

건설. Joda-Time에는 개체를 수락하고 형식 변환을 수행하는 생성자가 있습니다. java.time에는 공장 메서드만 있으므로 문자열에 대해 구문 분석() 메서드가 제공되지만 변환은 사용자 문제입니다.

따라서 정적 공장 메서드가 있어야 하며, 정적 메서드를 검색하여 매우 가깝게 보이지만 정확히 동일하지는 않습니다.

그것은 우리의 원래 Joda-TimeTime 생성기 와 같은 7 int 매개 변수를 가지고 있지만 주의를 기울이지 않으면 중요한 세부 사항을 놓칠 수 있습니다.  7번째 매개 변수는 더 이상 밀리초를 나타내지 않으며, 대신 나노초를 기대하고 있으며, 이는 java.time이 Joda-Time에 비해 정밀도를 높이고 나노 초로 즉시 측정되기 때문입니다. 쉽게 놓칠 수 있는 중요한 세부 사항입니다. 또한 이 방법은 ZoneId를 기대하므로 이전에 필요하지 않은 이유와 왜 지금 필요한지 궁금합니다.

기본 표준 시간대를 사용할 것이라고 언급 한 원래 생성자의 자바도크를 기억하면 기본 ZoneId를 얻을 수있는 방법이 있습니까?

ZoneId용 자바도크는 나열된 생성자에 대해 알려주지 않지만 시스템기본값()을 사용할 수 있는 정적 메서드를 살펴보는 것입니다.

이제 ZoneId를 정리한 지금, 우리는 나노초 변환에 대한 우리의 밀리초에 대해 무엇을해야합니까? 어쩌면 우리는 변환을 수행하기 위해 java.util.cocurrent.TimeUnit을 사용할 수 있습니다.

이 메서드는 긴 반환, 그리고 우리의 방법은 int를 기대, 그래서 지금 우리 뿐만 아니라 해결 하는 변환 문제가 있다. 어쩌면 우리는 간단한 무언가를 시도 할 수 있습니다. 곱셈?

이것은 작동하지만 장소에서 조금 보이지 않습니다. 아직 눈치채지 못했다면 한 줄의 코드를 마이그레이션하는 데 상당한 시간과 노력을 기울였습니다. 그러나 당신이 상상할 수 있듯이, 우리는 손으로 할 수있는 많은 편집을 가지고 있으며, 그것은 더 나아지지 않습니다.

그러나 java.time API에서 좀 더 어려워 보이는 경우 좀 더 유창해 보이는 솔루션을 찾을 수 있습니다.

ZonedDateTime밀리초를 설정할 명백한 방법은 없지만 ChronoField.MILLI_OF_SECOND 임시 필드로 사용하여 (TemporalField 필드, 긴 새 값) 방법을 사용하여 수행 할 수 있습니다.

그리고 자바 문서는 우리를 위해 나노 초로 변환을 수행 할 것이라고 언급 :

값을 설정하는 데 이 필드를 사용하는 경우 값을 곱한 값과 NANO_OF_SECOND 설정하는 것과 동일한 방식으로 수행해야 합니다.

따라서 공장 메서드에서 나노초에 대해 0을 지정한 다음 사용하여 모든 원본 값과 밀리초가 있는 ZonedDateTime을 만들 수 있습니다.

최종 결과를 살펴보면 한 줄의 코드만 변경한 것 같습니다.

‍

더 빠르고 쉽게 마이그레이션할 수 있는 레시피 만들기

Sensei 이 하드 원 정보를 다른 개발자와 공유할 수 있는 방법을 제공합니다. 이러한 모든 요구 사항을 캡처하는 레시피를 만들면 Sensei 마우스 클릭으로 이 마이그레이션을 수행할 수 있습니다.

A Sensei 레시피는 3가지 주요 섹션으로 구성됩니다.

• 메타데이터
• 검색
• 사용 가능한 픽스

우리가 살펴 보자 Sensei 이 호출을 java.time에 상응하는 것으로 마이그레이션하는 데 도움이 되는 레시피(YAML 레시피로도 볼 수 있음).

DateTime foo = 새로운 날짜 시간 (년, 월, dayOfMonth, dayOfMonth, hourOfDay, minuteOfHour, 두 번째OfMinute, 밀리오브초);

메타데이터 섹션

메타데이터 섹션에는 레시피및 사용 방법에 대한 정보가 포함되어 있습니다.

검색 섹션

의 검색 섹션은 Sensei 레시피는 이 레시피에 적용할 코드 요소를 지정합니다.

검색:
인스턴스 만들기:
아르그:
1:
유형: int
2:
유형: int
3:
유형: int
4:
유형: int
5:
유형: int
6:
유형: int
7:
유형: int
아르그카운트: 7
유형: org.joda.time.DateTime

‍

이 검색 섹션에서는 다음과 같은 것을 볼 수 있습니다.

• 인스턴스 만들기 검색, 즉 생성자의 사용. 참고: 사용 가능한 검색 대상이 많이 있습니다.
• 생성자는 7개의 인수를 가져야 하며, 이는 argCount 속성에 의해 지정됩니다.
• args 1-7 은 유형 int이어야한다
• 우리는 유형 org.joda.timeTime의 생성자 찾기

‍

사용 가능한 수정 섹션

사용 가능한 Fixes 섹션에서일치 코드 요소에 적용할 수 있는 하나 이상의 수정 프로그램을 지정할 수 있습니다. 각 수정 에는 여러 작업이 있을 수 있으며, 경우에 따라 2개의 작업을 수행하는 단일 수정 프로그램이 있습니다.

‍

• 수정 의 이름은 'Quickfixes' 메뉴에서 사용자에게 표시되며 사용자가 이 퀵픽스를 적용하면 어떤 일이 일어날지 설명합니다.
• 작업 목록에는 이 퀵픽스에서 수행할 작업이 표시됩니다.
• 다시 작성 작업은 콧수염 템플릿을 사용하여 코드 요소를 다시 작성합니다. 변수 및 문자열 교체 기능을 사용할 수 있습니다.
• 수정할당변수 작업은 이 생성자가 변수에 값을 할당하는 데 사용되고 있는지 확인합니다. 이 경우 이 작업은 형식별로 지정된 유형으로 선언할 변수를 수정합니다.

‍

레시피를 사용하여 코드 변환을 수행합니다.

레시피를 작성하고 활성화하면 코드를 스캔하고 적용할 수 있는 세그먼트를 강조 합니다.

아래 스크린샷에서 대상 생성자가 표시된 것을 볼 수 있습니다. Sensei. 표시된 생성자 위로 마우스를 가져가면 레시피 단축설명설명과 빠른 픽스 옵션이 java.time.zonedDateTime으로 마이그레이션됩니다.

‍

java.time.ZonedDate 퀵픽스로 마이그레이션을 선택하면 레시피에 지정한 작업에 따라 코드가 변환됩니다.

‍

팀 간 일회성 마이그레이션 및 균일한 코딩 관행- Sensei

위의 예제에서 볼 수 있으며, 한 줄의 코드 마이그레이션에는 하드 원 지식이 포함될 수 있습니다. Sensei 이러한 지식을 팀 내에서 공유할 수 있는 실행 가능한 레시피 또는 쿡북으로 전환할 수 있습니다. 일회성 마이그레이션 스프린트를 계획하거나 Joda-Time 코드를 우연히 볼 때 java.time에 대한 점진적인 즉각적인 변환을 수행하는 방법을 취할 수 있습니다. 논리 적 단계 또는 단계에서 마이그레이션을 수행하고 스캔 한 파일의 범위를 확장하거나 줄이는 방법으로 레시피를 활성화 / 비활성화 할 수 있습니다. Sensei - 코드 마이그레이션을 덜 고통스럽게 만드는 유연성.

라이브러리 마이그레이션은 Sensei 을 사용하여 프로젝트를 표준화할 수 있는 다양한 방법 중 하나에 불과합니다. 풀 리퀘스트에서 또는 직접 코딩할 때 자주 접하게 되는 안티 패턴이나 특정 수동 코드 변환을 항상 경계할 수 있습니다. 개발자가 자주 놓치는 코딩 가이드라인이 있다면 가이드라인을 레시피로 변환하여 개발자가 승인된 코드 변환을 안심하고 적용할 수 있도록 할 수 있습니다.

질문이 있으시면, 저희는 여러분으로부터 듣고 싶습니다! 슬랙에 우리와 함께 : sensei-scw.slack.com

개발자, QA, 엔지니어링 리드 또는 AppSec 전문가 등 어떤 식으로든 소프트웨어를 다루는 경우 보안이 업무의 일부입니다. 소프트웨어 취약점을 지적하는 것은 보안 팀의 임무이며, 개발자는 결함 없이 코드를 작성하기 위해 최선을 다하는 것이 개발자의 임무입니다. 그러나 이러한 작업을 가능한 한 효율적이고 효과적으로 수행하려면 모든 당사자가 응용 프로그램이 실행되는 코드를 시작으로 보안 위협에 대해 협력하는 것이 중요합니다. 

그러나 보안 코딩에 대해 효과적으로 배우고 지식을 유지하는 것은 본질적으로 어려워 보일 수 있습니다. 올바른 도구를 사용하면 그럴 필요가 없습니다. 그러나 이해 관계자와 상사가 올바른 종류의 교육에 투자하도록 설득하는 것은 항상 쉬운 일이 아닙니다. 교육은 규정 준수 상자를 똑딱거리는 유일한 목표와 개발자의 일상 업무와 관련이 없는 대부분의 시간으로 선택됩니다. 그러나 개발자가 실시간으로, 언어:프레임 워크에서 보안에 대해 배우고, 그것을 재미있게 할 수 있다면 어떨까요? 그리고 모든 것을 위로? 조직은 동시에 업계 표준을 준수합니다.

우리는 당신의 뒤를 가지고있다. 다음은 개발자 중심의 보안 코딩 교육 프로그램을 통해 동료, 잠재 고객 및 조직 내의 궁극적인 의사 결정권자로부터 충성도를 얻기 위한 몇 가지 전략입니다.   

처음부터 소프트웨어 취약점을 방지하면 헤아릴 수 없는 시간과 비용을 절약할 수 있습니다.

반복되는 보안 문제를 찾거나 보고하거나 해결하는 데 너무 많은 시간을 할애하고 있습니까? 당신은 혼자가 아닙니다. 

다음 시나리오를 상상해 보십시오: AppSec이 취약점을 발견하고 다시 개발로 보고하는 즉시 개발자는 관련 교육 수업에 뛰어들어 해당 결함을 해결하는 방법뿐만 아니라 미래에 동일한 실수를 피하는 방법을 배웁니다. 그 결과는 무엇이라고 생각하십니까? 해당 개발자는 관련성으로 인해 해당 교훈을 기억하고 동일한 오류를 다시 만들 가능성이 줄어듭니다. 즉, 보안 팀에서 작업하는 경우 한 개발자가 무의식적으로 해당 취약점을 다시 만들 가능성이 적고 동일한 개발자가 다시 돌아가고 수정해야 할 가능성이 적습니다.

고객의 콘트라스트 시큐리티(Contrast Security)에서 개발 팀에 대한 강력한 실시간 교육이 얼마나 강력한지 확인하십시오.

모든 개발자가 정기적인 보안 코드 교육에 참여하고 실시간으로 보안 문제에 대해 배울 수 있는 도구를 손끝에서 가지고 있다면 놀라운 소프트웨어를 만들고 보안 프로그램을 작업하기 위해 회복되는 시간은 헤아릴 수 없습니다. 조직이 그런 도구에 투자할 수 있는 아주 좋은 논쟁처럼 들리죠. 

당신이 보안에서 기술 업에 사용하고 싶은 좋은 도구를 발견 한 경우, (기침) Secure Code Warrior, 이것은 조직 내에서 CISO 또는 CTO에 피칭하기위한 좋은 인수입니다. 

역량 강화 된 개발자는 더 나은 결과를 제공하고 더 행복합니다.

시간과 돈은 물론 경영진에게 매우 중요하지만, 직무 만족도도 마찬가지입니다. 만족한 직원들은 더 나은 결과를 제공하고, 더 오래 일자리를 유지하며, 긍정적인 근무 환경에 기여합니다. 그렇기 때문에 커리어 구축과 교육은 비용이 아닌 투자입니다. 그리고 그 훈련이 실제로 재미있고 관련 있는 것을 가르치는 다면? 바로 그곳에서 성공을 위한 황금 티켓입니다. 

좋은 소식은 개발자가 일반적으로 자신의 작업에 얼마나 중요한지 알고 있기 때문에 보안을 배우려는 동기가 높다는 것입니다. 우리는 에반스 데이터 코퍼레이션과의 연구에서 전 세계의 개발자를 대상으로 설문조사를 실시한 결과 개발자가 다음과 같은 이유로 보안을 배우고 싶어한다는 것을 알게 되었습니다. 

1. 생산성과 효율성을 높입니다.
2. 그들은 호기심이 많고 개인적으로 그것에 대해 배우는 데 관심이 있습니다.
3. 안전하지 않은 코드와 관련된 문제를 피하려고 합니다.
4. 그들은 그것이 경력 발전을위한 잠재력을 제공한다는 것을 이해합니다.
5. 그것은 인적 자원의 보다 효율적인 사용입니다
   

(여기에서 전체 백서를 다운로드하십시오 .)

유일한 문제는 가장 안전한 코딩 교육이 그들을 실망시키는 것입니다. 그것은 그들의 일상 업무와 관련이 없으며, 그것을 직면하자, 그것은 명백히 지루합니다. 이러한 기능은 일반적으로 정보를 유지하고 실제로 학습하는 측면에서 좋은 결과를 제공하지 않는 기능입니다. 때 learning platform 그러나 개발자 중심의 재미와 참여감이 있으며 실제 결과를 제공하고 보안 코드를 작성 하려는 권한을 부여받은 개인을 만들 수 있습니다. 그리고 왜 당신의 상사, 그것은 개발 리드 또는 CISO 또는 CTO 개발자가 안전하게 코딩에 관심이 있고 그렇게 할 수있는 기술을 가지고 싶지 않을 까요?

보안 이해는 전반적으로 더 나은 엔지니어를 만든다 

엔지니어가 소프트웨어가 공격에 취약할 수 있는 방법을 이해하면 이를 염두에 두고 작업을 수행합니다. 누군가가 무엇이 잘못될 수 있는지 더 많이 이해할수록 예방 적 접근 법으로 더 많이 작동합니다.

뿐만 아니라 품질이 좋지 않은 코드에는 소프트웨어 취약점이 포함될 가능성이 높으며 개발자가 무의식적으로 해당 코드에 취약점을 도입하는 것이 더 쉽습니다. 왜? 왜냐하면 그들이 하는 일은 코드를 읽고 변경하는 것이기 때문입니다. 해당 코드가 제대로 구성되지 못하고 잘못된 논리를 사용하는 경우 이러한 작업을 수행하는 데 시간이 오래 걸리며 작업을 변경하고 실수로 중요한 보안 버그를 도입하는 것이 더 쉬워집니다.

보안에 대한 이해와 문제를 방지하는 방법에 대해서도 해당 코드의 전반적인 품질과 사고 시 버그를 쉽게 도입할 수 없는 방식으로 코드를 작성하는 방법에 대해 더 열심히 생각할 수 있습니다. 보안 교육은 윈-윈입니다. 개발자는 보안 코딩에 대해 배우지만 그 동안 더 나은 엔지니어가 됩니다. 

숫자에 힘이 있습니다.

보안 코딩을 채택하기 위해 지도자로부터 구매를 얻는 또 다른 훌륭한 전술 learning platform 동료를 승선시키기 위한 것입니다. 보안 지식을 강화하려는 개발자가 많을수록 경영진이나 C-suite에 투자하도록 설득하는 것이 더 쉬워집니다.

그렇다면 어떻게 해야 할까요? 대부분의 개발자가 보안을 더 잘 해야 할 필요성을 이해하고 배우고 싶다는 사실을 감안할 때 너무 어렵지 않아야 합니다. 당신은 또한 그들이 이것을 살펴 볼 수 있습니다 secure code warrior 개발자는 제품을 소개 하고 엿볼 수 있으며 안전한 코딩 기술을 테스트하십시오. 안전하지 않은 코드의 영향을 보고 보안에 대해 배우는 것이 재미있을 수 있다는 것을 알게 되면 더 많은 것을 배울 수 있습니다.

올바른 도구를 채택한 후 개발자가 참여할 수 있는 좋은 방법은 몇 가지 건전한 경쟁입니다. 교육 프로그램을 시작해 보십시오. tournament. 

Nelnet이 어떻게 정말 창의력을 발휘했는지 확인하십시오. tournaments 회사 내에서 보안 문화를 구축할 수 있습니다.

지속적인 보안 교육은 바람직한 기업 문화를 촉진합니다.

훈련은 지루할 필요는 없으며, 실제로는 그렇지 않습니다. 우리는 강의가 비싸고, 조직하기 어렵다는 것을 알고 있습니다 - 특히 분산 된 팀과 함께 - 그리고 당신은 그들로부터 많은 것을 빼앗을 가능성이 낮습니다. 그러나 조직은 규정 준수를 위해 매년 상자를 체크하는 것보다 조금 더 많은 것을 수행하는 개발자에게 안전한 코딩 교육을 계속 제공합니다. 단순히 현상 유지만으로는 더 이상 충분하지 않습니다. 개발 관리자와 AppSec은 게임을 강화하고 함께 협력하여 진행적이고 매력적인 학습을 촉진하는 교육 도구를 구현해야 할 때입니다. 그리고 그것은 의사 결정자를 설득하는 것으로 시작됩니다.

여러 가지 이유로 연속적이고 실습 교육이 필요합니다. 사이버 보안 위협은 끊임없이 진화하고 있으므로 이러한 위협에 대처하기 위한 교육도 지속적으로 발생하는 것은 당연한 일뿐입니다. 뿐만 아니라, 이미 언급했듯이, 우리가 실시간으로 배울 때, 우리는 우리가 배운 것을 보유 할 가능성이 훨씬 더 높습니다. 개발자가 슬라이드쇼에서 배운 것을 컨텍스트에서 기억할 것으로 예상하는 것은 거의 1년 전에 비현실적이기 때문에 보안을 염두에 두고 코딩하는 것은 구현하기 어렵습니다. 그러나 그들이 특정 소프트웨어 취약점을 피하는 방법을 배우는 경우 그것은 그들에게보고되는 순간과 동시에 게임을하는 것처럼 느낀다, 그것은 완전히 새로운 야구 게임이다. 

실무적이고 관련 교육이 시행되자마자 보안은 회사 문화의 일부가 되고 더 이상 사후 고려사항으로 취급되지 않습니다. 소프트웨어 개발 수명 주기시작부터 개발 프로세스에 구이됩니다. 

그래서 당신은 무엇을 기다리고 있습니까? 조직 내 보안을 개선하고 중요한 회사 및 고객 데이터를 보호하기 위한 여정을 시작합니다. 개발자와 상사를 타고 조직의 다음 단계로 안전하게 코딩할 수 있습니다. 처음부터 보안에 대해 생각함으로써 동일한 취약점을 몇 번이고 반복해서 경험하지 마십시오. 

더 많은 리소스가 필요하십니까? ‍

전체 다운로드 "당신의 CISO / CTO 키트를 설득"

10월 초, 아파치는 경로 트래버스 및 원격 코드 실행 취약점 을 해결하기 위해 버전 2.4.49를 출시한 다음 2.4.50으로 수정이 완료되지 않았다는 사실을 해결했습니다. 아파 치가 일부 추정에 의해 인터넷의 25 %를 구동주어진, 이러한 위험을 피하기 위해 최신 버전으로 업데이트의 중요성에 대한 소셜 미디어에 얘기를 보았다. 하지만 거래는 무엇입니까? 여기에 얼마나 많은 위험이 존재합니까?

왜 자신을 시도하지? 

우리는 실제 환경에서 위험을 입증하는 임무를 구축하고 모든 사람이 시도 할 수 있도록 공개했다. 이 미션에서는 경로 트래버스 취약점이 인프라및 애플리케이션에 어떤 영향을 미칠 수 있는지 살펴보겠습니다. 아래를 클릭하여 오른쪽으로 이동하거나 계속 읽으면서 취약점에 대해 자세히 알아봅니다.

경로 트래버스 취약점에 대해 

이 취약점은 새로운 경로 정규화 기능이 도입된 2.4.49 릴리스(URL 정규화 기능변경)에 도입되었습니다. 안타깝게도 URL 인코딩된 경로를 올바르게 정규화하지 못했습니다. 이렇게 하면 다음 구성이 없는 경우 경로 통과 공격을 수행할 수 있습니다.

또한 mod_cgi 활성화하면 원격 코드 실행 취약점으로 활용할 수도 있습니다. 그러나 먼저 무엇이 잘못되었는지 더 잘 이해하기 위해 URL 인코딩을 살펴보겠습니다.

URL 인코딩

가장 기본적인 경우 URL 인코딩이 있는 URL에 대한 고려가 부족하여 취약점이 발생합니다. 새로 도입된 경로 정규화 함수는 점이 URL인코딩된 경우를 완전히 처리하지 못했습니다. 

경로 통과 공격을 수행하려면 시퀀스를 통해 통과해야 합니다 .. /. 그러나 정규화 기능은 이를 제거할 만큼 똑똑합니다. 그래서 당신은 무엇을해야합니까? URL을 인코딩할 수 있습니다 . (점) 아래로 %2e, 같은 순서를 사용 .% 2e /. 그것은 아파치 2.4.40에 대한 많은 경우에 작동합니다. 그러나 한 단계 더 나아가 두 번 인코딩 할 수 있습니다. URL 인코딩 된 버전 .%2e / 는 .%252e /입니다. 이것은 아파치의 시도 된 정상화를 우회 할 수 있었습니다.

그러나 캐치가 있습니다.

누군가가 브라우저에서 바로이 취약점을 악용하려고 하면 성공하지 못할 것입니다. 이는 브라우저가 서버로 전송되는 URL을 정규화하려고 시도하기 때문입니다. 즉, 이중 인코딩된 시퀀스도 제거됩니다. 그것은 또한 우리가 단순히 이것을 보여 주는 브라우저를 사용할 수 없습니다 의미.

cURL을 사용하여 URL을 보내기 전에 URL을 정규화하지 못하도록 하는 -path-as-is 플래그를 사용하여 이를 입증할 수 있습니다.

예방 및 완화

문제를 완전히 방지하려면 아파치의 최신 패치를 최신 상태로 유지하는 것이 중요합니다. 특히 최소한 2.4.51로 업그레이드할 수 있습니다. 그러나 최신 상태를 유지하기 위해 정기적 인 일정에 업그레이드하는 것이 좋습니다.

2.4.49를 실행하는 경우 이 문제를 완화하려면 아파치 구성에 다음 사항을 포함했는지 확인합니다.

또한 원격 코드 실행을 방지하기 위해 mod_cgi 사용하지 않는 경우 mod_cgi 사용하지 않도록 설정합니다.

자신에게 미치는 영향을 경험하세요

정확히 무슨 일이 있었는지 탐구하고 자신을 위해 그것을 시도에 관심이 있으십니까? 

‍

Micha Martinez는 미국 의 대기업인 Nelnet의 사이버 보안 분석가이자 시네마토그래퍼로 학자금 대출 및 교육 금융 서비스의 관리 및 상환을 거래하고 있습니다. 그는 보안 코딩을 중심으로 개발자를 위한 교육 프로그램을 만드는 임무를 맡았을 때, 팀을 참여시키는 창의적인 방법을 모색했습니다. 우리는 그가 그의 보안 코드 교육 프로그램을 실행하는 방법에 너무 감동했다 우리는 더 많은 것을 배우기 위해 그와 함께 앉아. 

결론? 

보안 문화를 조성하고 개발 팀 내에서 내부 보안 챔피언을 육성하여 "선의의 힘이 되십시오." 

"보안 코드에 중점을 두어 회사를 더 강력하고 안전하게 만들 수 있도록 도왔습니다." 

Nelnet에서 Micha와 그의 보안 팀은 처음부터 보안 코드를 구축하는 것의 중요성을 이해했습니다. 그들은 매력적이고 관련성이 있으며 보람있는 방식으로 이를 달성하고 싶었습니다. 그는 보안 코딩에 대한 강한 관심과 숙련도를 가진 개발자를 식별하고 보안 챔피언이 되기 위해 육성함으로써 이러한 챔피언들이 보안 교육 전반에 대한 사고 방식을 바꾸는 촉매제가 되었다는 것을 발견했습니다. 이러한 개인은 피어 투 피어 수준에서 더 많은 도움이 필요한 동료에게 멘토링을 하고 조직 내에서 보안 코드 관행의 변화를 구현하는 리더가 됩니다. 

Micha는 그와 그의 팀이 보안 예방에 관한 사고 방식과 문화를 어떻게 바꾸어 회사를 "더 강하고 안전하게" 만들었는지에 대해 자세히 설명합니다.

그것은 자랑 권리에 대한 모든 ... 취약성 감소

Micha는 평균 보안 교육 프로그램을 실행하지 않습니다. 그는 경쟁과 그의 영화 촬영 재능을 사용하여 tournaments 매우 매력적이고 성공적입니다. 개발자가 얻는 것은 관련성이 높고 실용적인 지식으로 인해 보안 코드가 강화됩니다. 

제품이 더욱 안전해지고 소프트웨어 취약점에 대한 더 높은 수준의 보호를 제공함에 따라 비즈니스도 승리합니다. 소프트웨어 보안을 학습하는 것은 상자를 확인하는 것보다 조금 더 많은 전형적인 지루한 학습 경험이 될 필요가 없습니다. 개발자는 몰입감과 도전적인 교육 경험뿐만 아니라 일상 업무와 관련된 교육 경험을 원합니다. 

그가 통해 안전한 코딩 훈련을 만드는 방법에 대한 미카 이야기 보기 tournaments 상으로 라 레슬링 매니아를 물리적 챔피언 벨트를 포함. 그의 팀을 위해 보안을 유지하기 위해 조금 건강한 경쟁입니다. 

누가 자랑스러운 권리를 사랑하지 않습니까? 

‍

보안 코딩을 중심으로 한 문화를 포용... 도구가 충분하지 않습니다.

미카는 그가 추천하는 이유에 대한 마지막 생각으로 우리를 떠났다 Secure Code Warrior. 이 플랫폼은 예방 문화와 적극적인 학습을 만들어 준 차량이었습니다. 교육 프로그램을 구축하고 훈련하고 잘 수행하는 개발자에 투자하는 데 시간이 걸렸습니다. 각 개발자의 기술을 구축하여 코딩에 대한 예방 적 접근 방식을 채택하려면 혁신적인 문화가 필요합니다. 

보안 코딩 문화를 포용하는 것이 왜 마이카에서 더 많은 차이를 만드는지에 대한 자세한 내용은 Secure Code Warrior.

Secure Code Warrior 몰입감 있고 매력적인 보안 코딩 제공 learning platform 개발자를 위한 것입니다. 데모에 관심이 있으십니까? 아래에서 예약하세요. 

이 점점 더 혼란 스러운 세계에서, 항상 사람들이 안정적으로 믿을 수 있는 몇 가지 상수가 있다: 태양 아침에 상승 하 고 밤에 다시 설정, 마리오 는 항상 소닉 고슴도치 보다 쿨러 될 것입니다., 그리고 주입 공격 항상 오픈 웹 응용 프로그램 보안 프로젝트 (OWASP) 공격자 적극적으로 악용 하는 상위 10 개의 가장 일반적이고 위험한 취약점의 목록에서 상위 자리를 차지 합니다.

음, 태양은 내일 상승 할 것이다, 마리오는 여전히 소닉에 "원 업"을 가지고 있지만, 주입 공격은 악명 높은 OWASP 목록에 1 위 자리에서 떨어졌다, 에서 새로 고침 2021. 공격의 가장 오래된 형태 중 하나, 주입 취약점은 컴퓨터 네트워킹만큼 거의 주변되었습니다. 일괄 취약점은 기존의 SQL 주사부터 OGNL(개체 그래프 탐색 라이브러리)에 대해 시작된 악용에 이르기까지 광범위한 공격을 담당합니다. OS 명령 주입 기술을 사용하여 서버에 대한 직접 공격을 포함하기도 합니다. 잠재적으로 공격할 수 있는 장소의 수는 말할 것도 없고 공격자에 대한 사출 취약점의 다양성은 이 카테고리를 수년 동안 상위 권에 보관해 왔습니다.

그러나 주사 왕은 떨어졌다. 긴 왕을 살고. 

우리가 마침내 주입 취약점 문제를 해결했다는 것을 의미합니까? 안 돼. 그것은 보안 적 번호 1로 그것의 위치에서 멀리 떨어지지 않았다, 단지 OWASP 목록에 3 에 아래로. 그것은 주입 공격의 지속적인 위험을 과소 평가하는 실수 가 될 것입니다,하지만 다른 취약점 범주가 그것을 능가 할 수 있었다는 사실은 중요하다, 그것은 새로운 OWASP 최고 개가 실제로 얼마나 광범위 한 보여줍니다 때문에, 왜 개발자는 앞으로 이동에 주의를 기울여야.

그러나 가장 흥미로운 점은 OWASP Top 10 2021이 새로운 카테고리로 데뷔하는 중요한 정밀 검사를 반영한다는 것입니다: 안전하지 않은 디자인, 소프트웨어 및 데이터 무결성 오류, 커뮤니티 설문조사 결과: 서버 측 요청 위조. 이는 아키텍처 취약성에 대한 관심이 증가하고 소프트웨어 보안의 벤치마크를 위한 표면 수준 버그를 넘어서는 것을 가리킵니다.

깨진 액세스 컨트롤은 크라운을 차지합니다(추세를 밝힙니다)

OWASP 상위 10개 취약점 목록의 5위 자리에서 현재 1위까지 의 액세스 제어가 끊어졌습니다. 주입 및 안전하지 않은 디자인과 같은 새로운 항목과 마찬가지로 침입된 액세스 취약점은 광범위한 코딩 결함을 포괄하므로 여러 전선에서 손상을 줄 수 있기 때문에 모호한 인기를 추가합니다. 이 범주에는 사용자가 의도한 권한 밖에서 행동할 수 있도록 액세스 제어 정책을 위반할 수 있는 모든 인스턴스가 포함됩니다. 

OWASP가 취약점 패밀리를 상위 지점으로 승격시키는 데 인용한 액세스 제어가 깨진 예로는 공격자가 URL, 내부 응용 프로그램 상태 또는 HTML 페이지의 일부를 수정할 수 있는 액세스 권한이 포함됩니다. 또한 사용자가 기본 액세스 키를 변경하여 응용 프로그램, 사이트 또는 API가 권한이 높은 관리자와 같은 다른 사람이라고 생각하도록 허용할 수도 있습니다. 심지어 공격자가 메타데이터를 수정하지 못하도록 제한되지 않는 취약점을 포함하며 JSON 웹 토큰, 쿠키 또는 액세스 제어 토큰과 같은 항목을 변경할 수 있습니다.

악용되면 공격자가 파일 또는 개체 권한을 우회하거나 데이터를 도용하거나 데이터베이스 삭제와 같은 파괴적인 관리자 수준 기능을 수행하는 데 이 취약점 제품군을 사용할 수 있습니다. 이렇게 하면 액세스 제어가 점점 더 일반화되는 것 외에도 액세스 제어가 매우 위험합니다.

인증 및 액세스 제어 취약점이 공격자가 악용할 수 있는 가장 비옥한 근거가 되고 있다는 것은 그리 흥미롭습니다. Verizon의 최신 데이터 유출 조사 보고서에 따르면 액세스 제어 문제는 거의 모든 산업, 특히 IT 및 의료 분야에서 만연하고 있으며, 모든 위반의 무려 85%가 인간의 요소를 포함하고 있습니다. 이제 "인간 요소"는 엔지니어링 문제가 아닌 피싱 공격과 같은 사건을 다루지만 위반의 3 %는 악용 가능한 취약점을 포함했으며 보고서에 따르면 주로 오래된 취약점과 보안 오구성과 같은 인적 오류 주도였습니다.

XSS 및 SQL 주입과 같은 보안 버그가 개발자를 계속 방문하는 동안 핵심 보안 설계가 실패하고 있으며, 특히 특정 버전의 응용 프로그램의 보안 결함이 공개된 후 패치를 해제한 경우 위협 행위자에 매우 유리할 수 있는 아키텍처 취약점에 대한 방법을 제공합니다. 

문제는, 몇몇 엔지니어는 기본을 넘어 교육 및 기술 개발을 부여하고, 적은 여전히 진정으로 자신의 지식과 실용적인 응용 프로그램은 일반적으로 개발자가 처음에 도입 된 지역화, 코드 수준 버그를 넘어 확장하고 있다.

로봇이 거의 찾을 수 없는 버그 방지

새로 그룹화된 액세스 제어 취약점 제품군은 매우 다양합니다. 액세스 중단 컨트롤의 몇 가지 구체적인 예와 YouTube 채널 및 블로그에서이를 중지하는 방법을 찾을 수 있습니다.

그러나, 나는이 새로운 OWASP 탑 10을 축하하는 것이 중요하다고 생각합니다. 실제로 스캐너가 반드시 픽업하지 않는 공격 벡터를 포함하는 더 넓은 범위의 공격 벡터를 포괄하는 것이 더 다양합니다. 발견 된 모든 코드 수준의 약점에 대해, 더 복잡한 건축 결함은 무기고에 얼마나 많은 자동 방패와 무기가 상관없이, 보안 기술 스택의 대부분에 의해 주목 갈 것이다. OWASP Top 10 목록의 사자 점유율은 여전히 스캔 데이터를 기반으로 컴파일되지만, 안전하지 않은 설계 및 데이터 무결성 오류를 다루는 새로운 항목은 개발자를 위한 교육 지평을 빠르게 확장하여 로봇이 할 수 없는 것을 달성해야 한다는 것을 보여줍니다.

간단히 말해서 보안 스캐너는 큰 위협 모델러를 만들지 는 않지만 보안 숙련 된 개발자 팀은 모범 사례와 비즈니스의 요구사항과 함께 보안 IQ를 인라인으로 성장시킴으로써 AppSec 팀을 헤아릴 수 없을 정도로 도울 수 있습니다. OWASP Top 10이 우수한 기준이지만 위협 환경이 너무 빠르게 진행되고 있다는 이해와 함께 좋은 보안 프로그램으로 고려해야하므로 개발자가 보안을 강화하면서 더 깊고 구체적으로 나아갈 계획이 있어야 합니다. 그렇게 하지 않으면 필연적으로 조기에 수정할 기회를 놓치고 인간이 주도하는 예방적 사이버 보안에 대한 성공적인 전체론적 접근 방식을 방해할 수 있습니다.

‍

우리는 OWASP 탑 10 2021 준비, 그리고 그건 시작에 불과! 오늘 높은 보안 기술 경로에 개발자를 시작합니다.

사이버 위협 환경은 날이 갈수록 복잡해지고 있습니다. 공격자는 취약한 애플리케이션, 프로그램, 클라우드 인스턴스에 대한 네트워크를 지속적으로 스캔하고 있으며, 이달의 최신 맛은 API로, 종종 느슨한 보안 제어 덕분에 쉽게 승리할 수 있는 것으로 널리 간주됩니다. 너무 영구적이어서 배포 후 몇 시간 내에 새 앱이 손상되고 악용될 수 있습니다. Verizon 2021 데이터 유출 조사 보고서는 기업과 조직에 대해 평준화 된 위협이 오늘날 역사상 다른 어느 시점보다 더 위험하다는 것을 매우 분명하게 합니다.

생성되는 소프트웨어를 진정으로 보호하는 유일한 방법은 보안 코드에 기반을 두는 것이 아니라는 것이 매우 분명해지고 있습니다. 즉, 위협 행위자 침공을 막는 가장 좋은 방법은 애초에 응용 프로그램에 대한 발판을 거부하는 것입니다. 일단 당신이 그 전쟁을 시작 하면, 장점의 대부분은 공격자쪽으로 왜곡 됩니다.

이러한 상황은 먼저 민첩한 개발과 DevOps를 일으켰으며, 나중에는 개발에서 배포에 이르는 소프트웨어를 만드는 과정에 관련된 모든 사람에게 보안이 공유된 책임이 있는 전체 DevSecOps 이동에대한 책임을 발생시켰습니다. 그러나 그 피라미드의 기초, 그리고 틀림없이 가장 중요한 부분은 개발자입니다. 대부분의 개발자는 자신의 역할을 하고 보안 코드를 작성하기를 원하지만, 작업하는 많은 조직은 우선 순위의 큰 변화에 대한 지지가 적습니다.

디자인에 의한 패배

수년 동안 개발자들은 조직에서 그들의 주요 역할은 비즈니스가 멈추지 않으며 고객이 잠들지 않는 빠르게 진행되는 환경에서 앱을 신속하게 구축하고 배포하는 것이라고 들었습니다. 개발자가 코딩할수록 더 많은 기능을 배포할 수록 성능 검토 측면에서 더 가치 있는 기능을 볼 수 있습니다.

보안은 사후 고려, 그것은 전혀 고려 된 경우. 대신, 이 모든 것을 알아내기 위해 AppSec(응용 프로그램 보안) 팀에 맡겨졌습니다. AppSec 팀은 대부분의 개발자가 보안 패치를 적용하거나 취약점을 수정하기 위해 코드를 다시 작성하기 위해 완료된 응용 프로그램을 다시 개발로 보내기 때문에 싫어했습니다. 그리고 개발자가 이미 "완료"된 앱에서 작업하는 데 보낸 매 시간마다 새로운 앱과 기능을 만들지 않은 시간이었기 때문에 성능과 그 가치는 특히 징벌적 인 회사의 눈에 저하되었습니다.

그리고 위협 환경은 대부분의 기업의 보안의 중요성과 우선 순위를 변경했습니다. IBM과 Ponemon 연구소의 최근 데이터 유출 보고서 비용에 따르면, 평균 사이버 보안 위반은 이제 사건 당 약 380 만 달러의 비용이 들지만, 이는 거의 상한선입니다. 한 회사에서만 네트워크 위반으로 13억 달러의 손실을 입었습니다. 오늘날의 회사들은 DevSecOps가 제공하는 보안을 원하지만 슬프게도 그 전화에 응답하는 개발자에게 보상하는 것이 느렸습니다.

단순히 개발 팀에게 보안이 작동하지 않습니다 생각하라고 말하는 것만으로는 특히 속도만으로 인센티브를 받고 있는 경우 작동하지 않습니다. 사실, 이러한 시스템 내에서 보안에 대해 배우고 코드를 보호하는 데 시간이 걸리는 개발자는 실제로 보안이 덜 인식된 동료가 계속 벌고 있는 더 나은 성능 검토및 수익성 있는 보너스를 잃을 수 있습니다. 그것은 거의 회사가 무의식적으로 자신의 보안 실패에 대한 시스템을 조작하고, 개발 팀에 대한 자신의 인식으로 돌아갑니다. 그들이 그들을 보안 최전선으로 보고 있지 않다면, 인력을 활용하는 실행 가능한 계획이 결실을 맺을 가능성은 매우 낮습니다.

그리고 이것은 심지어 훈련의 부족에 대한 설명하지 않습니다. 일부 매우 숙련 된 개발자는 수십 년 동안 코딩 경험했지만 보안에 관해서는 거의 없습니다 ... 결국, 그것은 그들에게 결코 필요하지 않았습니다. 회사가 숙련 된 프로그래머에게 좋은 교육 프로그램을 제공하지 않는 한 개발자가 갑자기 새로운 기술을 습득하고 취약점을 적극적으로 줄이는 의미있는 방식으로 행동에 나설 것으로 기대할 수는 없습니다.

좋은 보안 관행에 대한 개발자에게 보람

좋은 소식은 개발자의 압도적 인 대다수가 도전과 보람을 모두 발견하기 때문에 자신의 일을하고, 그들은 자신의 위치가 수반 되는 존경을 즐기기 때문에. 평생 전문 코더 마이클 Shpilt는 최근 자신의 개발 작업에 그와 그의 코딩 동료동기모든 것들에 대해 썼다. 예, 그는 그 인센티브 중 금전적 보상을 나열하지만, 놀랍게도 목록 아래로 멀리입니다. 대신, 그는 새로운 무언가를 창조하고, 새로운 기술을 배우고, 자신의 작품이 다른 사람들을 돕기 위해 직접 사용될 것이라는 것을 아는 만족의 스릴을 우선시합니다. 그는 또한 자신의 회사와 지역 사회 내에서 가치를 느끼고 싶다고 이야기합니다. 요컨대, 개발자는 자신의 작품에 자부심을 가지고 좋은 사람들의 많은 처럼.

Shpilt 와 다른 개발자는 위협 행위자가 코드를 손상시키고 회사 또는 도움을 주려는 사용자에게 해를 끼치기를 원하지 않습니다. 그러나 지원 없이는 우선 순위를 보안으로 갑자기 전환할 수 없습니다. 그렇지 않으면 시스템이 그들에 대해 작동하는 것과 거의 같습니다.

개발 팀이 사이버 보안 역량을 향상시킬 수 있도록 먼저 필요한 기술을 가르쳐야 합니다. 스캐폴드 학습과 Just-in-Time(JiT) 교육과 같은 도구를 사용하면 이 프로세스가 훨씬 덜 고통스럽고 올바른 맥락에서 기존 지식을 구축하는 데 도움이 됩니다. 

JiT의 원칙은 개발자가 프로그래머가 안전하지 않은 코드를 만들고 있음을 감지하거나 실수로 응용 프로그램에 취약점을 도입하는 경우 개발자가 적절한 시기에 적절한 지식을 제공한다는 것입니다. 그리고 나중에 동일한 기능을 수행하기 위해 보다 안전한 코드를 작성하는 방법.

그 자리에 업스킬링에 대한 노력의 도움으로, 속도에 만 기초하여 개발자를 평가하는 기존의 방법을 제거해야합니다. 대신, 코더는 보안 코드를 만드는 능력에 따라 보상을 받아야하며, 최고의 개발자는 팀의 나머지 팀이 기술을 향상시키는 데 도움이되는 보안 챔피언이됩니다. 그리고 그 챔피언은 회사 명성과 금전적 보상으로 보상해야합니다. 또한 개발자는 일반적으로 보안에 대한 긍정적인 경험이 없으며, 자신의 관심사에 대해 이야기하는 긍정적이고 재미있는 학습및 인센티브로 고양하는 것은 지식 유지와 구축 기술을 유지하려는 욕구를 보장하는 데 먼 길을 갈 것입니다.

기업은 여전히 개발자 평가의 일부로 코딩 속도를 포함할 수 있지만, 특히 코더가 새로운 기술을 배우고 있기 때문에 보안 응용 프로그램을 개발하는 데 조금 더 오래 걸릴 수 있다는 기대가 있습니다.

DevSecOps는 점점 더 위험한 위협 풍경의 어두운 예술에 대한 궁극적 인 방어가 될 수 있습니다. 이 새로운 세계의 챔피언, 지속적으로 새로운 코드를 만드는 개발자는 존중하고 자신의 작품에 대한 보상이 필요하다는 것을 잊지 마세요.

전 세계의 다른 개발자에 대한 테스트에 보안 기술을 넣어 싶어? 체크 아웃 Secure Code Warrior'의 Devlympics 2021, 그리고 당신은 우리의 글로벌에서 주요 상을 취할 수 있습니다 tournaments!