[정보보안기사 실기] 어플리케이션 보안 - 웹 취약점

[정보보안기사 실기] 어플리케이션 보안 - 웹 취약점

SQL Injection

- Web Application에서 입력 받아 database에 전송하는 SQL 쿼리를 변조해 권한 상승, DB 조회 등을 수행해 DB에 불법적인 접근을 시도하는 공격

- SQL Injection 취약점 스캐너 : Nikto, SQLMap, Absinthe

SQL Injection 분류(공격 방식)

1. Form SQL Injection

- HTML Form 기반 인증을 실시하는 웹 어플리케이션의 취약점을 이용해 인즈을 위한 쿼리문의 조건을 조작해 인증을 우회하는 공격

- where절을 항상 참이 되도록 조작

1) 공격 방식

- 쿼리문에 사용되는 특수문자를 넣어 에러 발생 여부 확인

-> 에러 발생 시 입력값 검증이 없는 취약한 페이지로 판단

- 'or '1' ='1'# 등 항상 참이되는 조건으로 조작하고 '#'을 이용해 뒷부분은 모두 주석 처리

- select한 결과의 첫번째 레코드로 로그인됨

2) 대응 방법

- php,ini 파일의 'magic_quotes_gpc=0' 설정

-> 특수문자를 이스케이프 처리해 SQL Injection 공격 방지

-> 최신 버전은 지원하지 않아 mysql_real_escape_string() 함수 사용

- mysql_real_escape_string() 함수 사용

-> 특수문자를 이스케이프 처리해 SQL Injection 공격을 방지하는 함수

- prepared statement(선처리 질의문)을 이용

-> 외부 입력 값을 제외한 쿼리 부분을 미리 컴파일 하고 입력값만을 설정해 실행하는 방식

-> 성능이 향상되고 공격을 방지할 수 있음

-> 선처리 질의문의 입력값을 '?'로 설정

prepare("select id,pw from table where id=? and pw=?");

bind_param("ss",$id,$pw);

execute();

- Blacklist(파라미터 필터링) 활용

-> 문자열을 필터링할 수 있는 함수를 설정해 검증 수행

2. Union SQL Injection

- union select 쿼리를 이용해 한 쿼리의 결과를 다른 쿼리의 결과에 결합해 공격하는 기법

- 각 select문의 컬럼 갯수는 같아야함

1) 공격 방식

- 컬럼 갯수 파악

-> order by를 이용해 컬럼 갯수 파악

-> 1씩 증가시켜가며 오류가 날 경우 가장 큰 값이면서 오류가 나지 않는 값을 찾고 이 값이 컬럼 갯수라는 것을 알 수 있음

- union select 이용

-> 선행 select문의 where 절을 빈 값으로 하고 union select문에서 특정 id에 대한 password를 지정해 결과를 반환

-> union select를 이용해 원하는 id에 passsword를 만들어 인증 우회

ex) select id,pw from table where id ='' union select 'admin', 'admin';

-> id : admin, pw : admin

3. Stored Procedure SQL Injection

- Stored Procedure : 쿼리를 함수처럼 실행하기 위해 만든 쿼리의 집합

- 입력 데이터 뒤에 ';'를 붙인 후 EXEC을 통해 Procedure 실행

4. Mass SQL Injection

- 한번의 공격으로 대량의 DB str값을 변조시켜 웹 사이트에 치명적인 영향을 미치는 공격

- DB 변조 시, DB에 들어있는 데이터들에 악성 스크립트를 삽입해 웹 사이트에 접속하는 사용자에게 감염되도록 함

SQL Injection 분류(공격 유형)

1. Error-Based SQL Injection

- 에러 값을 넣으며 점진적으로 DB 정보를 획득하는 방법

- 입력 값에 Query에 관련된 특수 문자를 삽입해 에러가 발생된다면 취약점이 있다고 판단할 수 있음

- 최근에는 에러 값을 사용자에게 노출시키지 않아 거의 사용되지 않음

2. Blind SQL Injection

- 쿼리 결과의 참과 거짓을 통해 의도하지 않은 SQL문을 실행하여 DB를 비정상적으로 공격하는 기법

- 참과 거짓에 대한 반응이 다르므로 이것을 파악하는 것이 우선

