웹 보안

이신필·2021년 12월 23일
0

웹 보안

목록 보기
1/1
post-thumbnail

웹 프로그래밍에 있어서 강력한 보안은 전문적인 지식을 가지고 있는 보안전문가에게 맡길 수 있다. 하지만 기본적인 설계,구현에 있어서 웹 개발자라면 어느정도 기본적인 공격 방법, 대응방법 정도는 알아야 한다고 생각하여 글을 정리해 보았다.

웹 해킹

웹 해킹(영어: web hacking)은 웹 사이트의 취약점을 공격하는 기술적 위협으로, 웹 페이지를 통하여 권한이 없는 시스템에 접근하거나 데이터 유출 및 파괴와 같은 행위를 말한다. (위키)

최신 브라우저, 라이브러리, 프레임워크등에서 기본적인 공격을 방어해주고 있지만, 기술 발전과 함께 공격 방법도 다양해 지고 있다.

국제 웹 보안 표준 기구인 OWASP(Open Web Application Security Project)에서는 3~4년 마다 트렌드에 맞고, 웹 환경에서 발생할 수 있는 다양한 취약점 상위 10가지를 발표한다.

2013년부터 삭제,통합, 생성된 (CRUD?) 다양한 취약점들을 볼 수 있는데 너무 어려우니 참고만하자... 오 근데, XSS CSRF같이 익숙한 이름도 보이고 XSS는 통합되긴 했지만 21년까지 살아남아 있다.

트렌드에 맞는 다양한 취약점은 보안전문가님께 맡기고? 우리는 기본적인 다음 3가지를 알아보자

  • SQL Injection
  • XSS
  • CSRF

SQL Injection

가장 기본적인 해킹 기법이기도 하면서 가장 강력한 공격이다. 이름 그대로 보안상의 취약점을 이용해 악의적으로 SQL문을 주입해서 데이터베이스가 비정상적으로 동작하게 하는 공격이다.

아래의 만화처럼 다음과 같은 엄청난 짓이 가능하다. → 당하면 바로 서비스종료각이다...

INSERT INTO students (이름) VALUES ('학생 이름');

위 명령어를 아래처럼 바꿔버릴 수도 있다고 한다!

INSERT INTO students (이름) VALUES ('Robert');
DROP TABLE students;
--');

최근 사용되는 DB관련 라이브러리, 프레임워크들에서는 대부분 방어하지만 알아둘 필요성이 있다. 위에 만화에서 언급된 방법을 포함해 다양한 SQL Injection 기법들이 존재한다.

Error Based SQL Injection

위에 소개한 방법처럼 논리적 애러를 이용한 SQL Injection 기법이다. 위에서는 그냥 drop시키면서 삭제 해버렸지만, Select 구문이라면 데이터를 탈취할 수도 있다.

SELECT * FROM User WHERE id = "입력1" AND password = "입력2"

아래처럼 변경 가능하다.

SELECT * FROM Users WHERE id = ""OR 1=1 --" AND password = "INPUT2"

Union Based SQL Injection

두 테이블의 컬럼 수가 같고 데이터 형이 같다면, 두 개의 쿼리를 결과를 합쳐주는 Union 명령어를 통해서도 가능하다. 

SELECT * FROM Board WHERE title LIKE "%입력%" OR contents "%입력%"

아래처럼 변경 가능하다.

SELECT * FROM Board WHERE title LIKE "% "UNION SELECT null,id,passwd FROM User --
	%" OR contents "%입력%"

Blind SQL Injection

쿼리의 결과로 단순히 참/거짓만 알 수 있을 때 사용하며, 서버 응답의 실패 메시지를 이용하여 database,table,column이름을 파악할 수 있다. 공격시 자동화 스크립트를 이용한다고 한다.

대응 방법

  • 입력 값 검증: 사용자 입력에 의해 쿼리가 영향을 받는다면 의도 하지 않은 입력값들을 검증하고 필터링해야한다.
  • Prepared Statement 구문사용: 미리 지정된 형식을 사용하는 방법, 사용자의 입력값이 파라미터로 들어가기전에 DBMS가 미리 컴파일 하여 실행하지 않고 대기한다.
    INSERT INTO products (name, price) VALUES (?, ?);

    Prepared Statement는 동일하거나 비슷한 데이터베이스 문을 높은 효율성으로 반복적으로 실행하기 위해 사용되는 기능이다. 일반적으로 쿼리나 업데이트와 같은 SQL 문과 함께 사용되는 프리페어드 스테이트먼트는 템플릿의 형태를 취하며, 그 템플릿 안으로 특정한 상수값이 매 실행 때마다 대체된다. → 위키 (효율성 측면에서도 좋다는 사실은 몰랐다!)

  • Error Message: 애러에 관한 내용이 노출되면 db의 정보, 쿼리문이 노출될 수 있기때문에 보여주지 말아야한다
  • 웹 방화벽 사용, 최소 권한 DB운영, 신뢰할 수 있는 네트워크만 접근 허용 등

