오늘은 OWASP Top 10 취약점에 대해 알아볼 것입니다.
1. 인젝션 공격( Injection )
: 인젝션 공격은 신뢰할 수 없는 데이터를 명령 또는 쿼리에 삽입하여 애플리케이션이 사용자가 제공한 데이터에 대해 유효성 검사 ,필터링 또는 검사를 실행하지 않아 의도하지 않게 악성 명령어가 싱핼될 때 발생합니다.
- NOSQL, OS명령 ,SQL 인젝션 공격
- JS같은 악의적인 클라이언트 측 스크립트를 주입한는 XSS
- 이로 인해 개인정보 세션 쿠키와 같은 민감한 정보가 도용될 수 있다.
& 개발자가 방지할 수 있는 역할
- 프론트엔드
- 사용자 입력에 대한 유효성 검사를 철저히 수행
- 입력 필드나 쿼리 파라미터에서 허용되지 않은 문자를 필터링하거나 이스케이프 처리
- HTML 및 JS 인젝션을 방지하기 위해 출력 시 인코딩 처리
- 백엔드
- DB 쿼리에서 파라미터화된 쿼리를 사용하여 SQL 인젝션 방지
- 서버측에서도 사용자 입력의 유효성 검샤ㅏ를 이중으로 수행 ⇒ 백엔드는 클라이언트의 정보를 믿지 마라
2. 암호화 오류(Cryptographic Failures)
: 데이터 전송 중 및 저장 중인 민감한 데이터를 제대로 보호하지 못한 문제로 인해 발생
- 암호화 오류가 발생하면 데이터 보안 표준 등의 금융 표준을 위반할 수 있다.
& 개발자가 방지할 수 있는 역할
- 프론트엔드
- HTTPS를 사용하여 클라이언트 서버 간의 데이터 전송 암호화
- 사용자의 함호를 안전하게 입력받고 전송중에 데이터가 노출되지 않도록 보호
- 백엔드
- 암호화 알고리즘을 사용하고, 키 관리를 철저히 합니다.
- 안전하지 않은 암호화 알고리즘이나 짧은 키 길이를 사용하지 않도록 보장
3. 보안 구성 오류(Security Misconfiguration)
: 웹 어플리케이션 프레임워크, 플랫폼, 서버 또는 보안 제어의 보안을 강화하지 않으면 무단 액세스 , 민감한 정보 노출 또는 기타 보안 취약점이 발생할 수 있다.
& 개발자가 방지할 수 있는 역할
4. 취약하고 오래된 구성 요소(Vulnerable and Outdated Components)
: 오래되거나 업데이트가 안 된 라이브러리,프레임워크 등을 사용하면 애플리케이션이 알려진 보안 결함에 노출되어 공격 위헙이 증가할 수 있다.
& 개발자가 방지할 수 있는 역할
- 프론트엔드
- 애플리케이션에서 사용하는 프론트엔드 라이브러리 및 패키지를 정기적으로 업데이트하고, 알려진 취약점을 확인합니다.
- 백엔드
- 서버 측에서도 라이브러리, 플러그인, 프레임워크의 최신 보안 패치를 유지합니다.
- 오래된 구성 요소를 사용하지 않고, 주기적으로 보안 점검을 통해 취약점을 파악하여 대응합니다.
5. 식별 및 인증 실패(Identification and Authentication Failures)
: 인증 , ID , 세션 관리의 취약성으로 인해 공격자는 사용자 계정, 비밀번호, 세션 토큰을 손상시키거나 안전하지 않은 세션 처리를 악용할 수 있다.
- 위와 같은영역에 결함이 있으면, 크리덴셜 스터핑과 같은 자동화된 공격이 허용될 수 있다.
- 많은 사람들이 비밀번호를 재사용하거나 기본 비밀번호, 약한 비밀번호 또는 잘 알려진 비밀번호를 사용하기 때문에 관련 취약성은 위 위험성과 관련이 깊다.
& 개발자가 방지할 수 있는 역할
- 프론트엔드
- 강력한 비밀번호 요구사항을 프론트엔드에서 적용하고, 비밀번호 재사용 방지 기능을 추가합니다.
- 로그인 및 로그아웃 상태를 안전하게 관리하며, 세션 만료 시 자동 로그아웃 기능을 적용합니다.
- 백엔드
- 강력한 인증 메커니즘(OAuth, JWT 등)을 사용하고, 세션 관리와 만료를 엄격히 적용합니다.
- 사용자 인증 데이터와 세션 토큰을 안전하게 저장하고 전송합니다.
- 크리덴셜 스터핑 공격을 방지하기 위해 로그인 시도 제한을 적용합니다.
6. 소프트웨어 및 데이터 무결성 문제(Software and Data Integrity Failures)
: 데이터 및 소프트웨어 무결성 위반으로부터 보호하지 못하는 애플리케이션 코드 및 인프라로 인해 발생한다.
- 신뢰할 수 없는 소스 , 레포지토리 , 라이브러리 또는 모듈에 의존할 때 발생할 수 있다.
- 공격자는 잠재적으로 자체 업데이트를 업로드하여 모든 설치에 배포하고 실핼할 수 있다.
& 개발자가 방지할 수 있는 역할
- 프론트엔드
- 외부 라이브러리나 플러그인을 사용할 때 신뢰할 수 있는 소스에서만 다운로드합니다.
- 업데이트가 있는 경우 이를 적극적으로 반영하고, 무결성 검사를 통해 변경 사항을 검증합니다.
- 백엔드
- 외부 플러그인 및 소프트웨어 업데이트 시 코드 무결성을 검증하고 서명된 업데이트만 허용합니다.
- CI/CD 파이프라인에서 자동화된 배포 프로세스를 검증하여 무결성을 보장합니다.
7. 안전하지 않은 설계(Insecure Design)
: 애플리케이션 개발의 시작부터 보안을 고려해서 설계를 해야한다.
& 개발자가 방지할 수 있는 역할
- 프론트엔드 개발자:
- 애플리케이션 설계 초기부터 보안을 고려하여, 입력 필터링, 인증, 권한 부여 등 기본 보안 메커니즘을 반영합니다.
- 백엔드 개발자:
- 보안 요구사항을 설계 단계에서 명확히 정의하고, 최소 권한 원칙을 따른 아키텍처를 설계합니다.
- 애플리케이션 로직에서 인증 및 권한 검사를 철저히 적용하여 안전한 설계를 유지합니다.
8. 서버 측 요청 위조(SSRF)
: 애플리케이션이 원격 리소르에서 데이터를 가져오기 전에 사용자가 입력한 URL의 유효성을 검증하거나 검사하지 않을 떄 발생한다.
- 공격자는 이러한 결함을 사용하여 방화벽 또는 기타 방어 조치로 보호되는 경우에도 애플리케이션이 악의적인 웹 대상에 액세스하도록 할 수있다.
- SSRF의 위험을 최소화하기 위해 최소 권한 액세스를 위한 시스템을 설계하고 WAF를 사용하여 보안 정책에 인터넷 식별자(URI) 매개 변수를 명시적으로 정의하고 액세스할 수 있는 호스트를 허용 및 차단해야한다.
& 개발자가 방지할 수 있는 역할
- 프론트엔드 개발자
- URL 입력과 관련된 사용자 입력을 철저히 검증하고, 외부 리소스 요청 시 적절한 제한을 둡니다.
- 백엔드 개발자
- 서버가 외부 리소스에 접근할 때 적절한 허용 목록(whitelist)이나 필터링 규칙을 적용하여 악의적인 요청을 차단합니다.
- 요청된 URL을 검사하고, 내부 시스템에 대한 접근을 제한합니다.
9.접근 제어 실패 (Broken Access Control)
: 인증된 세션과 같이 어떤 종류의 사용자 인증이 필요한 것에 접근할 수 있는 방법을 찾을 수 있을 때 엑세스 제어가 끊어진다.
이런 약점을 악용하면, 공격자가 민감한 정보 보기 , 다른 계정 수정 또는 관리 기능 액세스를 포함한 승인되지 않은 작업을 수행할 수 있다.
- 프론트엔드 개발자
- UI 요소에서 불필요한 정보가 노출되지 않도록 주의하고, 민감한 기능은 클라이언트 측에서 보호합니다.
- 백엔드 개발자
- API 호출에 대한 접근 제어를 철저히 관리하고, 인증된 사용자만 민감한 정보에 접근할 수 있도록 조치합니다.
- 역할 기반 접근 제어(RBAC)를 적용하여 권한에 맞는 액세스만 허용합니다.
10.보안 로깅 및 모니터링 실패(Security Logging and Monitoring Failures)
: 로깅/모니터링이 부족하면, 보안 침해를 탐지하고 모니터링하기가 어려워진다.
마무리 정리
- 현재 개발을 하면서 ,어찌보면 당연히 챙겨야 할 것들을 놓치고 있는 부분들도 있었는데 ,좀 더 신경써가면서 개발할 수 있을 것 같다.
- 한 페이지에 있는 기능들을 만들 때 , 기획과 디자인을 먼저 읽어보고 작업을 하는데 오늘 공부해본 내용도 생각해보면서, 적용해야할 것들이 있으면 의견을 좀 더 내면서 해봐야겠다.
- 위의 모든 사항들을 회사 프로젝트에서 적용하며 좋겠다는 생각도 들지만, 현재의 여건에 맞게 적용하는게 중요하기에 그것도 잘 생각해보 는게 좋은 것 같다.
참고
https://dev.to/bytehide/top-10-application-security-vulnerabilities-in-2024-1m9l
https://www.f5.com/ko_kr/glossary/owasp