<이미지 출처 :http://www.boannews.com/media/view.asp?idx=40955 >
이번 주제는 웹 보안에 관련된 내용입니다. 홈페이지에 웹 취약성점검 툴을 돌려 테스트 해본 결과 나온 몇 가지 점들에 대해서 이야기 해볼까 합니다. 지금 여기서 이야기하지 않은 내용들도 많이 있겠지만 간단한 설정만으로 큰 효과를 볼 수 있는 사항에 대해서 진행해 보도록 하겠습니다.
1. 불필요한 Method 지원
첫 번째 목록은 불필요한 Method지원에 관한 내용입니다. HTTP method는 다음과 같은 Method를 지원하고 있습니다.
GET | 일반적인 요청으로 요청 URI에 모든 요청정보를 포함 하여 전송합니다. |
POST | GET이 URI에모든 요청정보를 포함하였다면 POST는 BODY에 요청정보를 숨겨 전송합니다. |
PUT | POST와 같은 방식으로 전달되지만 BODY의 내용이 실제 URI에 저장됩니다. |
DELETE | 요청 URI에 해당하는 자원을 삭제합니다. |
TRACE | 클라이언트로부터 수신 받은 내용을 응답에 포함시킵니다. |
CONNECT | SSL tunneling에서 사용됩니다. |
OPTIONS | URI에 대해 어떤 메서드 기능을 제공하는지, 서버는 무언인지 등의 정보를 제공합니다. |
HEAD | 요청에 대한 BODY없이 HEAD정보만을 반환합니다. 유효성, 접근성 등을 확인할 때 사용됩니다. |
위의 각 Method는 각 상황에 맞게 사용할 수 있도록 설계되었지만 취약성 점검 툴을 돌려 보면 GET과 POST이외의 모든 메서드는 제외 시키라고 권고합니다. PUT, DELETE등을 허용하는 것은 이를 통해 크로스 사이트 스크립팅 또는 페이지 위변조에 사용될 수 있기 때문입니다. 예를 들어 web서버의 WebDAV가 활성화 되어있고 PUT메서드가 허용된다면 공격자는 특정 파일을 삽입하여 홈페이지를 변조하거나 DELETE메서드를 통하여 특정위치의 파일들을 삭제 할 수 있습니다.
위 상황을 처리 하기 위해서는 서버에 몇 가지 간단한 설정만으로 처리 될 수 있습니다.
대표적인 Web server이 Apache의 경우 설정파일(httpd.conf)에 다음을 추가해서 처리 할 수 있습니다. 아래 설정은 Directory별로 또는 Location별로 처리 할 수 있는데 모든 요청에 대해서 GET 과 POST를 제외하고 거부하라는 설정입니다.
<Location /*>
<LimitExcept GET POST>
Order deny,allow
Deny from all
</LimitExcept>
</Location>
WAS서버의 경우는 web.xml에 다음과 같은 설정을 추가 합니다. url-pattern /* 에 대해서 HEAD, DELETE등 목록에 명시된 method를 제외한 나머지(GET, POST)만 허용하라는 의미 입니다.
<security-constraint>
<web-resource-collection>
<web-resource-name></web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>HEAD</http-method>
<http-method>DELETE</http-method>
<http-method>PUT</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
</security-constraint>
2. 보안에 필요한 필수 헤더의 누락
브라우저는 응답에 포함된 헤더를 통해 자체적으로 컨텐츠를 차단 또는 변경 하는 기능이 구현되어 있습니다. 설정의 종류는 다음과 같습니다.
1. Content-Security-Policy
브라우저에 XSS와 관련된 공격을 막아주는 헤더입니다. 브라우저는 기본적으로 페이지에서 요청하는 모든 코드를 다운로드하여 실행합니다. 하지만 CSP를 설정함으로써 브라우저게 어떠한 조건의 리소스만 실행하거나 렌더링 하라고 지시를 내릴 수 있습니다. 지시문의 종류는 default-src, script-src, child-src등 다양하게 존재 합니다.
또한 각 지시문에는 다음 4개의 키워드를 선택 적용할 수 있습니다.
1. 'none' 어떤 것도 허용하지 않습니다.
2. 'self' 현재 출처에서는 허용하지만 하위 도메인에서는 허용되지 않습니다.
3. 'unsafe-inline' 인라인 자바스크립트 <script> ... </script>, 인라인 스타일 <style> .... </style> 을 허용합니다.
4. 'unsafe-eval' eval과 같은 텍스트 - 자바스크립트 메커니즘을 허용합니다.
위 옵션 등을 적용하여 몇 가지 예를 들어보도록 하겠습니다.
Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'
1. default-src 'none'
기본적으로 모든 리소스를 차단합니다. 이것만 설정된 경우 사이트는 아무것도 동작하지 않을 것입니다.
2. script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net;
script, stylesheet, img 는 cdn.mybank.net을 통해 다운로드 되는 리소스만 허용됩니다.
3. connect-src https://api.mybank.com;
외부로의 데이터 요청(xhr)등은 api.mybank.com 에서 응답 받은 내용만 가능합니다.
4. child-src 'self'
iframe등의 하위요소는 동일 도메인( 서브 도메인조차 허용되지 않음)만 가능합니다.
위와 같이 설정된 경우 보안적으로 강력하게 대응할 수 있습니다. 하지만 저렇게 설정하여 바로 적용한다면 어떤 일이 벌어질까요? 일단 페이지 내부에 정의한 <script></script> 안의 내용은 모두 실행되지가 않습니다. 모든 script는 외부의 js 파일에 담겨 있어야 비로소 동작을 하게 됩니다. <style></style> 안에 적용한 css도 물론 처리되지 않습니다.
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline' 'unsafe-eval'; style-src https: 'unsafe-inline'
위 예제는 약간은 느슨하게 처리된 옵션입니다.
1. default-src https:
https: 로 시작하는 모든 요청을 허용합니다.
2. script-src https: 'unsafe-inline' unsafe-eval'
https: 로 시작하는 script를 허용하며 페이지 내에 선언된 <script> .... </script>와 element에 추가된 onclick과 같은 script가 허용됩니다. default-src에 https: 를 선언했지만 script-src를 재 정의했기 때문에 https: 를적어야 합니다.
Content-Security-Policy-Report-Only: 설정들 report-uri /my_amazing_csp_report_parser;
처음 CSP를 홈페이지에 적용하기는 생각보다 쉽지 않습니다. 모든 페이지를 알고 있지 않는 한 어디에 무슨 코드가 숨어있을지 알 수 없기 때문인데요. 실제 해당 내용을 바로 적용하는 것이 아니라 위반 사항이 발견될 경우 Report만 받는 것으로 설정을 할 수도 있습니다.
2. X-Frame-Option
이 헤더는 사용자의 눈에 보이지 않는 영역을 추가 하여 사용자는 의도한대로 버튼을 누르지만 실제로는 다른 곳을 클릭하게 만드는 ClickJacking을 방지 할 수 있는 옵션입니다. 페이지 내부에 심어질 수 있는 iframe과 같은 곳에 접근을 제어하는 옵션으로 설정 할 수 있습니다.
X-Frame-Options : DENY 모든 표시를 거부합니다.
X-Frame-Options : SAMEORIGIN 동일한 출처에 대한 것만 표시 합니다.
X-Frame-Options : ALLOW FROM http://www.webponent.com http:www.webponent.com에 대해서만 허용합니다.
3. X-Content-Type-Option
이 헤더는 리소스를 다운로드 할때 해당 리소스의 MIMETYPE이 일치하지 않는 경우 차단을 할 수 있습니다.
X-Content-Type-Options: nosniff
위 처럼 설정하는 경우 styleSheet는 MIMETYPE이 text/css와 일치할 때까지 styleSheet를 로드하지 않습니다. 또한 공격자가 다른 확장자(jpg)로 서버에 파일을 업로드 한 후 script태그등의 src의 경로를 변경하여 script를 로드 하는 등의 공격을 막아줍니다.
4. Strict-Transport-Security
이 헤더는 한번 https로 접속 하는 경우 이후의 모든 요청을 http로 요청하더라도 브라우저가 자동으로 https로 요청합니다.
Strict-Transport-Security: max-age=31536000;includeSubDomains;preload
https로 전송한 요청을 중간자가 가로채어 내용을 볼 수 있는(MIMT)기법을 클라이언트 레벨(브라우저)에서 차단할 수 있습니다. 또한 2014년 블랙햇 아시아 컨퍼런스에서 "Leonard Nve Egea"가 sslStrip+ 를 공개하면서 서브도메인을 통해 우회할 수 있는 방법에 대해 includeSubDomains 를 추가하여 차단할수 있습니다.
5. X-XSS-Protection
이 헤더는 공격자가 XSS공격을 시도할 때 브라우저의 내장 XSS Filter를 통해 공격을 방지할 수 있는 헤더입니다.
X-XSS-Protection: 1;mode=block
위 처럼 설정한 경우 브라우저가 XSS공격을 감지하면 자동으로 내용을 치환합니다. mode=block 유무에 따라 내용만 치환
하고 사용자화면에 보여주거나 페이지 로드 자체를 block할 수 있습니다.
위 헤더는 브라우저의 내장 XSS Filter에 의해 처리 되므로 각 브라우저마다 처리 방식이 다를 수 있습니다. 모든 공격을 막을 수는 없기 때문에 추가적으로 Filter를 설정하여 방어해야 합니다.
6.Cache-Control, Pragma
공격자가 브라우저의 히스토리를 통한 공격을 진행 할 수 있기 때문에 cache를 적용하지 않는다는 헤더 입니다.
위 설정에 대한 Apache 설정은 다음과 같이 처리 할 수 있습니다.
<FilesMatch "\.(html|htm|js|json)$">
<IfModule mod_headers.c>
Header set Content-Security-Policy "script-src * 'self' 'unsafe-inline' 'unsafe-eval' "
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1;mode=block"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;"
Header set Cache-Control "no-store"
Header set Pragma "no-cache"
</IfModule>
</FilesMatch>
WAS는 필터 등을 이용하여 response에 해당 해더들을 동일하게 내려 보내면 됩니다.
response.setHeader("X-Content-Type-Options","nosniff");
'유용한 정보' 카테고리의 다른 글
Ethereum_dApp_1_블록체인과 이더리움 (0) | 2018.05.18 |
---|---|
Fabric에 대해 살펴보겠습니다.(1편) (0) | 2018.05.16 |
thymeleaf (server-side template engine) 사용법 정리 - 2 (0) | 2017.08.24 |
이상금융거래 탐지 시스템(FDS) (0) | 2017.08.16 |
Tizen studio에서 Wearable기기 Web Application 만들기 (0) | 2017.08.04 |