[BackDoor] 취약점 분석/aws 1주차

* 까먹거나 모르는 부분 위주로 정리함(그래서 SQL은 뛰어넘음)

🏆 OWASP top 10

OWASP

: The Open Web Application Security Project, SW의 보안을 개선하기 위한 오픈소스 애플리케이션 보안 커뮤니티

웹 애플리케이션 취약점 중 빈도가 많이 발생하고, 보안상 영향을 크게 줄 수 있는 것들을 3~4년 주기로 10개 선정

2017 -> 2021 OWASP TOP 10

새롭게 발견된 취약점

• Top4. Insecure Design(불완전한 설계)

    : 코드 구현 단계에 앞서 기획과 설계 단계에서 발생하는 보안 결함

    취약점

    - 요구사항 및 리소스 관리
    - 보안설계
    - 보안 개발 생명 주기
    대응방안
     1. Secure SDLC
         SDLC(Software Development Life Cycle) = 개발 생명주기
         개발 생명주기 상에서 보안을 강화한 개발 프로세스
         개발 단계에서 보안을 고려하여 취약점 제거
     2. Secure by Design
         모든 계층에서 보안 고려
     3. 위협 모델링
         애플리케이션과 해당 환경에서 보안 허점을 찾기 위해 연습
         → 모든 구성 요소가 포함된 애플리케이션의 표현을 만든 뒤 취약점 식별
        (애플리케이션을 손상시키려는 사람처럼 생각해야 한다.)

 

• Top8. Software and Data Integrity Failures(SW 및 데이터 무결성 오류)

   : 애플리케이션이 신뢰할 수 없는 소스, 저장소 및 CDN, 플러그인, 라이브러리, 모듈에 의존하는 경우에 발생하는 보안 결함
   취약점
   - 애플리케이션이 사용하는 라이브러리나 모듈에 대한 무결성 검증이 없어 변조가 가능한 경우
   - 업데이트 공급망에 대한 검증이 없는 경우
   - CI/CD 파이프라인에 대한 적절한 보안성 검토가 없는 경우
   - 직렬화된 데이터에 대한 무결성 검증이 없는 경우
  대응방안
  1. PMS 일괄 배포
     PMS(Patch Management System) = 패치 관리 시스템
     : 시스템의 변경 사항이나 새로운 기능 등을 동시에 여러 곳에 배포 및 적용하는 것

     변경 사항을 한번에 적용하여 무결성 보장
  2. 서명 검증

  3. 사전 무결성 체크

 

• Top10. Server-Side Request Forgery(SSRF)

   : 애플리케이션이 사용자 제공 데이터를 적절한 검증 없이 로컬 및 원격 리소스를 가져와 취약점을 발생시키는 상황
   취약점
    - 서버가 적절한 검증 절차 없이 사용자 요청을 로컬 혹은 원격 리소스에 접근하도록 하는 경우
   공격방법
    - 서버측 자체의 요청을 변조하여 공격자가 원하는 형태의 악성 행위를 서버에 던져주고, 서버가 이를 검증없이 그대로 받아 응답
   대응방안

    1. 방화벽 정책 관리
    2. Secure OS
     - 서로 다른 보안 영역을 가진 여러 가상 네트워크 생성 → 단일장애점 제거
     - 네트워크 트래픽 필터링
    3. Security Group
     보안 그룹은 서버, 애플리케이션 및 네트워크 리소스를 보호하기 위해 네트워크 트래픽을 제어하는 일종의 가상 방화벽
     - 서버에 접근 가능한 IP 주소 범위 제한
     - 미사용 포트 차단
     - 서버에 직접 접근하는 대신 웹 프록시 사용
     - HTTP/HTTPS 프로토콜만 허용
    4. URL Host 화이트리스트
     : 허용된 호스트 목록만을 정의

🕸️ 웹 기술 기초

WWW이란

: World Wide Web, 인터넷에 연결된 사용자들이 서로의 정보를 공유할 수 있는 공간

WWW, W3, Web, 따따따로 칭함

 

특징

멀티미디어 정보를 하이퍼텍스트 방식으로 연결해 제공

하이퍼텍스트(HyperText) : 하나의 문서에서 다른 문서로 이동이 가능한 것을 말함(= 웹 서핑)

 

