OWASP Top 10 (2021)

OWASP

OWASP는 오픈소스 웹 애플리케이션 보안 프로젝트이다. 주로 웹에 관한 정보노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며 10대 웹 애플리케이션의 취약점을 발표했다 -> 이것이 OWASP Top 10(취약점의 95%를 차지한다.)이다.

A01 Broken Access Control

원인

• POST, PUT 및 DELETE에 대한 제어 누락
• CORS 구성 잘못
• 권한 상승 제어 누락

대응 방안

• 접근 통제 관리 필요성 : 권한을 적절하게 부여한다. (Least Privilege : 최소한의 특권, Need to Know : 알필요에 근거)
• 접근 관리(읽기, 쓰기, 수정, 복사, 삭제, 출력), 사용자에 대한 등급/카테고리 고려, 그룹단위 관리 등등
• 명백한 허용을 제외하고 모두 거부한다. (Deny All Philosophy : 모든 것을 거부하는 원칙)
• 디렉토리 리스팅을 차단 (URL을 통해 직접적으로 방문해 우회하는 문제 방지)
• 웹 서버 디렉토리 목록을 비활성화 하고, 파일 메타데이터(ex. .git) 및 백업 파일이 웹 루트 내에 존재하지 않는지 확인한다.
• 로그아웃시 세션, 쿠키등의 유효성 지우기(로그아웃하기 전에 값을 복사하고, 복사한 값을 로그아웃 후에 붙여넣으면 사용자로 계속 인식되는 문제 방지)
• 웹 서버 루트 디렉토리에 robots.txt 파일을 생성하고 

        User-Agent : *                       // 모든 검색엔진들을

        Disallow: /                            // 모든 디렉토리를 허용하지 않는다.

 

       일부를 허용하려면

        User-Agent : googlebot             // 구글만 해당됨

        Allow:/                                   // 모든 디렉토리 허용

A02 Cryptographic Failures (암호화 실패)

암호화를 잘 못하는 이유 : 암호화 및 복호화를 하는데 컴퓨터 연산량이 많아져서 서버에 부하가 걸림

처음에는 안전한 암호화였으나, 시간이 지남에 따라 컴퓨터의 성능이 발전해서 쉽게 크래킹 될 수 있는 상태가 됨

(#Moore의 법칙 : 18개월마다 2배로 성능이 향상됨)

민감한 데이터의 노출 : Crawler(검색엔진들이 사용하는 수집용 도구)의 숫자 증가, 성능 증가 ---> 검색 많이 됨

개인정보와 관련된 Compliance들이 요구수준이 높아짐

원인

• 암호화 알고리즘이 오래되거나 약하기 때문이다.
  • 안전하지 않은 암호화(아래 암호화를 사용할 경우 ISMS-P 인증심사에서 결함으로 판정)
    • 대칭키 : DES, 3DES, RC4 등등,   ECB방식
    • 공개키 : RSA1024bit 이하
    • 해시함수 : MD5, SHA1, LMhash, NThash 등

안전하지 않는 암호화를 사용했을 경우 크래킹이 되어 비밀번호를 알 수 있다.

대응 방안

• 민감한 데이터(개인 정보, 규제 요구 사항, 비즈니스 요구 사항 등)를 식별하여 분류한다.
• 민감한 데이터를 안전한 암호화 알고리즘(인증된 암호화)을 사용하여 암호화
  • 안전한 해시함수
    • SHA-2(256bit) : bitcoin, 공동인증서 등
    • SHA-2(512bit) : 리눅스 운영체제 등
• FTP(파일 전송 프로토콜), SMTP(이메일 프로토콜)와 같은 레거시 프로토콜 사용 금지
  • Salt : 해시함수와 원문이 같으면 해시값도 같아지기 때문에 Salt를 섞어서 다 다르게 한다.

변경 전 해쉬값

변경 후 해쉬값

A03 Injection(명령어 주입)

SQL인젝션, OS Command Injection등의 증가 ----> 대응 방법이 많이 알려져서 순위가 약간 내려감

XSS가 따로 분류되지 않고 Injection에 포함됨

원인

• SQL, NoSQL, OS(Command Injection)명령 등 사용자가 입력한 값을 그대로 코드에 대입하는 경우 생김
• 서버 코드에서 필터링을 해도 필터링의 코드가 취약한 경우(replace함수를 사용하거나 그 외 치환법은 불안정함)
• 잘못된 입력에 대해 처리하지 않는 경우 -> 오류 발생시 DB정보(버전, 테이블명, 컬럼명 등)가 나와 취약해짐

대응 방안

• 입력 유효성 검사 (명령어의 경우 특수 문자를 사용하고 파일의 경우 파일 확장자 검사(파일 매직넘버를 확인하는 것이 좋음))
• 잘못된 입력에 대해 일관된 오류 페이지를 보여줄 것
• 이스케이프 구문을 사용하여 특수 문자 사용을 금지할 것

A04 Insecure Design

보안이 고려된 설계의 의무화 ----> 경험없는 개발자, 보안에 대한 교육을 받지 못한 개발자

대충 만들고 나중에 보완하려면 비용이 더 많이 발생

원인

• 보안의 3대 요구사항인 기밀성 무결성 가용성을 확보하지 않는 코드
• 보안 개발의 수명 주기를 제대로 파악하지 못할 경우 -> 컴퓨터의 발전에 따라 안전했던 코드라도 시간이 지남에 따라 안전하지 않게 될 수도 있음

대응 방안

• 보안 전문가와 함께 코드를 설계
• 보안 개발 수명 주기를 설정하여 정기적으로 코드 패치
• 프론트엔드에서 백엔드까지 각 계층에서의 유효성 검사

A05 Security Misconfiguration(잘못된 보안 구성)

보안 설정이 잘못됨 : 로그인 우회

원인

• 불필요한 포트, 서비스, 페이지, 계정 또는 권한이 있을 경우
• 그 외 여러가지 보안에 대한 잘못된 구성

대응 방안

• 불필요한 것들은 없애고, 제대로 된 보안을 구성

A06 Vulnerable and Outdated Components

취약하고오래된요소들을사용 ex)SSL3.0, TLS1.0등을아직도사용하면안됨

