[정보 보안 개론] 웹 보안(인증 및 세션 관리 취약점, XSS 취약점, 취약한 접근 제어, 보안 설정 오류)

Jin_Hahha·2024년 10월 16일
1

정보 보안 개론

목록 보기
13/17
post-thumbnail

인증 및 세션 관리 취약점(A2. Broken Authentication and Session Management)

  • 인증이나 세션 관리 기능의 올바르지 않은 구현으로 발생할 수 있는 보안 취약점
    • 공격자가 로그인 과정 없이도 서비스 페이지에 접근 가능
    • 공격자가 다른 사용자 아이디로 접근할 수 있게 허용하는 것과 마찬가지의 상태

취약한 패스워드 설정

  • 가장 대표적인 문제점
  • 웹을 비롯해 패스워드를 사용하는 모든 운영체제와 응용 프로그램에 공통으로 해당하는 문제
  • 웹에서는 더 심각한 문제를 일으킬 때가 많음
    • 이는 기본적으로 개발자와 사용자가 동일하지 않기 때문
  • 웹의 경우 전문 개발자가 개발하고 사용자는 단순 이용하는 경우가 대부분
    • 관리자 패스워드를 변경하는 인터페이스가 별도로 존재하지 않고 데이터베이스를 변경하는 것과 같은 원시적 형태가 다반수
    • 위의 경우에서 사용자가 개발자의 초기 패스워드를 그대로 사용하거나 개발자가 취약한 패스워드를 사용하기도 함
    • 의외로 여러 웹에서 admin/admin과 같은 취약한 패스워드를 자주 발견할 수 있음

사용자 데이터를 이용한 인증

  • 사용자 데이터를 이용한 인증은 사용자 아이디, 패스워드 입력과 같이 당연한 것처럼 보이지만 아래의 경우에서는 아님

  • 위의 그림은 사용자 데이터를 이용한 인증 과정과 해당 과정에서 취약점 공격을 실행하는 시나리오를 나타냄
    1. 최초 인증 과정은 정상 아이디와 패스워드 입력으로 시작
    2. 웹 서버에서는 아이디와 패스워드를 확인 및 올바른 경우의 접속에 대한 인증을 진행하고 인증 값으로 쿠키와 같은 세션 값을 넘김
      • 2번 과정까지는 정상적
    3. 공격자는 새로운 페이지로 접근, 이때 웹 서버는 공격자가 수신한 인증 허용 값을 전달받으면서 해당 세션이 유효한 인증인지 확인
      • 이 과정에서 공격자가 전달해주는 값(아이디, 사용자 고유 번호 등)을 이용하여 해당 인증의 소유자를 구분
      • 이러한 동작 방식은 연결 허용과 사용자 구분의 연계가 명확하지 않은 경우에 해당
    4. 공격자는 세션 인증 값은 그대로 사용하면서 UserNo만 변경하여 다른 계정으로 로그인한 것처럼 웹 서비스를 이용
  • 이러한 문제는 기본적으로 최초 인증 이후의 인증과 신분 증명 역할을 클라이언트에 넘겼기에 발생
  • 인증뿐 아니라 데이터 신뢰도에 대한 증명 권한을 클라이언트에 넘기면 언제든 악용 가능
  • 웹 취약점은 편리하다는 이유로 서버가 통제해야 할 사항을 클라이언트에 넘기는 데 있음을 명심

XSS 취약점(A3. Cross-Site Scripting)

  • 공격자가 작성한 스크립트가 다른 사용자에게 전달되는 것
  • 다른 사용자의 웹 브라우저에서 적절한 검증 없이 실행됨
    • 다른 사용자의 세션 탈취 가능
    • 웹 사이트 변조 및 악의적 사이트로 이동 가능

  • 위의 그림은 XSS 공격의 구조를 나타냄
    1. 임의의 XSS 취약점이 존재하는 서버에 XSS 코드를 작성 및 저장
      • 가장 일반적인 경우는 사용자나 특정인이 이용하는 게시판 공격
    2. 공격자가 작성한 XSS 코드에 사용자가 접근
      • 사용자는 자신이 XSS 코드에 접근한다는 것을 인지하지 못함
      • 흔히 어떤 게시판의 글을 읽는 과정에서 XSS 코드에 접근
    3. 웹 서버는 사용자가 접근한 XSS 코드가 포함된 게시판의 글을 사용자에게 전달
    4. 사용자의 시스템에서 XSS 코드 실행
    5. XSS 코드가 실행된 결과가 공격자에게 전달되고 공격 종료

