이번 포스트는 웹 개발에서 유의해야할 3대 취약요소에 대해서 이야기를 해볼려고 합니다.
제가 개인적으로 생각하는 웹개발에서의 3대요소는 크게 injection, XSS, CSRF 입니다.
물론 이런 취약점 이외에도 많은 다른 위험요소가 있겟지만 OWASP의 10대요소...및 빈도 등을 생각할 때 개인적으로 판단한겁니다.
SpringFramework, 전자정부프레임워크(eGovframework)의 경우는 이 부분에 대한 방어를 하는 기법들이 많이 나왔습니다.
이 부분에 대해서 한번 알아보도록 하겠습니ㅏ.
1. injection
인젝션의 경우는 url,sql등이 많지만 여기서는 sql인젝션에 대해서 이야기 해보겠습니다.
사실 얼마전에 뽐뿌라는 사이트도 sql인젝션으로 뚤렸다는데 이 해킹 방법은 초보적이라서 요즘은 이걸로 뚤리는케이스는 좀...의문이 드는 항목입니다.
일반적인 자바로 하셧다면 prePareStatement로 쿼리를 실행하도록 하면 되고요.
sql 부분을 ibatis 프레임워크로 만들었다면 변수의 인자를 $가 아닌 #으로 받도록 개발이 되어있으면 됩니다.
변수 입력값이 user_id = 'admin'
select * form PRODUCT where PRD_ID = #user_id#
=> select * form PRODUCT where PRD_ID = ?
=> 등록이 되고
=> ? 에 'admin' 대입되서 들어가서
=> select * form PRODUCT where PRD_ID = 'admin' 실행이됩니다.
select * form PRODUCT where PRD_ID = '$user_id$'
=> user_id 에 'admin' 값을 가져와서
=> select * form PRODUCT where PRD_ID = 'admin'
=> 등록이 되고
=> select * form PRODUCT where PRD_ID = 'admin' 실행이 됩니다.
참고
http://yeonicon.tistory.com/713
JAVA/JSP SQL Injection 해킹 방지를 위한 코딩
출처: http://stove99.tistory.com/99 [스토브 훌로구]
2. XSS
크로스 사이트 스크립트 공격 그냥 줄여서 XSS라고 하는데요.
웹애플리케이션에서 가장 흔하면서 맨날 문제가 되는 녀석입니다.
방법은 in 또는 out으로 나오는 값에 대하여 필터링을 해야합니다.
백문이 불여일견이라고 한번 보시죠.
다음은 행자부에서 가이드하고 있는 xss방어를 하기 위한 안전한 코드의 예입니다.
보이시나요?? 매번 입력값에 대해서 이렇게 replaceAll하는 코드를 넣으라고 하고 있습니다.
이걸 그대로 받아들이시고 실제 개발자들에게 개발자분들...이걸 따라서 개선하세요...하면 욕먹기 딱 좋습니다.
아마도 개발자 눈에는 이렇게 보일겁니다.
그럼 어떻게 해야할까요??
개인적으로는 추천? 하는 2가지 방법에 대해서 말씀드리겠습니다. 전자정부 프레임워크를 사용한다고 가정했을때 다음과 같은
1번 선수 HTMLTagFilter의 적용
2번 선수 lucy xss servlet filter 의 적용
이렇게 2가지를 전자정보 프레임워크에 적용하는것을 추천합니다.
전자정부프레임워크에서 제공하는 HTMLTagFilter 는 을 사용하지 못하는 경우에 XSS 처리를 위해 입력 파라미터에 '<'와 같은 문자열을 '<' 등으로 변환해주는 기능이라고 합니다.
이 필터는 을 사용하지 못하는 경우에 적용하도록 제공되는 기능이라고 합니다. 둘 다 사용하는 경우 원하는 결과를 얻을 수 없다고 합니다. 을 표시해 주면 XSS에 문제가 되지 않는다고 합니다.
을 사용하면 원래 데이터를 그대로 DB상에 보관할 수 있습니다.
HTMLTagFilter를 사용하면 '<' 이 < 와 같이 변경되어서 저장되게 됩니다.
을 사용하면 원래 데이터를 그대로 DB상에 보관할 수 있구요, HTMLTagFilter는 변경된 형태로 저장됩니다.
HTMLTagFilter는 첨부파일이 있는 enctype="multipart/form-data" 방식의 경우는 처리되지 않습니다.
HTMLTagFilter를 사용하기 위해서는 web.xml 에 다음 코드를 삽입해 주어야 합니다.
HTMLTagFilter
egovframework.rte.ptl.mvc.filter.HTMLTagFilter
HTMLTagFilter
*.do
출처: http://roadrunner.tistory.com/411 [삶의 조각들]
참고자료
http://www.slideshare.net/HyeongKyuLee/spring-camp2015-xss
https://github.com/naver/lucy-xss-filter
3. CSRF
가장 방어하기 힘들고 까다로워서 다들 방어를 아예 안하거나 등한시 하는 CSRF공격입니다 .
사실 xss라던지...필터링이 어느정도 잘되면 과연 이 취약점이 직접적인 문제가 될지는 좀 고민?이 되긴하지만 약점이 되는 여지 자체를 없애는것이 가장 BEST라고 생각하기에 방어를 하는게 좋을듯 합니다 .
한번 이렇게 그림을 통해서 알아보면 좀더 쉽게 이해가 될듯 합니다.
공격자의 코드에 의해서 사용자 본인이 직접 서비스 요청을 해버리는게 문제입니다. 공격자의 밑장빼기롤 인해서 서비스 요청이 되긴했지만 사용자가 직접 요청을 햇다는 점에서 서버측 에서는 해당 요청을 거부할 방법이 없습니다 .
그럼 이 공격은 어떻게 방어 할수 있을까요??
예를 들어 사용자는 CRUD중에서 단순 조회인 R업무를 하려고 했는데...공격자의 숨겨진 코드에 의해서 U, D, C등의 업무가 진행이 되어서 계좌이체, 자료삭제, 권한변경 등의 작업을 수행하는게 문제입니다.
따라서 서버측에서는 매번의 요청마다 티켓을 발부해서 티켓에는 사용자:tom, 권한:조회(R) 이런식으로 해서 서버와 사용자가 나누어가지게 되는거죠. 그 다음에 사용자의 요청이 올때 티켓을 대조해서 일치하면 OK! 아니면 무시...하는 방법으로 CSRF를 방어할수 있습니다.
이 방법은 모든 요청에 세션 쿠키와 더불어 랜덤하게 생성되는 토큰을 HTTP 파라메터로 제공하는 것입니다. 요청이 오면, 서버는 반드시 그 토큰에 해당하는 값을 가져와서 요청에 있는 실제 값과 비교하고 값이 맞지 않으면 그 요청은 실패 처리합니다.
상태를 변경하는 HTTP 요청에서만 토큰을 사용하도록하여 이런 기대감을 조금은 완화할 수 있겠다. same origin policy로 인해 나쁜 사이트가 응답을 읽어가진 못할테니 그렇게 해도 비교적 안전하다. (즉, READ는 same origin policy로 막으니까 UPDATE만 sychronized token 패턴으로 막아도 된단 소리) 게다가, 랜덤 토큰을 HTTP GET에 넣는건 토큰이 누출될 가능성도 있다.
이런 티켓의 발부와 대조...서비스 요청의 거절등을 바쁜 프로젝트 일정에 구현을 하려면 힘들겁니다.
아마도 개발하는 AA(애플리케이션 아키텍트)는 이렇게 될겁니다.
그래서 준비했습니다.!!!!!!!
스프링 시큐리티
자바의 설정에서는 다음과 같이 비슷한 코드가 나올겁니다.
@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.csrf()
.and()
…;
}
}
JSP소스코드는 다음과 같이 나올수 있습니다.
여기에서 name=”${_csrf.parameterName}” value=”${_csrf.token}” 의 _csrf의 파라미터와 토큰값은 스프링 시큐리티 모듈에서 자동으로 삽입하고 대조하게 됩니다.
참고
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
출처: http://ralf79.tistory.com/882 [진형아빠이야기]
댓글 ( 4)
댓글 남기기