웹보안

지각생 연습장

목차

아파치 보안 조치

최신판으로 유지하기

아파치 웹서버는 안전과 보안 문제에 관심이 많은 개발자 공동체로 유명하다. 그러나 크건 작건 발표후 발견되는 문제들을 피할 수 없다. 그래서 소프트웨어를 최신버전으로 유지하는 것이 중요하다. 아파치에서 직접 웹서버를 다운로드했다면, 새로운 버전과 보안 업데이트를 알려주는 아파치 웹서버 발표 메일링리스트를 구독하길 강력히 권한다. 아파치 소프트웨어를 배포하는 많은 제삼자들도 비슷한 서비스를 제공한다.

물론 웹서버 코드때문에 웹서버가 공격을 당하는 경우는 많지 않다. 그보다 추가 코드, CGI 스크립트, 하위 운영체제의 문제로 공격을 당하는 경우가 많다. 그러므로 항상 주의하며 시스템의 모든 소프트웨어를 업데이트해야 한다.

ServerRoot 디렉토리 권한

보통 root 사용자가 아파치를 시작한 후, 요청을 서비스하기위해 User 지시어로 지정한 사용자로 변환한다. root가 실행하는 명령어가 있다면, root 이외의 사용자가 수정하지 못하도록 주의해야 한다. 이 파일들을 root만 쓸 수 있어야 하고, 디렉토리와 모든 상위디렉토리도 마찬가지다. 예를 들어, ServerRoot로 /usr/local/apache를 사용한다면 root 사용자가 다음과 같이 디렉토리를 만들길 제안한다: 

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

그러면 /, /usr, /usr/local 은 root만이 수정할 수 있다. httpd 실행파일을 설치할때 다음과 같이 보호해야 한다: 

cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd

htdocs 하위디렉토리는 다른 사용자들이 수정할 수 있도록 만들 수 있다 -- root는 그곳에 있는 파일을 실행하지도, 만들지도 않아야 한다.

root가 아닌 사용자가 root가 실행하거나 쓰기가능한 파일을 수정할 수 있다면 시스템의 root 권한을 훔칠 수 있다. 예를 들어, 누군가 httpd 실행파일을 변경하였다면 다음번 시작할때 임의의 코드를 실행하게 된다. logs 디렉토리가 (root가 아닌 사용자에게) 쓰기가능하다면 누군가 로그파일을 다른 시스템파일로 심볼링크를 걸어서 root가 파일에 임의의 자료를 덮어쓸 수 있다. 로그파일이 (root가 아닌 사용자에게) 쓰기가능하다면 누군가 로그에 이상한 자료를 기록할 수 있다.

Server Side Includes

Server Side Includes (SSI)는 서버 관리자에게 보안상 몇가지 잠재적인 위험이다.

첫번째 위험은 서버의 부하를 늘리는 점이다. 아파치는 파일에 SSI 지시어가 있는지 여부와 관계없이 모든 SSI 파일을 분석해야 한다. 조금 부하가 늘지만, 서버를 여러 사람이 같이 사용하는 환경에서는 심각할 수 있다.

또, SSI 파일은 일반적인 CGI 스크립트와 동일한 위험을 가진다. SSI 파일에서 "exec cmd"를 사용하면 httpd.conf에서 아파치를 실행하도록 설정한 사용자와 그룹 권한으로 CGI 스크립트나 프로그램을 실행할 수 있다.

장점을 활용하면서 SSI 파일의 보안을 향상시키는 방법이 있다.

SSI 파일이 가져올 수 있는 피해를 격리하기위해 서버관리자는 일반적인 CGI 절에서 설명하는 방법으로 suexec를 사용할 수 있다

.html이나 .htm 확장자를 SSI 파일로 사용하는 것은 위험하다. 특히 여러 사람이 공유하거나 통신량이 많은 서버 환경에서 위험하다. SSI 파일은 일반적으로 많이 사용하는 .shtml 같은 별도의 확장자를 가져야 한다. 그러면 서버 부하를 최소화하고 위험요소를 쉽게 관리할 수 있다.

다른 방법은 SSI 페이지가 스크립트나 프로그램을 실행하지 못하도록 만드는 것이다. Options 지시어에서 Includes 대신 IncludesNOEXEC를 사용한다. 그래도 스크립트가 ScriptAlias 지시어로 지정한 디렉토리에 있다면 <--#include virtual="..." -->를 사용하여 CGI 스크립트를 실행할 수 있음을 주의하라.

