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

Jin_Hahha·2024년 10월 14일
1

정보 보안 개론

목록 보기
12/17

웹의 이해

  • 웹의 정식 명칭은 월드 와이드 웹(World Wide Web, WWW)
  • 세계적 규모의 거미집 모양의 망
  • 초기 웹 구상 프로젝트의 이름은 하이퍼텍스트 프로젝트(Hyper Text Project)
  • 하이퍼텍스트를 이용하면 단어나 문구를 마우스로 클릭하여 관련 주제에 대한 정보를 추가로 얻을 수 있음
  • 현재 웹 문서로 가장 많이 쓰이는 HTML(Hyper Text Markup Language)은 하이퍼텍스트를 효과적으로 전달하기 위한 스크립트 언어

  • 웹은 수많은 보안 취약점이 존재
  • 대부분의 사이트가 임의의 사용자가 접근할 수 있도록 공개
  • 웹 해킹이 보안 사고의 대부분을 차지할 정도로 웹은 집중 공격 대상
    • 가짜 웹을 통한 금전적 피해
    • 웹 사이트 장악을 통한 데이터 변조
    • 웹 사이트 해킹을 통해 내부 네트워크로 향하는 경로로 사용
  • 위의 피해를 막기 위해 은행 보안 프로그램을 5~6개씩 사용(...)

HTTP 프로토콜

  • HTTP, SMTP, POP, FTP, Telnet 등의 여러 프로토콜이 웹에서 사용됨
  • HTTP는 그중 가장 흔히 사용되는 프로토콜
  • HTTP를 이용하면 다양한 응용 프로그램에 접근하여 텍스트, 그래픽, 애니메이션, 사운드 서비스 등을 이용할 수 있음
  • HTTP는 웹 처리 전반에 걸친 토대가 되기 때문에 웹 서버를 HTTP 서버라고도 함

  • 가장 초기에 사용되었던 단순 읽기 기능만 지원했던 HTTP 0.9 버전의 기본연결

    • 클라이언트가 웹 브라우저를 이용하여 서버에 연결을 요청하면 서버는 클라이언트에 대해 서비스 준비
      1. 서버 준비 상태 전환
      2. 클라이언트가 읽고자 하는 문서를 서버에 요청
      3. 서버는 웹 문서 중에서 요청받은 것을 클라이언트로 전송
      4. 연결 종료

  • 위의 기본 연결은 HTTP의 버전에 관계없이 동일

  • 0.9 버전은 하나의 웹 페이지 안에서도 텍스트와 그림이 반복적으로 connect 과정을 거쳐야 하는 등의 비효율성이 드러나서 오래 사용되지 못함

  • 현재 인터넷에서 사용되는 대부분의 HTTP는 1.0 또는 1.1 버전

    • 1.1 버전부터는 한 번의 connect 과정 이후 Request와 Response를 반복할 수 있게 됨

HTTP Request

  • 웹 서버에 데이터를 요청하거나 전송할 때 보내는 패킷
  • GET, POST와 같은 메서드를 주로 사용

GET

  • 가장 일반적인 HTTP Request 형태

  • 아래와 같은 요청 데이터의 인수를 웹 브라우저의 URL(Uniform Resource Locator)

    • 이름과 값을 &로 결합
    • 글자 수는 255자로 제한
    • 메신저로 받은 URL을 클릭하면 특정 웹 페이지를 똑같이 확인할 수 있음

  • GET 방식은 데이터가 주소 입력란에 표시됨

    • 최소한의 보안도 유지되지 않음
    • 보안에 매우 취약한 방식으로 인증 관련 정보를 GET 방식으로 전달하면 안 됨

