OWASP Top10(2013)

A1-인젝션:

인젝션이란 웹사이트에 조작된 값을 전송하여 DB의 데이터를 손실 시키거나 삭제, 수정 등의 악영향을 미치는 행위를 말한다. 이러한 결함은 소스코드를 검증하면 확인이 되지만 테스트를 하면서 발견하기란 쉽지 않기 때문에 자동 점검 툴을 이용하여 취약점을 확인 하는 것이 좋다.

아래는 서버로 전달되는 파라미터 값에 악의적인 쿼리를 삽입하는 경우에 대한 예시이다.

* 정상적인 요청

http://injectionTest.com/info.jsp?id=member1

String id = request.getParameter("id"); //member1이라는 값이 넘어옴

String query = "SELECT * FROM member WHERE memId='" + id + "'"; //id에 담긴  id로 DB조회하여 데이터를 돌려줌

위와 같이 조회를 할 경우 해당 파라미터로 넘어온 id의 데이터만 조회가 된다. 하지만 id 파라미터 값에 아래와 같은 쿼리를 추가하여 전달하면 해당 테이블의 모든 데이터가 조회된다. 이럴 경우 해당 사이트의 모든 가입자 정보가 유출되게 되며 이 정보에 개인 고유의 정보나 금융거래 관련 정보가 있을 경우 실제 금전적인 피해도 발생한다.

* 취약점을 이용한 요청

http://injectionTest.com/info.jsp?id=' or '1'='1

위와 같이 id의 변수 값에 ' or '1'='1 을 전달하면 OR 조건으로 무조건 참이기 때문에 데이터가 유출이 되며 이러한 데이터 유출 뿐만 아니라 사용자 패스워드 항목에 악의적인 쿼리를 전달하면 로그인 검증 역시 통과하게 된다. 지금 설명한 데이터 조회, 로그인 우회 외에도 데이터 조작 및 삭제도 가능하기 때문에 웹사이트에 심각한 영향을 끼치는 공격이다.

이를 예방하기 위해서는 브라우저가 전송한 파라미터 값을 모두 검증하거나 허용할 문구만 설정하여 통과시키는 '화이트리스트' 방식을 사용하여야 한다. 위의 경우엔 id의 파라미터 값에

일반적으로 id에 특수문자를 허용하지 않기 때문에 id의 파라미터에 특수문자가 추가되어있다면 모두 제거하여 사용하거나 그냥 오류 처리를 해버리면 된다.

검증 방식에는 '블랙리스트', '화이트리스트' 방식이 있는데

'블랙리스트'는 리스트 상의 모든 문구를 제거하거나 변환 시키는 방식이며, '화이트리스트'는 웹사이트의 해당 페이지에서 허가한 특수문자는 제거 시키지 않고 나머지를 제거하는 방식이다. 그리고 인젝션에는 SQL외에도 많이 사용되는 공격방법이다.

A2-인증 및 세션 관리 취약점:

해당 취약점은 웹사이트에 로그인과 같은 인증을 통해 웹사이트에 접속하여 있는 동안 세션에 개인의 고유 정보를 담고서 서비스를 제공한다. 이를 사용하는 방식 자체는 간단하고 유용하기 때문에 사용하기는 쉬우나 이를 강력한 인증을 하게 하는 방식이나 타인에게 노출되지 않게 관리하는 것은 쉽지 않기 때문에 발생한다. 예를 들면 공공장소에 제공된 컴퓨터(미용실, 커피숍등)를 이용하여 사이트에 로그인한 사용자가 로그아웃을 하지 않고 나갈 경우 세션이 만료되지 않는 이상 동일한 세션을 이용하여 사이트를 이용가능하게 된다. 이 경우는 프로그램의 문제이기 보다 사용자 문제이긴 하지만 이러한 경우는 사용자가 쉽게 실수 할 수 있는 부분이기 때문에 프로그램에서 보완을 해주는게 좋다. 그 외에도 타임아웃을 너무 길게 설정하거나 세션의 고유ID를 URL상에 노출, 로그인 시에만 체크하고 그 외의 메뉴에서 체크하지 않는 경우(패스워드 변경, 정보변경 페이지), 사용자의 고유정보가 암호화 되지 않고 전송되는 경우에도 취약점으로 판단 되기 때문에 조치를 취하여야 한다.

* 웹사이트에서 URL 덮어쓰기를 지원할 경우 세션 ID를 강제로 URL에 설정하면 해당 세션ID 소유자의 고유 권한 기능들을 사용가능하게 된다.

