[2021.09.04] OWASP TOP 10

---

Injection

1) 코드 주입은 공격자가 응용 프로그램이 설계/프로그래밍하지 않은 작업을 수행하도록 하기 위해 잘못된 데이터를 웹 응용 프로그램에 보낼 때 발생합니다. 코드 주입 취약성의 핵심은 웹 응용 프로그램에서 사용하는 데이터의 유효성 검사 및 검사 부족이며, 이는 웹 사이트와 관련된 거의 모든 유형의 기술에 이 취약성이 존재할 수 있음을 의미합니다. 매개 변수를 입력으로 받아들이는 모든 항목은 잠재적으로 코드 주입 공격에 취약할 수 있습니다. 대표적인 예시로 OS injection(command injection), SQL Injection 등이 있습니다.

 

String query = “SELECT * FROM accounts WHERE custID = ‘” + request.getParameter(“id”) + “‘”;

 

이 쿼리문은 URL: http://example.com/app/accountView?id=’ or ‘1’=’1 로

실행하는 웹 페이지를 호출해 database table에 저장된 IP, PW, 개인정보 등의 모든 행이 반환되도록 공격할 수 있습니다.

 

2) 공격자가 웹 어플리케이션으로 비정상적인 명령어, 쿼리 등을 보내 시스템에 접근할 수 있는 취약점입니다.

인젝션 공격은 사용자의 입력 값이 어플리케이션의 처리 과정에서 구조나 문법적인 데이터로 해석돼 발생하는 취약점을 의미합니다. 변조된 입력을 주입해 의도하지 않은 행위를 발생시킵니다.

 

SQL Injection

SQL을 사용할 때 공격자의 입력 값이 정상적인 요청에 영향을 주는 취약점입니다.
SQL Injection은 SQL 쿼리에 사용자의 입력 값이 삽입돼 사용자가 원하는 쿼리를 실행할 수 있는 취약점입니다.

SQL Injection이 발생하게 되면 현재 쿼리를 실행하는 DBMS 계정의 권한으로 공격이 가능하며

일반적으로 데이터베이스의 내용을 추출하거나 변조, 삭제하는 등의 행위가 가능합니다.

버그바운티(Bug Bounty) Write-up / SQL Injection ($2,000)
버그바운티(Bug Bounty) Write-up / SQL Injection ($4,500)

대응방안

✔ORM과 같이 검증된 SQL 라이브러리를 사용

ORM: Object Relational Mapper의 약자. SQL의 쿼리 작성을 돕기위한 라이브러리

✔정적 쿼리 사용

✔파라미터화된 쿼리 사용

 

Command Injection

OS Command를 사용 시 사용자의 입력 데이터에 의해 실행되는 Command를 변조할 수 있는 취약점입니다.

OS Command는 내부적으로 셸(Shell)을 이용해 실행하는데, 셸은 사용자 편의성을 위해 한 줄에 여러 명령어를 실행하는 특수 문자가 여럿 존재합니다. 만약 OS Command를 사용할 때 사용자의 입력 값을 검증하지 않고 함수의 인자로 전달한다면 오른쪽 탭의 특수 문자를 이용해 사용자가 원하는 명령어를 함께 실행할 수 있습니다.

Server Side Template Injection (SSTI)

템플릿 변환 도중 사용자의 입력 데이터가 템플릿으로 사용돼 발생하는 취약점입니다.

만약 Template 내부에서 사용되는 context가 아닌 Template source에 사용자 입력이 들어가게 된다면 악의적인 입력을 통해 개발자가 의도하지 않은 임의의 Template 기능을 실행할 수 있습니다. 즉, 사용자의 입력 데이터가 Template에 직접 사용될 경우 Template Engine이 실행하는 문법을 사용할 수 있기 때문에 SSTI 취약점이 발생하게 됩니다.

 

대응방안

SSTI 취약점을 막기 위해서는 사용자의 입력 데이터를 Template source에 삽입되지 않도록 해야합니다. 사용자의 입력 데이터를 Template에서 출력하기 위해서는 Template context에 값을 넣어 출력해야 합니다.

Path Traversal

URL / File Path를 사용 시 사용자의 입력 데이터에 의해 임의의 경로에 접근하는 취약점입니다.

대응방안

사용자의 입력 데이터가 경로로 사용되는 경우에는 URL Encoding과 같은 인코딩을 사용해

사용자의 입력 데이터에 포함된 구분 문자를 인식하지 않도록 할 수 있습니다.

Server Side Request Forgery (SSRF)

공격자가 서버에서 변조된 요청을 보낼 수 있는 취약점입니다.

