본문 바로가기

개발

웹 취약점 조치 방안

1. 시스템 관리 취약점

 

- 홈페이지 세션 쿠키 설정 시 HttpOnly 설정을 누락한 경우

 

나의 경우에는 JSESSIONID에 HttpOnly 설정이 누락됐었다. JSESSIONID는 톰캣에서 세션을 유지하기 위해 브라우저에 설정하는 키이다. HttpOnly는 클라이언트에서 쿠키 요청을 했을 때 이에 대한 응답여부를 설정하는 옵션이다. HttpOnly를 설정하면 클라이언트에서 document.cookie로 브라우저의 쿠키에 접근을 하는 것을 막을 수 있다.

 

최신 버전의 톰캣일 경우에 자동으로 설정이 되어있지만 구 버전을 사용하는 경우에는 직접 설정을 해줘야한다. 톰캣 6 버전 이상인 경우, context.xml에서 context 태크에 useHttpOnly="true"를 추가하면 된다. 적용이 됐는지 확인을 할 때는 브라우저에서 쿠키를 초기화 한 후에 새로고침을 하면 된다.

 

- HTTP 헤더에서 PHP 버전 정보를 노출한 경우

 

서버 응답의 HTTP 헤더에서 PHP 버전이 노출되었다. 웹 서비스 환경에 대한 정보는 악의적 공격자에게 추가 공격의 빌미를 줄 소지가 있으므로 출력을 제한하는 것이 바람직하다.

<IfModule mod_headers.c>  
  Header unset Server  
  Header unset X-Powered-By  
</IfModule>  

Apache 서버의 conf 폴더로 들어가 httpd.conf 파일에 상단 태그를 추가하고 php.ini에서 expose_php Off를 추가한다.

 

그 다음에 아파치 서버를 재가동하면 X-Powered-By: 헤더를 제거할 수 있다.


2. 권한인증 취약점

 

- 웹 에디터 이미지 및 파일 업로드 기능에 제한없이 접근이 가능한 경우

 

나의 경우에는 네이버 스마트에디터를 사용하고 있었는데 이미지를 업로드하는 팝업에 브라우저의 url을 이용하여 접근 후 업로드를 한 경우에도 서버에 업로드가 되었다. 이럴 경우에 공격자가 대량의 이미지를 서버에 전송하여 저장용량을 소진하게 하는 서비스 거부(Dos : Denial of Service) 공격 가능성이 높아진다. 

 

기존에는 html파일로 팝업창이 구성되어 있었는데 이를 jsp파일로 바꿨다. 그리고 java 단으로부터 session을 통해 내부의 이용자인지 외부의 이용자인지 식별을 할 수 있는 키값을 받아왔다.

 

외부에서 접근 시에는 오류 페이지로 이동하여 서버에 이미지를 무단으로 업로드하는 것을 막을 수 있었다.


3. 불필요한 Method 허용 취약점

 

- 웹 서버 운영에 불필요한 HTTP methodPUT, DELETE, TRACE 등이 활성화되어 있는 경우

 

해당 HTTP method들은 특수한 환경에서 원격으로부터 운영체제 명령어 실행이 가능한 취약성이 있다. 또한, HTTP 디버깅용으로 사용하는 TRACE는 XST(Cross-Site-Tracing) 공격 등에 취약하다.

 

리눅스나 파워셀에서 curl 명령어를 이용하여 HTTP method를 확인할 수 있다.

 

ex) curl -k -I -X OPTIONS https://확인하고자 하는 URL

 

나의 경우 아파치 톰캣을 사용했기 때문에 아파치 서버의 conf 폴더의 httpd.conf 파일에서 TraceEnable Off를 명시하고,

톰캣 서버의 conf/web.xml과 웹 서비스(프로젝트 파일)의 /WEB-INF/web.xml의 <web-app></web-app> 태그 사이에

 

<security-constraint>

<web-resource-collection>

<web-resource-name>Forbidden</web-resource-name>

<url-pattern>/*</url-pattern>

<http-method>PUT</http-method>

<http-method>DELETE</http-method>

<http-method>PATCH</http-method>

<http-method>TRACE</http-method>

</web-resource-collection>

<auth-constraint />

</security-constraint>

 

를 추가해줬다.

 

추가로 나의 서비스를 Spring MVC 기반의 웹 서비스이기 때문에 웹 서비스(프로젝트 파일)의 web.xml 파일에는 <servlet></servlet> 태그 안에

 

<init-param>

<param-name>dispatchOptionsRequest</param-name>

<param-value>true</param-value>

</init-param>

 

이러한 태그를 넣어줬다.

 

이후에 서버를 재가동 하니 문제가 됐던 HTTP method들이 사라진 것을 볼 수 있었다.