웹 보안

호기성세균·2023년 6월 7일
0

cs

목록 보기
6/30

(웹의 이해)

팀 버너스 리가 연구 목적의 프로젝트로 시작. 웹은 수많은 보안 취약점이 내재되어 있어 해킹에 취약한 집중적인 공격대상

(HTTP프로토콜)

여러 프로토콜이 쓰이나 가장 많이 쓰이는 프로토콜은HTTP이다. HTTP는 웹 처리 전반에 걸친 토대가 되기 때문에 웹 서버를 HTTP서버라고 부르기도 한다

(HTTP Request)

1. GET방식

가장 일반적인 HTTP Request 형태로, 요청 데이터의 인수를 웹 브라우저의 url로 전송.
글자 수 제한 255자, 메신저 등에서 활용. 데이터가 주소 입력란에 표시되므로 최소한의 보안도 유지되지 않는 취약한 방식(id,pass 등의 인증정보 x)

2.POST방식

URL에 요청 데이터를 기록하지 않고 HTTP헤더에 데이터를 전송. 인숫값을 URL로 정송하지 않으므로 다른 사용자가 링크로 해당 페이지를 볼 수 없음. 내부 구분자가 파라미터를 구분, 서버가 구분자에 대한 내용 해석, 처리속도가 GET보다 상대적으로 느림

  • 게시판의 경우 : 목록이나 글 보기 화면은 접근 자유도를 위해 GET방식을 사용 게스글을 저장, 수정, 삭제하거나 대용량 데이터를 전송할 때는 POST방식 사용

3. 기타방식

  • HEAD방식 : 서버 측 데이터를 검색하고 요청하는 데 사용
  • OPTIONS 방식 : 자원에 대한 요구/ 응답 관계와 관련된 선택 사항 정보를 요청할 때 사용
  • PUT방식 : 메시지에 포함된 데이터를 지정된 URL장소에 그 이름으로 저장
  • DELETE방식 : URL에 지정된 자원을 서버에서 지울 수 있게 함
  • TRACE방식 : 요구 메시지를 최종 수신처까지 루프백을 검사하는 데 사용(중간에 거쳐가는 네트워크 장비의 경로 등을 추적할 때 사용)

(HTTP Response)

  • 클라이언트의 HTTP Response에 대한 응답 패킷
  • 서버에서 쓰이는 프로토콜 버전, request에 대한 실행 결과 코드, 간략한 실행 결과 설명문 내용이 담겨 있음
  • 추가 정보로 전달할 데이터 형식, 길이 등이 MIME형식으로 표현되어 있음
  • 헤더 정보 뒤에는 실제 데이터(HTML 또는 이미지 파일)가 전달됨
  • 데이터 전달이 끝나면 서버 연결을 끊음

(프론트엔드)

1. HTML

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

  • 서버에 HTML문서를 저장하고 있다가 클라이언트가 특정 HTML페이지를 요청하면 해당 문서를 전송.
    클라이언트는 이 웹 페이지를 해석하여 웹 브라우저에 표현(정적인 웹 페이지).
    웹 브라우저와 웹 서버 사이에 전달되는 값을 변조하여 웹 서버 설정이나 로직을 바꾸는 웹 해킹에서 정적인 웹 페이지는 바꿀 수 있는 가능성이 매우 낮다는 것이 보안상 장점

2. CSS(client side script)

  • 동적인 웹 서비스를 제공하기 위해서 자바스크립트, 비주얼베이직 스크립트 등이 사용.
    현재 프론트 엔드를 담당하는 스크립트는 자바스크립트. 자바스크립트는 html과 마찬가지로 웹 브라우저에 의해 해석 및 적용되며 css라고 함.
    서버가 아닌 웹 브라우저에서 해석되어 화면에 적용되어 웹 서버의 부담을 줄이면서도 다양한 기능을 수행

3. 백엔드

  • 웹서비스를 제공하는 데 필요한 rest API를 제공하는 영역. 백 엔드의 역할은 클라이언트에 구현된 기능에 필요한 인지를 전달받고, 이 인자에 따라 함수처럼 그에 대한 결과만 전달함. 함수는 URL에 따라 구분되며, 보통 그 결과는 JSON형태로 클라이언트에 전달

- (웹 취약점 스캐너를 통한 정보 수집) :

웹 취약점 스캐너를 통한 정보 수집은 빠른 시간 내에 다양한 접속 시도를 수행할 수 있다는 것이 장점. 웹 취약점 스캐너로 확인된 취약점은 실제 보안 문제가 있는 취약점이 아닌 경우가 많음

- (웹 프록시를 통한 취약점 분석) :

웹의 구조를 파악하거나 취약점을 점검할 때 혹은 웹 해킹을 할 때는 웹 프록시 툴을 사용. 일반적으로 웹 해킹에 사용되는 웹 프록시는 클라이언트에 설치되고 클라이언트의 통제를 받음. 클라이언트가 웹 서버와 웹 브라우저 간에 전달되는 모든 HTTP 패킷을 웹 프록시를 통해 확인하면서 수정할 수 있음

-(구글 해킹을 통한 정보 수집) :

웹 해킹을 하면서 많은 정보를 수집하려면 구글 같은 검색 엔진이 유용
+검색 엔진의 검색을 피하는 방법 : 구글 검색 엔진의 검색을 막는다/ 모든 검색 로봇의 검색을 막는다./ dbconn.ini파일을 검색하지 못하게 한다./ admin 디렉터리에 접근하지 못하게 한다

