웹취약점(XSS, 자동화공격) 보완하기

웹 취약점 중 하나인 XSS(Cross Site Scripting)와 자동화공격에 대해 알아보고 대처할 수 있는 방법에 대해 알아보자.

 

1. XSS( Cross Site Scripting )

 

XSS는 게시판이나 웹 메일 등에 자바 스크립트와 같은 스크립트 코드를 삽입해 공격을 하는 해킹 기법 중 하나이다.

위의 그림과 같이 게시판이나 댓글 등 스크립트를 적어 세션을 탈취하는 등에 피해를 입힙니다.

 

해결방법은 입력값에 대한 문자열 중 특수문자에 대한 문자를 HTML Entity로 치환하는 것인데

 

ex) XSS방지 함수 적용

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

if ( postContent != null || postContent != "") {

      postContent  = xssFilter(postContent);

}

 

function xssFilter(str) {

     str = postContent.replaceAll("<", &lt;);

     str = postContent.replaceAll(">", &gt;);

     str = postContent.replaceAll("(", &#40;);

     str = postContent.replaceAll(")", &#41;);

     str = postContent.replaceAll("'", &quot;);

     str = postContent.replaceAll(""", &#x27);

 

     return str;

}

 

 

 

2.자동화공격

 

프로그램을 이용하여 짧은 시간내에 자동으로 수많은 트랜잭션을 일으키는 해킹 기법 중 하나이다.

이 공격이 반복된다면 트래픽이 폭주하여 서버가 다운되거나 데이터베이스에 많은 용량을 차지하여

과부하가 올 수 있습니다.

 

 

대응방안 중 한가지로는 캡챠(CAPTCHA)가 있습니다.

흔히들 보시는 밑의 그림과 같은 형태입니다.

대부분의 캡챠 이미지들은 분석Tool, 온라인의 크래킹 서비스 등을 통해 쉽게 우회할 수 있습니다.

그렇기 떄문에 캡챠는 완벽한 보호 수단이 아닌 속도 지연을 위한 임시방편으로 생각하시면됩니다.

 

두번째 방법으로는 트랜잭션 발생 후 세션을 통해 고유한 token을 생성 후 파라미터로 토큰값을 던져

동일한 요청인지 새 요청인지 비교하여 트랜잭션을 발생시킨다.

 

1.우선 등록화면 및 수정화면의 JSP에 다음과 같은 taglib을 적용한다.

<%@ taglib prefix="double-submit" uri="http://www.egovframe.go.kr/tags/double-submit/jsp" %>
...
 <form ...>
    <double-submit:preventer/>
</form>

 

이렇게 되면 세션에 고유 UUID 정보를 생성한 후에 파라미터로 해당 UUID 값을 기록한다.

 

 

2. 다음으로 Controller의 각 메소드에 실제 Service를 호출하는 부분을 다음과 같이 변경한다.

 

* 변경 전

if (isAuthenticated) {
    notification.setFrstRegisterId(user.getUniqId());
 
    notificationService.insertNotificationInf(notification);
 
}

 

*변경 후

if (isAuthenticated) {
    notification.setFrstRegisterId(user.getUniqId());
 
    if (EgovDoubleSubmitHelper.checkAndSaveToken()) {  
        notificationService.insertNotificationInf(notification);
    }
}

 

EgovDoubleSubmitHelper.checkAndSaveToken() 메소드에서 내부적으로 현재 기록된 세션상의 UUID와 파라미터의 UUID 값이 같은지 비교 후, 동일한 경우 새로운 UUID를 세션 상에 기록한 후 return true로 처리된다.

새로운 UUID가 세션에 변경되었기 때문에 동일한 request가 재 호출시 세션의 UUID와 이전 파라미터의 UUID 값이 다르기 때문에 return false로 처리되어 실제 등록 처리 등을 생략할 수 있다.