Always-Try(정보보안 및 일상)

[정보보안기사][실기] 웹 어플리케이션 취약점(SQL Infection, XSS, CSRF, 개발 보안 안내서 등등) 본문

정보보안 자격증 + ISMS-P

[정보보안기사][실기] 웹 어플리케이션 취약점(SQL Infection, XSS, CSRF, 개발 보안 안내서 등등)

Always-Try 2021. 10. 6. 23:29

SQL Injection 

 

더보기

1. 개요

  • Web Application에서 입력 받아 데이터베이스로 전달하는 정상적인 SQL 쿼리를 변조, 삽입하여 불법 로그인, DB 데이터 열람, 시스템 명령 실행 등을 수행하여 비정상적인 데이터베이스 접근을 시도하는 공격 기법

2. 종류

  • Form SQL Injection
  • Union SQL Injection
  • Stored Procedure SQL Injection
  • Mass SQL Injection
  • Error-Based SQL Injection
  • Blind SQL Injection

3. 대응 방법

  • 입력값에 대한 검증 수행
  • SQL Injection 관련 특수문자들 치환
    • php.ini의 magic_quotes_gpc = on
    • mysql_real_escape_string() 함수 사용
  • 블랙리스트 기반의 필터링
  • Prepared Statement 활용

 



크로스 사이트 스크립트(XSS: Cross Site Script)

 

더보기

1. 개요

  • 공격자가 입력이 가능한 폼(웹 브라우저 URL 또는 게시판 등)에 악의적인 스크립트를 삽입, 해당 스크립트가 희생자 측에서 동작하도록 하여 악의적인 행위를 수행하는 취약점
  • <script> document.cookie </script>

2. 종류

  • Stored XSS
    • 악성 스크립트가 담긴 게시물이 DB에 저장하는 방식
  • Reflected XSS
    • 메일로 악성 스크립트가 담긴 웹 서버 요청을 보내고, 사용자가 요청 클릭 시 처리 과정 상 파라미터로 전달된 악성 스크립트를 포함한 응답페이지 생성
  • DOM Based XSS
    • 메일로 악성 스크립트가 담긴 웹 서버 요청을 보내고, 사용자가 요청 클릭 시 악성 스크립트가 없는 응답페이지가 옴. 응답 페이지 상의 자바스크립트가 로컬에서 동작(DOM 객체 이용)하면서 악성 스크립트 동작