XSS 공격 실습

  • 게시판에 대한 XSS 취약성 여부는 간단한 XSS 코드를 게시판에 입력하고 글을 열람해보면 확인 가능
    • 게시판 작성 글의 형태는 HTML

  • HTML 형태로 쓰인 위의 글을 클릭하면 아래의 경고창이 나옴

  • 이후 확인 버튼을 누르면 게시물 contents 화면으로 이동

  • 위의 실습에서는 단순히 XSS 취약성 확인을 위한 경고 창을 띄우는 형태의 스크립트를 입력했으나 아래의 스크립트를 입력한다면?

    • 웹 서버(192.168.137.128)로 해당 게시글을 읽는 사용자의 쿠키 값을 전송

취약한 접근 제어(A4. Broken Access Control)

  • 인증된 사용자가 수행할 수 있는 제한이 제대로 적용되지 않는 것을 의미
  • 가장 큰 예시로 URL 접근 제한 실패 사례가 있음
    • 관리자 페이지를 추측하기 쉬운 URL
    • 인증이 필요한 페이지에 대한 인증 미처리로 인증을 우회하여 접속할 수 있는 경우
  • 위의 취약점에 노출되면 일반 사용자나 로그인하지 않은 사용자가 관리자 페이지로 접근 및 관리자 권한 기능 악용 사례가 발생할 수 있음
  • 인증 우회를 막기 위해서는 웹에 있는 중요 페이지에 세션 값(쿠키)을 확인하는 검증 로직을 입력해두어야 함

디렉터리 탐색(directory traversal)

  • 웹 브라우저에서 확인 가능한 경로의 상위를 탐색, 특정 시스템 파일을 다운로드하는 공격 방법
  • 자료실에 업로드한 파일을 전용 프로그램으로 내려받는 경우
    • 이때 파일 이름을 필터링하지 않아 발생하는 취약점
  • 게시판 등에서 첨부 파일을 내려받을 때는 아래와 같은 백 엔드 서비스를 주로 사용

  • 정상적인 다운로드 페이지를 이용하여 다른 파일의 다운로드를 요청하는 경우

  • 이는 download.jsp의 인숫값인 파일 이름에서 특수 문자 등이 존재하는지 여부를 필터링하지 않아서 발생하는 취약점

  • 따라서 directory traversal 취약점을 방지하려면 download.jsp 인숫값에 ..와 / 문자를 필터링해야 함

보안 설정 오류(A5. Security Misconfiguration)

  • 웹 서버 기본 제공 값은 안전하지 않기 때문에 서비스 시작 전이나 정기 점검 시 적절하게 안전성 여부를 검토해야 함
    • 이때 중요한 문제가 발견되면 보안 패치는 바로 적용해야 함
  • 일반적인 보안 설정 오류는 아래와 같음

디렉터리 리스팅(directory listing)

  • 웹 브라우저에서 웹 서버의 특정 디렉터리를 열면 해당 디렉터리의 파일과 목록이 모두 나열되는 것을 말함
  • 물론 의도적인 설정도 있지만 상당수 디렉터리 리스팅은 관리자의 설정 부재 또는 웹 서버 자체의 취약점으로 발생

백업 및 임시 파일 존재

  • 종종 웹 사이트 개발 이후 서버에 존재하는 백업이나 임시 파일을 삭제하지 않은 경우가 있음
  • 해당 파일에는 웹 애플리케이션 내부 로직, 데이터베이스 접속 정보와 같은 중요 정보가 있을 수 있음
    • 예시로 login.asp 파일에 대해 웹 서버의 편집 프로그램이 자동으로 생성하는 백업 파일인 login.asp.bak 파일이 여기에 속함

