Last Updated on 6월 5th, 2023, By
 In AppSealing News, 앱실링 블로그

시장의 애플리케이션 수가 폭발적으로 증가하면서 보안은 주요 관심사가 되었습니다. OWASP는 소프트웨어 보안을 향상시키기 위해 기사, 문서, 방법론, 도구 및 기술을 생산하는 비영리 재단 인 Open Web Application Security Project의 약자입니다. OWASP는 증가하는 사이버 공격을 고려하여 무료 및 공개 리소스를 오픈하기 시작했습니다.
애플리케이션은 데이터 도난 및 조작을 위한 해커의 주요 대상입니다. 보안을 사소하게 다루면 기업과 소비자 모두에게 돌이킬 수 없는 피해를 줄 수 있습니다.
수많은 애플리케이션이 정기적으로 사이버 공격을 받기 때문에 적절한 보안 조치를 배포하는 것이 가장 중요합니다. 통계를 살펴보면 데이터 유출 시도의 약 43 %가 웹 애플리케이션에 대한 것이었습니다. ASVS는 애플리케이션의 보안을 강화하기 위해 개발된 OWASP의 핵심 프로젝트 중 하나입니다. 본문에서는 OWASP ASVS와 보안팀에 대한 중요성에 대해 설명합니다.

OWASP ASVS가 무엇인가요?

ASVS는 애플리케이션 보안 검증 표준의 약자입니다. OWASP ASVS 프로젝트에는 테스터, 개발자, 보안 전문가 및 소비자를 위한 보안 요구 사항 목록이 포함되어 있습니다. ASVS는 웹 애플리케이션 기술 보안 제어를 테스트하기 위한 기초 역할을 하는 보안 요구 사항 및 제어 프레임워크를 설정합니다.
ASVS의 목적은 웹 애플리케이션 개발 및 테스트의 여러 단계에서 구현된 기능 및 비기능 보안 제어를 정규화 하는 보안 프레임워크를 구축하는 것입니다. ASVS는 개방형 표준을 사용하여 애플리케이션 보안 검증을 관리합니다.
ASVS는 테스터와 보안 전문가가 XSS(교차 사이트 스크립팅) 및 SQL 삽입 공격에 대한 보호를 제공하기 위해 앱 환경에 배포된 제어 및 애플리케이션 내의 보안 제어를 테스트하는 데 도움이 되는 온라인 커뮤니티 활동입니다.

ASVS는 아래에 언급된 목표를 달성하기 위해 개발되었습니다.
1. 지표로 사용: ASVS는 앱 개발자가 앱의 보안 수준을 결정하는 척도 역할을 할
수 있습니다.
2. 지침으로 사용: 요구 사항을 효과적으로 충족할 수 있도록 구현할 보안 제어에 대한 지침도 제공합니다.
3. 조달 중에 사용: 도구 및 서비스를 조달할 때 계약서에 애플리케이션 보안검증 요구사항을 명시하는 지침 역할을 합니다.

ASVS 3.0과 ASVS 4.0의 주요 차이점 이해

ASVS 4.0은 시장을 평가하고 업계 전문가의 피드백을 통합한 후 2019 년 3 월에 출시되었습니다. ASVS 3.0과 ASVS 4.0의 주요 차이점을 빠르게 이해해 보겠습니다.

  1. ASVS의 최신 버전은 DevSecOps 방식을 다루며 레벨 0은 제거되었습니다.
  2. 이전 버전에는 자동화된 공구 스캔 및 기본 침투 테스트를 위한 레벨 0A와 0B가 각각 있었으며 레벨 1은 새 버전의 기본 레벨 테스트입니다. 새 버전은 이전 버전보다 더 많은 OWASP Top 10 취약점을 다루는 레벨 1로 시작합니다.
  3. 새 버전에서는 애플리케이션의 소스 코드 또는 문서에 액세스하지 않고 레벨 1을 덮는 것이 좋습니다.
  4. 새 ASVS 문서는 이전 버전에 비해 이해하기 쉽습니다. 요구 사항은 이제 분할되어 하위 장으로 나뉩니다.
  5. 버전 4에는 키 자격 증명 모음과 GUID가 포함되어 있습니다. 또한 백업, 캐시 및 보조 데이터 저장소는 보호해야 할 자산 목록에 새로 추가된 것입니다.
  6. ASVS 4.0 버전에 도입한 개인 정보 보호 제어에 대한 새로운 섹션이 있습니다.
  7. 최신 버전에는 암호 대체 및 암호 복잡성 요구 사항이 포함됩니다. 또한 인증 토큰 및 암호 관리자도 다룹니다.
  8. 비즈니스 로직 검증 요구 사항 섹션이 새 버전에 위협 모델링을 포함하도록 확장되었습니다.

