OWASP Top 10 취약점 및 Rails 방어 전략

1. 서버 측 요청 위조 (SSRF)

악의적인 공격자가 취약한 서버를 통해 내부 또는 외부 리소스에 요청을 보내는 공격입니다. IP 주소 유출이나 내부 네트워크 접근에 사용될 수 있습니다. * 방어 전략: 사용자 입력 데이터 검증, 네트워크 세분화(incoming/outgoing 트래픽 분리), 원시 요청을 클라이언트에 반환하지 않기, 의심스러운 활동 로그 모니터링.

2. 보안 로깅 및 모니터링 실패

보안 사고 발생 시 이를 감지하고 대응하는 데 필수적인 로깅과 모니터링이 부실한 경우를 의미합니다. * 방어 전략: 모든 의심스러운 활동 로깅, 로그인 실패 증가와 같은 경고 설정, 민감 정보(비밀번호, 신용카드 번호) 로깅 금지 (Rails의 parameter_filter 활용).

3. 식별 및 인증 실패

인증 및 세션 관리와 관련된 취약점입니다. 강력한 비밀번호 정책, 다단계 인증, 속도 제한 등이 부족할 때 발생합니다. * 방어 전략: 강력한 비밀번호 정책(복잡성, 유출 여부 확인 - pwned gem), 다단계 인증(2FA) 구현(특히 비밀번호 재설정 시 - devise-two-factor, ROTP gem), 인증 실패 시 일반적인 메시지 사용, 속도 제한(Rails 7.2 내장 Rate Limiter 또는 rack-attack gem), has_secure_password, has_secure_token, authenticate_by 등 Rails 헬퍼를 통한 강력한 암호화 및 타이밍 공격 방지.

4. 취약하고 오래된 구성요소

사용 중인 라이브러리, 프레임워크, 기타 소프트웨어 구성요소에 알려진 취약점이 포함되어 있거나 오래된 경우입니다. * 방어 전략: Dependabot(GitHub), bundler-audit를 사용하여 취약한 의존성 주기적으로 확인 및 업데이트.

5. 보안 미설정

기본 보안 설정이 부족하거나 잘못 구성되어 발생하는 취약점입니다. * 방어 전략: 프로덕션 환경에서 개발 기능(예: 상세 로깅) 비활성화, Sidekiq UI와 같은 관리 도구에 인증 적용.

6. 안전하지 않은 설계

보안을 고려하지 않은 애플리케이션 설계로 인해 발생하는 취약점입니다. 기획 단계부터 보안을 고려하는 것이 중요합니다. * 방어 전략: 기능 기획 단계에서 ‘무엇이 잘못될 수 있는가?’ 질문을 던져 잠재적 위험 식별.

7. 인젝션

신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부로 해석되어 실행될 때 발생합니다(SQL 인젝션, NoSQL 인젝션). * 방어 전략: Active Record는 대부분의 인젝션을 방지하지만, calculate, delete_by, destroy_by, exists? 등 사용자 제어 문자열을 직접 전달할 수 있는 일부 API 사용 시 주의. railsqli.org에서 상세 목록 확인. 데이터베이스에 저장된 사용자 입력이 나중에 안전하지 않은 API에 사용될 때 발생하는 ‘2차 SQL 인젝션’에도 유의.

8. 암호화 실패

암호화 관련 기능이 부적절하게 구현되거나 사용될 때 발생합니다. * 방어 전략: 직접 암호화 로직을 구현하지 않고, Rails의 내장 암호화 라이브러리(Active Record encryption, has_secure_password, has_secure_token) 사용.

9. 접근 제어 실패 (인가 문제)

사용자가 허용되지 않은 리소스나 기능에 접근할 수 있을 때 발생합니다. * 방어 전략: 강력한 인가(Authorization) 규칙 적용 및 모든 곳에서 강제, 화이트리스트(whitelist) 기반 접근 제어, UID는 인가를 대체하지 않음(UID 유출 가능성), 외래 키(Foreign Key)를 통한 레코드 생성 시 사용자 ID 조작 방지.