웹을 구성하는 3대 요소

1. HTML(HyperText Markup Langage)
   • 전체적인 웹을 틀을 잡아 사용자에게 제공
2. HTTP(HyperText Transfer Protocol)
   • 웹 서버(WAS)와 웹 클라이언트 간에 통신 지원
   • HTTP Request Message, HTTP Response Message
3. URL(Uniform Resource Locator)
   • 웹 클라이언트가 웹 서버로 자원을 요청할 수 있도록
   • URL의 구조
     • `https://www.naver.com/`
       • http: 스키마, 사용할 프로토콜
       • www.naver.com: 호스트, 서버주소, 포트 번호 생략 가능(보통 80임)
       • 뒤에 요청할 자원이 존재하는 디렉터리와 자원을 표기할 수 있다.
   • URL 예약 문자([표1] 참고)
     • URL 상에서 특정 기능 수행
     • 웹 브라우저를 사용할 경우 브라우저에서 이를 자동으로 인코딩하여 단순 데이터로 전송
4. HTTP 프로토콜
   • 통신 규약
   • 비지속 연결 → 지속 연결(`Connection: Keep-Alive`로 확인 가능)
   • HTTP 메세지
   • 시작줄
     • 요청 메세지: 무엇을 요청하고 어떻게 해야 하는가
     • 응답 메세지: 요청에 대한 결과가 어떻게 되었는가
   • 메세지 헤더
     • 상세 속성 정보
     • 일반, 요청, 응답, 엔티티, 확장 헤더가 존재
       • 우리가 JWT 토큰을 보낼 때 사용하는 Authorization 헤더는 `요청 헤더`에 해당
       • 확장 헤더에는 일반적으로 `X-` 접두어를 사용한다고 함.
   • 메세지 바디
     • 자원
   • 개행 문자
     • 텍스트 한 줄이 끝남을 표시하는 문자 또는 문자열(= 줄바꿈)
     • CRLF
       • CR(Carriage Return)(`\r`, 0x0D)
         • 문서의 끝으로 이동
       • LF(Line Feed)(`\n`, 0x0A)
         • 줄바꿈
       • 인터넷 프로토콜에선 CRLF가 개행 문자로 사용하도록 규정
       • 개행 문자 2개 == 헤더의 끝
   • 응답 메세지
     • 상태 라인(메소드, 요청 URL, 버전)
     • 메세지 헤더: 응답 속성 및 추가 정보
     • 메세지 바디
       • 엔티티 바디
       • 메세지 데이터
       • 데이터 수송을 목적으로 설계
   • 요청 메세지
     • 요청 라인(메소드, 요청 URL, 버전)
     • 메세지 헤더: 요청 속성 및 추가 정보
     • 메세지 바디
       • 엔티티 바디
       • 메세지 데이터
       • 데이터 수송을 목적으로 설계
   • Get/Post
     • Get
       • URL에 데이터가 실림
       • 자원을 단순히 받기 위해 사용
       • Request Body에 값을 넣을 수 없음
     • Post
       • 메세지 바디에 데이터가 실림
       • Content-Type이라는 헤더가 있을 시에만 POST 방식 사용 가능
       • 주로 insert, update에 사용