POST

  • POST 방식은 URL에 요청 데이터를 기록하지 않음
    • HTTP 헤더에 데이터를 전송
    • GET 방식의 파라미터 부분이 존재하지 않음
  • 내부의 구분자가 파라미터를 구분하고 서버가 각 구분자에 대한 내용을 해석 및 데이터 처리
    • GET 방식에 비해 처리 속도가 상대적으로 느림
  • 인숫값을 URL을 통해 전송하지 않기 때문에 다른 사용자가 링크를 통해 해당 페이지를 열람할 수 없음
  • 게시판 등에서 파일 업로드는 POST 방식으로만 가능
  • GET 방식과 달리 보내려는 데이터가 URL을 통해 노출되지 않기 때문에 최소한의 보안성은 갖춤
  • 일반적으로 게시판 목록이나 글 보기 화면은 접근 자유도를 위해 GET을, 게시글 저장/수정/삭제 or 대용량 데이터를 전송할 때는 POST 방식 사용

기타 방식

  • GET 방식이나 POST에 비해 사용 비중이 낮지만, 다른 방식도 존재
  • 서버 측의 데이터를 검색하고 요청하는 데 사용

OPTIONS

  • 자원에 대한 요구/응답 관계에서 관련된 선택 사항의 정보를 요청할 때 사용
  • 클라이언트는 무엇을 선택할지 결정할 수 있음
  • 자원과 관련된 필요 사항도 결정할 수 있음
  • 서버의 수행 능력도 알아볼 수 있음

PUT

  • 메시지에 포함된 데이터를 지정한 URI(Uniform Resource Identifier) 장소에 그 이름으로 저장

DELETE

  • URI에 지정된 자원을 서버에서 지울 수 있게 함

TRACE

  • 요구 메시지의 최종 수신처까지 루프백을 검사하는 용도로 사용
  • 클라이언트가 보내는 요구 메시지가 거쳐 가는 프록시나 게이트웨이의 중간 경로와 최종 수신 서버까지 이르는 경로를 알아내는 데 사용

HTTP Response

  • HTTP Request에 대한 응답 패킷
  • 서버에서 쓰이는 프로토콜 버전, Request에 대한 실행 결과 코드 및 간략한 실행 결과 설명문에 대한 내용이 있음
  • 전달 데이터의 형식, 길이 등과 같은 추가 정보가 MIME 형식으로 표현
  • 헤더 정보 뒤에는 실제 데이터가 전달(HTML or Image)
  • 데이터 전달이 종료되면 서버는 연결 끊음

HTTP Response 주요 실행 결과 코드

웹 서비스의 이해

  • 프론트 엔드와 백 엔드 영역으로 나뉨
  • 프론트 엔드는 클라이언트 영역, 백 엔드는 서버의 실행 영역

프론트 엔드

  • 클라이언트, 즉 웹 브라우저에서 실행되는 프로그램 영역

  • 가장 단순한 형태가 HTML

    • 웹 서버에 HTML 문서를 저장하고 있다가 클라이언트가 특정 HTML 페이지를 요청하면 해당 문서를 클라이언트로 전송
    • 클라이언트는 해당 문서를 해석하여 웹 브라우저에 표현
      • 이러한 웹 페이지를 정적 웹 페이지라고 함

  • 초기의 웹 서비스는 정적 웹 페이지가 대부분

  • 정적 웹 페이지는 변화에 적응할 수 없고 새로운 것을 추가하는 데 많은 시간이 걸린다는 단점이 있음

    • 그러나 이러한 점이 보안상 장점으로 작용
    • 웹 해킹은 흔히 웹 브라우저와 서버 사이에 전달되는 값을 변조
      • 위의 행위를 통해 서버의 설정, 로직을 변경
      • 정적 웹 페이지는 바꿀 수 있는 가능성이 매우 낮음

  • 이후 동적 웹 서비스를 위한 JavaScript, Visual Basic Script 등이 사용

  • 현재의 프론트 엔드 담당으로는 흔히 자바 스크립트를 사용

    • HTML과 마찬가지로 웹 브라우저에 의해 해석 및 적용
    • CSS, Client Side Script라고 함

  • CSS는 서버가 아닌 웹 브라우저에서 해석되어 화면에 적용

    • 웹 서버의 부담을 줄이면서 다양한 기능을 수행