http://sessionTest.com/session.jsp?jsessionid=1O2E23E5RPOSD?boardid=1

* 적절한 XSS(크로스사이트스크립팅)을 처리하지 않은 경우 브라우저로 내려온 jsessionid를 빼낼수도 있다.

A3-크로스 사이트 스크립트(XSS):

XSS는 브라우저로 전송하는 페이지에서 사용자 입력 데이터를 체크하지 않는 경우 발생한다. 공격 방식은 단순한 텍스트를 기반으로 서버로 악의적인 스크립트 코드를 전송하여 웹 사이트의 데이터나 페이지 변조 등을 하는 공격법이다. 이를 막는 방법으로는 3가지가 있다.

1. 블랙리스트: HTML 문맥에 올수가 없는 문구는 모두 제거하는 것이다. 예를 들면 BODY태그 안에 스크립트 코드가 들어갈 일은 없기 때문에 모두 제거해버리는 것이다. BODY 외에도 HTML문맥에 오지 않거나 해당 페이지에서 사용될 일이 없는 데이터가 올 경우 모두 제거하는 것이다. 가장 많이 제거하는 문구로는 <, script, ? 등의 특수문자(주로 스크립트에 사용되는 문자열)을 제거하며 인코딩되어 올 경우도 있기 때문에 해당 문자의 인코딩된 문자열도 제거해준다.

2. 화이트리스트: 웹서비스를 제공하다 보면 고객의 요구에 따라 화면에 효과(색, 크기, 기울기, 폰트 변경, 표 삽입)등이 필요할 수도 있다. 이렇게 화면을 꾸미는 효과를 주는 태그의 경우 "화이트 리스트"에 설정하여 제거하지 않도록 한다. 이 방식은 주로 게시글 본문에 많이 사용된다. 완벽하게 방어되지 않기 때문에 "블랙리스트"와 "화이트리스트"를 동시에 사용한다.

3. 유효성검사: 웹서비스마다 서비스해주는 페이지의 특성에 따라 특정한 규칙을 만드는 경우가 많다. 예를 들면 회원가입 시에 특수문자를 허용안한다거나 게시글의 제목은 40자 이하라거나 하는 등의 규칙이다. 이러한 규칙을 벗어나는지 여부를 체크하는 검사를 통해서도 방어가 가능하다.

   ** 제거 외에도 문자를 치환하는 방법도 있다.

* 검증을 하지 않는 소스

String mail = request.getParameter("mail");

out.print("<input name='mail' type='text' value='" + mail + "'>");

위와 같이 소스를 작성 해놓을 경우 mail 매개변수에 아래의 공격 스크립트를 같이 전송하면 공격이 성공하게 된다.

http://xssTest.com/xss.jsp?mail=test@test.com"><script>alert(document.cookie)</script>

A4-취약한 직접 객체 참조:

웹서비스를 개발할 시에 페이지에 객체 실제 키나 이름을 자주 사용하며 서비스 사용자가 해당 정보에 접근 가능한지 여부를 항상 검증하지는 않는다. 어느 사이트는 로그인 할 때에만 사용자 검증을 하는 곳도 있다.

* 상대경로를 통한 직접 객체 참조 소스1

String filename = request.getParameter("filepath");

File file = new File(filename);

위와 같은 방식으로 파일 다운로드를 제공하는 서비스는 해당 서비스를 실행시킨 계정이 접근가능한 파일에는 모두 접근이 가능하게 된다 아래와 같이 공격을 하면 파일 다운이 가능하다.

http://filedown.com/donw.jsp?filepath=../../../../../etc/passwd

이를 방어하기 위해서는 filename 변수에 '../' 같은 상대 경로를 제거하도록 하거나 웹 서비스를 구동시키는 계정의 권한 자체를 접근하지 못하도록 제한하도록 한다.

* 검증되지 않은 SQL구문을 사용하는 소스

String query = "SELECT * FROM member WHERE id=?";

String id = request.getParameter("id");

PreparedStatement pstmt = conn.prepareStatement(query);

pstmt.setString(1, id);

ResultSet rs = pstmt.executeQuery();

위의 소스는 사용자 정보 조회 시 id만 체크하기 때문에 id 파라미터에 타인의 id 값을 넣어도 조회가 가능 해진다. 이럴 경우 password도 함께 검증하여 해당 사용자의 정보만 조회 가능 하도록 하여야 한다.

A5-보안 설정 오류:

해당 오류에는 플랫폼, 서버, 데이터베이스, 프레임 워크를 포함하는 웹 서비스의 모든 과정에서 발생할 수 있는 오류이다. 해당 오류가 있는지 확인하는 방법으로는 툴을 이용하거나 아래의 방법을 사용한다.

1. 웹 사이트를 서비스하는 데에 사용되는 OS, 서버, DB, 라이브러리 등이 결함이 패치 된 최신버전인지 확인한다.(사용 중인 리소스의 결함 여부를 주기적으로 모니터링 해야한다.)

2. 필요하지 않은 기능이 활성화 되어 있는지 확인한다. 여기서 말하는 기능이란 외부와 통신을 하는 포트, 계정, 페이지(샘플소스코드, 테스트용 코드) 등을 말한다.

3. 2번에서 말한 불필요한 계정인 OS의 기본 계정의 기본 패스워드를 변경한 적 없는지 체크한다.

4. 웹 사이트의 예외 처리 부분에서 오류 문구가 사이트의 소스를 분석 가능한 수준으로 너무 자세하게 보여 주는지 체크한다.

5. 웹 사이트 개발에 이용된 프레임 워크, 라이브러리 등의 보안이 보증 가능한가?

보안 설정 오류를 통한 공격을 방지하기 위해서는 취약점이 확인된 즉시 빠르게 대처할 수 있는 프로세스를 정립하는 것이 중요하다. 웹 서비스에 필요한 모든 리소스에 대해 취약점을 패치하고 적용할 수 있게 시나리오도 작성하여야 하고 주기적으로 웹 사이트를 검사를 해야 한다.

A6-민감 데이터 노출:

웹 사이트에는 필요에 따라 사용자의 민감한 개인정보를 요구하여 저장하는 경우도 있다. 이러한 정보를 요구하여 저장 할 때에 과거에는 그냥 평문(입력한 문자 그대로)으로 저장하는 경우가 대다수 였으며 다양한 공격 및 웹 사이트 내부 사용자에 의해 유출되어 피해를 입은 경우가 상당하였다. 이를 체크하기 위해서는 다양한 방법이 필요하다. 우선적으로 웹 사이트에서 수집하는 데이터 중 보호해야 할 데이터와 그렇지 않은 데이터의 분류가 필요하며 다음과 같은 항목을 체크하여야 한다.

1. 사용자의 개인정보가 저장될 때 암호화되지 않은 문자로 저장되는가?

2. 개인정보가 네트워크를 통해 전송될 경우 암호화 되지 않고 전송되는가?(인터넷 트래픽을 가로채서 훔칠 수 있다.)

3. 오래되거나 이미 취약점이 밝혀진 암호화 알고리즘을 사용하는가?

4. 취약한 암호 키를 생성하였거나 암호키 관리가 제대로 되는가 주기적으로 변경하는가?

5. 브라우저 보안 지침이나 헤더가 민감한 데이터가 제공되었거나 브라우저로 전송되었을 경우 놓치지 않는가?

위와 같은 취약점을 확인 후 이를 방어하기 위해서는 아래와 같은 조치를 하여야 한다.

1. 개인정보를 보호하기 위해 현재 사용하지 않거나 통신으로 전달되는 개인정보는 강력한 암호화 알고리즘을 이용하여 암호화한다.

2. 해당 웹사이트의 목적에 위배되는 불필요한 개인정보는 저장하지 않도록 하고 불필요하게 저장된 정보는 파기하도록 한다.

3. 강력한 표준 알고리즘과 키를 사용한다.

4. bcrypt, PBKDF2, jscrypt와 같이 패스워드 보호용으로 설계된 알고리즘으로 패스워드를 저장한다.

5. 개인정보 수집 시에는 자동 완성 기능을 끄고 해당 페이지에 캐쉬 저장 기능도 제거한다.

A7-기능 수준의 접근통제 누락:

웹사이트에는 모든 사용자가 네트워크를 통해 요청을 보낼 수 있다. 해당 요청을 보낼 때 해당 사용자가 해당 기능을 사용할 권한이 있는지 체크는 항상 필요하다. 예를 들면 아래와 같은 경우가 있다.

1. 가입이 필요한 사이트에서 첫 화면에서만 회원 권한을 체크하고 내부 화면에서 체크를 하지 않는 경우 내부 화면으로 직접 접근하면 권한이 없는 사용자에게 서비스가 제공되게 된다.

