OWASP Top 10 - 2021

Top 10 Web Application Security Risks

A1:Broken Access Control(was A5)

Description

• Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits. 다음과 같은 예들에서 이런 일이 발생합니다.
• 유저가 예상 밖의 행동들을 할 수 있을때 발생하는 이슈입니다. 오직 한정된 user, role에만 접근 가능한 곳들에 누구에게나 사용가능하도록 만들때 취약점이 생기고 보통 default값으로 deny를 하지 않았을 때.
• URL을 수정해서 다른 계정의 정보를 열람 할 수 있거나 공격 툴을 이용해 API request를 수정해서 access controle 을 우회할 수 있을 때.
• API에 관한 POST, PUT, DELETE 콘트롤이 없을때.
• 로그인을 하지 않은 채로 user로써 활동 할 수 있거나 user로 접속했을때 admin으로 접근 가능한 경우.
• Access control token으로 사용하는 JWT를 replying or tampering하거나 쿠키나 hidden field를 조작해서 권한 상승을 하는 경우.
• Cross-Origin Resource Sharing(CORS) misconfiguration이 인가되지 않은 API접근을 허용할 때.
• 인증되지 않은 이용자가 force browsing을 할 수 있을 때

Prevention

• Access control은 공격자가 access control check or metadata를 수정할 수 없는 오직 trusted server-side code or server-less API에만 효과를 받아야 한다.
• Public resources를 제외한 나머지는 default 값으로 deny를 해야 한다.
• CORS 사용을 최소화 하는 방식의 메커니즘을 implement해야 한다.
• 접근통제 모델은 사용자에게 특정 레코드를 생성/열람/수정/삭제할 수 있는 권한을 허용하기 보다 레코드 소유자만 권한을 갖게끔 강제 설정해야 한다.
• 비즈니스 어플리케이션의 경우 도메인 모델에 의해서 limit requirements를 적용해야 한다.
• 웹 서버상의 디렉토리 리스팅 기능을 비활성화하고 .git과 같은 메타데이터와 백업파일들이 웹 루트에 존재하지 않게끔 운영.
• Access control 실패, 경고등에 관한 적절한 로깅을 해야한다.
• 공격 툴이 acess control에 관한 API 호출을 함부러 할 수 없을 만큼의 rate limit을 걸어야 한다.
• JWT는 로그아웃 이후 무효화 되어야 합니다.

Attack Scenarios

• Scenario #1: Accessing account하는 SQL call에서 verify 하지 않는 코드를 사용해서 공격자가 쉽게 acct 파라미터를 수정하여 보낼 수 있게 합니다. 공격자는 https://example.com/app/accountInfo?acct=notmyacct를 사용 할 것이고 서버의 코드는 아래와 같습니다.

  pstmt.setString(1, request.getParameter("acct"));
  ResultSet results = pstmt.executeQuery( );
  

• Scenario #2: 공격자가 간단하게 target URLs에 force browse를 합니다. 다음 페이지에 접속을 하려 했을 때 관리자가 아닌 데 접속이 가능하면 취약한 것입니다.

   https://example.com/app/getappInfo
   https://example.com/app/admin_getappInfo
  

A2:Cryptographic Failures(was A5 - Sensitive Data Exposure)

Description