백 엔드

  • 웹 서비스를 제공하는 데 필요한 REST API를 제공하는 영역
  • JAVA, NET, 파이썬, 루비, 자바스크립트 등 사용
  • 클라이언트에 구현된 기능에 필요한 인자를 전달받고, 이 인자에 따라 함수처럼 그에 대한 결과만 전달
  • 함수는 URL에 따라 구분, 결과는 JSON 형태로 클라이언트에 전달
  • 현재 자바스크립트는 서버 사이드에서도 NODE.JS를 통해 사용됨

웹 해킹

  • 사이트의 구조와 동작 원리를 이햐하는 데서부터 시작
  • 실제 웹 모의 해킹 과정을 보면, 초기에는 며칠 동안 사이트를 만든 사람의 코딩 스타일과 습관, 사이트의 구조, 인수 전달 방식 등을 파악
    • 기본적으로 웹 스캔, 웹 프록시를 통한 패킷 분석, 구글 해킹 수행
    • 위의 과정은 웹 해킹에 소요되는 시간의 대부분을 차지할 만큼 중요한 과정

웹 취약점 스캐너를 통한 정보 수집

  • 주로 웹 메뉴를 하나하나 클릭하면서 수작업으로 파악
  • 웹 취약점 스캐너인 Acunetix를 사용하기도 함
    • 빠른 시간 내에 다양한 접속 시도를 수행할 수 있음
    • 그러나 해당 기술로 확인된 취약점은 실제 보안 문제가 있는 취약점이 아닌 경우가 많음
    • 개별 확인 과정을 거쳐 유효성을 파악해야 함

웹 프록시를 통한 취약점 분석

  • 웹의 구조 파악 및 취약점 점검, 웹 해킹에 사용되는 웹 프록시

  • 위의 그림은 웹 프록시의 동작 구조를 나타냄

  • 웹 프록시는 클라이언트에 설치되고 클라이언트의 통제를 받음

    • 클라이언트가 웹 서버와 웹 브라우저 간에 전달되는 모든 HTTP 패킷을 웹 프록시를 통해 확인하면서 수정할 수 있음
    • 대표적 툴은 Burp Suite
    • 툴에서 주로 사용하는 탭은 Proxy

  • Burp Suite를 사용하기 위해서는 클라이언트 웹 브라우저 패킷이 웹 프록시로 향하도록 설정해야 함

  • 윈도우의 프록시 설정 창에서 주소 란에 루프백 주소를 입력하고 포트에는 8080 포트, HTTP Alternate 번호를 입력

  • 위의 설정을 마친 후 Burp Suite를 사용하면 아래와 같이 동작

  • intercept is on 상태에서는 패킷을 하나씩 살펴볼 수도 있고 내용을 수정하여 전송할 수 있음

  • intercept is off 상태에서는 패킷을 살펴보지 않고 웹 프록시를 통해 바로 주고받게 됨

