Top 10 Web Application Security Risks
A1:Injection
- Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
- 소스코드 리뷰와 자동화 테스트로 취약점을 확인하면 된다.
- Mitigation으로 데이터를 명령어와 쿼리로부터 분리시켜야 한다. 특수 문자 필터링 처리가 필요하다.
A2:Broken Authentication
- Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities tempolrarily or permanently.
- 무차별 공격 및 자동화 공격을 허용하고 세션 id가 url에 노출되기도 합니다. 세션 ID를 제대로 무효화 시키지 않고 평문을 쓰거나 취약한 해시 비밀번호를 사용해서 이 취약점이 발생하게 됩니다.
- 가능하면 multi-factor authentication(MFA)를 구현해서 무차별 공격, 정보 재사용 공격을 예방합니다. admin계정의 경우는 기본 정보를 사용하지 말아야 합니다. 비밀번호는 강력한 조합으로 사용하고 로그인 실패에 대한 제한이나 시간 delay를 두어야 합니다.
- 브라우저의 경우 로그아웃을 하는 것이 아닌 단순히 탭만 닫으면 세션 정보가 남아 공격자가 인증이 된 상태로 무언가를 할 수 있습니다. 그리고 알려진 암호 목록을 통해 공격이 가능하지 자동화 툴로 미리 알려진 비밀번호, 계정 조합으로 공격을 해보고 방어책을 구축해야 할 것입니다.
A3:Sensitive Data Exposure
- Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
- 민감한 데이터를 암호화하지 않는 것이 가장 큰 결함입니다. 암호화를 사용 했을 때에는 취약한 키 생성 및 관리, 약한 알고리즘, 프로토콜 및 암호 사용으로 인해 취약점이 더 두드러집니다. 취약한 해싱 저장 기술때문에 이러한 취약점이 많았습니다.
- HTTP, SMTP, FTP는 평문으로 데이터를 전송하는데 이런 프로토콜은 위험합니다. 백업 혹은 저장할때 평문으로 처리하는 민감한 데이터가 있는지 확인해야 합니다. 키 생성 및 관리에서 약한 암호 키를 생성하지 않는지 확인하고 디폴트가 재사용되는지도 확인해야 합니다. 또한 사용자 프로그램에서 보안 디렉티브나 헤더와 같은 암호화를 적용하고 있는지, 혹은 서버 인증이 유효한지 확인하는 절차가 있는지를 통해 이러한 취약점이 있는지 점검할 수 있습니다.
- 보안 대책으로는 데이터의 민감도를 파악하고 그 분류에 따라 처리 방식을 달리합니다. 불필요한 민감한 데이터는 저장하지 않고 그런 데이터를 줄이도록 노력합니다. 또한 최신의 강력한 표준 알고리즘, 프로토콜, 암호 키를 사용하는지 확인하여 적절한 키 관리가 이루어져야 합니다.
A4:XML External Entities (XXE)
- Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
- 애플리케이션이 직접 XML을 입력 받거나 특히 신뢰할 수 없는 곳의 XML을 업로드하거나 데이터를 입력할 경우 취약할 수 있습니다. XXE 공격에 취약하다는 것은 Bilion Laughs공격을 포함하는 서비스 공격에 취약하다는 것을 의미합니다.
- 보안책으로 JSON과 같은 덜 복잡한 데이터 형식을 사용하거나 민감한 데이터 사용을 지양합니다. 또한 XML 프로세서와 라이브러리를 패치하거나 업그레이드 합니다. SOAP(XML 메시징 프로토콜)는 1.2 이상으로 업그레이드합니다. 서버에서 필터링 및 검사를 사용하여 XML 문서, 헤더, 노드에 있는 악의적인 데이터를 막습니다. XML 파일 업로드시에는 XSD 검증기 등을 사용합니다.
A5:Broken Access Control
- Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
- 다른 계정의 정보를 열람하거나 편집 할 수 있다면 이러한 취약점이 존재하는 것이고 JWT의 토큰 재전송, 변경이 허용된다면 접근 통제를 실패한 것입니다. 인가되지 않은 API에 접근 허용 하는 것도 취약점 중에 하나입니다.
- 디폴트 정책으로 차단을 해야 할 것이며 접근통제 모델은 사용자에게 특정 레코드를 생성/열람/수정/삭제할 수 있는 권한을 허용하기 보다 레코드 소유자만 권한을 갖게끔 강제 설정해야 할 것입니다. 웹 서버상의 디렉토리 리스팅 기능을 비활성화하고 .git과 같은 메타데이터와 백업파일들이 웹 루트에 존재하지 않게끔 운영해야 합니다. JWT는 로그아웃 이후 무효화 되어야 합니다.
A6:Security Misconfiguration
- Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.
- 디폴트 계정과 비밀번호가 활성화 되어 있거나 해당 정보들을 변경 없이 사용하고 있으면 취약한 상태입니다. 또한 에러 처리 과정에서 스택 추적 정보나 공격에 도움이 될만한 다른 정보들을 노출하고 있어도 위험합니다. 서버, 프레임워크, 라이브러리, 데이터베이스 상에 보안 설정이 되어 있지 않거나 구버전을 사용해도 이 취약점에 해당됩니다.
- 보안 대책으로 불피요한 기능, 구성 요소 없이 최소한으로 플랫폼을 유지하고 사용하지 않는 기능과 프레임워크는 삭제하거나 설치하지 말아야 합니다. 모든 보안 정보, 업데이트, 패치를 대상으로 적절한 검터와 갱신하는 절차가 필요하며 세분화, 컨테이너화, 클라우드 보안 그룹과 같은 방법으로 효율적이고 안전한 격리를 제공하는 아키텍처를 적용해야 합니다. 모든 영역의 보안 설정이 적절히 반영되어 있는지 검증 할 수 있는 자동화된 절차를 수립해야 합니다.
A7:Cross-Site Scripting XSS
- XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
- 일반적으로 3가지의 XSS가 있습니다. Reflected XSS, Stored XSS(persistent), DOM based XSS으로 나뉘어진다.XSS
A8:Insecure Deserialization
- Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
- 이 공격은 결코 쉽지 않습니다. 이 취약점을 통해 원격 코드 실행, 권한 상승 공격, 주입 공격, reply 공격을 포함한 다양한 공격을 할 수 있습니다. 직렬화라는 것은 정보를 전달하는 수단으로 데이터의 형식이 있고 그 안에 정보를 포함하여 보냅니다. 이때 user라는 권한을 주는 직렬화 데이터에 역직렬화 하는 과정에서 admin 권한으로 변조를 해버리면 치명적인 문제가 발생 할 수 있습니다.
- 이러한 공격을 방어하기 위해서는 신뢰 할 수 없는 출처로부터 직렬화된 객체를 허용하지 않거나 디지털 서명이나 무결섬 검사와 같은 것을 구현합니다. 역직렬화하는 과정에 제약을 두는 것도 좋지만 이것은 우회방법이 존재합니다. 역직렬화하는 과정을 모니터링 하고 역직렬화를 지속적으로 할 경우 경고합니다.
A9:Using Components with Known Vulnerabilities
- Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
- 소프트웨어가 취약하거나 지원되지 않거나 오래된 버전의 경우 취약할 가능성이 있습니다. 업그레이드된 라이브러리의 호환성을 테스트하지 않느다면 취약할 가능성이 있습니다. 라이브러리, 프레임워크 및 다른 소프트웨어 모듈 같은 컴포넌트는 애플리케이션과 같은 권한으로 실행됩니다. 취약한 컴포넌트가 악용된 경우는 심각한 데이터 손실을 일으키거나 서버가 장악됩니다.
- 사용하지 않는 구성요소는 제거하고 안전한 출처 확인 및 모니터링과 같은 수동적인 방법만으로 막아야 합니다. 가능하면 서명된 패키지를 사용합니다. IoT의 경우 패치가 어렵거나 불가능하지만 패치를 적용하는 것이 중요할 수 있습니다.(예: 생체 의료 장비)
A10:Insufficient Logging & Monitoring
- Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
- 불충분한 로깅과 모니터링은 모든 중요한 보안사고의 기반이 됩니다. 이러한 취약점으로 인해 공격자들은 시스템을 더 공격할 수 있게 됩니다. 불필요한 로그를 많이 남기는 것도 좋지 않지만 감시해야 할 이벤트들은 기록해야 합니다. 로그인, 로그인 실패와 같은 로그가 모니터링 되지 않고 경고 및 오류에 대한 로그 메시지도 없거나 의심스러운 활동에 대한 API의 로그를 모니터링 하지 않으면 이러한 취약점에 노출 될 수 있습니다. 로그를 단지 로컬에만 저장하고 사용자나 공격자에게 로깅이나 경고 이벤트가 보여질 수 있다면 이러한 취약점을 가지고 있는 것입니다.
- 모든 로그인, 접근 통제 실패, 서버 측면의 입력값 검증 실패등의 의심스럽거나 악의적인 계정을 식별할 수 있는 내용들은 로깅을 하고 중앙 집중적 로그 관리 솔루션에 의해 쉽게 사용될 수 있는 형식으로 로그가 생성되는지 확인하여 보안 대책을 세웁니다.