CGI

  • 일반적인 CGI
    • 결국 당신은 항상 CGI 스크립트/프로그램의 저자를 신뢰해야 하고, 고의건 실수이건 CGI의 잠재적인 보안상 허점을 발견할 수 있어야 한다. 기본적으로 CGI 스크립트는 웹서버 사용자 권한으로 시스템에서 어떤 명령어라도 실행할 수 있기때문에 주의있게 확인하지 않으면 매우 위험하다.
    • 모든 CGI 스크립트가 같은 사용자로 실행되기때문에 다른 스크립트와 (고의건 실수이건) 충돌할 가능성이 있다. 예를 들어, 사용자 A는 사용자 B를 매우 싫어하여, 사용자 B의 CGI 데이터베이스를 지워버리는 스크립트를 작성할 수 있다. 아파치 1.2 버전부터 포함되었고 아파치 서버에서 특별한 훅(hook)으로 동작하는 suEXEC는 스크립트를 다른 사용자로 실행하는 방법중 하나다. 다른 대중적인 방법에는 CGIWrap이 있다.
  • ScriptAlias하지 않은 CGI
    • 다음 조건을 만족할때만 사용자가 어떤 디렉토리에서라도 CGI 스크립트를 실행하도록 허용할 수 있다:
      • 당신은 고의건 실수이건 사용자가 시스템을 공격에 노출시키는 스크립트를 작성하지 않는다고 믿는다.
      • 시스템의 다른 부분의 보안이 약해서, 잠재적인 허점을 하나 더 만들어도 나빠질 것이 없다고 생각하는 경우.
      • 사용자가 없고, 아마 아무도 서버를 방문하지않는 경우.
  • ScriptAlias한 CGI
    • 특정 디렉토리에서만 CGI를 실행할 수 있도록 제한하면 관리자는 이들 디렉토리를 통제할 수 있다. 이 경우는 scriptalias하지 않은 CGI보다 확실히 안전하다. 단, 신뢰하는 사용자만 디렉토리에 접근할 수 있고, 관리자가 새로운 CGI 스크립트/프로그램의 잠재적인 보안상 허점을 검사할 용이가 있다면.
    • 대부분의 사이트는 scriptalias하지 않은 CGI 방식 대신 이 방식을 사용한다.

동적 내용을 생성하는 다른 방법

mod_php, mod_perl, mod_tcl, mod_python 같이 서버의 일부로 동작하는 임베디드 스크립트는 서버와 같은 사용자로 (User 지시어 참고) 실행되기때문에, 스크립트 엔진이 실행하는 스크립트는 잠재적으로 서버 사용자가 접근할 수 있는 모든 것에 접근할 수 있다. 어떤 스크립트 엔진은 어느정도 제한을 하지만, 안전하다고 가정하지 않는 것이 좋다.

시스템 설정 보호하기

정말로 안전한 서버를 운영하려면 사용자가 .htaccess 파일을 사용하여 당신이 설정한 보안기능을 변경하길 바라지 않을 것이다. 그러기위해 다음과 같은 방법이 있다.

  • 서버 설정파일에 다음을 추가한다 
<Directory />
AllowOverride None
</Directory>

그러면 사용가능하도록 명시적으로 허용한 디렉토리를 제외하고는 .htaccess 파일을 사용할 수 없다.

  • 기본적으로 서버에 있는 파일 보호하기

사람들은 종종 아파치의 기본 접근에 대해 잘못 알고있다. 즉, 서버가 일반적인 URL 대응 규칙을 사용하여 파일을 찾을 수 있다면, 특별히 조치를 하지 않는한 클라이언트에게 파일이 서비스될 수 있다.

예를 들어, 아래와 같은 경우: 

# cd /; ln -s / public_html
http://localhost/~root/ 에 접근한다

그러면 클라이언트는 전체 파일시스템을 돌아다닐 수 있다. 이를 막기위해 서버설정에서 다음과 같은 조치를 한다: 

<Directory />
Order Deny,Allow
Deny from all
</Directory>

그러면 파일시스템 위치에 대해 기본 접근이 거부된다. 원하는 영역에 접근할 수 있도록 다음과 같은 Directory 블록을 추가한다. 