서버에서 클라이언트로 전송되는 패킷 변조

  • 위의 설정을 마치고 데이터를 전송하면 자기 자신이 전송하는 정보에 대한 조작을 수행하게 됨
  • 무슨 의미가 있겠냐는 의문이 들 수 있으나 아래의 경우들에 대해서 위력을 지님

  1. 해킹하려는 대상이 클라이언트에 있는 경우

    • 기본적으로 웹 브라우저 내용을 변경할 수 있음
    • ActiveX 등의 형태로 여러 프로그램이 클라이언트에 설치되어 웹 서비스를 제공하는 경우, 설치된 서비스 프로그램을 속이는 것이 가능

  2. 서버에서 클라이언트에 정보를 전송했다가 이를 다시 전송받아 처리하는 경우

    • 특정 데이터의 값을 확인하고 해당 값을 클라이언트로 전송

    • 서버는 전송한 데이터가 필요할 때 자신의 데이터베이스에서 다시 읽지 않고, 클라이언트가 관련 서비스를 수행할 때 서버에 다시 전송해주는 데이터의 값을 참조하여 서비스 수행

    • 2번 과정에서 값을 바꾸면 3, 4, 5 과정 전체에서 변경된 값으로 작업 수행

    • 4번 과정에서 변조를 가해도 되지만 일반적으로 2번 과정에서 변조하는 것이 훨씬 쉬움

    • 위의 정보 처리 방식이 가능한 이유는 HTTP 프로토콜이 기본적으로 연결이 존재하지 않는 무상태 프로토콜(Stateless Protocol)이기 때문에 가능

    • 개발자들이 웹 사용자의 정보를 간단한 형태로 유지 및 처리하려는 의도에서 이용하는 방식

      • 상당히 위험한 결과를 초래할 수 있음

    • 이러한 위험을 없애기 위해서는 서버에서 클라이언트로 전송한 값을 다시 참조하지 말아야 함

클라이언트에서 서버로 전송되는 패킷 변조

  • 서버에서 클라이언트로 전송되는 패킷을 변조하는 방법과 기본적으로 동일
  • GET 방식을 통해 웹 페이지를 요청할 때 특정 인숫값을 넣어 비밀글에 접근하거나 시스템에 오작동을 일으키는 등의 보안 위협을 가할 수 있음

구글 해킹을 통한 정보 수집

  • 구글은 아래와 같은 다양한 고급 검색 기능 제공

주요 검색 인자

  • wishfree.com 도메인이 있는 페이지에서 admin 문자열 검색

    site:wishfree.com admin

    • site는 특정 사이트만 집중적으로 선정해서 검색할 때 유용

  • 파일 확장자가 txt이고 문자열 password가 들어간 파일 검색

    filetype:txt password

    • filetype은 특정 파일 유형을 검색할 때 사용

  • 디렉터리 리스팅이 가능한 사이트 검색

    • Intitle을 이용하면 디렉터리 리스팅 취약점이 존재하는 사이트를 쉽게 찾을 수 있음
    • 디렉터리 리스팅은 웹 브라우저에서 웹 서버의 특정 디렉터리를 열면 그 디렉터리에 있는 모든 파일과 디렉터리 목록이 나열되는 것을 말함

intitle:index.of admin

검색 엔진의 검색을 피하는 방법

  • 검색 엔진 취약점 대응법은 웹 서버의 홈 디렉터리에 'robots.txt' 파일을 만들어 검색할 수 없게 만드는 것
  • http://www.wishfree.com/robots.txt 파일이 있으면 검색 엔진은 robots.txt에 있는 디렉터리를 검색하지 않음
  • robots.txt 파일 내용의 형식은 매우 간단
    • 2개의 필드로 구성
    • User-Agent와 Disallow를 이용
      • User-Agent는 검색 엔진의 검색 차단
      • Disallow는 특정 파일이나 디렉터리를 로봇이 검색하지 못하게 함

웹의 취약점과 보완

웹의 주요 취약점

  • 국제웹보안표준기구는 각 분야별 상위 열 가지 주요 취약점을 발표하고 있음
  • 3년마다 갱신되고 갱신 이전과 이후의 내용이 큰 차이가 없으면 새롭게 발표하기도 함