CSRF는 변조된 요청이 웹 클라이언트(브라우저)가 보내며, SSRF는 웹 어플리케이션에서 보내지게 됩니다. 웹 어플리케이션에서 요청을 보내기 때문에 웹 어플리케이션이 작동하고 있는 서버 내부의 포트, 서버와 연결된 내부망에 요청을 보낼 수 있고 Server-side에서 변조된 요청 / 의도하지 않은 서버로 요청을 보내는 공격이 SSRF입니다.

대응방안

✔URL Host 화이트리스트방식 필터링

✔사용자의 URL을 처리하는 서버를 독립적으로 망 분리를 하여 SSRF 취약점이 발생하여도 다른 취약점과 연계를 하지 못하도록 방지하는 방법입니다.

---

Broken authentication

인증 및 세션 관리와 관련된 어플리케이션 기능이 종종 잘못 구현되어

공격자에게 취약한 암호, 키 또는 세션 토큰을 제공하여 다른 사용자의 권한을 얻도록 착취하는 것입니다.

취약한 암호 설정, 취약한 인증과정 등으로 인증에 필요한 사용자의 계정정보를 노출할 수 있습니다.

 

* Types of Broken Authentication Vulnerabilities

-공격자가 유효한 사용자 이름 및 암호 목록을 가지고 있는 자격 증명 스터핑과 같은 자동 공격을 허용합니다.

- 무차별 공격 또는 기타 자동 공격을 허용합니다.

- "Password1" 또는 "admin/admin"과 같이 기본 암호, 취약 암호 또는 잘 알려진 암호를 허용합니다.

- 안전할 수 없는 "지식 기반 응답"과 같은 취약하거나 효과적이지 않은 자격 증명 복구 및 잊어버린 암호 프로세스를 사용합니다.

- 일반 텍스트, 암호화된 암호 또는 약하게 해시된 암호를 사용합니다.

- 다중 요인 인증이 없거나 효과적이지 않습니다.

- URL에 세션 ID를 표시합니다(예: URL rewriting).

- 로그인 후 세션 ID를 rotate 하지 않습니다.

- 세션 ID를 올바르게 무효화하지 않습니다.
로그아웃 또는 비활성 기간 동안 사용자 세션 또는 인증 토큰(특히 SSO(Single Sign-On) 토큰)이 제대로 무효화되지 않습니다.

 

 

---

Sensitive Data exposure

- 프로그램이 보안과 관련된 민감한 데이터를 평문으로 송수신할 경우,
통신채널 스니핑을 통해 인가되지 않은 사용자에게 민감한 데이터가 노출될 수 있습니다.

- 암호화된 데이터 또한 다음과 같은 이유로 취약할 수 있습니다.

---

XML external entities

1) XML 타입의 데이터 웹 요청을 통해 전송, 서버에서 XML External Entity가 처리 가능하게 설정된 경우 발생합니다.
     XML 문서에서 External Entity를 이용하여 공격자가 의도하는 외부 URL을 실행시킬 수 있습니다.

ex)

<!DOCTYPE foo [

<!ENTITY xxe SYSTEM "file:///etc/passwd">

]>

 

- DOCTYPE 선언을 한 다음 ENTITY 태그 이용, xxe라는 외부 entity 선언

-> 선언된 외부 entity는 프로그래밍 시 변수 참조 처럼 XML 내부에서 참조 가능

=> xxe 엔티티를 참조하면 xxe 값인 SYSTEM 키워드로 지정된 /etc/passwd 파일 참조

* file:// 대신 http://를 사용하여 외부 리소스 참조도 가능

https://portswigger.net/web-security/xxe

 

 

2) 입력되는 XML 구문을 파싱하는 어플리케이션을 대상으로(웹 사이트 등) 하는 공격입니다.

입력받은 XML 데이터가 외부 엔티티(external entity)를 포함하고 있고 이를 취약하게 설정된 XML 파서가 처리할 때 발생합니다.

XML: 마크업 언어, HTML보다 개선된 언어

XML 엔티티는 반복적으로 나오는 문자열이나 특별처리가 필요한 특수 문자를 XML 문서에서 사용하기 위해 미리 정의해놓고

사용하는 개체입니다. XML Entity는 앰퍼샌드('&') 문자로 시작하고 세미콜론(';') 문자로 끝납니다.

XML External Entity Injection Attack (XXE Injection 공격)

 

대응방안

✔클라이언트로부터 입력되는 정보들을 충분히 검증

✔Java에서는 DTD를 애초에 사용하지 않도록 XML 파서에 설정

---

Broken access control

웹 사이트 보안에서 Access control은 방문자가 필요에 따라