• The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU’s General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS).
• 데이터를 보호함에 있어 우선적으로 고려해야 할 것은 trainsit과정과 그 이후의 과정에서 데이터가 잘 보호되고 있냐이다. 다음과 같은 경우를 고려해야한다.
• Any data가 clear text로 보내어지고 있지는 않은가? 암호화가 되어 있지 않은 HTTP, SMTP, FTP같은 것을 사용하고 있지는 않은가?
• 기본 값이나 혹은 이전의 코드에서 any old or weak cryptographic algorithms or protocols을 쓰고 있지 않은가?
• Default crypto keys로써 약한 생성기에서 만들어졌거나 재사용하지는 않는지? 키 관리는 제대로 되어 있는 것인지? Source code repositories에 키가 있지는 않은지?
• 서버쪽 인증서 확인이나 trust cahin이 제대로 validat하고 있는지?
• Initialization vector가 안 사용하거나 재사용하거나 제대로 안전한 방법으로 생성되어 적절한 operation에 잘 사용하고 있는지? insecure mode of operation such as ECB를 안 사용하고 있는건 확실한지?
• MD5 or SHA1과 같은 deprecated(더이상 사용하지 않는) hash function 혹은 non-cryptographic hash function을 사용하고 있지는 않는지?
• PCKS number 1 v1.5와 같은 deprecated cryptographic padding methods는 사용하고 있지는 않는지?
• Padding oracle attacks와 같은 형태의 cryptographic error messages or side channel information이 exploitable하지는 않는지?

Prevention

• Data가 processed되는지 stored되는지 trainmitted되는지 분류를 하고 어떤 데이터가 privacy laws나 규제 사항, 비즈니스 니즈에 의해 중요한 데이터로 분류되는지 파악을 먼저 해야한다.
• Sensitive data는 필요하지 않다면 저장하지 마라. 흔적이 없는 데이터는 훔쳐질 수 없으니 필요 없는 것들은 빨리 버려라.
• 민간한 데이터는 암호화가 되었는지 꼭 확인해라.
• 최신의 표준 알고리즘, 프로토콜, 키를 사용하는지 확인하고 키 관리를 제대로 하는지 확인해라.
• TLS와 같은 암호화 프로토콜로 데이터를 보내고 HTTP Strict Transport Security(HSTS)와 같은 directives를 사용해서 암호화를 enforce해라.
• 민감한 데이터를 저장한 response를 캐시하는 것을 disable해라.
• 민감한 자료를 보냄에 있어서 FTP and SMTP와 같은 legacy(유산) protocol을 쓰지 마라.
• 암호화에는 PBKDF2, bcrypt, scrypt ,and Argon2와 같은 강력한 솔티드 해시 function을 사용해라.
• CSPRNG(cryptographically secure pseudo random number generator)과 같은 것을 사용해서 적절한 IV를 선택해야한다. 그리고 두번 이상 재사용하면 안된다.
• 단순한 encryption이 아니라 authenticated encryption을 사용해야한다.

Attack Scenarios

• Scenario #1: 애플리케이션이 카드 정보를 자동으로 암호화해주는 데이터베이스에서 사용을 하는데 이 데이터가 검색시 자동으로 해독되어 SQL injection flaw로 평문상태로 그 카드를 알 수 있게 됩니다. 이 경우는 stored경우는 암호화가 안전하지만 transmit에서 암호화가 제대로 이루어지고 있지 않는 것입니다.
• Scenario #2: TLS를 사용을 강제 하지 않는 사이트에서 공격자가 HTTPS를 HTTP로 다운그레이드 한 다음 유저 쿠키를 훔칩니다. 이후 그 쿠키로 유저의 세션을 탈취하고 유저의 개인 정보를 바꿉니다. 그리고 그들은 이런 데이터가 특히 돈에 관련한 데이터일때 수치를 바꿔서 데이터를 전송할 수 있게 됩니다.
• Scenario #3: 암호 데이터베이스가 slated를 쓰지 않는다면 file upload flaw에서 공격자가 그 틈을 이용해 암호 db의 정보를 탈취(retrieve) 할 수 있습니다. 그리고 레인보우 테이블 공격을 통해 암호를 복호화 할 수도 있을 것입니다.

A3:Injection(was A1)

Description

• 다음과 같은 경우에 취약점이 존재한다.
  • User-supplied data가 validate, filter, sanitized되지 않을때.
  • Context-aware escaping이 없는 dynamic queries or non-parameterized calls이 인터프리터에서 직접 실행 될 때.
  • Hostile data가 object-relational mapping(ORM) 서치 파라미터에서 추가적이거나 민감한 자료를 extract 할 때.
  • Hostile data가 직접적으로 사용되거나 conacatenated 될 때.
