웹 해킹: 웹 사이트의 취약점을 공격하는 기술적 위협으로, 웹 페이지를 통하여 권한이 없는 시스템에 접근하거나 데이터 유출 및 파괴와 같은 행위를 말한다.
XSS
Cross-Site Scription: 공격자가 웹사이트에 악성 스크립트를 주입해 공격하는 기법
이는 웹 응용프로그램에 존재하는 취약점을 기반으로 HTTP 프로토콜 동작 과정 중에 발생합니다. 이 취약점은 웹이 사용자로부터 입력받은 값을 제대로 검사하지 않고 사용할 경우 나타나며, 사용자의 정보인 Cookie, Session 등을 탈취하거나 자동으로 비정상적인 기능을 수행하게 할 수 있습니다.
주로 다른 웹사이트와 정보를 교환하는 방식으로 작동하기 때문에 Cross-Site Scription이라고도 합니다.
- Stored XSS
저장 XSS 공격은 웹 애플리케이션 취약점이 있는 웹 서버에 악성 스크립트를 영구적으로 저장해 놓는 방법입니다. 이때 웹 사이트의 게시판, 사용자 프로필 및 코멘트 필드 등에 악성 스크립트를 삽입해 놓으면, 삽입된 스크립트는 데이터베이스에 저장이 되고, 사용자가 악성 스크립트가 존재하는 사이트를 방문하여 페이지에 저장되어 있는 정보를 요청할 때, 서버는 악성 스크립트를 사용자에게 전달하여 사용자 브라우저에서 스크립트가 실행되면서 공격이 이루어지게 됩니다.
악성 스크립트가 데이터베이스에 저장되어 지속적으로 공격을 실시하기 때문에 많은 피해가 발생할 수 있다는 것이 저장 XSS 공격의 특징입니다.
이러한 공격이 가장 많이 발생되는 곳은 게시판이며, 게시판 외에도 사용자가 입력한 값이 데이터베이스에 저장되고 저장된 데이터가 요청되는 곳에서 공격이 발생할 가능성이 높습니다.
그렇기 때문에 사용자의 입력 값을 검증해야 합니다.
- Reflected XSS
반사형 XSS 공격은 이름처럼 입력을 그대로 브라우저에 출력하는 로직을 공격하는 방법입니다.
사용자에게 입력 받은 검색어를 그대로 표시하는 곳이나 사용자가 입력한 값을 오류 메시지와 함께 보여주는 곳에 악성 스크립트를 삽입하며, 스크립트는 서버가 피해자의 입력 값을 포함해 응답을 전송할 때 실행됩니다.
파파고에서는 위와 같은 스크립트를 실행했을 때 우측과 같은 결과를 볼 수 있습니다. XSS 대비가 되지 않았다면 우측과 같은 결과가 아닌 스크립트로 인해 alert 창이 실행되는 것을 볼 수 있을 것입니다. 파파고와 같은 사이트는 번역을 누르면 외부 공개가 가능한 링크가 생성되는데, 만약 XSS 대비가 되지 않은 취약점이 존재하는 페이지라면 사용자 정보를 빼돌릴 수 있는 XSS 공격 스크립트가 담긴 URL을 생성하여 사용자에게 노출시키는 방법으로 공격을 발생시킬 수 있습니다.
반사형 XSS 공격은 피해자가 직접 스크립트를 실행하도록 유도하기 때문에 1회성 공격이라고 할 수 있습니다
- DOM Based XSS
DOM 기반 XSS 공격은 피해자의 브라우저가 HTML 페이지를 구문 분석할 때마다 공격 스크립트가 DOM 생성의 일부로 실행되면서 공격됩니다. 페이지 자체는 변하지 않으나, 페이지에 포함되어 있는 브라우저측 코드가 DOM 환경에서 악성코드로 실행되게 됩니다.
대응 방안
최근엔 React나 Vue.js와 같은 프론트엔드 프레임워크, 라이브러리를 사용하여 XSS에 대한 방어가 어느정도 자동화되어져 있습니다. 그럼에도 불구하고 사용자의 실수로 취약점이 드러날 수 있는데요. 예를 들어, React에서 다음과 같은 실수를 할 수 있습니다.
dangerouslySetInnerHTML속성을 사용href를 통한 XSS 공격
React는 문자열 변수를 자동으로 escaping해주기 때문에 웬만하면 문제가 되지 않습니다.
escaping: 문자 해석에 있어 문자에 부여된 특정한 의미나 기능이 아닌 단순한 문자로 취급해 해석되도록 하는 것
하지만 dangerouslySetInnerHTML 속성을 사용하면 문자열에 HTML 태그가 있더라도 그대로 출력하기 때문에 위험할 수 있습니다. 꼭 사용해야 한다면 절대로 사용자 입력이 들어올 수 없도록 조치하거나 자바스크립트 코드가 존재하는지 검증할 수 있도록 해야 합니다.
또한 외부 웹 페이지에 접속하기 위해 각 프레임워크가 제공해주는 Router가 아닌 Anchor 태그를 사용할 때가 있습니다. 앵커 태그의 href 속성은 <a href='javascript:alert("xss");'>XSS</a>처럼 자바스크립트 프로토콜을 사용하여 스크립트를 실행시킬 수 있다. 이를 막기 위해서 href 속성에 들어가는 값은 추가적인 필터링이 필요합니다. 필터링에는 블랙리스트와 화이트리스트가 존재하는데 이 경우 화이트리스트를 통한 필터링을 추천합니다.
블랙리스트: 기본 정책이 모두 허용인 상황에서 예외적으로 차단하는 대상을 지정하는 것
화이트리스트: 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 또는 그 지정된 대상들
입력 값 치환
XSS 공격은 기본적으로 <script> 태그를 사용하기 때문에 XSS 공격을 차단하기 위해 태그 문자(<, >) 등 위험한 문자 입력 시 문자 참조(HTML entity)로 필터링하고, 서버에서 브라우저로 전송 시 문자를 인코딩하는 것이 안전합니다. HTML 문자 참조란 ASCII 문자를 동일한 의미의 HTML 문자로 변경하는 과정입니다. 예를 들어, 문자 "<"는 동일한 의미의 HTML "<" 로 변경됩니다. HTML entity는 대부분의 인터프리터(특히, 브라우저)에서 특수한 의미를 가지지 않으며, 단순한 문자로 처리되고 있습니다. 이렇게 인코딩하면 사용자는
악성 스크립트는 많은 HTML 태그 안에 포함을 할 수 있으므로 반드시 아래 표에 있는 위험문자의 경우 출력값을 escaping 해야 합니다.
| ASCII 문자 | 인코딩 문자 |
|---|---|
| & | & |
| < | < |
| > | > |
| ' | ' |
| “ | " |
| ( | ( |
| ) | ) |
| / | / |
CSRF Attack
Cross-Site Request Forgery: 공격자가 서비스 사용자를 이용해 위조 요청을 보내는 공격
사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(등록, 수정, 삭제)를 웹사이트에 요청하게 하는 공격을 의미합니다. 앞서 언급한 XSS 공격은 악성코드가 클라이언트에서 발생되지만 CSRF는 악성코드가 서버에서 발생되는 공격입니다.
대응 방안
- Referrer 검증
서버에서 사용자의 요청에 HTTP Referrer 정보를 확인하여 허용된 요청만 수행하도록 설정하는 방어입니다. request header에서 Referrer 정보를 확인할 수 있습니다.
- CSRF Token 사용
모든 요청에 대해 토큰을 발급하여 서버에서 검증하는 방어 방법입니다. 임의의 CSRF Token을 생성해 세션에 저장하고 사용자의 요청마다 해당 토큰을 전송합니다. 세션에 저장된 토큰값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증하는 방식으로 발급된 토큰을 서버로 전달하지 않으면 요청이 허락되지 않기 때문에 효과적입니다.
- Double Submit Cookie
브라우저의 Same Origin 정책을 이용해 Same Origin이 아닌 경우 쿠키 값을 확인하거나 수정하지 못하는 점을 이용한 검증 방법입니다. 클라이언트에서 임의로 생성한 Token을 쿠키와 요청 헤더에 담아 서버에 전달하면 서버는 전달받은 쿠키와 요청 헤더에서 각자 토큰 값을 꺼내 이를 비교합니다. 이때, 쿠키에 저장된 토큰 정보는 이후에 재사용하지 못하도록 만료 처리를 해줍니다.
CAPTCHA
CAPTCHA는 기본적으로 로봇이 아닌 사람이 요청한 것이 맞는지 검증하는 방법이지만, 인증코드를 입력하게 하여 사용자가 정말로 변경을 의도하는 경우에만 요청하기 때문에 CSRF 공격에도 효과적입니다.
피해 사례
2008년, 옥션 사용자 개인정보 유출 사건, 공격코드가 포함된 이메일을 관리자에게 보내 관리자 권한 탈취
File Upload Attack
공격 스크립트가 담긴 파일을 서버로 업로드하는 공격
파일 업로드의 취약점은 게시판 등, 파일을 업로드할 수 있는 기능을 통하여 악의적인 파일을 업로드해 시스템 권한을 장악하는 기법입니다.
대응 방안
- 확장자와 파일 타입을 검사하여 허락된 확장자와 타입만 저장할 수 있도록 합니다.
- 업로드할 파일의 크기를 제한합니다.
- 해커가 파일을 찾을 수 없도록 업로드 파일의 이름과 확장자를 난수화하여 저장합니다.
- 특수 문자가 포함된 경우 업로드를 막습니다. (Null byte Injection 방지)
Command Injection
시스템 명령어를 주입해 OS 명령을 실행하는, 즉 Shell을 실행시키는 공격
system(), exec() 와 같은 OS 시스템 명령어를 실행할 수 있는 함수를 통해 사용자 입력값에 필터링이 제대로 이루어지지 않을 경우 이러한 취약점을 악용하여 내부 데이터 탈취 및 손상, 계정 정보 유출, 백도어 설치 등의 피해가 발생할 수 있습니다.
마찬가지로 각 언어마다 존재하는 eval() 함수도 해당 공격에 매우 취약하기 때문에 사용을 지양하는 것이 좋습니다.
대응 방안
- Shell 명령을 실행시키는 시스템 함수 지양
- |, &, ;, >, < 와 같은 민감한 문자 필터링
JavaScript Injection
브라우저에서 자바스크립트를 삽입시키는 공격, 브라우저에서 제공하는 Console을 통해 조작 가능합니다.
브라우저에서 제공하는 Console을 통해 언제든지 자바스크립트 명령어를 실행시키고 조작할 수 있기 때문에 Client-Side에 민감한 데이터를 넣는 건 아주 위험합니다. 또한 데이터가 아니더라도 Client에서 로직을 결정하는 경우 함수 변조도 가능하기 때문에 가급적 서버에서 결정하도록 수정하는 것이 좋습니다.
대응 방안
- 클라이언트엔 민감한 데이터를 Plain하게 넣지 않습니다.
- 데이터 유효성 검사가 필요한 경우 서버에서 처리하도록 합니다.
SQL Injection
SQL 구문을 삽입해 악의적으로 이용하는 공격
악의적인 사용자가 보안상의 취약점을 이용해 임의의 SQL 문을 주입하여 데이터베이스가 비정상적인 동작을 하도록 조작하는 행위입니다. 비교적 쉽게 공격할 수 있으며 공격을 당했을 시 치명적인 피해를 입기 때문에 보안 위협 공격 중에서도 중요하고 매우 조심해야 하는 공격 중 하나입니다.
Error based SQL Injection
논리적 에러를 이용한 공격으로 가장 많이 쓰이고 대중적인 기법입니다.
Blind SQL Injection
쿼리의 결과가 참/거짓인지를 보고 원하는 정보가 존재하는지 추론하여 테이블명과 컬럼명 등을 파악하는 데 사용됩니다.
Union SQL Injection
Union 명령어를 이용해 정보를 취득할 수도 있습니다 .Union 키워드는 두 개의 쿼리문에 대한 결과를 통합해 하나의 테이블로 보여주는 키워드입니다.
대응 방안
- 입력값에 대한 검증을 합니다
- SQL에서 특별한 의미를 가지는 문자를 escaping 합니다. ex) \n, \t, |, /, &, #, ...
- Error Message를 노출시키지 않습니다
- 웹 방화벽을 사용합니다
피해 사례
2017년 3월, “여기어때”의 대규모 개인정보 유출 사건
DDoS
분산된 시스템을 이용하여 서버에 비정상적으로 많은 트래픽을 보내 마비시키는 공격
공격자는 수많은 PC를 이용하여 서버에 트래픽을 보냅니다. 많은 트래픽이 발생하면 서비스에 부하가 생겨 느려지거나 서버가 죽을 수 있는 점을 악용해 사용자가 서버 또는 네트워크 리소스(사용자가 자주 접속하는 웹사이트나 애플리케이션)에 접속하지 못하도록 차단합니다
대응 방안
- 서버가 죽지 않도록 확장 가능한 분산 시스템을 설계합니다.
- 공격 IP를 필터링합니다.
- 서비스 지역 외의 IP를 차단합니다.
- DDoS를 막아주는 전문 업체의 솔루션을 구매합니다.
사례
Dictionary Attack
미리 데이터베이스에 등록해 놓은 수많은 문자열을 암호로 대입해보는 공격
사용자들의 키가 될 가능성이 있는 단어 및 값들을 사전 파일로 만들어 자동화된 툴을 이용해 데이터를 대입하며 키를 알아내는 Password Cracking Attack입니다.
대응 방안
- 간단한 단어로 비밀번호를 등록하지 않습니다.
- 일정 횟수 이상의 로그인 시도를 할 경우 계정이 잠기도록 합니다.
- 2단계 인증을 도입합니다.