- 많은 비교과정을 거치므로 자동화 도구를 사용하는 것이 일반적

1) 공격 방식

- where 절을 참, 거짓으로 조작해 반응을 확인

- limit, substr 함수 등을 이용해 얻으려는 정보의 값을 비교해가며 참이 되는 값을 찾음

-> 첫번째 값을 찾은 후 범위를 1씩 증가시켜가며 완성된 값을 찾을 수 있음

-> table 명 : information_schema.tables

-> 컬럼 명 : informatinon_schema.columns

-> substr(string, begin, size) : string에서 begin 위치부터 size만큼 자름

-> limit begin, size : begin 위치부터 size만큼 출력

ex) select * from table where id ='admin' and substr(select pw from table where id = 'admin',0,1) = '1'# and pw = '1234'

-> '1'의 값을 수정하며 비밀번호 첫번째 자리를 알 수 있음

-> 이 후 substr의 값을 바꿔가며 전체 비밀번호를 찾을 수 있음

- union select를 이용해 찾은 테이블의 정보를 가져와 볼 수 있음

XSS(Cross Site Script)

- 입력 값 검증이 제대로 되지 않으면 공격자가 입력이 가능한 폼에 악성 스크립트를 삽입해 희생자 측에서 동작하도록 하는 취약점

- 사용자의 개인정보, 쿠키정보 탈취

- 악성코드 감염, 웹 페이지 변조

Stored XSS

- 웹 서버에 게시판 등을 이용해 악성 스크립트를 저장하게 되면 사용자가 이 페이지를 요청할 시 악성 스크립트가 호출되어 동작하는 방식

1) 공격 방식

- 게시판 등 DB에 정보를 등록할 수 있는 곳에 스크립트를 삽입해 희생자가 글을 열 때, 스크립트가 실행되게하여 공격자에게 쿠키를 전송하게 하는 등 악성 스크립트가 실행되게함

2) 대응 방안

- 사용자의 입력 값 검증

-> htmlspecialchars() 함수를 이용해 특수문자를 이스케이프 처리함

-> strip_tags() 함수를 이용해 특수문자 제거

- 게시물 열람 시 스크립트를 일반 문자로 처리

Reflected XSS

- 악성 스크립트가 포함된 것을 희생자에게 전달하고 희생자의 액션에 의해 웹 서버로 악성 스크립트가 전달되고 웹 서버의 응답 페이지에 악성 스크립트가 삽입되어 희생자 측에서 동작되게 하는 방법

- DB에 저장되는 Stored XSS와 달리 요청 정보에 악성 스크립트가 삽입되어 악성 스크립트가 포함된 응답 페이지에 포함되어 희생자에게 전달

DOM Based XSS

- DOM : 웹 페이지 내에 있는 모든 객체들을 조작, 관리할 수 있는 계층 구조 형태의 문서 객체 모델

- 응답 페이지에 포함된 정상 스크립트가 실행되면서 DOM 객체를 실행할 때, URL 등에 포함된 악성 스크립트가 실행되게함

- DOM Based XSS는 응답 페이지에 관계없이 웹 브라우저에서 발생

대응 방법

1. 입력 값 검증을 클라이언트 측에서 할 경우 Web Proxy(Paros, Burp)를 통해 우회 가능하므로 서버 측에서 해야함

2. 입력 값에서 HTML 코드로 인식되는 특수문자를 이스케이프 처리(HTML 태그 허용 시 화이트리스트 활용)

1) 치환 필요 문자

- ( : (, ) : )

- < : &lt;, > : &gt;

- & : &amp;

- / : &#x2F;

- " : #quot;, ' : &#x27;

- # : &#x23;

CSRF(Cross Site Request Forgery)

- 웹 어플리케이션이 정상적인 요청과 비정상적인 요청을 구분하지 못할 경우, 공격자가 스크립트를 이용해 희생자가 정상적인 요청인 것처럼 비정상적인 요청을 전송하게 하여 계정 변경 등의 문제를 발생시키는 취약점

- 공격자가 GET or POST 방식의 요청으로 희생자가 공격자의 의도된 행위를 수행하게함