• 흔한 injections은 SQL, NoSQL, OS command, Object Relational Mapping(ORM), LDAP, Expression Language(EL) or Object Graph Navagation Library(OGNL) 인젝션들이 있습니다.
• 소스코드 리뷰가 가장 취약점을 찾기에 좋은 방법이고 자동화 툴은 모든 파라미터, 헤더, URL, cookies, JSON, SOAP, and XML data input을 반드시 확인해야 합니다.
• 기업들은 제품 출시 전 인젝션 flaw를 탐지하기 위해 SAST, DAST, IAST같은 테스팅 툴들을 CI/CI pipeline에 넣을 수 있습니다.

Prevention

• 가장 중요한 것은 data를 command와 queries로 부터 분리하는 것이다.
• safe API를 사용한다.
• 화이트 리스트 server-side의 input validation을 사용한다. 이것만으로 완벽한 방어법은 될 수 없다.
• Specific escape syntax를 사용해서 특수 문자를 escape하는 dynamic queries를 쓴다.
• LIMIT 이나 다른 SQL 컨트롤을 사용해서 SQL injection을 대비해 많은 자료가 disclosure되는 것을 막는다.

Attack Scenarios

• 아래 2가지의 시나리오들은 다음 공격이 다 적용된다.

  http://example.com/app/accountView?id=' or '1'='1
  

• Scenario #1: untrusted data를 그냥 써버리는 경우.

  String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";
  

• Scenario #2: 유사하게 어플리케이션이 blind trust해버리는 경우.

   Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
  

A4: Insecure Design(New)

Description

• 단순히 missing or ineffective control design을 의미하는 것이 아니다. Insecure design과 insecure implementation은 다르다.
• Insecure한 디자인은 아예 어떤 공격에 의해서는 절대 방어 할 수 없게 디자인 된 것이다. 이것은 애초에 소프트웨어나 시스템을 만들때 어느 정도 수준의 보안을 생각하는 디자인을 할지 생각하지 않고 그 비즈니스의 특성을 제대로 파악하지 못했기 때문에 발생하는 문제점이다.
• Requirements and Resource Management: 애플리케이션에 관한 비즈니스 requirement를 collect and negotiate해야 한다. 거기에는 모든 데이터에 관한 confidentiality, intergirty, availability, and authenticity가 다 들어가야 한다. Funtional and non-functional security requirements를 포함해서 컴파일 테크닉을 점검하고보안 활동을 포함한 모든 디자인, 빌드, 테스팅, 작동에 관한 버짓에 대해 계획을 세워야 한다.
• Secure Design: 시큐어 디자인은 끊임없이 위협을 평가하고 테스트하고 알려진 공격을 막는 코드를 ensure해줄 수 있게 하는 문화이자 방법론이다. Threat modeling은 refinement sessions안에 포함이 되어야 할 것이고 유저 story development에서 취약 할 수 있는 부분들에 대해 논의되어야 한다. 적절한 행동에 대한 고려 조건들을 어떻게 validate할 것인지 정하고 유저 스토리에 대한 결과를 문서화 해야 한다. Secure design은 툴을 추가하는 것도, 덧붙이는 것도 아닌 처음부터 진행되어야 하는 것이다.
• Secure Development Lifecycle: Secure software는 secure development lifecycle, 시큐어 디자인 패턴, secured component library, tooling 그리고 threat modeling들을 require합니다. 전체 ㅍ로젝트 및 소프트웨어 유지보수에 관한 시작을 할 때 보안 전문가와 함께 하는 것이 좋습니다.

Prevention

