보안 가이드라인
보안을 중요하게 생각합니다. CodeIgniter는 좋은 보안 관행을 강제하거나 쉽게 실행할 수 있도록 여러 기능과 기술을 포함합니다.
OWASP(Open Web Application Security Project)를 존중하며 가능한 한 그 권장사항을 따릅니다.
다음 내용은 OWASP Top Ten과 OWASP API Security Top 10에서 가져온 것으로, 웹 애플리케이션과 API의 상위 취약점을 식별합니다. 각 항목에 대해 간략한 설명, OWASP 권장사항, 그리고 문제를 해결하기 위한 CodeIgniter 조항을 제공합니다.
OWASP Top 10 2021
A01:2021 액세스 제어 위반
액세스 제어는 사용자가 의도된 권한 밖에서 행동할 수 없도록 정책을 적용합니다. 실패하면 일반적으로 권한 없는 정보 공개, 수정, 모든 데이터 파괴 또는 사용자 한도를 초과한 비즈니스 기능 수행으로 이어집니다.
일반적인 액세스 제어 취약점은 다음과 같습니다:
최소 권한 원칙 또는 기본 거부 원칙 위반: 액세스는 특정 기능, 역할 또는 사용자에게만 허용되어야 하지만 누구에게나 허용됩니다.
URL 수정(매개변수 변조 또는 강제 탐색), 내부 애플리케이션 상태 또는 HTML 페이지 수정을 통해, 또는 API 요청을 수정하는 공격 도구를 사용하여 액세스 제어 확인을 우회합니다.
고유 식별자(안전하지 않은 직접 객체 참조)를 제공하여 다른 사람의 계정을 보거나 편집하는 것을 허용합니다.
POST, PUT 및 DELETE에 대한 액세스 제어가 없는 API 접근.
권한 상승. 로그인하지 않고 사용자로 행동하거나, 일반 사용자로 로그인한 상태에서 관리자로 행동하는 것.
JSON 웹 토큰(JWT) 액세스 제어 토큰 재생 또는 변조, 또는 권한 상승을 위해 조작된 쿠키나 숨겨진 필드, JWT 무효화 남용 등의 메타데이터 조작.
CORS 잘못된 구성으로 인해 권한 없거나 신뢰할 수 없는 출처에서 API 접근이 허용됩니다.
인증되지 않은 사용자로 인증된 페이지에 강제 접근하거나 일반 사용자로 권한이 있는 페이지에 접근합니다.
OWASP 권장사항
액세스 제어는 공격자가 액세스 제어 확인이나 메타데이터를 수정할 수 없는 신뢰할 수 있는 서버 측 코드 또는 서버리스 API에서만 효과적입니다.
공개 리소스를 제외하고 기본값으로 거부합니다.
액세스 제어 메커니즘을 한 번 구현하여 교차 출처 리소스 공유(CORS) 사용 최소화를 포함하여 애플리케이션 전체에서 재사용합니다.
모델 액세스 제어는 사용자가 어떤 레코드든 생성, 읽기, 업데이트 또는 삭제할 수 있다는 것을 수용하는 것보다 레코드 소유권을 적용해야 합니다.
고유한 애플리케이션 비즈니스 제한 요구사항은 도메인 모델에 의해 적용되어야 합니다.
웹 서버 디렉토리 목록을 비활성화하고 파일 메타데이터(예: .git) 및 백업 파일이 웹 루트에 없도록 합니다.
액세스 제어 실패를 기록하고, 적절한 경우(예: 반복적인 실패) 관리자에게 알립니다.
자동화된 공격 도구로 인한 피해를 최소화하기 위해 API 및 컨트롤러 액세스를 속도 제한합니다.
상태형(Stateful) 세션 식별자는 로그아웃 후 서버에서 무효화되어야 합니다. 상태 없는(Stateless) JWT 토큰은 공격자의 기회 창을 최소화하기 위해 수명이 짧아야 합니다. 수명이 긴 JWT의 경우 액세스를 취소하기 위해 OAuth 표준을 따르는 것을 강력히 권장합니다.
CodeIgniter 보안 기능
공개 폴더(애플리케이션 및 시스템은 외부에 위치)
유효성 검사 라이브러리
세션 라이브러리 라이브러리
스로틀러 레이트 제한
log_message()로깅 함수공식 인증 및 권한 부여 프레임워크 CodeIgniter Shield
타사 인증을 쉽게 추가 가능
A02:2021 암호화 실패
첫 번째로 전송 중인 데이터와 저장된 데이터의 보호 필요성을 결정합니다. 예를 들어, 비밀번호, 신용카드 번호, 의료 기록, 개인 정보, 비즈니스 기밀은 특히 해당 데이터가 EU의 일반 데이터 보호 규정(GDPR) 같은 개인정보 보호법이나 PCI 데이터 보안 표준(PCI DSS) 같은 금융 데이터 보호 규정 적용을 받는다면 추가적인 보호가 필요합니다. 이러한 모든 데이터에 대해:
데이터가 일반 텍스트로 전송됩니까? HTTP, SMTP, FTP와 같은 프로토콜(STARTTLS 같은 TLS 업그레이드도 포함)이 이 범주에 해당합니다. 외부 인터넷 트래픽은 위험합니다. 로드 밸런서, 웹 서버 또는 백엔드 시스템 간 모든 내부 트래픽을 확인하세요.
오래되거나 약한 암호화 알고리즘 또는 프로토콜이 기본적으로 또는 이전 코드에서 사용됩니까?
기본 암호화 키가 사용 중이거나, 약한 암호화 키가 생성 또는 재사용되거나, 적절한 키 관리 또는 순환이 누락되어 있습니까? 암호화 키가 소스 코드 저장소에 체크인되어 있습니까?
암호화가 적용되지 않습니까? 예를 들어 HTTP 헤더(브라우저) 보안 지시문이나 헤더가 누락되어 있습니까?
수신된 서버 인증서와 신뢰 체인이 올바르게 검증되었습니까?
초기화 벡터가 무시되거나, 재사용되거나, 암호화 작동 모드에 충분히 안전하게 생성되지 않습니까? ECB와 같은 안전하지 않은 작동 모드가 사용 중입니까? 인증된 암호화가 더 적절한 경우에 암호화만 사용되고 있습니까?
비밀번호 기반 키 유도 함수 없이 암호화 키로 비밀번호가 사용되고 있습니까?
암호화 요구사항을 충족하도록 설계되지 않은 무작위성이 암호화 목적으로 사용됩니까? 올바른 함수가 선택되었더라도 개발자가 시드(seed)해야 하는 경우, 개발자가 충분한 엔트로피/예측 불가능성이 부족한 시드로 내장된 강력한 시드 기능을 덮어쓴 경우?
MD5 또는 SHA1 같은 더 이상 사용되지 않는 해시 함수가 사용되거나, 암호화 해시 함수가 필요할 때 비암호화 해시 함수가 사용됩니까?
PKCS 번호 1 v1.5 같은 더 이상 사용되지 않는 암호화 패딩 방법이 사용됩니까?
예를 들어 패딩 오라클 공격 형태로 암호화 오류 메시지나 사이드 채널 정보가 악용될 수 있습니까?
OWASP 권장사항
최소한 다음을 수행하고 참고 자료를 참조하세요:
애플리케이션이 처리, 저장 또는 전송하는 데이터를 분류합니다. 개인정보 보호법, 규제 요구사항 또는 비즈니스 필요에 따라 어떤 데이터가 민감한지 식별합니다.
불필요하게 민감한 데이터를 저장하지 마세요. 가능한 한 빨리 폐기하거나 PCI DSS 규정을 준수하는 토큰화 또는 절단을 사용하세요. 보유하지 않은 데이터는 도난당할 수 없습니다.
저장된 모든 민감한 데이터를 암호화해야 합니다.
최신의 강력한 표준 알고리즘, 프로토콜 및 키를 사용하고 적절한 키 관리를 합니다.
순방향 비밀성(FS) 암호, 서버의 암호 우선순위, 안전한 매개변수를 사용하는 TLS와 같은 보안 프로토콜로 전송 중인 모든 데이터를 암호화합니다. HTTP Strict Transport Security(HSTS) 같은 지시문을 사용하여 암호화를 적용합니다.
민감한 데이터를 포함하는 응답에 대해 캐싱을 비활성화합니다.
데이터 분류에 따라 필요한 보안 제어를 적용합니다.
민감한 데이터를 전송하기 위해 FTP 및 SMTP와 같은 레거시 프로토콜을 사용하지 마세요.
Argon2, scrypt, bcrypt 또는 PBKDF2와 같이 작업 인수(지연 인수)가 있는 강력한 적응형 및 솔트 해시 함수를 사용하여 비밀번호를 저장합니다.
초기화 벡터는 작동 모드에 적합하게 선택되어야 합니다. 많은 모드의 경우 이것은 CSPRNG(암호학적으로 안전한 의사 난수 생성기)를 사용함을 의미합니다. 논스(nonce)가 필요한 모드의 경우 초기화 벡터(IV)에 CSPRNG가 필요하지 않습니다. 모든 경우에 IV는 고정 키에 대해 두 번 사용되어서는 안 됩니다.
인증된 암호화를 항상 사용하세요 (단순 암호화만으로는 안 됨).
키는 암호학적으로 무작위로 생성되어 바이트 배열로 메모리에 저장되어야 합니다. 비밀번호가 사용된다면 적절한 비밀번호 기반 키 유도 함수를 통해 키로 변환해야 합니다.
암호화 무작위성이 적절한 경우에 사용되고, 예측 가능한 방식이나 낮은 엔트로피로 시드되지 않았는지 확인합니다. 대부분의 최신 API는 개발자가 보안을 위해 CSPRNG를 시드할 필요가 없습니다.
MD5, SHA1, PKCS 번호 1 v1.5와 같은 더 이상 사용되지 않는 암호화 함수 및 패딩 방식을 피합니다.
구성 및 설정의 효율성을 독립적으로 확인하세요.
CodeIgniter 보안 기능
전역 보안 접근을 위한 설정(
Config\App::$forceGlobalSecureRequests)데이터베이스 설정 (
encrypt)공식 인증 및 권한 부여 프레임워크 CodeIgniter Shield
A03:2021 인젝션
애플리케이션이 공격에 취약한 경우:
사용자가 제공한 데이터가 애플리케이션에 의해 검증, 필터링 또는 살균되지 않습니다.
컨텍스트 인식 이스케이핑 없는 동적 쿼리 또는 비매개변수화된 호출이 인터프리터에서 직접 사용됩니다.
적대적 데이터가 객체 관계형 매핑(ORM) 검색 매개변수 내에서 추가적인 민감한 레코드를 추출하는 데 사용됩니다.
적대적 데이터가 직접 사용되거나 연결됩니다. SQL 또는 명령에는 동적 쿼리, 명령 또는 저장 프로시저의 구조와 악성 데이터가 포함됩니다.
가장 일반적인 인젝션은 SQL, NoSQL, OS 명령, ORM, LDAP, 표현 언어(EL) 또는 OGNL 인젝션입니다. 개념은 모든 인터프리터에서 동일합니다. 소스 코드 검토는 애플리케이션이 인젝션에 취약한지 감지하는 가장 좋은 방법입니다. 모든 매개변수, 헤더, URL, 쿠키, JSON, SOAP 및 XML 데이터 입력의 자동화된 테스트를 강력히 권장합니다. 조직은 정적(SAST), 동적(DAST) 및 대화형(IAST) 애플리케이션 보안 테스팅 도구를 CI/CD 파이프라인에 통합하여 프로덕션 배포 전에 도입된 인젝션 결함을 식별할 수 있습니다.
OWASP 권장사항
인젝션을 방지하려면 데이터를 명령 및 쿼리와 분리해야 합니다:
선호하는 옵션은 인터프리터 사용을 완전히 피하거나, 매개변수화된 인터페이스를 제공하거나, ORM 도구로 마이그레이션하는 안전한 API를 사용하는 것입니다.
참고: 매개변수화된 경우에도 PL/SQL 또는 T-SQL이 쿼리와 데이터를 연결하거나 EXECUTE IMMEDIATE 또는 exec()로 적대적 데이터를 실행하는 경우 저장 프로시저는 여전히 SQL 인젝션을 도입할 수 있습니다.
긍정적인 서버 측 입력 검증을 사용합니다. 많은 애플리케이션이 텍스트 영역이나 모바일 애플리케이션용 API처럼 특수 문자가 필요하기 때문에 이것만으로는 완전한 방어가 되지 않습니다.
남아있는 동적 쿼리에 대해 해당 인터프리터의 특정 이스케이프 구문을 사용하여 특수 문자를 이스케이프합니다.
참고: 테이블 이름, 열 이름 등의 SQL 구조는 이스케이프할 수 없으므로 사용자 제공 구조 이름은 위험합니다. 이는 보고서 작성 소프트웨어에서 흔한 문제입니다.
SQL 인젝션 발생 시 대량 레코드 공개를 방지하기 위해 쿼리 내에 LIMIT 및 기타 SQL 제어를 사용합니다.
CodeIgniter 보안 기능
InvalidChars 필터
유효성 검사 라이브러리
esc()함수HTTP 라이브러리는 입력 필드 필터링 제공
콘텐츠 보안 정책 지원
A04:2021 안전하지 않은 설계
안전하지 않은 설계는 “누락되거나 비효율적인 제어 설계”로 표현되는 다양한 취약점을 나타내는 광범위한 범주입니다. 안전하지 않은 설계가 다른 모든 Top 10 위험 범주의 원인은 아닙니다. 안전하지 않은 설계와 안전하지 않은 구현 사이에는 차이가 있습니다. 우리는 설계 결함과 구현 결함을 이유가 있어 구별합니다. 두 가지는 서로 다른 근본 원인과 해결책을 가지고 있습니다.
안전한 설계는 여전히 취약점으로 이어지는 구현 결함을 가질 수 있습니다. 안전하지 않은 설계는 완벽한 구현으로도 수정될 수 없습니다. 정의상 특정 공격을 방어하기 위한 필요한 보안 제어가 결코 생성되지 않았기 때문입니다. 안전하지 않은 설계에 기여하는 요소 중 하나는 개발 중인 소프트웨어나 시스템에 내재된 비즈니스 위험 프로파일링 부재이며, 따라서 필요한 보안 설계 수준을 결정하지 못하는 것입니다.
OWASP 권장사항
보안 및 개인정보 보호 관련 제어를 평가하고 설계하는 데 도움이 되는 AppSec 전문가와 함께 안전한 개발 수명 주기를 수립하고 사용합니다.
사용 준비가 된 보안 설계 패턴 또는 포장도로(paved road) 구성 요소 라이브러리를 수립하고 사용합니다.
중요한 인증, 액세스 제어, 비즈니스 로직 및 주요 흐름에 위협 모델링을 사용합니다.
보안 언어 및 제어를 사용자 스토리에 통합
애플리케이션의 각 계층(프론트엔드에서 백엔드까지)에 타당성 확인을 통합합니다.
모든 중요한 흐름이 위협 모델에 저항하는지 검증하기 위해 단위 및 통합 테스트를 작성합니다. 애플리케이션의 각 계층에 대한 사용 사례 및 오용 사례를 컴파일합니다.
노출 및 보호 요구사항에 따라 시스템 및 네트워크 계층에서 계층을 분리합니다.
모든 계층에서 테넌트를 강력하게 분리하도록 설계
사용자 또는 서비스별 리소스 소비 제한
CodeIgniter 보안 기능
스로틀러 레이트 제한
공식 인증 및 권한 부여 프레임워크 CodeIgniter Shield
A05:2021 보안 구성 오류
다음과 같은 경우 애플리케이션이 취약할 수 있습니다:
애플리케이션 스택의 모든 부분에서 적절한 보안 강화가 누락되었거나 클라우드 서비스에 대한 권한이 잘못 구성되어 있습니다.
불필요한 기능이 활성화되거나 설치되어 있습니다(예: 불필요한 포트, 서비스, 페이지, 계정 또는 권한).
기본 계정 및 암호가 여전히 활성화되고 변경되지 않음.
오류 처리가 사용자에게 스택 추적이나 기타 지나치게 많은 정보를 포함하는 오류 메시지를 노출합니다.
업그레이드된 시스템의 경우 최신 보안 기능이 비활성화되거나 안전하게 구성되지 않았습니다.
애플리케이션 서버, 애플리케이션 프레임워크(예: Struts, Spring, ASP.NET), 라이브러리, 데이터베이스 등의 보안 설정이 안전한 값으로 설정되지 않았습니다.
서버가 보안 헤더나 지시문을 보내지 않거나, 안전한 값으로 설정되지 않았습니다.
소프트웨어가 구식이거나 취약합니다(A06:2021-취약하고 구식 구성요소 참조).
일관되고 반복 가능한 애플리케이션 보안 구성 프로세스 없이는 시스템이 더 높은 위험에 처합니다.
OWASP 권장사항
보안 설치 프로세스를 구현해야 합니다:
반복 가능한 강화 프로세스는 적절히 잠긴 환경을 빠르고 쉽게 배포할 수 있게 합니다. 개발, QA 및 프로덕션 환경은 각 환경에서 서로 다른 자격 증명으로 동일하게 구성되어야 합니다. 이 프로세스는 새로운 안전한 환경 설정에 필요한 노력을 최소화하기 위해 자동화되어야 합니다.
불필요한 기능, 구성 요소, 문서 및 샘플이 없는 최소한의 플랫폼. 사용되지 않는 기능과 프레임워크를 제거하거나 설치하지 마세요.
패치 관리 프로세스의 일부로 모든 보안 노트, 업데이트 및 패치에 적합한 구성을 검토하고 업데이트하는 작업(A06:2021-취약하고 구식 구성요소 참조). 클라우드 스토리지 권한(예: S3 버킷 권한)을 검토합니다.
세분화된 애플리케이션 아키텍처는 세분화, 컨테이너화 또는 클라우드 보안 그룹(ACL)을 통해 구성 요소 또는 테넌트 간에 효과적이고 안전한 분리를 제공합니다.
클라이언트에 보안 지시문 전송 (예: 보안 헤더).
모든 환경에서 구성 및 설정의 효율성을 확인하는 자동화된 프로세스.
CodeIgniter 보안 기능
기본값으로 Production mode
A06:2021 취약하고 구식 구성요소
다음과 같은 경우 취약할 가능성이 높습니다:
사용하는 모든 구성 요소의 버전(클라이언트 측 및 서버 측 모두)을 모르는 경우. 여기에는 직접 사용하는 구성 요소와 중첩된 의존성이 포함됩니다.
소프트웨어가 취약하거나, 지원이 중단되었거나, 구식인 경우. 여기에는 OS, 웹/애플리케이션 서버, 데이터베이스 관리 시스템(DBMS), 애플리케이션, API 및 모든 구성 요소, 런타임 환경, 라이브러리가 포함됩니다.
취약점을 정기적으로 검색하지 않고 사용하는 구성 요소와 관련된 보안 공지를 구독하지 않는 경우.
위험 기반, 시기 적절한 방식으로 기본 플랫폼, 프레임워크 및 의존성을 수정하거나 업그레이드하지 않는 경우. 이는 일반적으로 패치가 변경 제어 하에 월별 또는 분기별 작업인 환경에서 발생하며, 조직이 수정된 취약점에 며칠 또는 몇 달간 불필요하게 노출되게 합니다.
소프트웨어 개발자가 업데이트, 업그레이드 또는 패치된 라이브러리의 호환성을 테스트하지 않는 경우.
구성 요소의 구성을 보호하지 않는 경우(A05:2021-보안 구성 오류 참조).
OWASP 권장사항
패치 관리 프로세스를 실시해야 합니다:
사용하지 않는 의존성, 불필요한 기능, 구성 요소, 파일 및 문서를 제거합니다.
versions, OWASP Dependency Check, retire.js 등의 도구를 사용하여 클라이언트 측과 서버 측 구성 요소(예: 프레임워크, 라이브러리)와 그 의존성의 버전을 지속적으로 인벤토리합니다. CVE(공통 취약점 및 노출) 및 NVD(국가 취약점 데이터베이스)와 같은 소스를 지속적으로 모니터링합니다. 소프트웨어 구성 분석 도구를 사용하여 프로세스를 자동화합니다. 사용하는 구성 요소와 관련된 보안 취약점에 대한 이메일 경고를 구독합니다.
보안 링크를 통해 공식 소스에서만 구성 요소를 얻습니다. 수정된 악성 구성 요소가 포함될 가능성을 줄이기 위해 서명된 패키지를 선호합니다(A08:2021-소프트웨어 및 데이터 무결성 실패 참조).
유지 관리되지 않거나 이전 버전에 대한 보안 패치를 생성하지 않는 라이브러리 및 구성 요소를 모니터링합니다. 패치가 불가능한 경우 발견된 문제를 모니터링, 감지 또는 방어하기 위해 가상 패치 배포를 고려합니다.
모든 조직은 애플리케이션 또는 포트폴리오의 수명 동안 업데이트 또는 구성 변경 사항을 모니터링, 분류 및 적용하기 위한 지속적인 계획을 수립해야 합니다.
CodeIgniter 보안 기능
Composer를 통한 쉬운 업그레이드
A07:2021 식별 및 인증 실패
인증 관련 공격으로부터 보호하기 위해 사용자의 신원, 인증 및 세션 관리 확인이 중요합니다. 애플리케이션이 다음과 같다면 인증 취약점이 있을 수 있습니다:
공격자가 유효한 사용자 이름과 비밀번호 목록을 가지고 있는 자격 증명 채우기와 같은 자동화된 공격을 허용합니다.
무차별 대입 또는 기타 자동화된 공격을 허용합니다.
“Password1” 또는 “admin/admin”과 같이 기본, 약하거나 잘 알려진 비밀번호를 허용합니다.
안전하게 만들 수 없는 “지식 기반 답변”과 같이 약하거나 비효율적인 자격 증명 복구 및 비밀번호 찾기 프로세스를 사용합니다.
일반 텍스트, 암호화 또는 약하게 해시된 비밀번호 데이터 저장소를 사용합니다(A02:2021-암호화 실패 참조).
다중 인증이 없거나 효과적이지 않습니다.
URL에서 세션 식별자를 노출합니다.
성공적인 로그인 후 세션 식별자를 재사용합니다.
세션 ID를 올바르게 무효화하지 않습니다. 사용자 세션 또는 인증 토큰(주로 단일 로그인(SSO) 토큰)이 로그아웃 또는 비활성 기간 동안 올바르게 무효화되지 않습니다.
OWASP 권장사항
가능한 경우 자동화된 자격 증명 채우기, 무차별 대입 및 도난된 자격 증명 재사용 공격을 방지하기 위해 다중 인증을 구현합니다.
특히 관리자 사용자의 경우 기본 자격 증명으로 배송하거나 배포하지 마세요.
상위 10,000개의 최악의 비밀번호 목록에 대한 테스트와 같은 약한 비밀번호 확인을 구현합니다.
비밀번호 길이, 복잡성 및 순환 정책을 암기된 비밀의 섹션 5.1.1에 대한 NIST 800-63b의 지침 또는 기타 최신 증거 기반 비밀번호 정책에 맞춥니다.
등록, 자격 증명 복구 및 API 경로가 모든 결과에 동일한 메시지를 사용하여 계정 열거 공격에 강화되도록 합니다.
실패한 로그인 시도를 제한하거나 점점 더 지연시키되, 서비스 거부 시나리오를 만들지 않도록 주의합니다. 모든 실패를 기록하고 자격 증명 채우기, 무차별 대입 또는 기타 공격이 감지될 때 관리자에게 경고합니다.
로그인 후 높은 엔트로피를 가진 새로운 무작위 세션 ID를 생성하는 서버 측, 안전한, 내장 세션 관리자를 사용합니다. 세션 식별자는 URL에 있지 않아야 하고, 안전하게 저장되어야 하며, 로그아웃, 유휴 및 절대 타임아웃 후에 무효화되어야 합니다.
CodeIgniter 보안 기능
Session 라이브러리
공식 인증 및 권한 부여 프레임워크 CodeIgniter Shield
A08:2021 소프트웨어 및 데이터 무결성 실패
소프트웨어 및 데이터 무결성 실패는 무결성 위반으로부터 보호하지 않는 코드 및 인프라와 관련이 있습니다. 예를 들어 애플리케이션이 신뢰할 수 없는 소스, 저장소 및 CDN에서 플러그인, 라이브러리 또는 모듈에 의존하는 경우입니다. 안전하지 않은 CI/CD 파이프라인은 무단 액세스, 악성 코드 또는 시스템 침해의 가능성을 도입할 수 있습니다.
마지막으로, 많은 애플리케이션에는 이제 충분한 무결성 검증 없이 업데이트를 다운로드하고 이전에 신뢰했던 애플리케이션에 적용하는 자동 업데이트 기능이 포함됩니다. 공격자는 잠재적으로 모든 설치에 배포하고 실행될 자체 업데이트를 업로드할 수 있습니다.
또 다른 예는 공격자가 보고 수정할 수 있는 구조로 객체 또는 데이터가 인코딩되거나 직렬화될 경우 안전하지 않은 역직렬화에 취약한 경우입니다.
OWASP 권장사항
소프트웨어나 데이터가 예상 소스에서 왔으며 변경되지 않았음을 검증하기 위해 디지털 서명이나 유사한 메커니즘을 사용합니다.
npm 또는 Maven과 같은 라이브러리 및 의존성이 신뢰할 수 있는 저장소를 사용하는지 확인합니다. 더 높은 위험 프로파일이 있는 경우 검증된 내부 알려진 좋은 저장소 호스팅을 고려합니다.
OWASP Dependency Check 또는 OWASP CycloneDX와 같은 소프트웨어 공급망 보안 도구를 사용하여 구성 요소에 알려진 취약점이 없는지 확인합니다.
악성 코드나 구성이 소프트웨어 파이프라인에 도입될 가능성을 최소화하기 위해 코드 및 구성 변경에 대한 검토 프로세스가 있는지 확인합니다.
빌드 및 배포 프로세스를 통해 흐르는 코드의 무결성을 보장하기 위해 CI/CD 파이프라인에 적절한 분리, 구성 및 액세스 제어가 있는지 확인합니다.
서명되지 않거나 암호화되지 않은 직렬화된 데이터가 직렬화된 데이터의 변조나 재생을 감지하기 위한 무결성 확인이나 디지털 서명 없이 신뢰할 수 없는 클라이언트에 전송되지 않는지 확인합니다.
CodeIgniter 보안 기능
해당 없음
A09:2021 보안 로깅 및 모니터링 실패
이 범주는 활성 침해를 감지, 에스컬레이션 및 대응하는 데 도움이 됩니다. 로깅 및 모니터링 없이는 침해를 감지할 수 없습니다. 불충분한 로깅, 감지, 모니터링 및 적극적인 대응은 다음과 같은 경우에 발생합니다:
로그인, 실패한 로그인 및 고가치 거래와 같은 감사 가능한 이벤트가 기록되지 않습니다.
경고 및 오류가 로그 메시지를 생성하지 않거나 부족하거나 불명확합니다.
애플리케이션 및 API의 로그가 의심스러운 활동에 대해 모니터링되지 않습니다.
로그는 로컬에만 저장됩니다.
적절한 경고 임계값 및 응답 에스컬레이션 프로세스가 없거나 효과적이지 않습니다.
OWASP ZAP과 같은 동적 애플리케이션 보안 테스팅(DAST) 도구에 의한 침투 테스팅 및 스캔이 경고를 발생시키지 않습니다.
애플리케이션이 실시간 또는 준실시간으로 활성 공격을 감지, 에스컬레이션 또는 경고할 수 없습니다.
로깅 및 경고 이벤트를 사용자나 공격자에게 표시하여 정보 누출에 취약합니다(A01:2021-액세스 제어 위반 참조).
OWASP 권장사항
개발자는 애플리케이션의 위험에 따라 다음 제어 중 일부 또는 전부를 구현해야 합니다:
모든 로그인, 액세스 제어 및 서버 측 입력 유효성 검사 실패가 의심스럽거나 악의적인 계정을 식별하기에 충분한 사용자 컨텍스트로 기록될 수 있고 지연된 포렌식 분석을 허용하기에 충분한 시간 동안 보유될 수 있는지 확인합니다.
로그가 로그 관리 솔루션이 쉽게 소비할 수 있는 형식으로 생성되는지 확인합니다.
로그 데이터가 로깅 또는 모니터링 시스템에 대한 인젝션이나 공격을 방지하기 위해 올바르게 인코딩되는지 확인합니다.
추가 전용 데이터베이스 테이블 또는 유사한 방법과 같이 변조나 삭제를 방지하기 위한 무결성 제어가 있는 감사 추적을 고가치 거래에 보장합니다.
DevSecOps 팀은 의심스러운 활동이 신속하게 감지되고 대응될 수 있도록 효과적인 모니터링 및 경고를 수립해야 합니다.
NIST 800-61r2 또는 이후 버전과 같은 인시던트 응답 및 복구 계획을 수립하거나 채택합니다.
OWASP ModSecurity Core Rule Set과 같은 상용 및 오픈소스 애플리케이션 보호 프레임워크와 사용자 정의 대시보드 및 경고 기능을 갖춘 ELK(Elasticsearch, Logstash, Kibana) 스택과 같은 오픈소스 로그 상관 소프트웨어가 있습니다.
CodeIgniter 보안 기능
Logging 라이브러리
공식 인증 및 권한 부여 프레임워크 CodeIgniter Shield
A10:2021 서버 측 요청 위조(SSRF)
SSRF 결함은 웹 애플리케이션이 사용자가 제공한 URL의 유효성을 검사하지 않고 원격 리소스를 가져올 때 발생합니다. 이는 공격자가 방화벽, VPN 또는 다른 유형의 네트워크 액세스 제어 목록(ACL)으로 보호된 경우에도 애플리케이션이 예상치 못한 대상에 제작된 요청을 보내도록 강제할 수 있게 합니다.
최신 웹 애플리케이션이 최종 사용자에게 편리한 기능을 제공함에 따라, URL 가져오기가 일반적인 시나리오가 되었습니다. 결과적으로 SSRF 발생이 증가하고 있습니다. 또한 클라우드 서비스와 아키텍처의 복잡성으로 인해 SSRF의 심각도가 높아지고 있습니다.
OWASP 권장사항
개발자는 다음 심층 방어 제어 중 일부 또는 전부를 구현하여 SSRF를 방지할 수 있습니다:
네트워크 계층에서:
SSRF의 영향을 줄이기 위해 별도의 네트워크에서 원격 리소스 액세스 기능을 분리합니다.
“필수 인트라넷 트래픽을 제외한 모든 것을 차단하기 위해 “”기본 거부”” 방화벽 정책 또는 네트워크 액세스 제어 규칙을 적용합니다.”
힌트:
애플리케이션을 기반으로 방화벽 규칙의 소유권 및 수명 주기를 수립합니다.
방화벽에서 허용되고 차단된 모든 네트워크 흐름을 기록합니다(A09:2021-보안 로깅 및 모니터링 실패 참조).
애플리케이션 계층에서:
모든 클라이언트가 제공한 입력 데이터를 새니타이즈하고 검증하세요
긍정 허용 목록으로 URL 스키마, 포트 및 대상을 적용하세요
클라이언트에 원본 응답을 보내지 마세요
HTTP 리다이렉션 비활성화
DNS 재바인딩 및 “확인 시간, 사용 시간”(TOCTOU) 경쟁 조건과 같은 공격을 피하기 위해 URL 일관성을 인식합니다.
거부 목록이나 정규 표현식으로 SSRF를 완화하지 마세요. 공격자는 거부 목록을 우회할 페이로드 목록, 도구 및 기술을 가지고 있습니다.
CodeIgniter 보안 기능
유효성 검사 라이브러리
HTTP 라이브러리는 입력 필드 필터링 제공
OWASP API 보안 Top 10 2023
API2:2023 손상된 인증
인증 메커니즘은 종종 잘못 구현되어 공격자가 인증 토큰을 손상시키거나 구현 결함을 이용하여 다른 사용자의 ID를 일시적으로 또는 영구적으로 가정할 수 있게 합니다. 클라이언트/사용자를 식별하는 시스템의 능력을 손상시키면 전체적으로 API 보안이 손상됩니다.
OWASP 권장사항
API에 인증하는 모든 가능한 흐름을 알고 있는지 확인합니다(모바일/웹/딥 링크로 원클릭 인증 구현 등). 엔지니어에게 어떤 흐름을 놓쳤는지 물어보세요.
인증 메커니즘에 대해 읽습니다. 무엇이고 어떻게 사용되는지 이해하는지 확인하세요. OAuth는 인증이 아니며 API 키도 마찬가지입니다.
인증, 토큰 생성 또는 비밀번호 저장에서 바퀴를 재발명하지 마세요. 표준을 사용하세요.
자격 증명 복구/비밀번호 찾기 엔드포인트는 무차별 대입, 속도 제한 및 잠금 보호 측면에서 로그인 엔드포인트처럼 취급되어야 합니다.
민감한 작업(예: 계정 소유자 이메일 주소/2FA 전화번호 변경)에 재인증을 요구합니다.
OWASP 인증 치트시트를 사용하세요.
가능한 경우 다중 인증을 구현하세요.
인증 엔드포인트에 대한 자격 증명 채우기, 딕셔너리 공격 및 무차별 대입 공격을 완화하기 위한 반무차별 대입 메커니즘을 구현합니다. 이 메커니즘은 API의 일반 속도 제한 메커니즘보다 더 엄격해야 합니다.
특정 사용자에 대한 무차별 대입 공격을 방지하기 위해 계정 잠금/캡챠 메커니즘을 구현합니다. 약한 비밀번호 확인을 구현합니다.
API 키는 사용자 인증에 사용되어서는 안 됩니다. API 클라이언트 인증에만 사용되어야 합니다.
CodeIgniter 보안 기능
spark routes 명령어
공식 인증 및 권한 부여 프레임워크 CodeIgniter Shield
스로틀러 레이트 제한
API4:2023 제한되지 않은 리소스 소비
API 요청을 처리하려면 네트워크 대역폭, CPU, 메모리 및 저장소와 같은 리소스가 필요합니다. 이메일/SMS/전화 통화 또는 생체 인식 유효성 검사와 같은 다른 리소스는 API 통합을 통해 서비스 제공자가 제공하며 요청당 요금이 부과됩니다. 성공적인 공격은 서비스 거부 또는 운영 비용 증가로 이어질 수 있습니다.
OWASP 권장사항
컨테이너/서버리스 코드(예: Lambda)와 같이 메모리, CPU, 재시작 횟수, 파일 디스크립터 및 프로세스를 쉽게 제한할 수 있는 솔루션을 사용합니다.
문자열의 최대 길이, 배열의 최대 요소 수, 최대 업로드 파일 크기(로컬 또는 클라우드 스토리지에 저장 여부에 관계없이)와 같이 모든 수신 매개변수 및 페이로드에 대한 최대 데이터 크기를 정의하고 적용합니다.
정의된 시간 내에 클라이언트가 API와 상호 작용할 수 있는 횟수에 대한 제한을 구현합니다(속도 제한).
속도 제한은 비즈니스 요구사항에 따라 세밀하게 조정되어야 합니다. 일부 API 엔드포인트는 더 엄격한 정책이 필요할 수 있습니다.
단일 API 클라이언트/사용자가 단일 작업을 실행할 수 있는 횟수나 빈도를 제한/조절합니다(예: OTP 유효성 검사 또는 일회성 URL을 방문하지 않고 비밀번호 복구 요청).
쿼리 문자열 및 요청 본문 매개변수, 특히 응답에서 반환될 레코드 수를 제어하는 것에 대해 적절한 서버 측 유효성 검사를 추가합니다.
모든 서비스 제공자/API 통합에 대한 지출 한도를 구성합니다. 지출 한도를 설정할 수 없는 경우 청구 경고를 대신 구성해야 합니다.
CodeIgniter 보안 기능
API6:2023 민감한 비즈니스 흐름에 대한 제한되지 않은 접근
이 위험에 취약한 API는 자동화된 방식으로 과도하게 사용될 경우 비즈니스에 해를 끼칠 수 있는 방법을 보상하지 않고 티켓 구매나 댓글 게시 같은 비즈니스 흐름을 노출합니다. 이것이 반드시 구현 버그에서 비롯된 것은 아닙니다.
OWASP 권장사항
완화 계획은 두 계층으로 수행되어야 합니다:
비즈니스 - 과도하게 사용될 경우 비즈니스에 해를 끼칠 수 있는 비즈니스 흐름을 식별합니다.
엔지니어링 - 비즈니스 위험을 완화하기 위한 적절한 보호 메커니즘을 선택합니다.
일부 보호 메커니즘은 더 간단하고 다른 것들은 구현하기 더 어렵습니다. 다음 방법들이 자동화된 위협을 늦추는 데 사용됩니다:
디바이스 지문: 예상치 못한 클라이언트 디바이스(예: 헤드리스 브라우저)에 서비스를 거부하면 위협 행위자들이 더 정교한 솔루션을 사용하게 되어 비용이 더 많이 드는 경향이 있습니다.
인간 감지: 캡챠 또는 더 고급 생체 인식 솔루션 사용(예: 타이핑 패턴)
비인간 패턴: 사용자 흐름을 분석하여 비인간 패턴을 감지합니다(예: 사용자가 1초 이내에 “장바구니에 추가” 및 “구매 완료” 기능에 액세스)
Tor 종료 노드 및 잘 알려진 프록시의 IP 주소 차단 고려
머신에서 직접 소비되는 API(예: 개발자 및 B2B API)에 대한 액세스를 보호하고 제한합니다. 이러한 API는 종종 필요한 모든 보호 메커니즘을 구현하지 않기 때문에 공격자의 쉬운 목표가 되는 경향이 있습니다.
CodeIgniter 보안 기능
해당 없음
API7:2023 서버 측 요청 위조
서버 측 요청 위조(SSRF) 결함은 API가 사용자가 제공한 URI의 유효성을 검사하지 않고 원격 리소스를 가져올 때 발생할 수 있습니다. 이는 공격자가 방화벽이나 VPN으로 보호된 경우에도 애플리케이션이 예상치 못한 대상에 제작된 요청을 보내도록 강제할 수 있게 합니다.
OWASP 권장사항
네트워크에서 리소스 가져오기 메커니즘을 격리합니다: 일반적으로 이러한 기능은 내부가 아닌 원격 리소스를 검색하는 것을 목표로 합니다.
가능한 경우 다음의 허용 목록을 사용하세요:
사용자가 리소스를 다운로드할 것으로 예상되는 원격 출처(예: Google Drive, Gravatar 등)
URL 스키마 및 포트
주어진 기능에 대해 허용된 미디어 유형
HTTP 리다이렉션을 비활성화하세요.
URL 파싱 불일치로 인한 문제를 피하기 위해 잘 테스트되고 유지 관리되는 URL 파서를 사용합니다.
모든 클라이언트가 제공한 입력 데이터를 검증하고 새니타이즈하세요.
클라이언트에 원본 응답을 보내지 마세요.
CodeIgniter 보안 기능
유효성 검사 라이브러리
HTTP 라이브러리는 입력 필드 필터링 제공
CURLRequest 클래스
URI 클래스
API8:2023 보안 구성 오류
API와 이를 지원하는 시스템은 일반적으로 API를 더 맞춤화 가능하게 만들기 위한 복잡한 구성을 포함합니다. 소프트웨어 및 DevOps 엔지니어는 이러한 구성을 놓치거나 구성에 관한 보안 모범 사례를 따르지 않아 다양한 유형의 공격의 문을 열 수 있습니다.
OWASP 권장사항
API 수명 주기에는 다음이 포함되어야 합니다:
적절히 잠긴 환경의 빠르고 쉬운 배포로 이어지는 반복 가능한 강화 프로세스
전체 API 스택에 걸쳐 구성을 검토하고 업데이트하는 작업. 검토에는 오케스트레이션 파일, API 구성 요소 및 클라우드 서비스(예: S3 버킷 권한)가 포함되어야 합니다.
모든 환경에서 구성 및 설정의 효율성을 지속적으로 평가하는 자동화된 프로세스
더욱이:
내부 또는 공개 API 여부에 관계없이 클라이언트에서 API 서버 및 모든 다운스트림/업스트림 구성 요소로의 모든 API 통신이 암호화된 통신 채널(TLS)을 통해 이루어지는지 확인합니다.
각 API가 액세스할 수 있는 HTTP 동사를 구체적으로 지정합니다: 다른 모든 HTTP 동사는 비활성화되어야 합니다(예: HEAD).
브라우저 기반 클라이언트(예: WebApp 프론트엔드)에서 액세스할 것으로 예상되는 API는 최소한 다음을 수행해야 합니다:
적절한 CORS(교차 원본 리소스 공유) 정책 구현
적용 가능한 보안 헤더 포함
비즈니스/기능 요구사항을 충족하는 것들로 수신 콘텐츠 유형/데이터 형식을 제한합니다.
디싱크 문제를 피하기 위해 HTTP 서버 체인(예: 로드 밸런서, 역방향 및 순방향 프록시, 백엔드 서버)의 모든 서버가 동일한 방식으로 수신 요청을 처리하는지 확인합니다.
해당되는 경우 공격자에게 예외 추적 및 기타 귀중한 정보가 전송되는 것을 방지하기 위해 오류 응답을 포함한 모든 API 응답 페이로드 스키마를 정의하고 적용합니다.
CodeIgniter 보안 기능
전역 보안 접근을 위한 설정(
Config\App::$forceGlobalSecureRequests)
API9:2023 부적절한 인벤토리 관리
API는 전통적인 웹 애플리케이션보다 더 많은 엔드포인트를 노출하는 경향이 있어 적절하고 업데이트된 문서가 매우 중요합니다. 호스트 및 배포된 API 버전의 적절한 인벤토리도 더 이상 사용되지 않는 API 버전 및 노출된 디버그 엔드포인트와 같은 문제를 완화하는 데 중요합니다.
OWASP 권장사항
모든 API 호스트를 인벤토리하고 API 환경(예: 프로덕션, 스테이징, 테스트, 개발), 호스트에 대한 네트워크 액세스 권한이 있어야 하는 사람(예: 공개, 내부, 파트너) 및 API 버전에 초점을 맞추어 각각의 중요한 측면을 문서화합니다.
통합 서비스를 인벤토리하고 시스템에서의 역할, 교환되는 데이터(데이터 흐름) 및 민감도와 같은 중요한 측면을 문서화합니다.
인증, 오류, 리다이렉트, 속도 제한, CORS 정책 및 엔드포인트(매개변수, 요청 및 응답 포함)와 같은 API의 모든 측면을 문서화합니다.
오픈 표준을 채택하여 자동으로 문서를 생성합니다. CI/CD 파이프라인에 문서 빌드를 포함합니다.
API 문서를 API 사용을 위해 인증된 사람들만 사용할 수 있도록 하세요.
현재 프로덕션 버전만이 아니라 노출된 모든 버전의 API에 대해 API 보안 특정 솔루션과 같은 외부 보호 조치를 사용합니다.
비프로덕션 API 배포에 프로덕션 데이터를 사용하지 마세요. 이것이 불가피한 경우 이러한 엔드포인트는 프로덕션 엔드포인트와 동일한 보안 처리를 받아야 합니다.
새로운 버전의 API에 보안 개선 사항이 포함된 경우 이전 버전에 필요한 완화 조치를 알리기 위해 위험 분석을 수행합니다. 예를 들어, API 호환성을 깨지 않고 개선 사항을 백포트할 수 있는지 또는 이전 버전을 빠르게 제거하고 모든 클라이언트가 최신 버전으로 이동하도록 강제해야 하는지 여부.
CodeIgniter 보안 기능
spark routes 명령어
API10:2023 안전하지 않은 API 소비
개발자는 사용자 입력보다 서드파티 API에서 받은 데이터를 더 신뢰하는 경향이 있어 더 약한 보안 표준을 채택합니다. API를 손상시키기 위해 공격자는 대상 API를 직접 손상시키려는 대신 통합된 서드파티 서비스를 공격합니다.
OWASP 권장사항
서비스 제공자를 평가할 때 API 보안 태세를 평가하세요.
모든 API 상호 작용이 보안 통신 채널(TLS)을 통해 이루어지는지 확인합니다.
통합 API에서 받은 데이터를 사용하기 전에 항상 검증하고 적절히 살균합니다.
통합 API가 리다이렉트할 수 있는 잘 알려진 위치의 허용 목록을 유지합니다: 리다이렉트를 맹목적으로 따르지 마세요.
CodeIgniter 보안 기능
CURLRequest 클래스
유효성 검사 라이브러리