코더는 보안을 정복 : 공유 및 학습 시리즈 - CRLF 주입

게시일: 2019년 7월 25일
by Jaap Karan Singh
사례 연구

코더는 보안을 정복 : 공유 및 학습 시리즈 - CRLF 주입

게시일: 2019년 7월 25일
by Jaap Karan Singh
리소스 보기
리소스 보기

이 블로그 나 이와 같은 기사로, 독자는 문장 부호에 의해 지원됩니다. 예를 들어, 마침표는 문장이 끝나는 위치를 독자에게 알리고, 쉼표는 목록에 문서를 분리하거나 별도의 아이디어를 돕기 위해 하드 일시 정지를 삽입합니다. 잘 쓰여진 블로그 (이 블로그와 같은)를 사용하면 문장 부호는 거의 보이지 않는 데, 우리 모두가 수년 전에 처리하도록 배운 표준 배경 코드의 일부일 뿐입니다.

그러나 해커가이 문서에 들어가서 잘못된 장소에 이상한 문장 부호를 삽입하면 어떻게됩니까? 이런 식으로:

없이, 심지어! 변경. 텍스트입니다. 술래? 깡통. 그것을 확인! 많은? 어렵게. 받는 사람? 프로세스! , 정보!

즉, 기본적으로 CRLF 주입 공격으로 일어나는 일입니다. CRLF 문자는 회선의 종료를 기록하기 위해 개별적으로 또는 함께 사용되는 캐리지 리턴 및 선 피드를 나타냅니다. 공격자가 CR 또는 LF 코드를 기존 응용 프로그램에 삽입할 수 있는 경우 동작을 변경할 수 있습니다. 효과는 대부분의 공격에 비해 예측하기 쉽지만 대상 조직에 덜 위험할 수 있습니다.

이 에피소드에서 우리는 배울 것입니다 :

  • 공격자가 CRLF 주입을 트리거하는 방법
  • CRLF 주사가 위험한 이유
  • 이 취약점을 해결할 수 있는 기술입니다.

공격자는 CRLF 주입을 트리거하는 방법은 무엇입니까?

CRLF 문자를 기존 코드에 주입하고 특정 결과를 생성하려고 시도하는 것은 불가능하지는 않지만 다소 어렵습니다. 공격자가 운영 체제 및 대상 시스템의 다른 요인에 따라 다른 CRLF 조합을 사용해야 하기 때문에 더 어려워졌습니다. 예를 들어 최신 Windows 컴퓨터는 CR과 LF가 모두 라인을 종료해야 하며 Linux에서는 LF 코드만 필요합니다. HTTP 요청은 항상 라인을 종료하려면 정확한 CRLF 코드가 필요합니다.

그러나 CRLF 공격은 구현하기 어렵고 결과를 예측하기가 더 어렵다는 사실 외에도 다른 주입 유형 공격과 거의 동일한 방식으로 시작됩니다. 악의적인 사용자는 단순히 웹 사이트 또는 응용 프로그램의 모든 영역에 데이터를 입력하면 일반 입력 데이터가 아닌 CRLF 코드를 입력합니다.

예를 들어 공격자는 캐리지 리턴(%0d)을 나타내는 ASCII 코드를 입력한 다음 HTTPS 헤더 끝에 있는 라인 피드(%0a)에 대한 ASCII를 입력할 수 있습니다. 그런 다음 전체 쿼리가 다음과 같습니다.

https://validsite.com/index.php?page=home%0d%0a

데이터가 소독되거나 필터링되지 않으면 위의 코드에서 대상 응용 프로그램 또는 웹 사이트에서 몇 가지 이상한 일이 발생할 수 있습니다.

CRLF 주사가 위험한 이유는 무엇입니까?

CRLF 주입 공격은 대부분의 공격보다 덜 정확하지만 적어도 일부 시간은 상당히 위험할 수 있습니다. 로우 엔드에서 추가 줄을 추가하면 로그 파일을 엉망으로 만들 수 있으며, 이로 인해 자동 사이버 보안 방어가 트리거되어 관리자에게 문제가 되지 않습니다. 그러나 동시에 발생하는 실제 침입에서 리소스를 전환하는 데 사용할 수 있습니다.

그러나 CRLF 공격은 직접적으로 손상될 수 있습니다. 예를 들어 응용 프로그램이 명령을 수락한 다음 특정 파일을 검색하도록 설계된 경우 쿼리에 CRLF 코드를 추가하면 응용 프로그램이 해당 프로세스를 숨기지 않고 화면에 표시하여 공격자에게 유용한 정보를 제공할 수 있습니다.

