방금 다시 일어 났기 때문에 내 좌절감은 항상 높습니다. CVE-2022–29622: (In)vulnerability Analysis 라는 제목의 이전 분석을 읽었다면 내가 말하는 내용을 의심할 수 있습니다. 같은 이야기, 다른 피해자. 그러나 이 경우 날짜가 중요합니다. 이전 무적 분석은 2022년부터, 오늘은 2018년의 또 다른 문제를 분석하겠습니다.

"왜 2018년의 일을 처리해야 합니까?" 훌륭한 질문입니다! Sonatype의 OSS Index에서 취약성 정보를 가져오기 위해 최근에 Dependency Track을 활성화했기 때문입니다.

오늘 은 취약한 구성 요소가 있는지 확인하기 위해 SCA 를 훑어보았고 , 그런 경우 수정 작업의 우선 순위를 지정했습니다. 나는 매우 놀라운 것을 발견했습니다. Koa.JS 에 치명적인 취약점이 있다?! 평소 "#FFS, 일주일 내내 정리가 필요해. 저번에 있었던 일을 기억하시나….”

그래서 그렇게 했습니다. 우선, 제목은 2018년에 "문제"가 발견되었음을 분명히 합니다. 지금, 여전히 유지 관리되는 라이브러리에 취약점이 있고 최신 버전으로 계속 업그레이드하는 이유는 무엇입니까? 이 시점에서 내 두뇌의 조사 부분이 시작되었습니다.

이 시점에서 우리는 무엇을 알 수 있습니까?

1. 2018년에 Koa에 심각한 심각도가 할당된 취약점이 있었다고 합니다.
2. Sonatype OSS Index 및 Dependency Track에 따르면 최신 버전의 Koa를 실행하는 동안 2022년에 이 문제가 영향을 받습니다.

• "취약점"의 영향을 받은 Koa.JS 라이브러리 버전
• 최신 Koa.JS에 "취약점"이 존재하는 경우

이슈 분석

"취약점"이 무엇인지 살펴보겠습니다. 여기 에서 GitHub의 관련 문제 #1250을 빠르게 링크하겠습니다 . 분석할 수 있도록 아래 예제(PoC?)를 복사하여 붙여넣겠습니다.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

"웹 애플리케이션 또는 웹 서비스 개발자로서 내 웹사이트를 방문하면 원하는 곳으로 브라우저를 리디렉션할 수 있습니다."

위의 코드가 의미하는 바입니다. 위의 PoC에는 악의적인 행위자가 무엇이든 악용할 수 있는 공격 벡터가 없습니다.

이 비취약성에 대한 적절한 "PoC" 를 제공하려는 경우 (예, 방금 말씀드렸습니다) 다음과 같이 표시됩니다.

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

XSS 취약점에 대해 말하자면, 내가 vector매개변수 값으로 입력한 것이 HTML 컨텍스트에서 안전하지 않게 표시되면 내가 구현한 응용 프로그램은 Cross Site Scripting에 취약할 것입니다. (나중에 자세히 설명)

Sonatype이 이것을 제시한 방법을 확대하고 좀 더 자세히 분석합니다.

"Cross-Site Scripting으로 이어지는 Open Redirect"? 우선, 열린 리디렉션이 없었습니다. 열어야만 열리는데 두 PoC(원본과 내 것)의 차이가 이를 명확하게 보여줍니다. 첫 번째는 공격 벡터가 없었기 때문에 열린 리디렉션이 없었습니다. 내 PoC에는 공격 벡터가 있고 필터링이 없으므로 열린 리디렉션이 있었습니다. 그러나 보시다시피 공개 리디렉션이 있는지 여부는 Koa.JS가 아니라 개발자인 저에게 달려 있습니다. 더 좋은 점은 리디렉션이 있는지 여부도 나에게 달려 있다는 것입니다. 안전하지 않은 방식으로 리디렉션 URL에 사용자 제공 입력을 포함할지 여부도 나에게 달려 있습니다. 그렇다면 우리는 어떤 Koa.JS 취약점에 대해 이야기하고 있습니까? 기술적으로는 취약점이 없었고 누군가 여전히 위험 심각도를 할당했습니다. 정확히 전문적이지는 않습니다.

어쨌든 적절한 PoC에 의해 구현된 "취약점"을 "이용"합시다. 포트 3000에서 이미 수신 대기 중인 항목이 있으므로 서비스 포트를 3000에서 4444로 변경해야 했습니다.

Location응답 헤더에 값이 있는 것을 볼 수 있습니다 javascript:alert(1). 그런 다음 브라우저가 다음으로 리디렉션됩니다.

흥, 난 안전해! 경고창이 뜨지 않았습니다. 예, 쿼리 매개변수 https://google.com의 값으로 입력 vector하고 Google로 리디렉션할 수 있으므로 내 애플리케이션(PoC) 은 오픈 리디렉션에 취약하지만 Koa 때문이 아니라 필터링되지 않은 사용자 데이터를 ctx.redirect. 내가 걱정하는 것이 아닙니다. 절대 이런 일을 하지 않을 것입니다.

GitHub의 문제 의견에서 주목해야 할 중요한 사항은 다음과 같습니다.

