알아야 할 일반적인 웹 애플리케이션 취약점 22가지
게시 됨: 2021-10-14기업은 지속적으로 "좌측으로 이동"하고 클라우드 기반 애플리케이션이 제공하는 혁신적인 고객 및 직원 경험을 활용하고 있습니다. 동시에 악의적인 가해자들도 이러한 변화에 맞게 공격 전략을 지속적으로 수정하고 있습니다.
데이터 개인 정보 보호 및 보안을 유지하려면 기업이 이러한 22가지 일반적인 웹 애플리케이션 취약점 으로부터 보호를 찾는 것이 필수적입니다.
손상된 액세스 제어
액세스 제어는 사용자가 리소스 및 데이터와 상호 작용하는 방법과 편집 및/또는 읽을 수 있는 항목을 담당합니다. 사용자가 실제로 불필요한 방식으로 데이터를 사용할 수 있는 경우 잘못된 액세스 제어 취약점이 발생할 수 있습니다. 예를 들어, 사용자가 지불 세부 정보를 읽을 수만 있어야 하지만 실제로 편집할 수 있는 능력이 있는 경우 이러한 상황은 액세스 제어가 깨진 예입니다. 악의적인 공격자는 이 취약점을 이용하여 소프트웨어, 네트워크 및 시스템에 대한 무단 액세스를 얻습니다. 그런 다음 상황을 악용하고 사용자 ID에 인프라 내에서 더 많은 액세스 권한을 부여하여 데이터 가용성, 기밀성 또는 무결성을 손상시킬 수 있습니다.
손상된 인증
손상되거나 손상된 인증과 관련된 웹 응용 프로그램 취약성 은 또한 사용자 액세스에서 비롯됩니다. 그러나 이 경우 악의적인 공격자는 세션 토큰, 키 또는 암호를 도용하는 등 사용자의 신원을 확인하는 데이터에 부정적인 영향을 미칩니다. 악의적인 공격자는 조직이 적절한 ID 및 액세스 관리 제어를 적절하게 설정할 수 없기 때문에 소프트웨어, 시스템 및 네트워크에 대한 무단 액세스를 얻습니다.
캐리지 리턴 및 라인 피드(CRLF) 주입
캐리지 리턴은 일반적으로 /r로 표시되는 코드 행의 시작을 나타내는 명령으로 작동합니다. 반면에 줄 바꿈은 일반적으로 /n으로 표시되는 코드 줄의 끝을 나타내는 명령입니다. 다른 여러 소프트웨어와 마찬가지로 각 운영 체제는 캐리지 리턴과 줄 바꿈의 다양한 조합을 사용합니다. 악의적인 공격자가 CRLF 주입에 연루되면 입력된 코드가 웹 애플리케이션이 명령에 반응하는 방식을 변경합니다. 이것은 민감한 데이터를 공개하거나 코드를 실행하는 데 사용될 수 있습니다.
암호 변환이 안전하지 않음
"암호화 알고리즘"의 표준 용어인 Cipher는 실제로 암호화 또는 암호 해독 프로세스의 이면에 있는 수학입니다. 변환은 예상 출력을 제공하기 위해 입력에 대해 수행되는 작업의 개요를 나타냅니다. 따라서 암호 변환은 읽을 수 없는 암호화된 데이터를 다시 읽을 수 있고 해독된 데이터로 바꾸는 작업의 수를 나타냅니다. 암호 변환 안전하지 않은 취약점은 암호화 알고리즘이 쉽게 손상되어 궁극적으로 첫 번째 인스턴스에서 암호화의 본질을 방해할 수 있음을 나타냅니다.
명백한 취약점이 있는 구성요소
모든 웹 응용 프로그램은 다른 구성 요소에 따라 작동합니다. 예를 들어, 패치되지 않은 웹이나 애플리케이션 서버에서 애플리케이션을 운영하는 경우 서버는 명백한 취약점이 있는 부분입니다. CVE(Common Vulnerabilities and Exposures) 목록은 알려진 모든 보안 취약점으로 구성됩니다. 악의적인 공격자는 목록을 알고 있기 때문에 적절한 보안 패치 업데이트가 없는 구성 요소를 자주 찾습니다. 웹 애플리케이션의 한 구성 요소에 침투하는 순간 애플리케이션의 데이터에도 액세스할 수 있습니다.
CORS(교차 출처 리소스 공유) 정책
모든 웹 기반 응용 프로그램은 사용자의 브라우저를 서버에 연결하는 매체로 URL을 사용합니다. 동일 출처 정책은 하나의 공통 보호입니다. 이에 따라 서버는 동일한 프로토콜, 경로 스키마 및 최상위 도메인 이름을 가진 URL에만 응답합니다. 이것이 의미하는 바는 http://organization.com/page1 및 http://organization.com/page2가 모두 다음을 공유하기 때문에 액세스할 수 있다는 것입니다.
- 프로토콜: HTTP
- 도메인: Company.com
- 경로 스키마: /page#
동일 출처 정책은 안전하지만 제3자 또는 하위 도메인에 연결하는 리소스에 액세스해야 하는 웹 기반 앱을 처리할 때 제한적입니다.
CORS 정책은 "신뢰할 수 있는" 것으로 간주되는 허용된 여러 HTTP 헤더를 설정하여 이러한 상호 관련된 리소스를 볼 수 있는 브라우저 권한을 부여합니다. 예를 들어, 응용 프로그램은 별도의 웹 서버에 있는 두 데이터베이스에서 데이터를 가져와야 할 수 있습니다. 특정 "허용" 목록을 작성하는 것은 추가 서버를 포함할 때 과도한 작업이 됩니다. 두 서버 모두 애플리케이션을 "공유"하고 있기 때문에 회사는 브라우저가 둘 다에 연결할 수 있도록 허용하는 CORS 정책을 작성합니다. 그러나 CORS 정책이 제대로 정의되지 않은 경우 정책은 악의적인 공격자가 요청할 때 서버가 액세스 권한을 부여하도록 할 수 있습니다.
자격 증명 관리
사용자 자격 증명은 사용자 ID와 암호 키로 구성됩니다. 사용자는 응용 프로그램에 대한 액세스 권한을 얻기 전에 로그인 페이지에 두 가지 정보 항목을 모두 제공해야 합니다. 그러나 데이터베이스는 약한 암호화를 사용하거나 정보를 일반 텍스트로 유지하는 경향이 있습니다. 자격 증명 관리가 부실하면 공격자가 자격 증명을 쉽게 훔치고 이를 악용하여 웹 응용 프로그램에 액세스할 수 있습니다.
CSRF(교차 사이트 요청 위조)
CSRF 공격은 사회 공학 방법론을 사용하여 사용자가 애플리케이션에서 암호나 사용자 이름과 같은 정보를 수정하도록 합니다. XXS(교차 사이트 스크립팅) 공격이나 맬웨어와 달리 CSRF는 사용자 요청을 확인하거나 세션을 추적하기 위해 세션 쿠키만 사용하는 응용 프로그램에 사용자가 로그인해야 합니다. 사용자가 예상한 작업을 수행하는 순간 악의적인 행위자는 사용자가 알지 못한 채 브라우저를 사용하여 자금 이동과 같은 공격의 나머지 부분을 실행합니다.
교차 사이트 스크립팅(XXS)
사용자가 특정 정보를 변경하도록 속이기 위해 앱에 로그인해야 하는 CSRF와 달리 XXS 공격은 악의적인 공격자가 일반적으로 이미지와 같은 페이지의 일부 구성 요소에 있는 웹 페이지에 코드를 입력해야 합니다. 사용자가 브라우저에서 웹 페이지를 실행하면 잘못된 코드가 브라우저에서 다운로드되어 실행되기 시작합니다. 예를 들어, 악성 코드는 신뢰할 수 있는 사이트에서 불법 사이트로 사용자를 리디렉션할 수 있습니다.
디렉토리 인덱싱
일반적으로 웹 서버는 단일 디렉토리에 저장된 모든 파일의 개요를 설명합니다. 사용자가 웹 응용 프로그램에서 특정 파일을 찾으려면 일반적으로 요청에 파일 이름을 추가합니다. 파일을 사용할 수 없는 경우 응용 프로그램은 색인이 생성된 모든 파일의 목록을 사용자에게 표시하므로 사용자가 다른 파일을 선택할 수 있습니다.
그러나 파일은 웹 서버에 의해 자동으로 인덱싱됩니다. 응용 프로그램이 저장된 모든 파일 목록을 표시하면 디렉터리 인덱스의 취약점을 이용하는 악의적인 공격자가 시스템에 대한 추가 정보를 제공할 수 있는 데이터에 액세스할 수 있습니다. 예를 들어 개인 사용자 계정이나 명명 규칙에 대해 알 수 있습니다. 이 두 데이터 포인트는 자격 증명 도용 공격을 수행하거나 민감한 정보를 푸는 데 악용될 수 있습니다.
디렉토리 순회
역추적 공격(backtracking attack), 점-점-슬래시(dot-dot-slash) 및 디렉토리 상승으로도 알려진 디렉토리 탐색 취약점은 애플리케이션이 웹 서버에서 데이터를 수신하는 방식을 악용합니다. ACL(액세스 제어 목록)은 일반적으로 루트 디렉터리 내의 특정 파일에 대한 사용자 액세스를 제한합니다. 디렉터리 탐색 취약점 모드를 사용하는 악의적인 공격자는 응용 프로그램이 파일을 요청할 때 사용하는 URL 형식을 알아냅니다.
캡슐화
목록에 있는 다른 일반적인 웹 애플리케이션 취약점 과 달리 캡슐화 취약점은 개발자가 애플리케이션을 코딩하는 방식의 결함을 이용합니다. 캡슐화는 데이터와 해당 데이터에 대해 수행할 수 있는 작업을 하나의 단위로 묶는 것을 의미하는 프로그래밍 용어입니다. 캡슐화는 더 나은 사용자 인터페이스를 제공하는 코드 실행 방법에 대한 정보를 숨겨 데이터를 보호합니다. 사용자는 애플리케이션이 데이터를 어떻게 전달하는지 알 필요가 없습니다. 필요한 것은 액세스뿐입니다.
예를 들어 앱 개발자는 읽기 또는 쓰기 권한과 같은 액세스 제어를 애플리케이션이 데이터를 검색하는 기능에 포함할 수 있습니다. 사용자가 앱에서 정보를 요청하면 액세스가 허용된 데이터만 전달합니다.
그러나 개발자가 데이터와 애플리케이션의 다양한 측면에서 수행되는 작업 사이에 명확하게 정의된 경계를 설정하지 못하면 애플리케이션은 캡슐화 취약점을 겪게 됩니다. 공격자는 응용 프로그램에 요청을 보내 이를 이용합니다. 이러한 작업으로 인해 오류 메시지가 발생한다는 사실을 알고 있습니다. 이 오류 메시지는 응용 프로그램의 구조에 관한 정보를 제공하여 DOS(서비스 거부)와 같은 더 많은 공격 전략을 돕습니다.
안전하지 않은 직접 개체 참조(IDOR)
웹 애플리케이션 URL은 사용자를 백엔드 저장 위치로 안내하는 데 사용되는 패턴이나 형식을 노출할 수 있습니다. 예를 들어 URL은 파일 시스템이나 데이터베이스와 같은 스토리지 시스템의 레코드 식별자에 대한 패턴/형식을 표시할 수 있습니다.
IDOR만으로도 위험이 낮을 수 있습니다. 그러나 IDOR이 실패한 액세스 제어 확인과 결합되면 공격자는 성공적으로 공격할 기회를 얻습니다.
알아야 할 다른 일반적인 웹 애플리케이션 취약점 은 다음과 같습니다.
HTTP 응답 분할
이것은 일종의 CRLF 주입 공격입니다. HTTP는 브라우저가 쿼리를 보내고 서버가 응답을 다시 보내는 프로세스입니다. 이 웹 응용 프로그램 취약성에서 악의적인 공격자는 브라우저와 서버가 서로 통신하는 방법을 조작하기 위해 CR 및 LR 표기법을 사용하여 요청을 전달하지만 서버에 응답을 다양한 부분으로 "분할"하도록 지시합니다. 응답을 두 부분으로 나누면 악의적인 행위자가 요청의 다른 부분에 대한 응답으로 서버가 제공하는 정보를 제어할 수 있습니다. 이러한 요청 데이터가 사용자 ID 데이터 또는 민감한 정보인 경우 악의적인 행위자가 공격을 성공적으로 수행한 것입니다.
사출 결함
주입 결함은 다양한 공격 기술의 과잉을 허용합니다. 사용자가 셸 명령, 운영 체제 호출 또는 데이터베이스를 업데이트할 수 있는 모든 응용 프로그램은 주입 결함을 겪을 수 있습니다. 악의적인 공격자는 주입 결함을 활용하여 애플리케이션 내에서 새롭고 예상치 못한 작업으로 발전하는 명령을 변경합니다. 이러한 취약점을 이용하여 악의적인 행위자는 데이터를 생성, 업데이트, 읽기 또는 삭제할 수 있습니다.
안전하지 않은 메시지 다이제스트 취약점
이것은 암호화의 효율성을 제한하는 암호화 취약점입니다. 메시지 다이제스트는 암호화 해시 기능을 포함해야 합니다. 암호화와 달리 해시 함수는 발신자와 사용자가 키를 사용할 필요가 없습니다.
따라서 악의적인 공격자는 안전하지 않은 다이제스트 취약점을 이용하여 "해시 충돌 공격"을 지속합니다. 공격의 목적은 입력을 보내면 중복 해시가 생성되는지 확인하는 것입니다. 악의적인 작업이 공유 해시를 강제로 생성하는 경우 이 해시를 사용하여 다운로드할 악성 파일을 표시할 수 있습니다. 그러면 최종 사용자는 파일이 합법적이라는 가정을 하게 됩니다.
불충분한 전송 계층 보호
TLS(전송 계층 보안)는 컴퓨터 응용 프로그램이 인터넷에서 서로 안전하게 "통신"할 수 있는 프로세스를 나타냅니다. 많은 응용 프로그램은 인증 과정에서 TLS만 사용하므로 사람이 응용 프로그램을 사용할 때 데이터 및 ID 세션 정보가 취약합니다.
공격자는 이 취약점을 이용하여 데이터가 사용자의 장치와 응용 프로그램 서버 간에 인터넷을 통해 이동할 때 데이터를 우회할 수 있습니다.
원격 코드 실행(RCE)
원격 코드 실행 취약성은 악의적인 공격자가 지리적 위치에 관계없이 코드를 삽입할 수 있도록 하는 웹 애플리케이션의 코딩 오류입니다. RCE는 공격자가 사용자 입력을 확인하지 않는 응용 프로그램에 자신의 코드를 입력하여 서버가 이를 정품 응용 프로그램 코드로 인식하게 하는 더 넓은 범주의 웹 응용 프로그램 주입 취약점에 속합니다. 일반적으로 악의적인 공격자는 패치되지 않은 일반적으로 알려진 취약점을 이용하여 애플리케이션에 코드를 삽입합니다.
원격 파일 포함(RFI)
공통 디렉토리를 애플리케이션에 연결하기 위해 개발자는 코드에 "include" 문을 추가합니다. 예를 들어, 응용 프로그램은 데이터베이스에서 데이터를 가져와야 할 수 있습니다. 각 파일을 가져오기 위해 수동으로 코딩하는 대신 "include" 문은 전체 소스 디렉토리를 연결하여 거기에 저장된 모든 것을 사용할 수 있도록 도와줍니다.
웹 응용 프로그램이 RFI 취약성을 겪을 때 공격자는 응용 프로그램을 조작하여 데이터베이스, 서버 또는 웹 사이트에 악성 코드 또는 맬웨어를 업로드할 수 있습니다.
보안 구성 오류
보안 구성이 잘못될 가능성은 실제로 오늘날 가장 일반적인 웹 애플리케이션 취약점 중 하나입니다. 이 취약점은 일반적으로 조직의 기본 보안 설정 수정 실패로 인해 발생합니다. 일반적인 보안 구성 오류는 다음과 같습니다.
- 기본 암호 또는 계정 사용
- 패치되지 않은 소프트웨어
- 암호화 없음
- 부적절한 방화벽 정책
- 사용하지 않는 리소스, 기능 및 기타 구성 요소 무시
SQL 주입
Structured Query Language를 의미하는 SQL은 데이터베이스에 사용되는 프로그래밍 언어입니다. 관계형 데이터베이스에 대한 데이터 검색 및 조작을 허용합니다. SQL 주입 취약점은 확인되지 않은 사용자 입력의 더 큰 그룹에 있습니다. 악의적인 행위자가 의도적으로 잘못된 요청을 보내면 웹 애플리케이션은 데이터베이스의 구조 및 보호에 대한 정보를 제공하는 오류 메시지로 응답합니다.
검증되지 않은 자동 라이브러리 활성화
코딩 시 시간을 절약하기 위해 개발자는 타사 라이브러리를 사용하는 경향이 있습니다. 대부분의 경우 이를 통해 애플리케이션 개발 프로세스를 가속화하는 사전 테스트된 코드를 사용할 수 있습니다. 그러나 공개적으로 사용 가능한 오픈 소스 코드를 사용하면 다음과 같은 보안 위험이 높아집니다.
- 문서화된 소유권이 없으면 악성 코드가 추가될 위험이 높아집니다.
- 더 이상 업데이트되지 않는 방치된 프로젝트
이 특정 취약점은 여러 응용 프로그램이 타사 라이브러리 종속성을 사용한다는 점을 고려할 때 점점 더 널리 퍼집니다.
이 블로그 게시물의 내용이 실제로 유용하고 통찰력이 있기를 바랍니다. 귀하의 사례에 적용되는 웹 애플리케이션 취약점에 대한 솔루션을 찾는 것은 직원 및 고객 경험에 게임 체인저가 될 것입니다.