3. 대응 방법

  • 사용자 입력값에 대한 검증은 반드시 서버 단에서 하기
  • HTML 코드로 인식될 수 있는 입력 문자열 치환 (    < &lt > &gt ( &#x28 ) &#x29 & &amp / &#x2F     )
  • HTML 태그가 필요하면 허용할 HTML 태그만 허용 (화이트리스트)

 



크로스 사이트 요청 변조(CSRF:Cross Site Request Forgery)

 

더보기

1. 개요

  • 웹 어플리케이션에서 정상적인 경로를 통한 요청과 비정상적인 경로를 통한 요청을 서버가 구분하지 못할 경우 공격자가 조작된 스크립트 구문을 정상적인 사용자에게 전송하여 게시판 설정 변경, 회원 정보 변경 등의 문제가 발생할 수 있는 취약점

2. 공격 방법

  • 사용자 입력 폼에 <img src="조작된 요청"> 이 실행되는지 확인

3. 대응 방법

  • HTTP 요청에 예측할 수 없는 임의의 토큰을 추가하여 정상/비정상 요청 판별
  • XSS와 공격 방식이 유사하므로 대응 방법도 XSS 참고

 

 

 

운영체제 명령 실행(Command Execution) 취약점

 

더보기

1. 개요

  • 웹 어플리케이션에서 system(), exec()와 같은 시스템 명령어를 호출할 수 있는 취약점

2. 공격 방법

  • 입력 폼에 시스템 명령어 삽입
    • 127.0.0.1;cat /etc/passwd
  • (참고) 리눅스 명령어 연속 실행 조건
    • 명령1 ; 명령2  -> 명령1 수행 후 명령2 수행
    • 명령1 && 명령2 -> 명령1 결과가 참일 경우만 명령2 수행
    • 명령1 || 명령2 -> 명령1 결과가 거짓일 경우만 명령2 수행
    • 명령1 | 명령2 -> 명령1 결과를 명령2의 표준입력으로 전달

3. 대응 방법

  • 사용자 입력값 필터링
  • 꼭 필요한 운영체제 명령어를 사용해야 한다면 화이트리스트 기반으로 운영
  •  

 


파일 업로드 취약점

 

더보기

1. 개요

  • 허가 되지 않은 파일(ex. 웹쉘)을 웹 서버로 업로드 할 수 있는 취약점

2. 대응 방법

  • 업로드 파일에 대한 확장자 검증
  • 업로드 파일에 대한 파일 타입(MIME 타입) 검증
  • 파일 업로드 디렉터리에 있는 스크립트 파일이 실행되지 않도록 제한
    • httpd.conf의 AllowOverride ALL 설정 이후 htaccess 생성
      • <FilesMatch "\. (ph|inc|lib) ">
            Order allow, deny
            Deny from all
        -> deny 정책 이후 allow 정책을 본다. deny all이라 모두 차단
        </FilesMatch>
        AddType text/html .html .htm .php .php3 .php4 .phtml .phps .in .cgi .pl .shtml .jsp
        -> html~jsp 까지 모두 text/html로 동작하도록 하겠다는 뜻

 

 


파일 다운로드 취약점

 

더보기

1. 개요

  • 파일을 다운로드 받을 때, 노출되는 URL의 조작(디렉터리 트레버셜 포함)을 통해 파일을 다운로드 받는 공격

2. 대응 방법

  • 사용자 입력값 필터링 (ex. . \ 등의 문자열 차단)

 


파일 삽입 취약점

 

더보기

1. 개요

  • 악성 서버 스크립트를 서버에 전달하여 해당 페이지를 통해 악성코드가 실행되도록 하는 취약점
  • include 함수

2. 종류

  • LFI (로컬)
  • RFI (원격)

3. 대응 방법

  • 원격 파일 접근 제한
    • php.ini의 allow_url_fopen = Off

 

 

 

불충분한 세션 관리 취약점

 

더보기

1. 개요

  • 사용자 로그인 세션 ID의 세션 타임아웃을 너무 길게 설정 시, 공격자가 재사용할 수 있는 공격

2. 대응 방법

  • php.ini의 session.cookie_httponly = 1 
  • php.ini의 session.gc_maxlifetime = 600 (적절한 세션 타임아웃 설정)
  • php.ini의 session.cookie_secure = 1 (https 일때만 쿠키를 전송함)

 

 

HTTP 응답 분할 취약점

 

더보기

1. 개요

  • HTTP 요청에 포함된 파라미터 값이 HTTP 응답 헤더에 포함되어 클라이언트에게 다시 전달될 때, 파라미터값에 개행문자인 CR, LF가 포함되어 있으면 HTTP 응답이 2개 이상으로 분리될 수 있다. 이 경우 공격자가 개행문자를 이용하여 첫 번째 응답을 종료시키고 두 번째 응답에 악의적인 코드를 삽입하여 XSS 등의 공격을 수행할 수 있는 취약점

2. 대응방법

  • 클라이언트 요청 파라미터가 서버 프로그램의 쿠키, 리다이렉션, 기타 응답 헤더 설정에 사용될 경우 응답 분할이 발생하지 않도록 필터링하여 사용

 

 

 

개발 보안 안내서

 

더보기

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

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

3. 클라이언트에게 중요 정보를 전달하지 않는다.

4. 중요 정보 전송 시 POST 메서드 및 SSL(HTTPS)을 적용한다.

5. 중요한 트랜잭션이 일어나는 프로세스에 사용자의 비밀번호를 재확인한다.

6. 중요 정보를 보여주는 페이지는 캐쉬를 사용하지 못하도록 설정한다.

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

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

 

 

Comments