미흡한 주석 관리

  • 일반적인 프로그램 주석은 개발자만 볼 수 있음
  • 웹 애플리케이션의 경우 웹 프록시를 사용하면 일반 사용자도 열람 가능
  • 주석에도 간혹 중요 정보가 기록되는 경우가 있기 때문에 개발 과정에서 중요 정보가 기록되는가 주의할 필요가 있음

파일 업로드 제한 부재

  • 클라이언트에서 서버로 임의의 파일을 전송할 수 있다는 것은 웹 서버의 가장 치명적인 취약점
  • 공격자가 임의로 악의적인 파일을 전송하여, 원격지의 웹 서버를 장악하고 내부 침투 공격을 수행할 수 있기 때문
  • 웹 해킹의 최종 목표인 리버스 텔넷(Reverse Telnet)과 같은 웹 서버 통제권을 얻기 위해 반드시 성공해야 하는 공격
  • 국내에서 발생한 대규모 온라인 개인 정보 유출 사건은 대부분 이러한 형태로 일어남
  • 해당 취약점이 존재하는 가장 일반적인 형태는 게시판
    • 게시판에 첨부 파일로 악의적인 파일을 업로드하고 실행하는 것

리버스 텔넷

  • 웹 해킹으로 시스템 권한을 획득한 후 해당 시스템에 텔넷과 같이 직접 명령을 입력하고 확인할 수 있는 셸을 획득하기 위한 방법
  • 방화벽이 있는 시스템을 공격할 때 주로 사용
  • 일반적으로 웹 서버는 방화벽 내부에 존재
  • 웹 서버는 80번 포트를 이용한 웹 서비스만 제공하면 되기 때문에 방화벽은 외부 인터넷 사용자에게 80번 포트만 허용
    • 이러한 경우는 웹 서버의 텔넷이 열려 있어도 방화벽으로 인해 외부에서 공격자가 접근할 수 없음
  • 심화된 공격을 위해서는 텔넷과 유사한 접근 권한을 획득하는 것이 매우 중요
  • 방화벽의 인바운드 정책에서는 필요한 포트만 빼고 다 막아놓지만 아웃바운드 정책에서는 별다른 필터링을 수행하지 않는 경우가 많음
  • 공격자는 그저 리버스 텔넷을 하기 위해 텔넷 서비스만 열어놓으면 됨
  • 위의 공격을 성공시키기 위해서 웹 서버에서 권한을 획득해야 함
  • 일반적으로 권한을 얻기 위해 파일 업로드 공격을 수행
  • 웹 셸의 업로드를 통해 시스템에 명령을 입력할 수 있는 명령 창을 획득
    1. 명령 창 획득
      • 웹 브라우저에서 실행 가능한 웹 셸을 파일 업로드 등을 통해 웹 서버에 업로드
      • 공격자가 명령을 입력할 수 있는 명령 창 획득
    2. 리버스 텔넷용 툴 업로드
      • 서버 게시판의 파일 업로드 기능을 통해 ncnet cat와 같은 리버스 텔넷용 툴 업로드
    3. 공격자 PC의 리버스 텔넷 데몬 활성화
      • 서버에서 리버스 텔넷을 보내면 공격자는 이를 받아 텔넷을 열 수 있도록 준비
    4. 획득한 명령 창을 통해 리버스 텔넷 창을 획득
  • 리버스 텔넷 공격을 방지하기 위해서는 파일 업로드를 막아야 함
  • asp뿐 아니라 리버스 텔넷 종류를 실행하지 못하도록 exe나 com과 같은 실행 파일의 업로드도 막아야 함
  • 아웃바운드 정책도 인바운드 정책만큼 세세하게 설정
profile
Jin_Hahha
이전 포스트

[정보 보안 개론] 웹 보안(웹과 HTTP의 이해, 웹 서비스의 이해, 웹의 취약점과 보완, SQL Injection)

다음 포스트

[정보 보안 개론] 웹 보안(민감한 데이터 노출)

0개의 댓글