<Directory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>

Location과 Directory 지시어를 같이 사용하는 경우 특별히 주의를 기울여라. 예를 들어, <Directory />가 접근을 거부하더라도 <Location /> 지시어가 이를 무시할 수 있다

UserDir 지시어를 사용하는 경우에도 주의하라. 지시어를 "./" 같이 설정하면 root 사용자에 대해 바로 위의 경우와 같은 문제가 발생한다. 아파치 1.3 이상을 사용한다면 서버 설정파일에 아래 줄을 추가하길 강력히 권한다: 

UserDir disabled root


로그 살펴보기

실제로 서버에서 무슨 일이 있어나고 있는지 알려면 로그파일을 살펴봐야 한다. 로그파일은 이미 일어난 일만을 보고하지만, 서버에 어떤 공격이 있었는지 알려주고 현재 필요한 만큼 안전한지 확인하게 해준다.

여러가지 예: 

grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
grep "client denied" error_log | tail -n 10

첫번째 예는 잘못된 Source.JSP 요청으로 서버정보를 알아낼 수 있는 Tomcat의 취약점를 이용하려는 공격 횟수를 알려주고, 두번째 예는 접근이 거부된 최근 클라이언트 10개를 다음과 같이 보여준다: 

[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied by server configuration:  /usr/local/apache/htdocs/.htpasswd

잘 알 듯이 로그파일은 이미 발생한 사건만을 보고한다. 그래서 클라이언트가 .htpasswd 파일에 접근할 수 있었다면 접근 로그에 다음과 같은 기록이 남을 것이다: 

foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"

즉, 당신은 서버 설정파일에서 다음 부분을 주석처리했을 것이다: 

<Files ~ "^\.ht">
Order allow,deny
Deny from all
<Files>

웹 에플리케이션 보안 솔루션

  • 웹 해킹 및 웜으로부터 핵심적인 엡 어플리케이션을 보호하는 전용 솔루션
  • 웹 프로그래밍 오류에 의한 역기능을 최소화시키고 DMZ 혹은 Web zone을 방어하는 보안 솔루션
  • 웹 스캐너, 웹 어플리케이션 게이트웨이로 구분
    • 웹 스캐너: 웹 어플리케이션의 취약점을 진단
    • 웹 어플리케이션 게이트웨이
      • 웹 어플리케이션에 대한 공격을 전문적으로 차단.
      • 기존 방화벽과 웹서버 중간 혹은 웹서버에 위치하면서 외부에서 유입되는 HTTP 요청을 필터링해 웹어플리케이션에 전달
      • SSL로 암호화된 데이터를 패킷 분석 후 웹서버로 보내줄 수 있음
  • 기존 보안 솔루션과 보완적 관계

솔루션들

  • 카바도 (이스라엘)
    • 웹 스캐너 (ScanDo), 웹 방화벽 (InterDo) 통합형 제품 보유
    • 자동정책설정 (Autopolicy) 기능 제공
  • 생텀: 웹 스캐너 (AppScan)에서 진단한 취약성을 바로 웹 어플리케이션 방화벽 (App-Shield)로 업로드
  • 넷컨티넘
    • NC-1000 (웹 어플리케이션 방화벽)
    • ASIC 기반이며 타 어플리케이션 스캐너와 연동 가능
  • 테로스: ASIC 기반의 SSL 가속 기능 제공
  • 체크포인트
    • Connectra, 웹 인텔리전트, SSL 네트워트 익스텐더 출시
  • F5네트웍스: Traffic Shield (웹 보안 방화벽)은 SSL 가속기를 내장한 하드웨어 일체형
  • 임퍼바
    • SecureSphere: 호스트 IPS 제품을 포함한 웹 어플리케이션 게이트웨이
  • 패닉시큐리티 (국내)
    • 웹 취약점 스캐너 PS 스캔 W3B 자체 개발
  • 듀얼시큐리티 (국내)
    • ASROC 개발
    • OWASP에서 규정한 10대 취약점을 기반으로 해커의 공격에 대한 룰 생성으로 웹 해킹을 차단

웹 app 보안 취약점 10

입력값 검증 부재

  • 웹 브라우저는 HTTP request에 URL, Query string, Form Fields, Hidden Fields, Cookies, Headers 등을 포함하여 웹 어플리케이션에 전송
  • 웹 어플리케이션은 이 정보를 가지고 웹 페이지를 생성
  • 공격자는 request를 수정하여 공격할 수 있음
  • 대처 방안:
    • 모든 parameter에 대해 사용 전에 검증 수행
    • 허용된 값만을 받아들이는 Positive 방식을 사용하여 parameter 검증

취약한 접근 통제

  • 인증되지 않은 사용자가 시스템에 접근하여 권한 없는 기능을 수행
  • 접근 통제 설계가 취약하여 공격자가 SQL-Injection 등의 방법을 사용하여 다른 사람의 계정으로 들어갈 수 있음
  • 대처 방안:
    • 어플리케이션의 접근통제 요구사항을 반영하여 보안정책을 명시
    • 접근 통제 메커니즘의 우회 가능성 검증

취약한 인증 및 세션 관리

  • 강력한 인증 메커니즘도 취약한 사용자의 credential 관리로 침해 받을 수 있음 (ex. 패스워드 분실)
  • 세션 토큰이 적절히 보호되지 않으면 공격자가 현재 활성화된 사용자의 세션을 가로채 다른 사용자를 가장하여 접속 가능
  • 대처 방안:
    • 강력한 패스워드 사용
    • 전송중의 credential 보호
    • 세션 아이디 보안

Cross-Site Scripting 취약점

  • 웹어플리케이션의 특성상 사용자의 브라우저에서 실행될 수 있는 악성코드 전달가능
  • 대처 방안:
    • 어플리케이션 차원에서 HTTP 헤더, 쿠키, 쿼리 스트링, 폼 필드, 히든 필드 등의 모든 인자들에 대해 허용된 유형의 데이터만을 받아들이도록 한다.

버퍼 오버플로우

  • 웹 어플리케이션의 실행 가능한 스택을 덮어쓰기 위해 사용됨
  • 웹 어플리케이션에 주의깊게 조작한 입력 값을 보내 웹 어플리케이션이 임의의 코드를 수행하도록 함
  • 대처 방안:
    • 해당 제품의 최신 패치 적용
    • 자체 제작한 어플리케이션의 경우 HTTP 요청을 통해 입력 받아들이는 코드 검토

삽입 (Command Injection) 취약점

  • 취약한 웹 어플리케이션을 통해 악성 코드를 전송하여 시스템 콜을 통한 OS 호출, 쉘 명령어를 통한 외부 프로그램 사용, SQL 구문을 통한 백엔드 데이터베이스 호출 등을 수행
  • SQL-Injection의 예: 
SELECT Count (*) FROM Users WHERE UserName=‘’ Or 1=1 -–’ AND  Password=‘’
  • 대처 방안:
    • 가능한 한 외부 인터프리터 사용하지 않는다.
    • 백엔드 데이터베이스 호출할 경우, 입력 값을 주의 깊게 검증

부적절한 에러 처리

  • 부적절한 에러 처리로 stack trace, 데이터베이스 덤프나 에러 코드를 사용자가 볼 수 있도록 자세한 에러 메시지 반환
  • 대처 방안:
    • 해당 사이트가 예상 가능한 모든 에러를 적절히 다루도록 보장

암호의 안전하지 않은 사용

  • 중요 데이터를 암호화하지 않거나, 키를 안전하지 않은 장소에 보관하는 등 암호를 적절히 사용하지 않는 경우
  • 대처 방안:
    • 취약점이 없는 암호 라이브러리 사용
    • 사용자 인증정보, 패스워드 등은 안전하게 저장되도록 함

Denial of Service

  • 웹 어플리케이션은 공격과 정상적인 트래픽 사이의 차이를 구분하기 어려워 DoS 공격에 취약할 가능성이 높음
  • 대처 방안:
    • 완벽하게 방어하는 방법은 없음
    • 모든 사용자에게 제한된 자원만을 할당

부적절한 환경 설정

  • 취약점을 패치하지 않거나 적절하지 않은 파일 권한 설정, 디폴트 패스워드를 사용하는 계정을 남겨두는 등의 부적절한 환경 설정은 심각한 위험을 줄 수 있음
  • 대처 방안:
    • 보안 강화 가이드라인을 만들고 준수
원본 주소 "http://latecomer.pe.kr/wiki/index.php?title=%EC%9B%B9%EB%B3%B4%EC%95%88&oldid=4054"
개인 도구