어떤 섹션이나 페이지에 접근할 수 있는지에 제한을 두는 것을 의미합니다.

"access":

-Access to a hosting control / administrative panel

-Access to a server via FTP / SFTP / SSH

-Access to a website’s administrative panel

-Access to other applications on your server

-Access to a database

Attackers can exploit authorization flaws to the following:

 

Access unauthorized functionality and/or data → 허가되지 않은 기능과 데이터에 접근

View sensitive files → 민감한 파일 노출

Change access rights → 접근권한 변경

 

---

Security misconfigurations

패치되지 않은 결함, 기본 구성, 미사용 페이지, 보호되지 않은 파일 및 디렉터리, 불필요한 서비스로 인하여

보안 설정 오류가 발생할 수 있습니다. 

웹 브라우저에서 웹 서버의 특정 디렉토리에 접근하게 되면 모든 파일 리스트를 확인할 수 있는 경우가 있습니다.

관리자가 의도하는 경우도 있지만 대부분 관리자의 인지하지 못하여 발생하는 문제가 대다수입니다. 

또한 개발자가 백업 파일이나 임시 파일을 삭제하지 않고 방치함으로써 내부 정보를 획득할 수도 있고, 미흡한 주석관리도 문제가 될 수 있습니다. 웹은 누구나 볼 수 있기에 주석에 주요 로직이나 구조, 데이터를 작성해 놓게 되면 문제가 발생할 수 있습니다.

웹 서버에 어떠한 파일이라도 업로드 할 수 있도록 방치하는 것도 공격자에게 공격을 위한 빌미를 제공하는 것입니다.

악성 파일을 전송하여 서버에서 실행하게 된다면 내부 침투가 가능해지고,

악성 파일 업로드를 통해 리버스 텔넷 공격등도 가능해집니다.

대부분 서버는 텔넷등의 포트로 서버에 접속하지 못하도록 방화벽을 사용하는데, 인바운드만 신경쓰게 되고 아웃바운드에 대해선 인식이 미흡하다면 악성 프로그램 업로드로 서버에서 공격자에게 텔넷을 연결하도록 할 수 있습니다.

 

---

Cross Site Scripting

크로스사이트 스크립팅

서버의 응답에 공격자가 삽입한 악성 스크립트가 포함되어 사용자의 웹 브라우저에서 해당 스크립트가 실행되는 취약점을

Cross Site Scripting (XSS) 이라고 합니다.

Stored XSS

Stored XSS는 악성 스크립트가 서버 내에 존재하는 데이터베이스 또는 파일 등의 형태로 저장되어 있다가 사용자가 저장된 악성 스크립트를 조회하는 순간 발생하는 형태의 XSS 입니다.

서비스의 형태와 접근성, 그리고 해당 서비스를 통해 얻을 수 있는 정보 또는 행위들에 따라 파급력은 달라질 수 있습니다.

버그바운티(Bug Bounty) Write-up / Stored XSS

Reflected XSS

Reflected XSS는 악성 스크립트가 사용자의 요청과 함께 전송되는 형태입니다. 사용자가 요청한 데이터가

서버의 응답에 포함되어 HTML 등의 악성 스크립트가 그대로 출력되어 발생하게 됩니다.

Reflected XSS는 Stored XSS와는 다르게 사용자의 요청 데이터에 의해 취약점이 발생하기 때문에,

변조된 데이터가 사용자의 요청으로 전송되는 형태를 유도해야 합니다.

가장 간단한 방법으로는 특정 링크를 유도하는 방식이 존재하며 Click Jacking, Open Redirect 등의 다른 취약점과 연계하여

발생시키는 방법도 존재합니다.

버그바운티(Bug Bounty) Write-up / Reflected Cross site Scripting ($375)

대응방안

✔Server-side Mitigations

✔HTTPOnly 플래그 사용

✔Content Security Policy 사용

✔X-XSS-Protection

---

Insecure deserialization

Insecure deserialization 과정은 바이트 문자열을 객체로 변환하는 것입니다.

이러한 유형의 위험으로부터 웹 애플리케이션을 보호하는 가장 좋은 방법은 신뢰할 수 없는 소스에서

직렬화된 개체를 허용하지 않는 것입니다.

이를 수행할 수 없는 경우 OWASP 보안은 귀하(또는 귀하의 개발자)가 구현하려고

시도할 수 있는 추가 기술 권장 사항을 제공합니다.

 

- 적대적인 개체 생성 또는 데이터 변조를 방지하기 위해 직렬화된 개체에 대한 디지털 서명과 같은 무결성 검사를 구현합니다.