- 희생자의 권한을 공격자가 얻을 수 있음

공격 방식

- 게시판에 변경할 비밀번호를 파라미터로 하여 비밀번호 변경 페이지를 요청하는 스크립트 or 링크를 넣은 게시글을 작성해 사용자가 클릭하게함

- 사용자가 해당 링크를 클릭할 시 공격자의 의도된 비밀번호로 계정 비밀번호가 변경됨

취약점 판단 기준

- 입력 가능한 폼에 img 태그의 src 속성을 이용해 조작된 요청이 입력되고 요청이 실행되면 취약한 것으로 판단

대응 방법

1. 모든 HTTP 요청에 예측할 수 없는 토큰을 추가해 정상, 비정상 요청을 구분

- 세션 토큰과 요청 토큰 비교

- 세션 검증과 재인증 유도

2. XSS와 비슷하므로 XSS 취약점 제거

Command Execution 취약점

- 웹 어플리케이션에서 시스템 명령어 실행 함수를 제공하고 입력 값 검증이 제대로 되어있지 않아 공격자가 시스템 명령어를 호출할 수 있는 취약점

- 시스템 계정 정보 유출, 백도어 설치, 관리자 권한 탈취

취약점 판단 기준

- 입력 가능 폼에 시스템 명령어를 삽입해 실행되면 취약한 것으로 판단

대응 방법

1. 사용자 입력 값 검증

- 운영체제 명령어를 실행할 수 있는 문자를 검사

- 블랙리스트를 이용해 비허용 문자 확인

2. 시스템 명령어 삽입 시 경고메시지 or 로그 기록(블랙리스트 활용)

1) php함수

- shell_exec()

- passthru()

- exec()

- system()

3. 명령어 사용이 필요한 경우 화이트리스트 활용

File Upload 취약점

- 파일 업로드 기능이 존재하고 확장자 필터링이 제대로 이루어지지 않은 경우, 웹쉘을 업로드해 해당 웹셀을 통해 원격에서 시스템을 제어할 수 있는 취약점

- 시스템 제어, 웹 페이지 변조

공격 방식

- 파일 업로드가 가능한 게시판에 웹쉘 업로드

- POST 요청의 multipart/form-data 형식으로 전달

- 웹쉘 파일 경로 확인

- 웹쉘 실행

취약점 판단 기준

- 파일 업로드가 가능한 입력 폼에 웹쉘 업로드를 시도해 업로드에 성공한 경우 취약한 것으로 판단

대응 방법

1. 업로드 파일 확장자에 대한 필터링을 통해 웹쉘 업로드 차단(화이트리스트 활용)

2. 파일저장 전용 디렉토리 생성 후, 웹 서버 데몬 설정파일에서 실행 설정을 제거해 웹쉘이 실행되지 않게함

File Download 취약점

- 파일 다운로드 기능이 존재하고 다운로드 시 경로 or 파일 명을 파라미터로 받아 처리하는 경우 필터링 처리를 하지 않으면 공격자가 이를 조작해 허용되지 않은 파일을 다운로드할 수 있는 취약점

- 시스템 환경 설정 파일, 소스 코드 파일, DB 파일 등 중요 파일을 다운로드할 수 있음

공격 방식

- 정상적인 파일 다운로드 후 URL 파라미터 확인

- URL 파라미터를 조작해 허용되지 않은 파일 다운로드

취약점 판단 기준

- 다운로드가 가능한 페이지의 파라미터를 조작해 임의의 파일을 다운로드할 수 있는 경우 취약한 것으로 판단

대응 방법

1. 허용하는 경로와 이름 이외의 디렉토리, 파일에 접근할 수 없게함

2. 경로를 변경할 수 있는 문자열 필터링( . , .. , /)

File Inclusion 취약점

- 공격자가 악성 스크립트를 서버에 전달해 해당 페이지를 통해 악성 코드가 실행되도록 하는 취약점

- 삽입할 악성 스크립트 파일의 위치에 따라 LFI(Local File Inclusion)와 RFI(Remote File Inclusion)으로 나누어짐

공격 방식

- include 함수를 이용해 악성 스크립트를 포함한 페이지를 include함