ASVS 4.0 버전의 새로운 기능은?

새 버전은 이해하기 쉽도록 더 긴 챕터는 더 작은 챕터로 재구성하여 나뉘어져 있습니다. 이렇게 하면 개발자 또는 팀이 준수해야 하는 제어를 최소화할 수 있습니다. 자신의 애플리케이션에 적용되지 않는 섹션은 건너뛸 수 있습니다. 새 버전에 추가된 주요 기능 중 하나는 증거 기반 인증 제어를 다루는 NIST 800-63-3 디지털 ID 지침입니다. 이 지침은 디지털 ID 서비스를 구현하는 기관의 요구 사항을 간략하게 설명합니다. 4.0 버전에는 도구 제조업체가 다른 도구 및 이전 버전의 ASVS의 취약성 평가 결과를 일치시키는 데 도움이 되는 CWE 매핑이 포함되어 있습니다.
새 버전에는 OWASP Top 10 2017 및 OWASP 사전 제어 2018을 준수하는 데 도움이 되는 보안 체크리스트가 포함되어 있습니다. 최신 버전은 버퍼 오버플로, 안전하지 않은 메모리 작업 및 안전하지 않은 메모리 관련 컴파일 플래그에 대한 장을 포함하므로 PCI DSS 3.2.1 규정도 준수합니다. ASVS는 이전에는 서버 측 컨트롤에 중점을 두었지만 이제는 모든 API 및 애플리케이션을 포함합니다. 새 버전에는 오래되었거나 관련성이 낮은 보안 제어가 더 이상 포함되어 있지 않습니다.

애플리케이션 보안 확인 수준 이해
ASVS에는 서로 다른 보안 요구 사항을 가진 애플리케이션의 보안을 강화하도록 설계된 세 가지 수준의 보안 검증이 있습니다. 그들은 다음과 같습니다:

ASVS 레벨 1 기본

ASVS 레벨 1은 민감한 정보를 처리하지 않고 공격에 덜 취약한 애플리케이션과 관련이 있습니다. 모든 애플리케이션은 ASVS 레벨1에 명시된 기본 보안 표준을 준수해야 합니다. 이 레벨에서는 알려진 취약성으로부터 보호하도록 설계된 보안 제어를 간략하게 설명합니다. 이 레벨에 나열된 보안 조치는 펜 테스트 가능하고 통합 테스트가 가능합니다. 레벨1은 주요 보안 위험에 직면하지 않는 중소기업에 적합합니다.

ASVS 레벨 2 표준

레벨 2 지침은 B2B 거래를 수행하는 애플리케이션에 적용할 수 있습니다. 이러한 지침을 따르면 앱 개발자는 불법 액세스, 인젝션 결함, 유효성 검사 및 인증 오류로부터 애플리케이션을 보호하는 데 도움이 됩니다. ASVS 레벨 2 표준은 구현된 조치가 애플리케이션에 중점적으로 위험을 초래하는 취약성 및 위협과 일치하는지 확인합니다. ASVS 레벨 2는 대부분의 애플리케이션을 보호하기 위해 보안 전문가가 권장합니다. 이 수준에서 테스트하려면 소스 코드, 문서, 구성 및 개발에 관련된 사람들에 대한 액세스가 필요합니다.

ASVS 레벨 3 고급

매우 민감한 정보를 처리하는 애플리케이션은 ASVS 레벨 3 고급을 준수해야 합니다. 이러한 애플리케이션의 예로는 의료, 국방, 금융, 법률 문서 관리 앱 등이 있습니다. 레벨 3의 요구 사항을 충족하려면 앱 개발자는 초기 단계부터 애플리케이션에 보안 계층을 포함해야 합니다. 또한 모든 보안에 관련된 내용을 문서화하고 감사해야 합니다

ASVS 4.0 구조 개요

다음은 ASVS 문서에서 다루는 장으로, 특정 보안 요구 사항을 충족하는 지침이 포함되어 있습니다.

V1: 아키텍처, 설계 및 위협 모델링 요구 사항

첫 번째 장의 주요 초점은 가용성, 개인 정보 보호, 기밀성, 무결성 및 부인방지 입니다. 또한 이 장에서는 최신 보안 시스템에 대한 위협 모델링의 관련성을 강조합니다.

V2: 인증 및 검증 요구 사항

