TIL. 221 OWASP의 10대 취약점

조윤식·2022년 9월 27일
0

OWASP 10대 순위를 통해 어플리케이션 보안에 가장 중요한 위험과 취약점을 확인할 수 있습니다. 웹 앱과 이를 만드는 프로그래밍 언어가 지속적으로 발전하는 가운데 우리는 과거의 위협에 주의를 분산하지 않고 가장 중요한 형태의 어플리케이션 취약점에 노력을 집중해야 합니다.

OWASP에 따르면 2021년 10대 취약점에는 3가지 신규 범주가 있습니다.

OWASP에 따르면 2021년에 추가된 범주는 설계 및 아키텍처 결함과 관련되며 위협 모델링, 보안 설계 패턴, 기준 아키텍처 등의 대응을 요합니다. 또한 코딩에 있어서는 단순 원점 회귀 방식을 넘어섬으로써 설계상 보안 원칙에 중요한 사전 코드 활동을 실시해야 합니다.

2021년 OWASP 10대 취약점

1. 접근 제어 문제

잘못된 접근 제어는 요청된 오브젝트에 대한 적절한 접근 확인이나 검증이 이루어지지 않는다는 뜻입니다. 또한 중요한 데이터와 정보에 대한 무단 접근이 이루어지기도 합니다.

접근 제어 취약점의 일반적인 예는 브라우저를 목표 URL로 강제하는 경우입니다.

이를테면 어플리케이션의 어드민 대시보드에 접근하려면 어드민 접근 권한이 있어야 합니다.

http://appwebsite.com/app/getadmininfo

http://appwebsite.com/app/admin_getadmininfo

두번째 URL은 변수를 수정하여 접근 권한을 확인합니다. 검증이 이루어지지 않으면 민감성 데이터에 대한 접근 제어가 “손상”되므로 이 URL은 무단 접근을 허용하는 셈입니다.

2. 암호 문제

어플리케이션 내의 민감성 데이터에 무단 접근이 일어나면 큰 피해가 일어날 수 있습니다. 우버 기사들은 이 점을 알고 있었습니다.

민감성 정보 노출의 일반적인 예는 아래와 같습니다.

  • 세션 토큰
  • 로그인 ID와 암호
  • 온라인 거래
  • 개인 세부정보(주민등록번호, 의료기록 등) .
    피해자 계정에 대한 무단 접근은 심각한 문제입니다. 단순한 해쉬값으로 민감성 데이터를 저장하는 방법은 절대 지양해야 합니다.

이와 함께 모든 민감성 데이터의 암호화가 이루어지지 않을 시 이 위협은 커다란 피해를 입힐 수 있습니다.

3. 주입

주입은 SQL을 이용하여 어플리케이션의 데이터베이스를 공격하는 방법으로 이를 통해 일반적으로 인증된 사용자 계정을 필요로 하는 행위를 실행하게 됩니다.

해커는 이미 데이터베이스를 장악했지만 당사자는 아직 모릅니다. 이는 매우 우려스러운 상황입니다.

SQL 주입의 일반적인 예는 “101”이 아닌 “101 OR 1=1”을 전달하는 경우입니다.

4. 비보호 설계

최신 OWASP Top 10 개정판은 설계 프로세스의 시작부터 위협 모델링, 보안 설계 패턴 및 참조 아키텍처를 구현하기 위한 권장 사항과 함께 설계 및 아키텍처 결함 관련 위험에 대해 설명하고 있습니다.

5. 보안 구성오류

이는 서버에서 잘못 구성된 권한을 통해 어플리케이션에 대한 공격을 초대하는 것이나 다름없는 문제입니다.

어플리케이션을 침해에 취약하게 만드는 문제로는 기본 구성, 개방된 포트, 권한, 부정확한 HTTP 헤더 등이 있습니다.

NB: XML 외부 개체(XXE)는 아직 보안 구성오류에 속하지 않습니다.

XXE 공격은 어플리케이션이 VML* 입력을 파싱할 시에 발생합니다. 이 입력은 XML 파서의 보안 결함을 이용하여 어플리케이션에 침투하려는 외부 개체로 볼 수 있습니다.