이 문제는 Koa가 리디렉션 응답의 본문에 HTML 하이퍼링크를 인쇄하고 크로스 사이트 스크립팅 공격을 유발할 수 있다는 사실에서 비롯됩니다.

아, 그게 좀 더 이해가 가네요! 여전히 그런 것인지 봅시다.

아니요, 더 이상 그렇지 않습니다. 응답 본문이 없습니다. 이 "취약점"이 나에게 영향을 미치지 않는다는 결론을 내릴 수 있을 것 같습니다. 의존성 추적에서 거짓 긍정으로 표시할 수 있습니다.

컨텍스트 분석

나는 모든 보안 전문가가 채택하고 "문제"를 보고하기 전에 수행할 "컨텍스트 분석"을 제안합니다. 이것이 또 다른 예가 되어 어떻게 수행되는지 보여줍니다. ( CVE-2022–29622: (In)vulnerability Analysis 를 읽는 것이 좋습니다 . 컨텍스트의 중요성을 훨씬 더 잘 설명하기 때문입니다.)

1. Koa.JS 기본 제공은 사용자를 어디로도 리디렉션하지 않습니다. 따라서 Sonatype OSS Index에서 명시한 "Open Redirect"가 있고 없었습니다.
2. GitHub에서 제공되는 "PoC"를 기반으로 개발자가 XSS로 이어질 수 있는 어리석은 일을 할 수 있는 기회가 있었습니다. 그러나 위의 #1을 참조하십시오. Koa.JS는 자체적으로 리디렉션을 수행하지 않았습니다. 아래 #2를 참조하십시오.
3. 보고된 "취약점"이 존재하려면 개발자가 안전하지 않은 방식으로 애플리케이션을 구현해야 합니다. 이것은 Koa.JS가 더 잘할 수 있었지만 취약하다고 말할 수 없다는 것을 의미합니다. 문맥상 부적절합니다. 문제의 취약점 은 안전하지 않게 구현된 웹 애플리케이션에만 존재할 수 있습니다 .

이와 같은 상황이 어떻게 가장 잘 처리되는지 예를 들어 보겠습니다. Swagger Parser에 제출한 이 문제 와 전달 방법을 살펴보세요 . 문제 보고서를 분석해 보겠습니다.

1. 제목은 "안전하지 않은 확인자 동작"입니다. 제목에서 LFI(Local File Inclusion)에 대해 말하는 것이 아닙니다. IF I MESS TINGS UP 에 로컬 파일이 포함될 가능성이 있기는 하지만 내가 무엇을 작업하고 어떻게 작업하는지 아는 것은 개발자인 나에게 달려 있기 때문입니다. 기본 동작은 안전하지 않았습니다(아마도 여전히). 그러나 내가 관여하지 않는 도서관은 그 자체로 아무 일도 하지 않을 것입니다.
2. 그런 다음 내가 말하는 라이브러리의 버전을 명확하게 설명합니다. 라이브러리의 안전하지 않은 기본 동작이 애플리케이션에 영향을 미치는 조건을 나열하여 컨텍스트를 더욱 명확하게 만듭니다. 이를 통해 라이브러리 자체는 취약하지 않지만 개발자를 돕기 위해 개선할 수 있는 안전하지 않은 동작이 있음을 분명히 알 수 있습니다.
3. 이제 컨텍스트가 설정되었으므로 작동하는 PoC, 취약한 코드 스니펫(PoC로 작성했으며 Swagger Parser의 일부가 아닙니다!) 및 안전하지 않은 라이브러리.
4. 몇 가지 조사를 했고 개발자로서 실제로 문제를 완화하는 방식으로 라이브러리를 구성할 수 있음을 발견했습니다. (어느 정도) 나는 이것을 devs와 공유했습니다. 다른 것이 없다면 최소한 문서를 업데이트하여 인식을 높일 수 있습니다.
5. 추가 컨텍스트, 분석 및 개선 방법에 대한 예를 제공했습니다.

결론

우선 Sonatype은 OSS 인덱스를 더 잘 수행하고 데이터베이스의 각 취약점에 대해 버전 정보를 사용할 수 있는지 확인해야 합니다. 그것이 최소한의 것입니다. (데이터베이스에서 이 특정 항목을 완전히 제거하면 보너스 포인트가 생깁니다.)

종속성 추적이 FOMO로 인해 어려움을 겪고 있는 것 같아서 버전 번호를 사용할 수 없는 경우 순전히 구성 요소 이름 일치를 기반으로 문제를 보고할 의향이 있습니다. 나는 그들이 치명적인 취약점을 놓칠 위험이 없다는 것을 어느 정도 이해합니다. 이 동작(가양성)의 문제는 소프트웨어 구성 분석의 채택을 권장하지 않는다는 것입니다. 정적 코드 분석의 오탐지처럼 개발자를 놀라게 할 것입니다. 비생산적입니다.

문맥! 피비린내 나는 맥락, 사람들! 내가 제안:

1. 모든 보안 전문가가 채택하고 "문제"를 보고하기 전에 수행되는 "컨텍스트 분석"
2. "취약성"과 "안전하지 않은 행동" 구별
3. 소프트웨어 라이브러리와 애플리케이션/서비스의 차이점 이해