ASVS 4.0의 두 번째 장에서는 고급 인증 방법에 대해 설명합니다. 이 장은 많은 변화가 있었습니다. 해싱 및 암호화와 같은 보다 안전한 방법은 이 장에서 논의됩니다.

V3: 세션 관리 확인 요구 사항

이 장에서는 애플리케이션이 소유해야 하는 중요한 세션 관리 기능을 중점적으로 설명합니다. 명심해야 할 기능은 다음과 같습니다.

  • 세션은 각 개인마다 고유해야합니다.
  • 상당한 시간 동안 작업/입력이 없는 경우 세션을 일시 중단해야 합니다.

V4: 액세스 제어 확인 요구 사항

애플리케이션에 대한 액세스 제어 요구 사항을 충족하기 위한 지침은 다음과 같습니다.

  • 애플리케이션은 필수 자격 증명을 가진 사용자에게만 액세스를 허용해야 합니다.
  • 제한된 수의 사용자에게만 특정 권한 및 역할이 할당되어야 합니다.
  • 도난 및 변조로부터 보호하기 위해 액세스 제어 및 권한 메타데이터를 안전하게 저장해야 합니다.

V5: 검증, 클린 및 인코딩 검증 요구 사항

이 장에서는 입력 유효성 검사를 위한 보안 파이프라인 설정 및 주입 공격을 방지하기 위한 출력 인코딩과 같은 요구 사항에 중점을 둡니다. 또한 애플리케이션에서 입력 데이터의 범위와 길이를 올바르게 확인하고 출력 데이터를 인코딩하여 악의적인 실행코드로부터 보호해야합니다.

V6: 저장된 암호화 검증 요구 사항

여섯 번째 장에서는 애플리케이션이 다음 요구 사항을 충족하도록 요구합니다.

  • 애플리케이션에는 보안 오류 처리 메커니즘이 있어야합니다.
  • 구현된 암호화 모듈은 안전해야 합니다.
  • 애플리케이션의 암호화와 일치하는 효율적인 숫자 생성기가 있어야합니다.
  • 암호화 키는 안전하게 저장해야 합니다.

V7: 오류 처리 및 로깅 확인 요구 사항

문서의 일곱 번째 장에서는 로깅 및 오류 처리를 다룹니다. 애플리케이션은 절대적으로 필수적인 경우가 아니면 중요한 사용자 정보를 수집하지 않아야 합니다. 기록된 데이터는 규정된 표준을 준수하여 보호되어야 하며 수집된 데이터는 일정 기간 후에 삭제되어야 합니다.

V8: 데이터 보호 검증 요구 사항

기밀성, 가용성 및 무결성은 이 장에서 중점을 두고 있습니다. 데이터 기밀성은 항상 유지되어야 합니다(저장 및 전송). 또한 합법적 인 사용자가 계속 액세스 할 수 있도록 보장하면서 데이터를 조작 및 삭제로부터 보호해야합니다.

V9: 통신 검증 요구 사항

이 장에서는 항상 암호화 및 전송 계층 보안을 사용하는 것의 중요성을 강조합니다. 앱 개발자는 보안이 떨어지는 오래된 알고리즘에 의존하기보다는 최신 보안 알고리즘을 사용해야 합니다. 개발자는 최적의 성능과 보안을 유지하기 위해 때때로 보안이 떨어지는 암호와 알고리즘을 대체해야 합니다.

V10: 악성 코드 확인 요구 사항

이 장에서는 전체 애플리케이션에 영향을 미치지 않으면서 악성 활동을 관리하는 것의 중요성을 강조합니다. 애플리케이션에는 루트킷, 시한 폭탄 또는 해커가 악용 할 수있는 기타 유해한 요소와 같은 요소가 없어야합니다.

V11: 비즈니스 로직 검증 요구 사항

애플리케이션은 이 장에 따라 다음과 같은 비즈니스 논리 검증 요구 사항을 충족해야 합니다.
• 비즈니스 로직은 해커가 회피하기 어렵게 만드는 엄격한 보안으로 구축되어야 합니다.
• 비즈니스 논리는 순차적이어야합니다.
• 공격을 탐지하고 완화할 수 있어야 합니다.
• 변조 및 스푸핑과 같은 보안 결함을 효과적으로 해결해야 합니다.

V12: 파일 및 리소스 확인 요구 사항

열두 번째 장에서는 애플리케이션이 알 수 없는 원본의 데이터를 관리하기 위한 안전하고 규정을 준수하는 메커니즘이 있어야 한다고 기술합니다. 또한 신뢰할 수 없는 출처에서 수집된 데이터에 대해 제한된 사용 권한을 요구합니다. 이러한 데이터는 항상 웹 루트 외부에 저장해야 합니다.