XXE의 예는 공격자가 서버에서 데이터를 추출하려 시도하는 경우가 있습니다.

         <?xml version=”1.0″ encoding=”ISO-8859-1″?> <!DOCTYPE foo [
          <!ELEMENT foo ANY >
          <!ENTITY xxe SYSTEM “file:///etc/passwd” >]> <foo>&xxe;</foo>     

또한 서버의 사설망을 위의 ENTITY 라인을 수정하여 조작할 수 있습니다.
이를테면 이와 같이 조작합니다.

     <!ENTITY xxe SYSTEM “https://192.168.1.1/private” >]>

출처:HdivSecurity

NB: XSS (크로스 사이트 스크립팅) 공격은 이제 “주입” 범주에 해당합니다.

XSS 취약점은 여러 어플리케이션에 영향을 미치며 기본적으로 서버와 브라우저 간의 통신을 가로채는 악성 자바스크립트의 형태로 악용됩니다.

일반적인 XSS 취약점의 예로는 워드프레스 관리자 대시보드에서 글을 올리려 하는 경우입니다.

여기서 해커는 XSS를 악용하여 관리자 URL을 주입, 조작하고 브라우저가 새 관리자를 생성하도록 강제할 수 있습니다. 이제 어떻게 될까요? 워드프레스 글을 마음대로 편집, 수정하거나 상상을 초월하는 일이 일어나게 됩니다.

  1. 취약하며 최신화되지 않은 구성요소
    대부분 웹 어플리케이션은 서드파티가 제공하는 특수한 프레임워크로 개발됩니다. “코딩” 세계는 어플리케이션을 구축하는 여러 오픈소스 구성요소와 프레임워크로 가득하며 다시 말해 소스코드에서 취약점을 찾아내려 눈을 부릅뜬 이들이 수없이 있다는 뜻입니다.

알려지지 않은 어플리케이션 코드는 액센트 제어 침해, SQL 주입 등 좋지 못한 결과를 일으킬 수 있습니다.

출처:Sucuri

  1. 신원파악 및 인증 문제
    이름 그대로 이 신원파악 및 인증 문제는 해커들이 부적절한 인증을 악용하는 데 이용합니다. 공격자가 사용자 정보, 암호 회수, ID 세션, 기타 로그인 크리덴셜을 구하게 되면 보안 위험이 일어납니다.

이러한 크리덴셜 스터핑의 형태로 된 인증 공격 시도는 주로 브루트 포스로 일어납니다.

이를테면 온라인 쇼핑몰 URL에 대해 이러한 시도가 가능합니다.

한 온라인 쇼핑몰이 URL 리라이팅을 지원하는 어플리케이션을 운영하는 경우 URL에 세션 ID가 존재합니다.

http://shoppingsitexample.com/products/item;jsessionid=2P0OC4KBIWHYDYIBOME1JV?dest=Nike

  1. 소프트웨어 및 데이터 무결성 문제
    데이터베이스에 저장되는 민감성 정보가 늘어나면서 소프트웨어의 데이터 무결성 문제는 날로 중요성이 높아지고 있습니다.

여기서는 소프트웨어 업데이트 관련 문제, 불충분한 무결성 검증, 보안 CI/CD 파이프라인, 충분한 데이터 무결성의 필요 등에 대해 다룹니다.

OWASP는 비보안 역직렬화(바이트 스트링을 오브젝트로 변환하는 행위) 취약점이 데이터 무결성 문제에 해당한다고 간주하는데 이는 이 약점이 무효한 데이터를 이용하여 어플리케이션의 로직을 파괴하기 때문입니다.

비보호 역직렬화 공격은 RCE(원격 코드 실행) 공격에 해당합니다.

참고: – 비보호 역직렬화는 이제 소프트웨어 및 데이터 무결성 문제에 해당합니다.

  1. 보안 로깅 및 모니터링 문제
    의심스러운 행동과 이벤트를 적절히 기록하지 못하면 감시가 이루어지지 않는 시간이 늘어나고 보안 침해도 장시간 발생하게 됩니다.

웹사이트 해킹은 좋지 못한 행동이지만 웹 어플리케이션의 소유주가 의심스러운 코드 거동을 감시하지 않으면 더욱 심각해집니다.

그러므로 모니터링 시스템이 필요합니다. 이 시스템은 사이트에 무슨 일이 일어날 시 경보를 제공하며 이를 적시에 해소하도록 도와줍니다.

효율적 로깅 및 모니터링 프로세스가 없다면 무슨 일이 벌어졌는지 알지도 못하고 공격의 피해를 고스란히 받아야 합니다.

불충분한 로깅과 모니터링의 예

공격자나 프로그램이 쉽게 해킹가능한 암호를 쓰는 사용자를 찾아냅니다.

이 작업이 완료되면 공격자는 모든 계정에 간단한 1개 암호만 시도할 수 있습니다.

더 많은 암호를 시도할수록 사용자에게는 좋습니다. 일정 시간이 지나면 단 1건의 잘못된 로그인 기록만 남기 때문입니다. 공격자가 더 많은 계정에 침투하고자 하는 경우 더 많은 작업이 필요합니다.

  1. 서버측 요청 위조(SSRF)
    먼저 사용자가 제공한 URL을 검증하지 않고 서버측 요청이 일어나는 경우를 서버측 요청 위조(SSRF) 공격이라 합니다.

이를 테면 웹 어플리케이션이 사용자가 제공한 원격 자원 URL을 검증하지 않을 시 SSRF에 취약할 수 있습니다.

– 예를 들어 이 URL은 http://target.example.com/inc/sharefile.asp 일 수 있습니다.

– 웹 어플리케이션이 이 URL을 검증하지 않으면 사용자는 이를 악용하여 다른 내부 자원이나 내부 네트워크에 접근할 수 있습니다.

profile
Slow and steady wins the race

0개의 댓글