• A secure development lifecycle을 구축하는 것이 좋고 privacy-related controls, 디자인 시큐어와 같은 것을 평가하는데 도움이 될 전문가와 함께 하는 것이 좋습니다.
• Critical authentication, access control, businees logic, key flows들에 관한 threat modeling을 합니다.
• 유저 스토리 안에 시큐어 언어와 control을 통합해서 구성합니다.
• 모든 critical flow를 validate할 수 있는 unit과 integration test를 작성합니다.
• 모든 tier layers에서 위험이 될만한 네트워크와 시스템 레이어들을 segregate(분리)합니다.
• 유저나 서비스에 의해 사용될 수 있는 consumption을 제한합니다.

Attack Scenarios

• Scenario #1: A credential recovery 워크 플로우에서 questions and answers이라는 플로우가 들어갈텐데 한사람 이상 자격 증명이 되도록 하지 말아야하는데 만약 2명이 자격증명을 할 수 있게 된다면 답을 알아버릴 수 있을 것입니다. 그래서 이런 코드는 시큐어한 디자인에서 제거해야 합니다.

• Scenario #2: 영화관 사이트에서 최대 15명만 예약을 할 수 있고 그룹 예약시 할인을 해준다고 할 때, 공격자는 이것에 관한 threat model을 구현해서 600자리를 예약하는 것을 시도할 것입니다. 그리고 그것은 거대한 손실을 가져다 줄 것입니다.

• Scenario #3: 위와 비슷한 예로 전자 상거래 경매 웹사이트에서 봇에 관한 방어가 안 되어 있는 사이트라면 나쁜 해커에 의해 경매 가격이 비정상적으로 만들어 놓는 허위 구매를 막을 수 없습니다.

A5:Security Misconfiguration(was A6)

Description

• 다음과 같은 경우에 취약점이 발생합니다.
  • 애플리케이션 스택의 어떠한 부분에서건 적절한 보안 강화가 누락되었거나 클라우드 서비스에 대한 권한 설정이 부적절하게 되었을 때.
  • 불필요한 부분들을 가능하게 했거나 설치했을 때(불필요한 포트,서비스,페이지 등등)
  • Default account와 그에대한 비밀번호가 변경되지 않았거나 그대로일때.
  • 유저에게 에러 핸들링이나 에러 이상의 정보가 보여질때.
  • 업그레이드된 시스템에 대해 최신 보안 features가 diable되었거나 안전하게 설정되어 있지 않을 때.
  • 애플리케이션 서버, 프레임워크, 라이브러리, 데이터베이스등 그 속의 보안 셋팅이 보안에 강한 값으로 설정되어 있지 않을때.
  • 서버가 안전한 헤더나 directives를 보내지 않거나 그들이 secure value로 설정되어 있지 않았을 때.
  • 소프트웨어가 구식이거나 취약할때
• 일관되고 반복 가능한 보안 configuration process가 없으면 시스템은 매우 위험합니다.

Prevention

• 반복가능한 hardning process를 만들어서 빠르고 쉽게 다른 환경에 deploy할 수 있게 만듭니다. 개발, QA, production 환경은 모두 동일한 설정값으로 되어 있어야 하고 각자에 맞는 서로 다른 인증서를 사용해야 합니다. 이것들은 가능하면 자동화 작업이 되어야 하며 자동화 작업을 통해 새로운 보안 환경을 설치하는데 드는 비용이 최소화되어야 합니다.
• 불필요한 것들은 지우거나 설치하지 않습니다. 최소한의 platfrom으로 만드십시오.
• 모든 보안 노트, 업데이트, 그리고 패치에 관한 적절한 configuarions을 리뷰하고 업데이트하는 task를 implement합니다. 그리고 cloud stroage권한에 대해서 review합니다.
• A segmented application architecture는 효과적이고 안정적으로 components들이 작동할 수 있게 해줍니다.
• 보안 헤더와 같이, security directives를 client에게 보내는 로직을 구성합니다.
• 모든 환경에서 효과적으로 각 셋팅 값을 verify하는 자동화 프로세스를 구축합니다.

Attack Scenarios