5. 쿠키와 세션
   • 쿠키
     • 식별 및 세션 유지를 통한 클라이언트-서버 간 상태 관리
     • 상태 유지 및 관리 + 사용자 인증 수단
     • 구분
       • 지속 쿠키
         • 웹 서버 발급 → 클라이언트 HD에 txt 형태로 저장됨(클라이언트 PC 사용자는 해당 쿠키 정보 열람 가능)
         • `Set-Cookie`라는 쿠키 헤더를 이용하여 사용자 식별
         • 로그아웃 시 `Set-Cookie : id = deleted`로 쿠키 폐기
         • 쿠키의 속성
           • path - url 값으로 이 경로 하위의 경로에서만 쿠키 접근 가능
           • domain - 쿠키에 접근 가능한 도메인 설정 가능(이 필드가 있어야 서브도메인도 같은 쿠키 이용 가능)
           • expires, max-age - 기한 설정(expires 미입력시 브라우저 닫으면 삭제됨)
           • secure - https 환경에서만 접근 가능
           • sameSite - XSRF 공격 방지, 사이트 외부에서 쿠키에 대한 접근을 막음
           • httpOnly - 클라이언트에서 document.cookie를 활용해 조작할 수 없도록 함
         • 문제
           • 폐기해도 해당 값을 알고 있으면 재사용 가능
           • 쿠키 값이 평문일 경우 변조의 위협 있음
           • 폐기 방법, 암호화 알고리즘에 대한 적절성 등 검토 필요
         • 필요성
           • 서버 부담이 적다
       • 세션 쿠키
         • 웹 서버 발급 → 클라이언트 웹 브라우저 캐시에 저장
         • 정상 로그인 
           → 서버: 세션ID 생성 후 이에 대한 정보 저장(메모리, 파일 시스템, DB)
           → `Set-Cookie`를 통해 세션 값을 넣어 의미 있는 세션 값을 만듦
         • 임의의 문자 나열 → 공격자 추측이 어려움
         • 폐기 후 재사용 불가
6. 웹 아키텍처
   • 동작 원리 분석
     1. 사용자가 웹 브라우저를 통해 사이트 접속
     2. 웹 브라우저 : 도메인에 따른 IP 변환 작업
        • 도메인 → IP 작업
          1. 로컬 DNS 캐시 확인
          2. host 파일 참조
          3. DNS 서버 질의
     3. HTTP 요청 메세지 제작
        • TCP/IP 통신
          1. 3-way hand shake 연결
          2. 요청 메세지 전송
     4. 바디에 있는 데이터를 깔끔한 인터페이스를 통해 제공
   • WS와 WAS
     • WS
       • 정적 콘텐츠 제공
       • 아파치, nginx 등
     • WAS
       • 동적 콘텐츠 제공
       • jsp 등
     • 왜 둘을 같이 쓰는가?(기술면접 빈출!)
       • WAS는 동적 콘텐츠를, WS는 정적 콘텐츠에 넘겨 서버 부하 방지
       • WAS가 혼자 처리하면 느려지고 이로 인해 페이지 노출 시간이 늘어나는 문제 발생
   • 웹 서버 동작 원리
     1. 요청 메세지
     2. 웹 서버가 요청 메세지 해석
        1. 메소드 파싱
        2. URL 파싱
        3. 메소드에 따른 동작
           • 자원 유/무 체크
           • 파일 시스템에 자원이 있다면 객체 생성
           • 동적/정적 자원에 따른 액션
             • 정적 자원 → Server Side Script 해석 필요 X
             • 동적 자원 → Server Side Script 해석 필요 O
             • DB 확인
           • 결과 반환
     3. 응답 메세지 제작 및 전송(헤더, 바디 세팅 후 메세지 전송)
     4. 클라이언트에게 전송
   • 3-Tier 구조(3계층 구조)
     • 클라이언트(프론트엔드) - 웹/앱플리케이션 서버(미들웨어/백엔드) - 데이터베이스 서버
     • 각 계층에서 변화가 일어나도 서로 영향을 받지 않고 독립적으로 운영됨
     • 장점
       • 각 계층 분리 = 업무 분담 → 업무 효율성 증가
       • 여러 서버로 나누어 각 계층 동작 → 서버 부하↓
     • 단점
       • 1계층에 비해 더 관리 필요
       • 장애가 발생하는 포인트가 더 늘어날 수 있다
       • 비용 문제
     • 동작
       • 정적 자원 요청 → 웹 서버에서 응답
       • 동적 자원 요청
         1. 요청 메세지
         2. WS에서 WAS로 포워딩
         3. WAS가 로직에 따라 처리(DB 질의 과정이 있다면 DB와 연결)
   • Server Side와 Client Side
     • Server Side Script
       : 웹 애플리케이션 서버에서 해석되는 스크립트
     • Client Side Script
       : 웹 클라이언트에서 해석되는 스크립트
       • 문제
         • 웹 프록시 도구/개발자 도구를 통한 Client-Side Script 조작 및 값 변조가 가능하기 때문에 검증이 무의미
         • 사용자 입력을 받는 태그도 이를 통해 확인 및 변조가 가능해 신뢰하기 어려움

[표1] 예약 문자와 기능