XSS(Cross Site Scripting)

SQL injection처럼 가장 기초적인 취약점 공격 방법중 하나로 공격자가 클라이언트에 악성 스크립트를 삽입하는 공격이다. (주로 javascript를 이용)

원래 줄이면 CSS로 줄여지지만 우리가 아는 Style Sheet의 CSS와 겹쳐서 XSS라고 부른다고한다.

XSS의 종류는 다음과 같다.

  • Reflected XSS
  • Stored XSS
  • DOM Based XSS

Reflected XSS

가장 기본적인 XSS 형태, 보통 URL을 통해 공격을 진행한다. 공격자가 URL에 악의적인 스크립트를 포함하여 다음과 같이 만든다.

http://johnachuiyakhe?search=<script>alert("당신은 해킹당했..")</script>

저렇게 만든 URL을 메일이나 쪽지, 게시글등에 뿌려서 사용자들에게 접속을 유도하고 위 예시에서는 alert이지만 쿠키를 요청하는등의 스크립트로 만든다면 쿠키를 탈취할 수 있다.

Stored XSS

말그대로 저장된 XSS 공격, Reflected와 달리 지속적으로 공격이 가능하다. 아래 처럼 다수의 사용자가 볼 수 있는 게시글, 쪽지함 형태에서 많이 이용된다.


혹은 아래처럼 html을 넣어서 타사이트로 이동하게 할 수도 있다. (숨겨진 iframe)

<iframe src="http://www.hacker.com" width="0" height="0" frameborder="0"></iframe>

DOM Based XSS

위에서 설명한 두 XSS공격은 서버 측 결함으로 인해 공격이 실행된다. 하지만 DOM Based XSS공격은 서버와 관계없이 클라이언트측 코드가 원래 의도와 다르게 실행되면서 나타난다.

대응 방법

최신 프레임워크, 라이브러리를 이용하면 대부분 XSS에 대한 방어가 자동으로 된다.

  • XSS 공격에 대한 문자열 필터링
  • XSS 방어 라이브러리 사용
  • 웹 방화벽 사용

CSRF(Cross-Site Request Forgery)

사이트 간 요청 위조, 해커가 사용자의 의지와는 무관하게 권한을 얻어 공격을 의미한다.

사용자가 해커의 피싱 사이트에 접속을 해 로그인을 하거나, XSS공격으로 악성 스크립트가 실행되어 의도하지 않은 api가 실행되는 경우 해당한다.

실제로 1800 만명의 개인정보가 해킹당한 2008년 옥션의 경우 관리자가 작업중 메일을 조회하면서 해당 태그가 담긴 이메일을 열었다.

<img src="http://auction.com/changeUserAcoount?id=admin&password=admin" width="0" height="0">

열자마자 해당 이미지 파일을 받아오기 위해 URL이 실행되고 해커가 원하는 대로 id,pw가 모두 변경되었다.

대응 방법

일반적으로는 쓰기/변경이 가능한 post,updated,delete API에 방어를 적용하고, 중요한 정보를 가진 Get 조회에 적용할 수 있다. 방법은 다음과 같다.

  • Referrer 검증: 서버에서 reqeust header에 있는 referrer 속성을 검증하여 차단하는 방법

    HTTP 리퍼러(HTTP referer)는 웹 브라우저로 월드 와이드 웹을 서핑할 때, 하이퍼링크를 통해서 각각의 사이트로 방문시 남는 흔적을 말한다. →(위키)

    리퍼러는 조작 또한 가능하기 때문에 리퍼러 정보를 사용할 때에는 보안에 항상 주의해야 한다. 그리고 같은 도메인 내에서 XSS 취약점이 있는 경우 위험해 질 수 있다.(도메인 단위 검증에서도 세밀하게 하면 가능하긴 하다.)
  • CSRF Token (Security Token): 모든 요청에 토큰을 발급, 서버에서 검증하는 방법 로그인시 토큰을 생성하여 세션에 저장하고, 모든 요청시 검증함, 세션을 사용할 수 있는 환경이어야 함.
  • Double Submit Cookie 검증: 웹 브라우저의 same origin 정책으로 타 도메인의 쿠키값을 확인,수정하지 못한다는 것을 이용한 방어기법, 세션을 사용한 검증보다 가벼움
    1. 클라이언트에서 요청시 토큰 생성하여 쿠키에 저장
    2. 동일한 토큰 값을 요청 파라미터에 저장하여 서버에 전송
    3. 서버에서 쿠키의 토큰 값과 파라미터의 토큰값이 일치하는지 검사
  • CAPTCHA: 사람이 요청 한 것이 맞는지 검증하는 방식,

    우리가 자주보던 이런걸 캡차라고함 → 위키

참고자료

profile
이신필

0개의 댓글