2. 사용자 권한에 따라 적절한 UI가 제공되는지도 필요하다. 글쓰기 권한이 없는 사용자에게 해당 버튼이 노출되면 안된다.

3. 웹 사이트에서 사용자 인증을 할 시에 클라이언트 측과 서버 측 체크를 함께 하여야 한다.

4. 서버에서 체크 할 시에 전적으로 사용자가 제공한 정보만으로 체크하면 안된다. 서버에 저장된 정보와 함께 체크하도록 한다.

사실상 대부분의 웹 사이트는 해당 사이트에서 제공하는 링크나 버튼을 인증이 되지 않으면 보여주지 않는다. 하지만 클라이언트 영역은 해당 사용자에 의해서 얼마든지 변조가 가능하기 때문에 서버의 컨트롤러 및 비즈니스 로직에서 반드시 체크하여야 한다.

A8-크로스 사이트 요청 변조(CSRF):

CSRF는 웹 서비스에서 특정 행위에 대한 세부 정보를 예측 가능하다는 점을 이용하며 브라우저는 자동적으로 세션 쿠키와 같은 인증 데이터를 보내기 때문에 정상적인 요청과 구분하기 어려운 위조된 HTTP 요청을 생성하여 공격을 하는 방법이다. 일반적으로 공격자가 미리 작성해 놓은 악성 코드를 통해 일어나며 피해를 입은 사용자는 자신의 의도와 다르게 동작이 일어나는 것을 보게된다. 예를 들면 공격자가 작성한 게시물을 클릭하는 순간 해당 게시물에 포함된 악성 코드가 작동하여 자신의 게시물이 지워 지거나 수정, 등록되게 되며 강제로 회원 탈퇴가 되거나 서버의 관리자 권한 획득, 회원 정보 변경도 가능하다. 이를 예방하기 위한 방법으로는 XSS방어법을 적용하거나 각 요청마다 예측이 불가능한 고유 토큰을 포함 시키는 것이 있다. 추가적으로 개인정보를 변경하거나 게시물 수정, 삭제 할 경우 추가적으로 사용자 재 인증을 요구하는 방법도 있다.

A9-알려진 취약점이 있는 컴포넌트 사용:

대부분의 웹사이트는 개발에 사용된 컴포넌트/라이브러리 등을 최신 버전으로 관리하지 않기 때문에 상당히 많은 사이트가 해당 취약점에 노출이 되어있다. 사실상 개인 개발자가 모든 컴포넌트에 대해 알기 어려우며 한번 개발한 뒤에는 크게 신경쓰지 않는다. 이 취약점은 외부 컴포넌트나 라이브러리에 의존적일 수록 피해가 크다. 이를 확인하기 위해서는 해당 컴포넌트나 라이브러리의 데이터베이스를 검색하거나 정기 소식지 같은 메일을 받거나 새로운 소식에 대한 발표를 할 경우 잘 캐치하여 해당 내용이 웹 서비스에 영향이 미치는지 여부를 체크하여야 한다. 최근 이슈가 된 취약점은 OpenSSL의 취약점 중 하나인 하트 블리드가 있다. 하트 블리드의 경우 서비스 체크를 위한 기능이 취약한 것이었다. 상태 체크 요청을 보내면 무조건적으로 소스에 설정된 bit수만큼 응답하는 것이 발견된 것이다.

A10-검증되지 않은 리다이렉트 및 포워드:

애플리케이션의 기능 중에는 사용자를 타 사이트나 페이지로 이동 시키게 하는 경우가 있다. 이때 신뢰할 수 없는 데이터를 사용하는 경우가 있으며, 검증을 하지 않으면 피싱 및 악성코드 사이트로 이동 시키거나 승인되지 않은 페이지에 접근할 수 있게 된다. 이를 체크하기 위해서는 소스에 사용된 모든 리다이렉트, 포워드 URL이 웹 서비스에서 허용된 URL인지 확인하며 웹 사이트 정보 수집 도구를 사용하여 리다이렉트 이전에 나오는 파라미터를 조사하여 목적지 URL인지 아닌지를 분석하고 변경이 가능한지와 변경 후 변경된 목적지로 이동하는지도 관찰하여야 한다. 예방법으로는 리다이렉트나 포워드를 사용하지 않는 것이 가장 좋지만 현실적으로는 불가능하기 때문에 사용자 파라미터로 목적지 계산이 불가능하도록 해야 하며 목적지 파라미터 사용 시에 값이 유효한지와 접근이 인가된 URL인지를 체크하여야 한다.