V13: API 및 웹 서비스 검증 요구 사항

이 장에서는 애플리케이션의 API에 대해 설명합니다. 다음 요구 사항을 충족해야 합니다.

  •  API에 세션 관리 매개 변수가 있어야 합니다. 웹 서비스에 액세스하려면 적절한 인증이 있어야 합니다.
  •  매개 변수가 낮은 신뢰 수준에서 더 높은 신뢰 수준으로 이동하는 경우 적절한 입력 유효성 검사가 있어야 합니다.
  •  클라우드 및 서버리스 API를 처리하는 동안 필수 보안 제어를 구현해야 합니다.

V14: 구성 및 검증 요구 사항

이 장에서는 애플리케이션 환경이 항상 취약성으로부터 보호해야 한다는 구성 요구 사항을 다룹니다. 앱 개발자는 타사 라이브러리를 모니터링하고 구성 및 종속성 관리 시스템을 구현하여 애플리케이션 보안에 위험을 초래하는 구성 요소를 제거해야 합니다.

보안 감사를 위한 OWASP ASVS 체크리스트

보안 감사 체크리스트에서 다루는 여러 섹션을 살펴 보겠습니다.

아키텍쳐:

이 섹션에서는 광범위한 보안 요구 사항을 다룹니다. 위협 모델링 검증에서 애플리케이션의 액세스 제어 메커니즘 분석에 이르기까지 아키텍처 섹션은 애플리케이션의 신뢰 경계를 확인하는 데 도움이 됩니다.

인증:

이 체크리스트는 자격 증명 확인, 자격 증명의 안전한 저장, 인증 경로 및 ID 관리 API의 확인이 포함된 인증 요구 사항을 다룹니다. 암호 보안 요구 사항, 일반 인증자 요구 사항, 인증자 라이프싸이클 요구 사항, 자격 증명 저장소 요구 사항, 자격 증명 복구 요구 사항, 조회 비밀 검증 도구 요구 사항, 대역 외 검증 도구 요구 사항, 단일 또는 다중 요소 일회성 검증 도구 요구 사항, 암호화 소프트웨어 및 장치 검증 도구 요구 사항 및 서비스 인증 요구 사항을 다룹니다.

세션 관리:

이 체크리스트에서는 세션 로그아웃 및 시간 초과를 관리하기 위해 충족해야 하는 요구 사항을 간략하게 설명합니다. 또한 세션 관리 악용에 대한 방어와 함께 쿠키 기반 및 토큰 기반 세션 관리가 포함됩니다.

액세스 제어:

액세스 제어는 서버, 액세스 제어 게이트웨이 및 서버리스 기능에 적용되어야 합니다. 액세스 제어는 애플리케이션의 요구 사항을 충족할 수 있을 만큼 유연해야 합니다. 이 목록에서는 일반 액세스 제어 설계, 작동 수준 액세스 제어 및 기타 액세스 제어 고려 사항을 다룹니다.

입력 유효성 검사:

입력 및 출력 요구 사항을 확인하여 유형, 콘텐츠 및 관련 법률에 따라 데이터 처리 기술을 정의하는지 확인해야 합니다. 체크리스트에는 입력 유효성 검사 요구 사항부터 직렬화 해제 방지 요구 사항에 이르기까지 모든 것이 포함됩니다.

미사용 암호화

이 체크리스트는 강력한 암호화 아키텍처를 갖는 것의 중요성을 강조합니다. 암호화 키의 저장소는 제대로 관리되어야 합니다. 키와 암호는 교체 가능해야 하며 클라이언트와 공유되는 대칭 키는 위험도가 낮은 데이터를 보호하는 데만 사용해야 합니다. 데이터 분류, 알고리즘, 랜덤값 및 비밀관리는 이 섹션에서 중점을 두고 있습니다.

오류 처리 및 로깅:

이 섹션에서는 주로 로그 콘텐츠 확인 및 로그 처리 및 로그 보호에 대한 요구 사항과 오류 처리에 대해 다룹니다.

데이터 보호:

민감한 데이터는 체크리스트의 이 부분에서 언급한 것처럼 다양한 보호 수준으로 분류되어야 합니다. 이 섹션에서는 클라이언트 측 및 일반 데이터 보호와 관련된 지침도 다룹니다.

통신 보안:

서버 통신 보안 요구 사항이 포함된 이 체크리스트에는 애플리케이션이 구성 요소 간의 모든 통신을 암호화해야 한다고 나와 있습니다. 통신과 관련된 모든 구성 요소는 중간자 공격을 피하기 위해 보안되어야 합니다. 신뢰할 수 있는 TLS 인증서만 사용해야 합니다.

악성 코드:

이 섹션에서는 코드 분석 도구의 검증에 대해 다룹니다. 악성 코드 검색, 코드 무결성 제어 및 애플리케이션 무결성 제어는 이 섹션의 범위에 포함됩니다.

비즈니스 로직:

이 섹션에는 외부 위협으로부터 애플리케이션을 보호하는 모든 비즈니스 논리 보안 요구 사항이 수반됩니다.

파일 및 리소스:

이 섹션에서는 파일의 안전한 업로드를 위해 충족해야 할 요구 사항을 중점적으로 설명합니다. 파일 업로드 요구 사항, 파일 무결성 요구 사항, 파일 저장소 요구 사항, 파일 다운로드 요구 사항 및 SSRF 보호 요구 사항을 다룹니다.

웹 서비스:

이 섹션에서는 RESTful 웹 서비스 확인, SOAP 웹 서비스 확인, 일반 웹 서비스 보안, GraphQL 및 기타 웹 서비스 데이터 계층 보안 요구 사항과 관련된 요구 사항을 제공합니다.

구성:

이 체크리스트에는 빌드, 종속성, HTTP 보안 헤더 및 의도하지 않은 보안 공개와 관련된 요구 사항이 포함됩니다.

최종 고려사항

OWASP ASVS는 개발자와 보안 팀이 철저한 웹 애플리케이션 보안 평가를 수행할 수 있도록 보다 포괄적인 테스트 범위를 제공합니다. ASVS 표준에는 3가지 수준이 있으며 각 수준은 애플리케이션의 특성에 따라 다양한 보안 요구 사항을 충족하도록 설계되었습니다. ASVS 표준을 준수하면 애플리케이션의 보안이 크게 향상됩니다. 요즘 사이버 공격이 증가함에 따라 ASVS를 사용하는 것이 모든 조직이 시장에서 신뢰성과 명성을 유지하는 것이 좋습니다. OWASP ASVS에 나열된 보안 지침을 따르면 조직이 보안을 우선시하고 있음을 증명합니다.

애플리케이션 취약성이 확산됨에 따라 기업은 웹 애플리케이션에 대한 포괄적 인 평가를 수행하는 것이 필수적이었으며 OWASP ASVS는 개발 팀이 애플리케이션 보안을 강화하기 위한 완벽한 가이드 역할을 합니다. ASVS는 애플리케이션의 신뢰를 평가하는 척도로 사용할 수 있습니다. 여기에는 286개의 컨트롤이 포함되어 있으며 보안 서비스 제공업체는 ASVS를 테스트의 기반으로 사용하여 표준화되고 반복 가능한 서비스를 제공할 수 있습니다. 개발 및 평가 활동을 적절한 ASVS 수준과 일치시키면 향후 비용이 많이 드는 수정작업으로부터 기업을 보호할 수 있습니다.

AppSealing은 Android, iOS 및 하이브리드 앱의 보안을 전문으로 하는 강력한 모바일 애플리케이션 보안 솔루션 제공 업체입니다. 게임, 핀테크, O2O 및 전자 상거래와 같은 산업 전반에 걸친 전문 지식을 갖춘 당사는 공격 벡터에 대한 위협 분석을 통해 인앱 확장 가능한 보호 기능을 제공합니다. 제로 코딩 기능을 특징으로하는 당사의 보안 솔루션은 타사 도구와 호환되며 데이터 도난, 변조 및 무단 액세스로부터 중요한 데이터를 쉽게 보호할 수 있습니다. 저희에게 연락하시고 보안 솔루션을 활용하여 악의적인 행위자로부터 애플리케이션을 보호하세요.

 

Dustin Hong
Dustin Hong
Dustin은 잉카엔트웍스의 앱실링 비즈니스 개발을 이끌고 있습니다. 그는 사이버 보안, IT, 컨텐츠 및 애플리케이션 보안 분야의 소프트웨어 개발과 혁신에 많은 관심을 가지고 있습니다. 또한 사이버 보안 세계에서 주요 사건의 대상, 이유 및 방법에 대해 다양한 사람들에게 공유하고 토론하는 것을 좋아합니다. 업계 동향 및 모범 사례에 대한 그의 견해는 기사, 백서에 실려있으며, 여러 보안 행사에서 유사 주제로 발표를 하였습니다.