• Senario #1: Production 서버를 제거하지 않은 샘플 애플리케이션과 함께 애플리케이션 서버가 동작합니다. 이 샘플 애필르케이션은 보안 취약점이 있는 것으로 알려져있고 공격자는 그것을 이용해 서버를 compromise합니다. 이 이팰르키이션이 만약 관리자 콘솔이고 default account를 변경하지 않았다면 공격자는 default password로 시스템을 take over 할 것입니다.
• Senario #2: Directory listing이 서버에서 disabled되지 않았습니다. 공격자가 쉽게 디렉토리를 알 수 있게 됩니다. 공격자는 컴파일이 된 자바 클래스를 찾아서 다운로드 할 것이고 그들은 그것을 디컴파일하고 리버스 하여서 코드를 볼 것입니다. 공격자는 취약한 access control flaw를 발견하여 공격할 것입니다.
• Scenario #3: 애플리케이션 서버가 디테일한 error message를 허용해버린다면 이것은 컴포넌트 버전의 취약점을 드러내어서 공격을 당하기 쉽게 만들 것입니다
• Scenario #4: 클라우드 서비스 공급자가 Content Security Policy header(CSP) 유저에 의해 permission을 오픈할 수 있도록 default값을 해놓아 버린다면 클라우드 안의 저장장치에 접근을 가능하게 만들어 sensitive data가 탈취당할 것입니다.

A6:Vulnerable and Outdated Components(was A9 - Using Components with Known Vulnerabilities)

Description

• 다음의 경우 이 취약점이 존재합니다.
  • 당신이 서버사이드와 클라이언트 사이드 모드에 사용되고 있는 모든 컴퍼넌트에 관한 버전을 모를때.
  • 소프트웨어가 취약하거나 지원이 더 이상 되지 않거나 out of date일때. 특히 OS, 앱 서버, DBMS, API, 라이브러리, 런타임 환경 모두 포함됩니다.
  • 취약점을 정규적으로 스캔하지 않거나 당신이 사용하고 있는 컴퍼넌트에 관한 새로운 보안 뉴스를 접하지 않을때.
  • 위험이 있는 프레임워크나 플랫폼같은 것들을 업그레이드 하지 않거나 고치지 않을때. 흔히 이런 일들은 한달에 혹은 분기마다 패치를 하고 매달 첫째날에만 고치는 방식이면 더 생깁니다.
  • 소프트웨어 개발자가 새로 업그레이드된 라이브러리에 관한 테스트를 하지 않을 때.
  • 각 컴퍼넌트의 configuration을 secure하게 하지 않ㅇ르 때.

Prevention

• 사용하지 않는 features, dependencies, compopnets, files, and documentation과 같은 것은 지운다.
• 지속적으로 CVE, NVD와 같은 것을 모니터링 하면서 관련된 컴퍼넌트의 취약점에 대한 뉴스를 계속 주시합니다. 만약 사용하고 있는 컴퍼넌트에 관한 취약점이 나왔을때 메일로 알람을 주는 것을 구독합니다.
• 오피셜한 소스에서 secure link를 통해 컴퍼넌트를 구합니다. 최대한 악성 코드가 포함될 가능성이 있는 루트로는 컴퍼넌트를 구하지 않습니다.
• 유지보수가 되고 있지 않거나 시큐어 패치가 되지 않는 라이브러리와 컴퍼넌트를 모니터링 하고 패치가 가능하지 않을때는 알려진 취약점에 대해 조치를 취할 수 있는 가상 패치를 고려해야 합니다.
• 모든 조직은 반드시 모니터링, 업데이트 확인 밑 configuration 변화를 애필리케이션 lifetime동안 끊임없이 해야합니다.

Attack Scenarios

• Senario #1: 컴퍼넌트들은 주로 애플리케이션과 같은 권한으로 실행됩니다. 따라서 어느 컴퍼넌트라던지 취약점이 생길때는 심각한 문제를 초래할 수 있습니다. IoT의 경우 주기적인 패치가 어렵거나 불가능 ㅎ라 수 있지만 biomedical device같은 경우는 패치가 반드시 중요합니다.