- 코드에서 일반적으로 정의 가능한 클래스 집합을 예상하므로 개체 생성 전에 역직렬화 중에 엄격한 형식 제약 조건을 적용합니다. 이 기술에 대한 우회가 입증되었으므로 이것에만 의존하는 것은 바람직하지 않습니다.

- 가능한 경우 낮은 권한 환경에서 역직렬화하는 코드를 격리 및 실행합니다.

- 들어오는 형식이 예상 형식이 아니거나 deserialization에서 예외가 발생하는 경우와 같은

deserialization 예외 및 오류를 기록합니다.

- 역직렬화하는 컨테이너 또는 서버에서 들어오고 나가는 네트워크 연결을 제한하거나 모니터링합니다.

- 사용자가 지속적으로 역직렬화하는 경우 경고하는 역직렬화를 모니터링합니다.

직렬화: 객체를 나중에 복원할 수 있도록 데이터 형식으로 변환시키는 과정입니다. 객체를 저장하거나 전송하기 위해 직렬화를 수행합니다.

역직렬화는 직렬화의 반대로, 직렬화된 객체를 원래의 객체로 재구성하는 과정을 의미합니다.

오늘날 직렬화를 위해 가장 많이 사용되는 데이터 형식은 JSON

자체 직렬화 많은 프로그램 언어는 자체 직렬화 기능을 제공합니다. 이러한 자체 기능은 신뢰할 수 없는 데이터로부터 악영향을 받을 수 있습니다.

안전하지 않은 역직렬화(Insecure Deserialization), OWASP Top 10 2017 A8

 

대응방안

✔사용자의 입력을 역직렬화의 입력으로 사용하지 말 것

✔반드시 역직렬화 이전에 무결성 검사

✔노출 여부를 조절할 수 있도록 커스터마이징된 직렬화 메소드 사용

 

---

Using components with known vulnerabilities

공격
공격자가 대상 사이트를 검색하여 사용하는 컴포넌트의 종류 파악,

파악 후 취약한 컴포넌트를 사용하는 사이트가 발견되면 해당 컴포넌트 버전을 알아내고 해당하는 취약점을 검색하여

이를 활용해 공격 수행

 

대응 방안
1) NVD, CVE와 같은 소스로부터 취약점 정보를 수집하고
웹 애플리케이션에 사용된 구성요소에 취약점이 존재하는지 감독합니다.

2) 관리 도구 도입 - 오픈소스 sw 사용에 따른 라이선스 위배 여부를 분석,
취약점 DB를 통해 알려진 취약점 존재 여부를 확인해줍니다.

 

- 오픈소스 sw를 사용할 때, 오픈소스 sw 사용부를 컴포넌트화하여 유지보수가 쉽게 어플리케이션을 구성,
오픈소스 sw와 주 애플리케이션 사이 결합도가 높아지면 향후 취약점이 패치된 버전으로 업데이트할 때 영향도가 커져서
마이그레이션을 포기하는 경우도 발생할 수 있습니다.

 

---

Insufficient logging and monitoring

 

시스템을 지속적으로 모니터링하여 공격을 발견하고 서비스를 빠르게 복구하려면 로깅과 모니터링이 필수입니다.

지속적인 모니터링이 공격 징후를 빠르게 발견할 수 있고 피해가 커지기 전에 공격자를 차단함으로써

다운타임을 최소화할 수 있습니다.

또한 빠르게 복구하려면 공격자의 행위를 자세하게 기록하는 로깅이 필수적입니다.

 

<로깅 및 모니터링의 3단계>

1) 로그 수집

로그를 파싱하고 변환하고 필터링하는 단계입니다.

2) 로그 관리

로그의 보관 주기를 설정하고 분산 저장하거나 인덱싱하여 서비스 성능과 로그 탐색 속도를 높입니다. 중요정보에 대한 접근 이력을 관리하는 등 정책 설정도 이 단계에 포함됩니다.

3) 로그 모니터링 및 분석

수집된 로그를 시각화하고 경보를 설정하거나 기록 행위를 보고하는 단계입니다.

 

<로깅 및 모니터링 강화 방안>

1) 로그의 분산 저장 및 동기화

로그는 별도의 장소에 분산 저장되고 동기화되어야 공격자가 모든 로그를 수정할 수 없게 되고 그만큼 시스템이 안전해집니다.

2) 로그 정책 설정

로그 정책을 통해 불필요한 로깅은 최소화하고 민감정보에 대한 접근과 같은 주요 트랜잭션 위주로 로그를 기록합니다.

3) 모니터링 자동화

로그 모니터링은 자동화하여 이상 징후가 발생했을 때 경보를 줄 수 있도록 구성해야 합니다.