원인

• 소프트웨어 개발자가 업데이트, 업그레이드 또는 패치된 라이브러리의 호환성을 테스트 하지 않는 경우
• 각 소프트웨어 버전에 따른 취약점을 정기적으로 스캔하지 않는 경우 (원데이 익스플로잇)
• 구성 소프트웨어에 대한 보안이 부족할 경우 (제로데이 익스플로잇)

대응 방안

• 사용하지 않는 기능 및 종속성을 없앤다.
• 버전에 대해 민감하게 대응하고 중요도를 높인다 -> 지속적인 모니터링을 하여 버전에 따른 취약점을 알아낸다.

Zeroday Exploit (제로데이 공격)

• 알려지지 않은 취약점(패치가 아직 없음, 제조사가 아직 모르는 상태)
• 무방비상태에서 공격을 하는 것
• 제조사가 패치를 만들기 전 (PoC이전, 패치를 만드는 중, 패치를 만들었는데 취약점이 사라지지 않는 경우 등등)
• 패치를 만드는데 걸리는 시간?  25~50일 (PoC --> 설계 --> 개발 --> 테스터)
• 엠바고 (뉴스에 내지말라고 언론에 요청함)
• Dark Web에서 고액으로 거래가 되기도 함 (iPhone > Windows > ....  )

Oneday Exploit : 알려진 취약점(패치 나와있음, 설치 안하면 공격 가능)

• 패치가 있는데 왜 적용을 하지 않을까요?  의존성(Dependancy)문제 ---> OS를 업데이트 하면 App이 잘 안돌아가는 문제
• 반도체 생산라인 OS를 업데이트???  에러 발생시 엄청난 손실이 발생할 우려
• Version : 3.2.8      (3:업그레이드,  2:업데이트,  8:패치 )

Shodan : IoT기기를 검색하는 검색 엔진

• 취약한 IoT기기를 검색하거나 ID/PW가 취약한 장치를 파악할 때 사용
• shodan.io 사이트에 접근하지 못하도록 차단하는 것은 좋지 않음 (내 눈을 가리는 것)

HeartBleed (OpenSSL 취약점)

공격자가 "감자"를 물어봤을 때 "감자"를 500글자로 말하라 하면 컴퓨터는 "감자"를 포함한 불필요한 정보를 외부에 유출한다.

취약점이 있는 버전

A07 Identification and Authentication Failures(2021년 가장 심각한 취약점)

로그인 문제, 인증(지식, 소유, 생체, 위치기반)문제가 Mobile때문에 강화된 측면---> 순위 내려감

원인

• 이용자의 편리성 추구로 생김 -> 이용자가 기억하기 쉽게 하기 위하여 동일 ID,Password를 사용 할 경우
• 취약한 사이트에 자주 사용하는 아이디를 사용하여 유출 됐을 경우 -> 안전한 사이트에 무차별 대입하여 로그인 됨
  • Credential Stuffing (크리덴셜 스터핑, 자격증명 스터핑)

대응 방안

• 이용자가 각 사이트 별로 다른 ID 혹은 Password를 사용할 것

A08 Software and Data Integrity Failures

무결성 훼손은 조작 등 우려

원인

• 소프트웨어 및 데이터 무결성 위반으로 무결성이 위반된 업데이트를 진행할 경우
• 사용자가 위의 상황을 확인하기 어려움
• 소프트웨어를 제공한 업체가 해킹되어 해커가 업데이트 파일에 악성코드를 넣었을 경우

대응 방안

• 업체에서 해시값으로 확인하는 것이 좋다. (단 한 글자라도 달라질 경우 해시값이 달라지기 때문)
• 사용자의 경우 업데이트 파일의 서명을 확인해야 함

A09 Security Logging and Monitoring Failures

로그 양이 많고 실시간 분석 ---> 최근에는 ML, AI을 활용

원인

• 로그인, 로그인 실패 및 그와 같이 가치가 높은 이벤트를 기록하지 않음
• 로그 메시지 자체가 부적절, 불명확함
• 로그 메시지에 대한 적절한 모니터링의 부재
• 수많은 서버에서 기록되는 로그의 양은 너무나도 많아 관제 비용이 증가함에 따라 제대로 된 관제 부재
• 스마트폰의 경우(리눅스, 유닉스) 로그가 존재하는 위치(/var/log)가 대부분 일정

대응 방안

• 로그 메시지가 적절하게 생성되도록 함
• 의심스러운 행위로 인한 로그 발생을 파악하는 도구를 설치하고 이를 활용 (알람 기능)

A10 Server Side Request Forgery (SSRF : 서버쪽의 조작된 요청)

스크립트를 활용한 요청 위조 공격

원인

• URL의 유효성 검사 미흡
• URL을 통해 원격 리소스를 가져올 수 있는 경우

대응 방안

• 악성 명령어를 입력 했을 경우 명령어의 유효성을 검사하는 코딩 습관(Injection 대응방안과 비슷)