(웹의 주요 취약점)

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

  • 클라이언트의 요청을 처리하기 위해 전송 받는 인수에 특정 명령을 실행할 수 있는 코드가 포함되는 경우 특정 명령을 실행하는 코드를 적절히 필터링하지 못하면 삽입 공격에 대한 취약점이 발생
  • 명령 삽입 공격은 SQL, OS, LDAP 등 웹으로 명령을 전달하는 모든 경우에 적용 가능
  • 웹 서버에서 데이터베이스로 전송되는 SQL쿼리에는 아이디, 패스워드, 검색어 등 여러가지 인수가 사용됨
  • SQL삽입 공격은 이 인수에 추가 실행 코드를 넣는 것
  • 웹에서 로그인할 때 도 이와 유사한 SQL문이 삽입

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

  • 취약한 패스워드 설정 : 웹의 경우 사용자는 개발자가 처음 설정한 패스워드를 그대로 쓰는 경우가 많음.
    웹에서 admin/admin과 같이 취약한 패스워드를 자주 발견할 수 있음

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

  • XSS : 공격자가 작성한 스크립트가 다른 사용자에게 전달되는 것
  • 다른 사용자의 웹 브라우저 안에서 적절한 검증 없이 실행되기 때문에 가용자의 세션을 탈취하거나 웹 사이트를 변조하고 악의적인 사이트로 이동할 수 있음

-XSS 공격의 구조
①임의의 XSS 취약점이 존재하는 서버에 XSS 코드를 작성하여 저장
②공격자가 작성해놓은 XSS코드에 해당 웹 서비스 사용자가 접근
③웹 서버는 사용자가 접근한 XSS 코드가 포함된 게시판의 글을 사용자에게 전달
④사용자의 시스템에서 XSS 코드가 실행
⑤XSS코드 실행 결과가 공격자에게 전달되고 공격종료

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

  • 인증된 사용자가 수행할 수 있는 것에 대한 제한을 제대로 적용하지 않은 것을 의미
  • 이 취약점에 노출되면 일반 사용자나 로그인하지 않은 사용자가 관리자 페이지에 접근 하여 관리자 권한의 기능을 악용할 수 있음
  • 인증 우회를 막으려면 웹의 중요 페이지에 세션 값(쿠키)를 확인하는 검증 로직을 입력해두어야 함
  • 프로그램 개발시 표준 인증 로직을 만들어 웹에 존재하는 모든 페이지의 앞부분에 입력해야 함

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

  • 백업 및 임시파일 존재 :
    웹 사이트 개발시 웹 서버 백업 파일이나 임시 파일을 삭제하지 않고 방치하면 공격자가 백업 파일을 통해 웹 애플리케이션의 내부 로직, 데이터베이스 접속 정보 등 획득 가능
  • 미흡한 주석 관리 : 웹 애플리케이션에서 웹 프록시를 이용하면 일반 사용자도 볼 수 있는 주석에는 웹 애플리케이션 개발 과정, 주요 로직에 대한 설명, 디렉터리 구조, 테스트 소스 정보, 아이디와 패스워드 등이 기록됨.
    웹 애플리케이션 개발시 주석에 정보를 기록할 때 주의해야함
  • 파일업로드 제한 부재 :
    공격자가 웹 서버에 악의적인 파일을 전송한 뒤 원격지에서 실행하면 웹 서버 장악, 내부 침투 공격 수행 가능.
    웹 해킹의 최종 목표인 웹 서버 통제권을 얻기 위해 반드시 성공해야 하는 공격
    +리버스 텔넷 : 웹 해킹으로 시스템 권한을 획득한 후 해당 시스템에 텔넷과 같이 직접 명령을 입력하고 확인할 수 있는 셀을 획득하기 위한 방법으로, 방화벽에 있는 시스템을 공격할 때 자주 사용

6.민감한 데이터 노출(A6. Sensitive Data Exposure)

  • 웹 사이트 해킹으로 개인 정보가 유출되는 것은 신용카드 번호, 주민등록번호, 인증 신뢰 정보와 같은 민감한 데이터를 보호하지 않는 것이 주요한 원인.
    민감한 데이터를 보호하려면 데이터 중요도에 따라 암호화 로직을 사용하고 데이터베이스 테이블 단위에서 암호화를 수행해야 함

7.공격방어 취약점(A7. Insufficient Attack Protection)

  • 예전 웹 애플리케이션은 패킹 공격을 탐지 방지 대응할 수 있는 기능을 갖추고 있지 않았음.
    apt공격이 일반화되면서 보안 솔루션으로 탐지가 어렵자 웹 애플리케이션 수준에서 자동으로 탐지 로깅 응답 및 공격 시도 차단을 포함하도록 권고

8.CSRF취약점(A8. Cross-Site Request Forgery)

CSRF :
특정 사용자를 대상으로 하지 않고 불특정 다수를 대상으로 로그인된 사용자가 자신의 의지와 무관하게 공격자가 의도한 행위(수정, 삭제, 등록, 송금 등)을 하게 만드는 공격.
기본적으로 XSS 공격과 매우 유사하며 그의 발전된 형태로 보기도 함.
XSS공격은 악성 스크립트가 클라이언트에서 실행되는 데 반해 CSRF 공격을 하면 사용자가 악성 스크립트를 서버에 요청

9.취약점이 있는 컴포넌트 사용(A9. Using Components with Known Vulnerabilities)

  • 컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈이 다양하게 사용되면서 보안에 취약한 컴포넌트가 악용되면 심각한 데이터 손실, 서버 장악이 가능해짐.
    사용하려는 컴포넌트, 라이브러리의 보안 취약점을 충분히 검토해야 함

10.취약한 API(A10. Underprotected APis)

API를 통해 웹 서비스 상호 간의 연동이 이루어지므로 API 사용시 보안에 취약하지 않은지 충분한 검토가 필요

profile
공부...열심히...

0개의 댓글