티스토리 뷰
OWASP는 웹 취약점을 정기적으로 발표하는 비영리 조직이다. 수익을 추구하지 않기 때문에, 기부를 통해 운영되고, 웹 취약점은 물론 다양한 취약점들에 대한 연구를 지원하며, 컨퍼런스도 개최한다. 국내지부에서도 모임을 개최하고 있지만, 코로나19의 영향으로 2019년 모임 이후에는 개최되지 않고 있다고 하나 이제 슬슬 모임이 열리지 않을까 기대해 본다. 또한 OWASP는 웹취약점 10개항목에 대한 취약점 대응내용을 설명하고 있기도 한다. OWASP를 읽을 때는 오와삽 이라고 읽으면 된다.
[OWASP TOP 10 2021 목록 A1 : Broken Access Control(취약한 접근 제어: 권한/인가)]
접근 제어(Access Control)는 사용자가 권한을 벗어난 행동을 할 수 없도록 정책을 만들고 실행하는 기능이다. 접근 제어가 취약하게 구현되면 사용자는 주어진 권한을 벗어나 인가되지 않은 데이터에 무단으로 접근해, 조작이나 삭제하는 등을 할 수 있게 된다.
2017 대비 4계단 상승해 첫 번째 항목으로 선정됐으며, 그만큼 다양한 방식으로 많은 취약점이 발생하고 있다. 적절한 예방을 위해서 설계 단계에서부터 올바른 접근 제어 정책을 수립하고 애플리케이션 모든 범위에 누락 없이 적용해야 한다.
취약점 예시
- 특정 사용자에게만 부여해야 하는 권한을 기본적으로 모든 사용자에 부여하는 경우
- 인증되지 않은 사용자가 인증이 필요한 페이지를 강제로 탐색할 수 있는 경우
- 사용자로 로그인해 관리자 권한으로 활동할 수 있는 경우
- POST, PUT, DELETE API 요청에 대한 접근 제어가 누락된 경우
- 파라미터나 쿠키 등의 요청을 조작해 권한 상승 혹은 타 사용자의 권한을 사용할 수 있는 경우
예방 방법
- 공용 리소스를 제외하고 기본적으로 접근을 거부하는 정책 수립(화이트 리스트 기반)
- 접근제어 정책이 애플리케이션 전체에 일괄 적용되도록 확인
[A1에 대한 공격 시나리오]
시나리오1: 애플리케이션이 계정 정보를 조회하는 SQL을 호출하는 경우, 이를 조작해 허가되지 않은 데이터에 접근할 수 있다.
- 계정 정보를 조회하는 SQL 호출
- userID 파라미터 조작
공격자가 HTTP 요청을 할 때 ‘userId’ 파라미터를 조작해, 타 사용자의 계정 정보를 요청할 수 있다. 서버 측에서 ‘userId’를 검증하지 않는다면 공격자는 모든 사용자의 계정 정보에 접근할 수 있다. |
- 관리자 페이지 접근제어
시나리오2: 정상적인 방법을 통해서는 접근할 수 없는 관리자 페이지 URL을 클라이언트 소스코드 내에서 획득하거나, 추측 또는 무작위 대입 등을 통해 해당 URL로 직접 접근을 시도했을 때 서버 측 접근 권한 검증이 없다면 공격자는 관리자 페이지에 접근할 수 있다.
[OWASP TOP 10 2021 목록 A2 : Cryptographic Failures(암호화 실패)]
기존에는 민감 데이터 노출(Sensitive Data Exposure)이라고 했었으나, 이번에 암호화 실패(Cryptographic Failures)로 명칭이 변경되었다. 2017년 대비 한 단계 상승해 두 번째 항목으로 선정되었으며, 이 항목에서는 암호화와 관련된 전반적인 내용을 광범위하게 다루고 있다.
암호화에 오류가 있거나 미흡한 부분이 있는 경우, 민감 데이터 노출로 이어질 수 있다. 특히 개인정보와 금융 데이터 같은 법과 규정에 강력하게 영향을 받는 경우라면 안전하게 보호하기 위한 추가 요구 사항을 지켜야 한다. (국내의 경우 개인정보보호법, 정보통신망법, 신용정보법, ISMS-P 인증, ISO-27001 인증, 주요정보통신기반시설 취약점 분석평가, 전자금융기반시설 취약점 분석평가 등이 있다.)
취약점 예시
- 내·외부망에 관계없이 데이터가 전송구간에서 평문으로 전송되는 경우(HTTP, FTP, TELNET 등)
- 취약한 암호화 프로토콜을 사용하는 경우(SSL v2.0, SSL v3.0, TLS v1.0, TLS v1.1)
- 취약한 암호화 알고리즘을 사용하는 경우(DES, RC4, MD5 등)
- 취약한 암호화 컴포넌트를 사용하는 경우(취약한 버전의 openssl 사용 등)
- 보안 헤더 설정을 통한 HSTS가 누락된 경우(HSTS : HTTP를 HTTPS로 강제 리다이렉트)
- 고정된 암호문을 사용하는 경우(Salt, 일회용 난수 미포함)
- 사설 인증서 사용, 인증서와 도메인 불일치
- 암호키 관리가 미흡한 경우(소스코드 하드코딩 등)
예방 방법
- FTP, TELNET과 같은 레거시 프로토콜 미사용
- 최신 버전의 암호 프로토콜 및 안전한 암호 알고리즘 사용
- HSTS(HTTP를 HTTPS로 강제 리다이렉트) 설정
- 암호화 시 암호문이 고정되지 않도록 의사 난수 생성기를 포함
- 신뢰할 수 있는 기관에서 발급한 인증서 사용
[A2에 대한 공격 시나리오]
- 평문으로 노출된 아이디와 패스워드
공격자가 스니핑하고 있는 네트워크에서 중요 정보가 포함된 데이터를 평문으로 전송하는 경우, 공격자는 평문으로 노출된 아이디와 패스워드를 획득해 해당 시스템에 로그인할 수 있다.
- 세션ID 획득 후 시스템 접근
공격자가 인증한 세션ID를 획득하면, 해당 세션ID에 부여된 권한으로 시스템에 접근할 수 있다.
[OWASP TOP 10 2021 목록 A03: Injection(인젝션)]
역사적으로 웹 애플리케이션 취약점 중 가장 많이 알려진 인젝션(Injection)이 세 번째 항목으로 선정되었다. 이번에 XSS(Cross-site Scripting)가 인젝션 항목에 포함되면서, 사용자 제공 데이터 조작을 통한 공격은 모두 인젝션 항목으로 통일되었다.
인젝션은 사용자가 전달하는 데이터(파라미터, 헤더, URL, 쿠키(Cookie), Json 데이터, SOAP, XML 등 모든 형태)를 신뢰할 수 없는 데이터로 조작해서, 서버 측에서 명령어나 쿼리문의 일부로 인식하게 만들 때 발생하는 취약점이다.
취약점 예시
- SQL injection, NoSQL injection
- OS Command Injection
- ORM(Object Relational Mapping) injection
- LDAP injection
- EL(Expression Language) injection
- OGNL(Object Graph Navigation Library) injection
- Cross-site Scripting
예방 방법
- 사용자 입력이 SQL 문법으로 인식되지 않도록 Binding 변수를 사용(예: Prepared statement)
- 사용자 제공 데이터에 대한 화이트리스트 기반 서버 측 검증
[A03에 대한 공격 시나리오]
- id 파라미터 조작
// SQL 호출을 취약하게 구현한 애플리케이션
\
String query = “SELECT \* FROM accounts WHERE custID=’” + request.getParameter(“id”) + “‘“;
Query HQLQuery = session.createQuery(“FROM accounts WHERE custID=’” + request.getParameter(“id”) + “‘“);
|
cs |
SQL 호출을 취약하게 구현한 애플리케이션에서 사용자 제공 데이터를 공격자가 조작할 수 있도록 방치한다면, 공격자는 사용자 제공 데이터에서 id 파라미터를 조작하는 것만으로도 해당 컬럼의 모든 데이터를 조회할 수 있다.
- 다음 : [OWASP TOP 10 2021 목록 A4 ~ A10] -
'정보보안.Security' 카테고리의 다른 글
[리눅스][초보][보안][비밀번호 작성 규칙 : 안전한 패스워드 생성TIP] (0) | 2023.01.19 |
---|---|
[리눅스][초보][보안][무차별대입공격][OWASP TOP10 취약점대응2] (0) | 2023.01.18 |
[리눅스][초보][보안][무차별대입공격과 OWASP TOP10 소개] (0) | 2023.01.04 |
[리눅스][초보][보안][무차별대입공격 방어와 대응책] (0) | 2023.01.04 |
[리눅스][초보][보안][무차별대입공격유형] (1) | 2022.12.31 |