명령 삽입 취약점(A1. Injection)

  • 클라이언트 요청 처리를 위해 전송받는 인수에 특정 명령을 실행할 수 있는 코드가 포함되는 경우가 있음
  • 이를 적절히 필터링하는 처리 과정을 수행하지 않으면 삽입 공격에 대한 취약점이 생김
  • 명령 삽입 공격은 SQL, OS, LDAP 등 웹을 통해 명령을 전달하는 어떤 경우에도 적용될 수 있음
    • 가장 일반적인 공격은 SQL Injection
  • 웹은 대부분 데이터베이스와 연동되어 운영됨
  • DB를 이용하기 위해 웹 서버는 SQL 쿼리를 활용
  • 웹 서버에서 DB로 전송되는 SQL 쿼리에는 아이디, 패스워드, 검색어 등 여러 인수 사용
  • SQL 삽입 공격은 전송되는 인수에 추가적인 실행을 위한 코드를 넣는 것을 말함

SQL Injection 실습

  • 일단 웹 서버를 구동해야 함

  • 기초 기반은 다 완성했으니 실습 때마다 어떻게 웹 서버를 키는지만 기록하겠음

    • cmd에서 index.js 파일이 있는 경로로 위치 변경 후, 아래의 명령어 실행

      nodemon index.js

  • 데이터베이스에 SQL문을 보내려면 별도의 클라이언트가 필요

  • DB로 SQLite, 클라이언트로 DBeaver 툴을 사용

  • 웹에서 로그인할 때도 유사한 SQL문이 삽입됨

    • 사용자가 아이디와 패스워드를 입력하면 아래의 SQL문이 작성되어 DB로 전달

    • 만약 DB에 입력된 아이디, 패스워드와 동일한 계정이 있으면 결과 창에 계정 정보가 출력됨

    • DB에 동일한 계정이 없으면 아무것도 출력되지 않음

  • 아래의 그림은 실제로 웹 소스에서 SQL을 처리하는 부분을 나타냄

    • 일반 사용자가 웹에 접근하여 사용자의 아이디와 패스워드를 입력할 경우
      • 아이디는 user_email 변수에 반영
      • 패스워드는 password 변수에 반영
    • SELECT문을 실행한 결과 값이 확인되면 해당 사용자의 이름을 넘겨주고 로그인

  • 인증을 하기 위해 할 일

    • SQL 결과 값에 NULL이 나오지 않고 출력 값이 나오게 하면 로그인에 성공할 수 있음

    • 정확한 아이디와 패스워드를 아는 것이 가장 기본이긴 하지만 SQL문에서는 where로 입력되는 조건문을 항상 참으로 만들 수 있는 방법이 있음

    • 조건 값에 ' or ''=' 입력하는 것

      ' or ''='

    • 패스워드 값에 위의 조건을 입력했을 때 나온 SQL 결과 값

  • 이를 실제 웹 사이트에서 실행

  • 아이디에 admin@russia.com, 패스워드에 ' or ''=' 입력

    • 실제 admin@russia.com의 비밀번호는 admin

  • ' or ''=' 문구를 넣었을 때 로그인에 성공한 모습
  • 단순히 ' or ''=' 문구만 가능한 것은 아님
    • ' or '1'='1
    • ' or ''='--
    • 위의 두 문구와 같이 SQL문이 결과적으로 참이 되는 SQL문은 무엇이든 SQL 공격에 사용될 수 있음
      • SQLite, MS-SQL에서 '--'는 주석 처리 표시
  • SQL Injection은 로그인뿐 아니라 웹에서 사용자의 입력 값을 받아 DB에 SQL문으로 데이터를 요청하는 모든 곳에서 가능
  • 인증 외에도 경우에 따라서는 매우 다양한 형태의 SQL문을 실행할 수 있음
  • 주로 게시판이나 우편 번호 검색 등과 같이 대량의 정보를 검색하는 부분에서 웹 서버와 데이터베이스의 연동이 일어나기 때문에 그곳을 공략하면 SQL Injection에 성공할 수 있을 것
profile
Jin_Hahha
이전 포스트

[정보 보안 개론] 네트워크 보안( 분산 서비스 거부 공격: DDoS, 스니핑 공격, 스푸핑 공격, 세션 하이재킹 공격, 무선 네트워크 공격과 보안)

다음 포스트

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

0개의 댓글