A7:Identification and Authentication Failures(was A2 - Broken Authentication)

Description

• The user’s identity, authentication, and session management는 authentication 관련 공격을 보호함에 있어 굉장히 중요한 부분이다. 다음과 같은 부분이 있을때는 취약점들이 존재하게 된다.
• Credential stuffing과 같은 자동화 공격을 허용할때. -다른 사이트에서 얻은 계정 정보를 입력하는 공격 기법
• admin/admin과 같은 약하고 잘 알려진 기본 설정값을 허용할때
• knowledge-based answer과 같은 safe할 수 없는 방식으로 recovery and forgot-password process를 사용할 때
• 평문을 쓰거나 약한 암호화 알고리즘을 사용할 때
• MFA가 불충분하거나 사용되지 않을 때
• URL에 세션 정보가 그대로 노출될때
• 로그인 성공 이후 session identifier가 재사용 가능할때
• 세션ID가 제대로 invalidate되지 않거나 로그아웃이나 일정 시간 이후에도 SSO token과 같은 authentication token이 제대로 invalidate되지 않을때

Prevention

• 가능하면 MFA를 사용해서 자동화 공격이나 stolen creentia resue attack을 막는다.
• Admin users에 관한 것들은 기본값을 사용하지 않은 채로 ship or deploy해야한다.
• 약한 비밀번호를 체크하고 top 10,000 worst password list에 들어간 비밀번호는 허용하지 않는 것을 implement한다.
• 비밀번호 길이, 복잡성, roation policy를 N과 함께 설정한다.
• 접속 실패에 대한 기록은 남기고 자동화 공격이 먹히지 않도록 로그인 시도 횟수와 시간에 제한을 걸어놓고 DOS를 방지한다.
• 로그인 이후에 높은 엔트로피를 지닌 랜덤한 세션 ID를 generate하는 안전한 세션 관리자를 사용한다. 세션에 관한 정보는 URL에 노출시키지 않고 로그인 이후 혹은 특정 시간 이후 invalidate하게 한다.

Attack Scenarios

• Senario #1: Credential stuffing은 흔한 공격법이다. 이것에 관한 방어책이 없다면 그 어플리케이션은 crentials가 valid한지 안한지 결정할 수 있는 채널로 사용될 수도 있다.
• Senario #2: 대다수의 authentication attacks은 지속적인 비밀번호 사용때문에 생기는 것이다. 따라서 MFA를 사용하던지 쉬운 비밀번호를 사용할 수 없도록 해야 한다.
• Senario #3: 세션 타임아웃이 제대로 설정되지 않았을 때 유저가 public computer에 접속했을 경우, 공격자가 같은 브라우저로 한 시간 뒤에 그 컴퓨터를 사용해 유저의 authenticated된 상태로 서비스를 이용할 수 있게 될 것이다. 로그아웃 말고 탭으로 닫았을 때에도 적절하게 세션 셋팅을 해주어야 한다.

A2:Cryptographic Failures(was A5 - Sensitive Data Exposure)

Description

• The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU’s General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS).

Prevention

Attack Scenarios

A2:Cryptographic Failures(was A5 - Sensitive Data Exposure)

Description

• The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU’s General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS).

Prevention

Attack Scenarios

A10:Server-Side Request Forgery (SSRF)(New)

Description

• 유저가 제공한 URL을 validating하는 것 없이 외부 리소스를 fetching할때 취약점이 발생한다. 이를 통해 공격자는 방화벽, VPN 또는 다른 유형의 네트워크 access control list(ACL)에 의해 보호되는 경우에도 특정 애플리케이션에 조작된 요청을 예기치 않은 destination으로 보내도록 허용해버립니다.
• 현대 웹 애플리케이션은 엔드유저에게 편리한 기능을 제공하기 위해 URL 패칭과 같은 시나리오가 일반화 되었습니다. 그 결과 SSRF 취약점이 증가하게 된 것입니다. 클라우드 기반과 architectures의 복잡성 때문에 더욱이 이 취약점이 증가하게 될 것입니다.