- URL 파라미터에 웹쉘의 위치를 포함시켜 전달해 해당 파일이 include되어 웹쉘이 실행되게 함

대응 방법

1. 소스코드에 include, require 등의 함수가 존재하는지 검증

- 입력 값으로 파일명이 결정된다면 악의적 파일이 포함되어 실행되지 않도록 설정(php.ini 파일의 allow_url_fopen 속성을 Off)

URL/파라미터 변조 취약점

- 실행 경로에 대한 접근 제어를 검사하지 않는 경우 공격자가 URL/파라미터 값을 조작해 중요 정보에 접근할 수 있게 되는 취약점

- 입력 값 검증의 누락이 발생하는 모든 상황을 포함

- SQL Injection, XSS 등 다양한 공격에 이용

공격 방식

- 파라미터를 원하는 값으로 조작

- 해당 파라미터로 보여지는 페이지, 정보등을 볼 수 있음

취약점 판단 기준

- 파라미터를 조작해 권한 상승 or 정보 유출이 발생하는 경우 취약한 것으로 판단

대응 방법

1. 제공하는 정보, 기능을 역할에 따라 분류해 데이터 노출을 최소화

2. 파라미터 변조 여부를 검증하고 중요 정보 페이지 접근 시 재인증

3. 파라미터 대신 서버 측 세션 정보를 이용해 정보를 보여주게 함

불충분한 세션 관리 취약점

- 사용자 로그인 시 매번 동일한 세션 ID를 발급하거나 세션 타임아웃이 너무 긴 경우 공격자가 사용자의 세션을 재사용해 권한을 탈취할 수 있는 취약점

공격 방식

- 세션 ID, 쿠키 정보를 탈취함

- 탈취한 정보를 이용해 로그인

취약점 판단 기준

- 세션 ID를 분석, 변조해 로그인에 성공할 경우 취약점이 있는 것으로 판단

대응 방법

1. 세션 ID는 로그인마다 추측할 수 없는 랜덤한 값으로 생성

2. 세션 타임아웃을 적절하게 설정(권장 : 10분~30분)

- php.ini 파일의 session.gc_maxlifetime(초단위) 설정

3. HttpOnly 속성을 이용해 쿠키정보가 탈취되는 것을 막음

- php.ini 파일의 session.cookie_httponly 속성을 1(true)로 설정

약한 문자열 강도 취약점

- 안전한 패스워드 규칙이 없어 취약한 패스워드로 회원가입이 가능한 경우 Dictionary Attack or Brute Force를 통해 패스워드를 획득할 수 있는 취약점

공격 방식

- Brute Force or Dictionary Attack을 통해 정상적인 응답이 올 때까지 시도

취약점 판단 기준

- 패스워드 크래킹 툴을 사용해 취약한 패스워드 사용 여부 확인

대응 방법

1. 영 대소문자, 숫자, 특수문자 사용 권장

2. 취약한 패스워드를 사용하지 못하도록 권장

- 유추 가능한 패스워드

- 사전에 있는 단어

3. 패스워드를 주기적으로 변경하게함(최소, 최대 사용기간 설정)

4. 계정 잠금 정책 지원(로그인 실패 회수 제한)

5. 계정 존재 유무를 알지 못하도록 '패스워드가 틀렸습니다.'와 같은 메시지 보다는 '올바르지 않은 정보입니다.'와 같은 메시지 출력

정보누출 취약점

- 민감한 정보가 개발자의 부주의로 노출되는 것으로 중요 정보를 주석 구문에 포함시켜 의도하지 앟ㄴ게 정보가 노출되거나 에러 메시지를 통해 불필요한 정보가 노출되는 취약점

노출 방식

1. Default 에러 페이지에 의한 정보 노출

2. 에러 메시지에 의한 정보 노출

- 프로그램 실행 에러, DB 에러 등을 보여주게 되어 정보 노출

대응 방법

1. 웹 서버 환경 설정 파일(httpd.conf) 파일 설정

- 사용자 정의 에러 페이지를 생성하여 보여줌

ErrorDocument error_num file_path

2. php.ini 파일을 이용해 에러 메시지 차단

- display_errors 속성 값을 Off로 설정

기타 취약점

XPath/XQuery Injection