CRLF 주사를 사용하여 응답 분할 공격이라고 하는 것을 만들 수 있으며, 여기서 줄 코드의 끝이 유효한 응답을 여러 조각으로 분해합니다. 따라서 추가 코드를 삽입하는 데 사용할 수 있는 CRLF 코드 후 해커가 헤더를 제어할 수 있습니다. 또한 공격자가 자신의 코드를 완전히 주입할 수 있는 개구부를 만들고 CRLF 공격으로 인해 부서진 부품 에 따라 모든 라인에서 다른 형태의 공격을 트리거할 수도 있습니다.

CRLF 주입 취약점 제거

이 시리즈에서 가져갈 키 메시지가 하나 있다면 사용자 입력을 신뢰하지 마십시오. 이 시리즈에서 다루고 있는 대부분의 취약점에는 사용자 입력 영역이 어떤 식으로든 포함되었으며 CRLF 주입 결함도 예외는 아닙니다.

사용자가 입력할 수 있는 모든 지점에서 응용 프로그램 이나 서버에서 잘못 해석될 수 있는 승인되지 않은 코드의 삽입을 방지하기 위해 필터를 적용해야 합니다. CRLF 공격의 경우 HTTP 헤더를 잠그는 것이 특히 중요하지만 GET 및 POST 매개 변수 또는 쿠키도 잊을 수 없습니다. CRLF 코드가 추가 주사를 트리거하는 데 도움이되지 않도록 특별히 차단하는 한 가지 좋은 방법은 HTML 인코딩을 사용자의 브라우저로 다시 보낸 모든 것에 적용하는 것입니다.

CRLF 주사에 대한 자세한 정보

추가 읽기를 위해, 당신은 OWASP CRLF 주사에대해 말하는 것을 살펴 볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

리소스 보기
리소스 보기

저자

야프 카란 싱

더 알고 싶으신가요?

블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.

Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.

블로그 보기
더 알고 싶으신가요?

개발자 중심 보안에 대한 최신 연구 보기

광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.

리소스 허브

코더는 보안을 정복 : 공유 및 학습 시리즈 - CRLF 주입

게시일: 2019년 7월 25일
Jaap Karan Singh

이 블로그 나 이와 같은 기사로, 독자는 문장 부호에 의해 지원됩니다. 예를 들어, 마침표는 문장이 끝나는 위치를 독자에게 알리고, 쉼표는 목록에 문서를 분리하거나 별도의 아이디어를 돕기 위해 하드 일시 정지를 삽입합니다. 잘 쓰여진 블로그 (이 블로그와 같은)를 사용하면 문장 부호는 거의 보이지 않는 데, 우리 모두가 수년 전에 처리하도록 배운 표준 배경 코드의 일부일 뿐입니다.

그러나 해커가이 문서에 들어가서 잘못된 장소에 이상한 문장 부호를 삽입하면 어떻게됩니까? 이런 식으로:

없이, 심지어! 변경. 텍스트입니다. 술래? 깡통. 그것을 확인! 많은? 어렵게. 받는 사람? 프로세스! , 정보!

즉, 기본적으로 CRLF 주입 공격으로 일어나는 일입니다. CRLF 문자는 회선의 종료를 기록하기 위해 개별적으로 또는 함께 사용되는 캐리지 리턴 및 선 피드를 나타냅니다. 공격자가 CR 또는 LF 코드를 기존 응용 프로그램에 삽입할 수 있는 경우 동작을 변경할 수 있습니다. 효과는 대부분의 공격에 비해 예측하기 쉽지만 대상 조직에 덜 위험할 수 있습니다.

이 에피소드에서 우리는 배울 것입니다 :

  • 공격자가 CRLF 주입을 트리거하는 방법
  • CRLF 주사가 위험한 이유
  • 이 취약점을 해결할 수 있는 기술입니다.

공격자는 CRLF 주입을 트리거하는 방법은 무엇입니까?

CRLF 문자를 기존 코드에 주입하고 특정 결과를 생성하려고 시도하는 것은 불가능하지는 않지만 다소 어렵습니다. 공격자가 운영 체제 및 대상 시스템의 다른 요인에 따라 다른 CRLF 조합을 사용해야 하기 때문에 더 어려워졌습니다. 예를 들어 최신 Windows 컴퓨터는 CR과 LF가 모두 라인을 종료해야 하며 Linux에서는 LF 코드만 필요합니다. HTTP 요청은 항상 라인을 종료하려면 정확한 CRLF 코드가 필요합니다.