Prevention

• From Network layer
  • SSRF의 영향을 줄이기 위해 separate networks에서 원격 리소스 접근 기능을 나눕니다.
  • 방화벽이나 네트워크 접근에 관한 기본 정책을 deny로 설정하고 필수적인 인트라넷 트래픽만 허용합니다.
  • 방화벽의 모든 네트워크 플로우를 기록합니다.
• From Application layer
  • Client-supplied input data를 sanitze & validate합니다.
  • A positive allow list와 함께 URL schema, port, and destination을 강제합니다.
  • 클라이언트에게 raw response를 주지 않습니다.
  • HTTP redirection을 disable합니다.
  • SSRF의 mitigation으로 deny list를 사용하거나 regular expression을 사용해서는 안 된다. 공격자들은 그것들을 우회할 수 있는 도구와 기술들, payload들이 이미 있다.
• Additional Measures to consider:
  • Front system에 OpenID와 같은 보안 관련 서비스를 deploy해서는 안 됩니다. 이러한 시스템에 관해서는 로컬에서 통제해야 합니다.
  • Dedicated and manageable user groups이 있는 frontends에서는 VPN과 같이 고도로 보호해야 될 필요가 있는 독립적인 시스템에서 네트워크 암호화를 사용해야 합니다.

Attack Scenarios

• 공격자는 다음과 같은 시나리오들을 통해서 방화벽이나, network ACL뒤에서 보호받는 시스템을 공격할 수 있습니다.
• Senario #1: 내부 서버 port scan이 가능합니다. 만약 네트워크 구조가 unsegmented되었다면 공격자는 내부 네트워크에 맵핑을 시도하고 연결 결과 또는 SSRF 페이로드 컨넥션 거절 혹은 연결과 같은 경과시간으로 내부 포트 스캐닝이 가능해집니다.
• Senario #2: 민감 데이터가 노출될 수 있습니다. 공격자가 file:///etc/passwd<\/span>, http://localhost:28017 과 같은 정보에 접근할 수 있게 된다면 민감 데이터가 노출 됩니다.
• Senario #3: 클라우트 서비스의 메타데이터 저장장치에 접근할 수 있게 됩니다. 대다수의 클라우드 서비스 제공자들은 http://169.254.169.254와 같은 메타데이터 스토리지를 제공하고 있습니다. 공격자는 그것을 읽어들여 민감한 자료들을 볼 수 있을 것입니다.
• Senario #4: 내부 서비스를 compromise할 수 있습니다. 공격자는 내부 서비스를 악용하여 Remote Code Execution(RCE) or DoS와 같은 공격을 실행할 수 있게 될 것입니다.

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 검증기 등을 사용합니다.

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 권한으로 변조를 해버리면 치명적인 문제가 발생 할 수 있습니다.
• 이러한 공격을 방어하기 위해서는 신뢰 할 수 없는 출처로부터 직렬화된 객체를 허용하지 않거나 디지털 서명이나 무결섬 검사와 같은 것을 구현합니다. 역직렬화하는 과정에 제약을 두는 것도 좋지만 이것은 우회방법이 존재합니다. 역직렬화하는 과정을 모니터링 하고 역직렬화를 지속적으로 할 경우 경고합니다.

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의 로그를 모니터링 하지 않으면 이러한 취약점에 노출 될 수 있습니다. 로그를 단지 로컬에만 저장하고 사용자나 공격자에게 로깅이나 경고 이벤트가 보여질 수 있다면 이러한 취약점을 가지고 있는 것입니다.
• 모든 로그인, 접근 통제 실패, 서버 측면의 입력값 검증 실패등의 의심스럽거나 악의적인 계정을 식별할 수 있는 내용들은 로깅을 하고 중앙 집중적 로그 관리 솔루션에 의해 쉽게 사용될 수 있는 형식으로 로그가 생성되는지 확인하여 보안 대책을 세웁니다.