오픈 웹 애플리케이션 보안 프로젝트(OWASP)에서는 가장 시급한 웹 애플리케이션 보안 문제에 대한 목록을 정기적으로 업데이트하고 있습니다.
이 글을 읽은 후에 다음을 할 수 있습니다:
관련 콘텐츠
인터넷에서 가장 인기 있는 인사이트를 한 달에 한 번 정리하는 Cloudflare의 월간 요약본 theNET를 구독하세요!
글 링크 복사
오픈 웹 애플리케이션 보안 프로젝트(OWASP)는 웹 애플리케이션 보안에 전념하는 국제 비영리 단체입니다. OWASP의 핵심 원칙 중 하나는 웹 사이트에서 모든 자료를 무료로 제공하고 쉽게 액세스할 수 있도록 하여 누구나 웹 애플리케이션 보안을 개선할 수 있도록 하는 것입니다. 제공하는 자료에는 문서, 도구, 동영상, 포럼 등이 있습니다. 아마도 가장 잘 알려진 프로젝트는 OWASP 상위 10가지일 것입니다.
OWASP 상위 10가지는 정기적으로 업데이트되는 보고서로, 가장 중요한 10가지 위험에 초점을 맞춰 웹 애플리케이션 보안에 대한 보안 문제를 설명합니다. 이 보고서는 전 세계 보안 전문가로 구성된 팀에서 작성합니다. OWASP에서는 상위 10가지를 '인식 문서'라고 부르며 모든 기업에서 보안 위험을 최소화 및/또는 완화하기 위해 이 보고서를 프로세스에 통합하는 것을 권장합니다.
다음은 2021년 OWASP 상위 10가지 보고서에서 발표한 보안 위험입니다.
액세스 제어는 정보 또는 기능에 대한 액세스를 제어하는 시스템을 말합니다. 액세스 제어가 손상되면 공격자는 인증을 우회하여 관리자 등의 권한이 있는 사용자처럼 작업을 수행할 수 있습니다. 예를 들어 웹 애플리케이션에서는 사용자가 다른 인증 없이 URL의 일부를 변경하는 것만으로 로그인한 계정을 변경할 수 있습니다.
웹 애플리케이션이 인증 토큰*을 사용하고 이에 대한 엄격한 제어를 설정하도록 하여 액세스 제어를 보호할 수 있습니다.
*많은 서비스에서 사용자가 로그인할 때 인증 토큰을 발급합니다.사용자가 수행하는 모든 권한 요청에는 인증 토큰이 있어야 합니다.이는 로그인 자격 증명을 계속 입력할 필요 없이 사용자가 본인임을 확인할 수 있는 안전한 방법입니다.
웹 애플리케이션이 암호화를 사용하여 금융 정보, 비밀번호 등의 중요한 데이터를 보호하지 않으면 공격자가 해당 데이터에 액세스하여 이를 판매하거나 악의적인 목적으로 활용할 수 있습니다. 또한 경로상 공격을 사용하여 중요한 정보를 훔칠 수 있습니다.
데이터 노출 위험운 모든 중요한 데이터를 암호화하고, 모든 전송을 인증하며, 중요한 정보의 캐싱*을 비활성화하면 최소화할 수 있습니다. 또한 웹 애플리케이션 개발자는 중요한 데이터를 불필요하게 저장하지 않도록 주의해야 합니다.
*캐싱은 재사용을 위해 데이터를 임시로 저장하는 작업입니다.예를 들어, 웹 브라우저에서는 종종 웹 페이지를 캐시하여 사용자가 일정 시간 내에 해당 페이지를 다시 방문할 경우 브라우저가 웹에서 페이지를 가져올 필요가 없도록 합니다.
삽입 공격은 신뢰할 수 없는 데이터가 양식 입력이나 웹 애플리케이션에 대한 기타 데이터 제출을 통해 코드 인터프리터로 전송될 때 발생합니다. 예를 들어, 공격자는 일반 텍스트 사용자 이름을 예상하는 양식에 SQL 데이터베이스 코드를 입력할 수 있습니다. 양식 입력이 제대로 보호되지 않으면 해당 SQL 코드가 실행될 수 있습니다. 이를 SQL 삽입 공격이라고 합니다.
삽입 범주에는 이전에 2017 보고서에서 별도의 범주로 분류되었던 Cross-site scripting(XSS) 공격도 포함됩니다. Cross-site scripting에 대한 완화 전략에는 신뢰할 수 없는 HTTP 요청을 이스케이프 처리하고 기본 제공 Cross-site scripting 보호 기능을 제공하는 ReactJS, Ruby on Rails 등의 최신 웹 개발 프레임워크를 사용하는 것이 포함됩니다.
일반적으로 삽입 공격은 사용자가 제출한 데이터의 유효성을 검사 및/또는 삭제하여 방지할 수 있습니다. (유효성 검사는 의심스러운 데이터를 거부하는 것을 의미하며, 삭제는 데이터에서 의심스러운 부분을 정리하는 것을 말합니다.) 또한 데이터베이스 관리자는 삽입 공격으로 인해 노출될 수 있는 정보의 양을 최소화하도록 제어 기능을 설정할 수 있습니다.
SQL 삽입 방지 방법에 대해 자세히 알아보세요.
안전하지 않은 설계에는 애플리케이션의 아키텍처에 포함될 수 있는 다양한 약점이 포함됩니다. 이는 애플리케이션의 구현이 아닌 설계에 중점을 둡니다. OWASP에서는 비밀번호 복구를 위한 보안 질문(예: "어느 거리에서 자랐습니까?")을 사용하는 것을 설계상 안전하지 않은 워크플로우의 한 가지 사례로 나열합니다. 개발자가 이러한 워크플로우를 아무리 완벽하게 구현하더라도, 두 명 이상의 사람이 이러한 보안 질문에 대한 답을 알고 있기 때문에 애플리케이션은 여전히 취약할 것입니다.
애플리케이션을 배포하기 전에 위협 모델링을 사용하면 이러한 유형의 취약점을 완화하는 데 도움이 될 수 있습니다.
보안 구성 오류는 목록에서 가장 흔한 취약점으로, 기본 구성을 사용하거나 지나치게 장황한 오류를 표시한 결과인 경우가 많습니다. 예를 들어, 애플리케이션에서 사용자에게 애플리케이션의 취약점을 드러낼 수 있는, 지나치게 설명이 많다는 오류를 표시할 수 있습니다. 코드에서 사용하지 않는 기능을 제거하고 오류 메시지를 보다 일반화하면 이러한 문제를 완화할 수 있습니다.
보안 오류 구성 범주에는 XML 외부 엔터티(XEE) 공격이 포함됩니다. 이는 2017년 보고서에서 별도로 분류되었습니다. 이는 XML* 입력을 구문 분석하는 웹 애플리케이션에 대한 공격입니다. 이 입력은 외부 엔터티를 참조하여 파서의 취약점을 악용하려고 시도할 수 있습니다. 여기서 '외부 엔터티'는 하드 드라이브와 같은 저장 장치를 의미합니다. XML 파서는 속아서 권한이 없는 외부 엔터티로 데이터를 보낼 수 있으며, 이 엔터티는 중요한 데이터를 공격자에게 직접 전달할 수 있습니다. XEE 공격을 방지하는 가장 좋은 방법은 웹 애플리케이션이 JSON과 같이 덜 복잡한 유형의 데이터를 허용하도록 하거나, 최소한 XML 파서를 패치하고 XML 애플리케이션에서 외부 엔터티를 사용하지 않도록 설정하는 것입니다.
*확장 가능한 마크업 언어(XML)는 사람도 읽을 수 있고 기계도 읽을 수 있도록 고안된 마크업 언어입니다. XML은 복잡성과 보안 취약점으로 인해 현재 많은 웹 애플리케이션에서 단계적으로 사용이 중단되고 있습니다.
많은 최신 웹 개발자는 웹 애플리케이션에서 라이브러리 및 프레임워크와 같은 구성 요소를 사용합니다. 이러한 구성 요소는 개발자가 중복 작업을 피하고 필요한 기능을 제공하는 데 도움이 되는 소프트웨어로, 그 일반적인 예로는 React와 같은 프런트엔드 프레임워크와 공유 아이콘이나 A/B 테스트를 추가하는 데 사용되는 소규모 라이브러리가 있습니다. 일부 공격자는 이러한 구성 요소에서 취약점을 찾아 공격을 조율하는 데 사용할 수 있습니다. 일부 인기 있는 구성 요소는 수십만 개의 웹 사이트에서 사용되며, 공격자가 이러한 구성 요소 중 하나에서 보안 허점을 발견하면 수십만 개의 사이트가 익스플로잇에 취약해질 수 있습니다.
구성 요소 개발자는 알려진 취약점을 해결하기 위해 보안 패치와 업데이트를 제공하는 경우가 많지만, 웹 애플리케이션 개발자가 애플리케이션에서 항상 패치된 구성 요소나 최신 버전의 구성 요소를 실행하는 것은 아닙니다. 알려진 취약점이 있는 구성 요소를 실행할 위험을 최소화하려면 개발자는 프로젝트에서 사용하지 않는 구성 요소를 제거하고, 신뢰할 수 있는 출처로부터 최신 상태의 구성 요소를 받고 있는지 확인해야 합니다.
인증(로그인) 시스템에 취약점이 있으면 공격자에게 사용자 계정에 대한 액세스 권한이 주어지고 관리자 계정을 사용하여 전체 시스템을 손상시킬 능력이 주어질 수 있습니다. 예를 들어, 공격자는 데이터 유출로 얻은 수천 개의 알려진 사용자 이름/비밀번호 조합이 포함된 목록을 가져와 스크립트를 사용하여 로그인 시스템에서 모든 조합을 시도하여 작동하는 조합이 있는지 확인할 수 있습니다.
인증 취약점을 완화하기 위한 몇 가지 전략은 2단계 인증(2FA)을 요구하고 레이트 리미팅을 사용하여 로그인 시도 반복을 제한하거나 지연시키는 것입니다.
오늘날 많은 애플리케이션은 기능을 위해 타사 플러그인 및 기타 외부 소스에 의존하고 있으며, 이러한 소스의 업데이트 및 데이터가 변조되지 않았고 예상되는 위치에서 생성되었는지 항상 확인하지는 않습니다. 예를 들어, 자동으로 외부 소스의 업데이트를 수락하는 애플리케이션은 자체의 악의적 업데이트를 업로드하는 공격자에게 취약할 수 있으며, 이는 해당 애플리케이션의 모든 설치에 배포됩니다. 이 범주에는 안전하지 않은 역직렬화 익스플로잇도 포함됩니다. 이러한 공격은 신뢰할 수 없는 소스의 데이터를 역직렬화하여 발생하는 것으로, DDoS 공격, 원격 코드 실행 공격 등의 심각한 결과가 초래될 수 있습니다.
데이터 및 업데이트의 무결성이 침해되지 않도록 하려면 애플리케이션 개발자는 디지털 서명을 사용하여 업데이트를 확인하고, 소프트웨어 공급망을 확인하며, 지속적 통합/지속적 배포(CI/CD) 파이프라인에 강력한 접근 제어가 마련되어 있고 올바르게 구성되어 있는지 확인해야 합니다.
많은 웹 애플리케이션에서 데이터 유출을 감지하기 위한 충분한 조치를 취하지 않고 있습니다. 유출이 발견되는 데 걸리는 평균 시간은 유출이 발생한 후 약 200일입니다. 따라서 공격자가 대응하기 전에 피해를 입힐 수 있는 많은 시간이 주어집니다. OWASP에서는 웹 개발자가 로깅 및 모니터링과 사고 대응 계획을 구현하여 애플리케이션에 대한 공격을 인지할 수 있도록 할 것을 권장합니다.
서버 측 요청 위조(SSRF)는 누군가가 서버에 URL 요청을 보내, 해당 리소스가 보호되고 있더라도 서버가 예기치 않은 리소스를 가져오게 하는 공격입니다. 예를 들어, 공격자는 웹 사용자가 해당 위치로 이동할 수 없어야 하는 경우에도 www.example.com/super-secret-data/에 대한 요청을 보내고 서버의 응답을 통해 최고 비밀 데이터에 접근할 수 있습니다.
SSRF 공격에는 여러 가지 완화책이 있고, 가장 중요한 완화책 중 하나는 클라이언트에서 오는 모든 URL을 검증하는 것입니다. 유효하지 않은 URL은 서버로부터 직접적인 원시 응답으로 이어지지 않아야 합니다.
OWASP 상위 10가지에 대한 보다 기술적이고 심층적인 내용은 공식 보고서에서 확인할 수 있습니다.