그러나 CRLF 공격은 구현하기 어렵고 결과를 예측하기가 더 어렵다는 사실 외에도 다른 주입 유형 공격과 거의 동일한 방식으로 시작됩니다. 악의적인 사용자는 단순히 웹 사이트 또는 응용 프로그램의 모든 영역에 데이터를 입력하면 일반 입력 데이터가 아닌 CRLF 코드를 입력합니다.

예를 들어 공격자는 캐리지 리턴(%0d)을 나타내는 ASCII 코드를 입력한 다음 HTTPS 헤더 끝에 있는 라인 피드(%0a)에 대한 ASCII를 입력할 수 있습니다. 그런 다음 전체 쿼리가 다음과 같습니다.

https://validsite.com/index.php?page=home%0d%0a

데이터가 소독되거나 필터링되지 않으면 위의 코드에서 대상 응용 프로그램 또는 웹 사이트에서 몇 가지 이상한 일이 발생할 수 있습니다.

CRLF 주사가 위험한 이유는 무엇입니까?

CRLF 주입 공격은 대부분의 공격보다 덜 정확하지만 적어도 일부 시간은 상당히 위험할 수 있습니다. 로우 엔드에서 추가 줄을 추가하면 로그 파일을 엉망으로 만들 수 있으며, 이로 인해 자동 사이버 보안 방어가 트리거되어 관리자에게 문제가 되지 않습니다. 그러나 동시에 발생하는 실제 침입에서 리소스를 전환하는 데 사용할 수 있습니다.

그러나 CRLF 공격은 직접적으로 손상될 수 있습니다. 예를 들어 응용 프로그램이 명령을 수락한 다음 특정 파일을 검색하도록 설계된 경우 쿼리에 CRLF 코드를 추가하면 응용 프로그램이 해당 프로세스를 숨기지 않고 화면에 표시하여 공격자에게 유용한 정보를 제공할 수 있습니다.

CRLF 주사를 사용하여 응답 분할 공격이라고 하는 것을 만들 수 있으며, 여기서 줄 코드의 끝이 유효한 응답을 여러 조각으로 분해합니다. 따라서 추가 코드를 삽입하는 데 사용할 수 있는 CRLF 코드 후 해커가 헤더를 제어할 수 있습니다. 또한 공격자가 자신의 코드를 완전히 주입할 수 있는 개구부를 만들고 CRLF 공격으로 인해 부서진 부품 에 따라 모든 라인에서 다른 형태의 공격을 트리거할 수도 있습니다.

CRLF 주입 취약점 제거

이 시리즈에서 가져갈 키 메시지가 하나 있다면 사용자 입력을 신뢰하지 마십시오. 이 시리즈에서 다루고 있는 대부분의 취약점에는 사용자 입력 영역이 어떤 식으로든 포함되었으며 CRLF 주입 결함도 예외는 아닙니다.

사용자가 입력할 수 있는 모든 지점에서 응용 프로그램 이나 서버에서 잘못 해석될 수 있는 승인되지 않은 코드의 삽입을 방지하기 위해 필터를 적용해야 합니다. CRLF 공격의 경우 HTTP 헤더를 잠그는 것이 특히 중요하지만 GET 및 POST 매개 변수 또는 쿠키도 잊을 수 없습니다. CRLF 코드가 추가 주사를 트리거하는 데 도움이되지 않도록 특별히 차단하는 한 가지 좋은 방법은 HTML 인코딩을 사용자의 브라우저로 다시 보낸 모든 것에 적용하는 것입니다.

CRLF 주사에 대한 자세한 정보

추가 읽기를 위해, 당신은 OWASP CRLF 주사에대해 말하는 것을 살펴 볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

우리는 당신에게 우리의 제품 및 / 또는 관련 보안 코딩 주제에 대한 정보를 보낼 수있는 귀하의 허가를 바랍니다. 우리는 항상 최대한의주의를 기울여 귀하의 개인 정보를 취급 할 것이며 마케팅 목적으로 다른 회사에 판매하지 않을 것입니다.

전송
양식을 제출하려면 '분석' 쿠키를 활성화하세요. 완료되면 언제든지 다시 비활성화할 수 있습니다.