- DB가 연동된 웹 어플리케이션에서 XPath, XQuery에 대한 필터링이 제대로 되지 않으면 입력 가능한 폼에서 조작된 질의문을 삽입하여 인증 우회를 통해 데이텨 열람을 할 수 있게 되는 취약점

1. 대응 방법

- XPath, XQuery에 사용되는 외부 입력 데이터에 대해 필터링 수행

- 스트링을 연결하는 형태가 아닌 인자화된 쿼리문 사용

악성 컨텐츠 취약점

- 입력 값 검증이 제대로 이루어지지 않으면 공격자가 악성 컨텐츠를 삽입할 수 있고 이 페이지에 접속하는 사용자는 악성 코드 유포 사이트가 자동으로 호출되어 악성 코드에 감염되는 취약점

1. 대응 방법

- SQL Injection, XSS 등을 통해 삽입이 가능하므로 해당 취약점들을 제거

불충분한 인증/인가 취약점

- 개인 정보 수정 페이지 등에서 사용자 인증이 미흡할 경우, 공격자가 파라미터 값을 조작해 사용자 도용, 개인정보 노출 문제가 발생할 수 있는 취약점

1. 대응 방법

- 세션에 저장된 아이디 값과 파라미터 값을 비교해 인증/인가

- 세션을 통해 변수를 저장, 관리

취약한 패스워드 복구 취약점

- 비밀 번호 찾기, 임시 비밀번호 발급 시 인증이 미흡하거나 비밀번호를 출력하는 경우 공격자가 비밀번호를 탈취, 변경, 복구할 수 있는 취약점

1. 대응 방법

- 사용자를 식별하기 위한 사용자 고유값 사용

- 본인 인증 메커니즘 구현 시 추측 불가능하게 하고 임시 패스워드 발급 시 안전한 난수 값 사용

자동화 공격 취약점

- 특정 프로세스에 대한 접근 시도 횟수 제한을 하지 않을 경우, 자동화 도구를 이용해 지속해서 접근을 시도하고 많은 프로세스가 수행되어 시스템 성능에 영향을 미칠 수 있는 취약점

1. 대응 방법

- 일정 횟수 로그인 시도/실패 시 차단

- CAPTCHA 사용

데이터 평문 전송 취약점

- 데이터가 평문으로 전송될 경우, 공격자가 스니핑을 통해 데이터를 획득할 수 있는 취약점

1. 대응 방법

- 중요 데이터에 대한 암호화 적용

- SSL 등 암호화 통신 사용

쿠키 변조

- 공격자가 쿠키를 변조해 권한 상승이나 다른 사용자의 권한 탈취가 가능한 취약점

1. 대응 방법

- 쿠키를 사용하는 대신 세션 사용(쿠키를 사용해야할 경우 암호화해서 사용)

개발 보안 관리

개발 보안 안내서

1. 사용자에게 전달된 값을 재사용할 경우 신뢰해서는 안됨

2. 최종 통제 메커니즘은 반드시 서버에서 수행되어야함

- 클라이언트 측 검증은 프록시 등을 이용해 우회할 수 있기 때문에 최종 검증은 서버 측에서 해야함

3. 클라이언트에게 중요한 정보를 전달하지 않아야함

- 클라이언트에서 실행되는 컴포넌트에 중요 정보를 하드코딩하면 안됨

4. 중요 정보 전송 시 POST 방식 사용 or SSL 통신 적용

5. 중요한 트랜잭션이 일어나는 프로세스에서는 비밀번호 재확인

- 비밀번호 변경, 개인정보 변경 페이지 등

6. 중요 정보를 보여주는 페이지는 Cache를 사용하지 못하게 해야함

- 해당 페이지에 no-cache 설정을 하지 않으면 로그아웃을 한 이후에도 볼 수 있음

-> no-cache : 페이지 요청 시 마다 서버로부터 새로 받아 사용하도록 알리는 설정

-> head부분에 추가

<meta HTTP-EQUIV="Pragma" CONTENT="no-cache">

<meta HTTP-EQUIV="Cache-Control" CONTENT="no-cache">

7. 적절한 방법으로 암호화

8. 각 언어에서 제공하는 보안 수단을 이해한 후 사용