정보보안기사 필기 - 33(웹 보안)

- 웹 보안 개요

<웹 트래픽 보안 방법>

웹 보안을 제공하는 방법은 IPSec을 이용하는 것과 TCP 바로위에 보안을 구현한 SSL, TLS를 이용하는 것입니다.

 

- SSL/TLS

SSL/TLS는 클라이언트/서버 환경에서 TCP 기반의 애플리케이션에대한 종단간 보안서비스를 제공하기위해 만들어진 전송 계층 보안 프로토콜입니다. . SSL은 네스케이프사이에서 1990년대 초 처음으로 제안되었으며 SSL/TLS는 현재 가장 많이 이용되고 있는 암호 통신 방법입니다. 그 후 SSL은 version 3/.0이 되었는데 POODLE 공격이 가능한 취약점이 발견되었습니다. 이때문에 IETF가 SSL 3.0을 기반으로 TLS를 만들었습니다. SSL/TLS에서는 대칭키 암호, 공개키 암호, 일방향 해시함수, 메시지 인증코드, 의사난수 생성기, 전자 서명을 조합해서 안전한 통신을 수행합니다. 또한 SSL.TLS는 암호스위트(SSL/TLS에서 사용하는 암호 기술의 추천 세트를 암호 스위트라고합니다.)를 변경해서 암호 알고리즘을 선택할 수 있습니다. 즉, SSL/TLS는 특정 암호기술에 의존하지않고 어느 대칭키가 약하다고 판명되면 그 대칭키 암호를 사용하지않는 암호 스위트를 선택하면됩니다. 이는 기계의 부품이 고장 났을때 고장난 부품많을 교환하는 것과 같습니다.

 

<SSL/TLS상의 HTTP>

HTTP는 암호화하지 않기때문에 중간에 도청당하면 쉽게 정보를 획득할 수 있습니다. 이때문에 통신내용을 암호화해주는 프로토콜로 SSL 혹은 TLS를 사용합니다. 그리고 SSL/TLS 상에 HTTP를 올립니다. 이때 URL은 https://로 시작됩니다.

 

<SSL/TLS 보안 서비스>

• 기밀성 서비스 : DES, RC$와 같은 대칭키 암호화 알고리즘을 사용하여 제공되며 이때 사용되는 비밀키는 Handshake protocol로 생성됩니다.
• 클라이언트와 서버 상호 인증 : 인증에는 RSA와 같은 비대칭키 암호 알고리즘, DSS와 같은 전자서명 알고리즘과 X.509 공개키 인증서가 사용됩니다.
• 메시지 무결성 서비스 : 안전한 해시 알고리즘을 사용해서 메시지 인증코드를 만들어 메시지에 포함시키기때문에 신뢰성 있는 통신이 가능합니다.

<TLS 프로토콜>

가장 널리 사용하는 보안 서비스중의 하나가 전송 계층 보안(TLS)입니다. SSL을 아직도 사용하고 있지만 IETF에서 사용중지를 선언하였고 대부분의 기업에서는 TLS 소프트웨어로 대체하였습니다. TLS는 handshake 프로토콜로 인증서, 키, 난수등 보안 매개변수를 서버와 클라이언트끼리 교환하고 이를 기반으로 recorde 프로토콜이 암호화 과정을 시행합니다. 또한 동기화를 위해 하트비트 프로토콜이 있으며 오류를 위해 Alert 프로토콜이 있습니다.

 

<handshake 프로토콜>

SSL에서 가장 복잡한 부분으로 서버와 클라이언트끼리 서로를 인증하고 암호화 알고리즘 그리고 데이터를 보호하는 암호키를 협상하는 프로토콜입니다. 아래는 프로토콜의 과정입니다.

1단계 : 초기협상 단계

• HelloRequest : 서버가 아무때나 클라이언트에게 Client Hello를 보내어 협상을 시작하자고 요구하는 메시지입니다. 중복적인 HelloRequest를 보내면 안됩니다.
• ClientHello : 클라이언트는 서버에 처음으로 연결을 시작하거나 HelloRequest 메시지에 대한 응답으로 ClientHello를 보냅니다. ClientHello 메시지에는 세션 식별자, CipherSuite 리스트, 압축 알고리즘 리스트, 클라이언트의 SSL버전, 클라이언트가 생성한 난수를 서버에 전달합니다.
• ServerHello : ClientHello 메시지에대한 응답으로 ServerHello 메시지를 보냅니다. ServerHello 메시지는 세션 식별자, 서낵한 CipherSuite, 선택한 압축방법, 서버 SSl 버전, 서버가 생성한 나수를 클라이언트에 전달합니다.

2단계 : 서버 인증 단계

• ServerCertificate : 서버의 인증이 필요한 경우 서버의 인증서가 포함된 certificate를 보냅니다. 이때 서버의 인증서는 chiper suite의 키 교환 알고리즘에 맞는 타입이여야합니다.
• ServerKey Exchange : 서버가 인증서를 보내지 않았거나 보낸 인증서에 키교환에 필요한 정보가 부족할때 보내는 메시지입니다.
• CertificateRequest : 서버는 클라이언트에게 인증함과 동시에 클라이언트에게 인증서를 통한 인증을 요구합니다.
• ServerHelloDone : 서버가 보낼 메시지를 다 보냈음을 알려주는 메시지입니다. 클라이언트는 이 메시지를 기다립니다.

3 단계 : 클라이언트 인증 단계

• ClientCertificate : 서버가 클라이언트의 인증을 요구할 경우 클라이언트가 보내는 메시지입니다.
• ClientKeyExchange : 클라이언트는 세션키를 생성하기위해 임의의 비밀정보인 48바이트 pre_master_secret을 생성하고 선택된 공개키 알고리즘을 이용해서 pre_master_secret을 서버와 공유합니다.
• CertificateVerify : 클라이언트 인증서의 명백한 확인을 위해서 전자 서명을 하여 전송합니다.

4단계 : 종료 단계

• ChangeCipherSpecs : 이 메시지는 이 메시지 이후에 전송되는 메시지는 새롭게 협상된 알고리즘과 키를 이용할 것임을 나타냅니다.
• Finished : 이 메시지는 ChangeChiperSpecs 메시지 이후에 전송되며 협상된 알고리즘과 키가 처음으로 적용됩니다.

<Record 프로토콜>

레코드 프로토콜은 응용 메시지를 다룰 수 있는 크기의 블록으로 잘라내고 압축하고 MAC을 적용하고 암호화를 하고 헤더를 추가하여 TCP 단편으로 전송합니다. 수신된 데이터는 역의 연산을 거쳐 상위 계층 사용자에게 전달됩니다.

 

<Alert 프로토콜>

SSL/TLS 통신 과정에서 발생하는 오류를 통보하기위해 경고 할때 사용합니다. Alert 메시지는 경고메시지와 경고에대한 상세한 정보를 전달하며 치명적 레벨의 Alert 메시지는 연결을 즉시 단절하게됩니다. 이 프로토콜 안의 메시지는 각 2바이트로 구성도이ㅓ 첫바이트는 경고 혹은 심각이라는 2가지 값을 갖고 두번째 바이트에서는 특정 경고를 나타내는 코드가 있습니다.

 

<하트비트 프로토콜>

시스템의 다른 부분과 동기화하기위해서 하드웨어나 소프트웨어가 생성하는 주기적인 신호를 말하며 프로토콜 개체의 가용성을 모니터링 할때 사용합니다.

 

<SSL/TLS 공격>

• OpenSSL의 hearbleed 취약점 : gogle이 OpenSSL의 취약점을 발견하였는데, TLS의 하트비트 확장이라고 하는 기능에 요구 데이터 길이에대한 점검이 걸여되었다는 취약점으로 메모리상의 관계없는 정보까지 상대방에게 넘어가는 공격이 가능합니다. 이에따라 하트비트 확장을 사용하지않고 인증서를 재발급하는 등의 조치가 필요했습니다.
• SSL 3.0의 취약점과 POODLE 공격 : TLS를 SSL 3.0으로 다운그레이드한 통신을 강요할 수 있는 취약점이 발견되었습니다. 다운그레이드하여 공격하는 것을 POODLE 공격이라고 합니다. TLS를 사용해도 SSL POODLE공격이 가능한 것입니다. POODLE 공격을 통해 쿠키 정보나 데이터를 추출할 수 있습니다. 이에대한 대책은 SSL 3.0을 사용하지 않는 것입니다.
• FREAK 공겨과 암호 수출 규제 : MS사에서 SSL을 통해 강제로 취약한 RSA로 다운그레이드시킬 수 있는 취약점을 발견했습니다. RSA Export Suites 라고 불리는 약한 암호 스위트를 사용하게 하는 공격입니다. 대응책으로는 SSL을 최신버전으로 업그레이드하는 것이 있습니다.
• 완전 순방향 비밀성 : RSA방식으로 키교환을 수행할 경우 중간자 공격을 통해 트래픽을 가로채고 서버 개인키를 이용해서 데이를 보고화할 수 있습니다. 이러한 문제를 해결하기위해 등장한 암호학적 성질을 완전 순방향 비밀성이라합니다. 이는 서버 개인키가 노출되어도 과거의 세션키가 노출되지않는 성질을 말합니다.

- 웹 보안

<iss 보안 설정>

• 권한 설정 : 특정 폴더, 파일에대해서 읽기, 쓰기, 삭제, 실행등의 기능을 적절한 권한에따라 부여해야합니다.
• 관리자 페이지 접근 통제 : 관리자 페이지가 추측가능한 형태로 구성되어 있을경우 무작위 대입 공격을 통해 관리자 권한을 획득할 수 있으니 ip등을 통해서 통제해야합니다.
• 메소드 제한 : 불필요한 메소드 delete 같은 메소드가 있으면 서버측의 주요 자원이 삭제되거나 피해를 입을 수 있기에 필요한 경우가 아니라면 GET, POST를 제외한 메소드는 제거하는 것이 좋습니다.
• 헤더 정보 숨김 : 서버에대한 정보등이 헤더에 포함되므로 공격자가 해당 서버에 공격을 시도할때 정보로 이용할 수 있으니 숨깁니다.

<Apache 보안 설정>

• 서버 실행 계정 설정 : 구버전의 아파치는 root 권한으로도 실행되는 경우가 많아 사고가 빈번히 일어났습니다. 이를 막기위해 apache 라는 별도의 계정을 권한에따라 만들어서 실행해야합니다.
• httpd.cof 파일 설정: 아파치 설정파일로 안에 설정 값들은 아래와 같습니다.

• ServerType : 서버를 standalone 모드 혹은 inetd 모드로 운영할지를 결정하는 부분입니다.
• Timeout(300) : 클라이언트에서 서버로 접속할때 클라이언트나 서버의 통신 장애로 인해 300초 동안 클라이언트에서 완벽한 처리를 하지 못할때 클라이언트와의 연결을 해제합니다.
• KeepAlive(on) : 사용자의 요청 연결에대해 한번의 요청만 처리하는 것이 아니라 또 다른 요청을 기다리게 할지 설정합니다. Off라면 한번 요청받은후 바로 접속을 해제합니다.
• MaxKeepAliveRequests(100) : KeepAlive 상태에서 처리할 최대 요청 처리 건수를 설정합니다. 보통 100으로 합니다.
• KeppAlveTimeOut(15) : KeppAlive 상태를 유지할 시간을 초단위로 설정합니다.
• MinSoareServers(8) : 아파치가 실행될때 최소 예비 프로세스 수를 설정합니다.
• MaxSpareServers(20) : 아파치가 실행될때 최대 예비 프로세스 수를 설정합니다.
• MaxClient(150) : 아파치 서버의 동시 접속자 수를 정의하는 것으로 최대값은 256입니다.
• MaxRequsetPerChild(0) : 아파치 자식 프로세스가 처리할 수 있는 최대 요청 처리 건수를 설정합니다. 0은 무제한을 의미합니다.
• User(nobody) : 자식 프로세스가 생성될때 소유자와 소유 그룹을 결정합니다. 보안상 root는 안됩니다.
• Port(80) : 아파치가 사용하는 기본 포트이빈다.
• ServerAdmin(root@localhost) : 아피치 서버 관리자 e-mail을 설정하는 부분입니다.
• ServerName : 작동중인 아파치 서버의 서버 이름을 정합니다.
• DocumentRoot : 아파치의 웹 문서들이 존재하는 위치를 저장합니다.
• Options : 디렉터리의 접근제어를 설정합니다. Indexes 는 파일목록을 웹브라우저로보여주기 때문에 사용하지않는 것이좋고 FollowSymlinks또한 링크 파일 경로를 확인할 수 있기에 사용하지 않는 것이 좋습니다.
• LrrorLog : 아파치 서버 접속 에러를 기록할 이름입니다.
• LogLevel : 에러 로그 내용의 레벨을 설정합니다.
• ServerSignature : 서버 배너 정보를 나타낸는 것으로 서버 정보를 은닉하기 원한다면 off로 변경합니다.
• ServerTokens : 서버의 정보 표시제한을 설정합니다. ProductOnly면 웹서버 종류만 Minimal이면 버전 정보도 함께 OS면 운영체제 정보도 함께 FULL이면 설치된 모듈 정보도 함께 표시합니다.

• 검색엔진 정보 노출 취약점 : 검색엔진에 의해 정보를 탈취당할 수 있으므로 로봇배제표준에대한 설정을 robots.txt파일에 기술합니다. tobot.txt파일은 웹사이트의 최상위 디렉터리에 저장해야합니다.

 

- 웹 보안 위협 및 대응책

웹서버 공격은 새로운 공격기법이 발견되므로 항상 최신 보안 경향에 관심을 가지고 3년마다 발표되는 OWASP top 10에대해 이해하고 있어야합니다.

 

<OWASP 2021 목록>

A01 : Broken Access Control (접근 권한 취약점)

엑세스 제어는 사용자가 권한을 벗어나 행동할 수 없도록 정책을 시행합니다. 만약 엑세스 제어가 취약하면 사용자는 주어진 권한을 벗어나 모든 데이터를 무단으로 열람, 수정 혹은 삭제 등의 행위로 이어질 수 있습니다. 

A02 : Cryptographic Failures (암호화 오류)
Sensitive Data Exposure(민감 데이터 노출)의 명칭이 2021년 Cryptographic Failures(암호화 오류)로 변경되었습니다. 적절한 암호화가 이루어지지 않으면 민감 데이터가 노출될 수 있습니다. 

A03: Injection (인젝션)
SQL, NoSQL, OS 명령, ORM(Object Relational Mapping), LDAP, EL(Expression Language) 또는 OGNL(Object Graph Navigation Library) 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 취약점이 발생합니다. 

A04: Insecure Design (안전하지 않은 설계)
Insecure Design(안전하지 않은 설계)는 누락되거나 비효율적인 제어 설계로 표현되는 다양한 취약점을 나타내는 카테고리 입니다. 안전하지 않은 설계와 안전하지 않은 구현에는 차이가 있지만, 안전하지 않은 설계에서 취약점으로 이어지는 구현 결함이 있을 수 있습니다. 

A05: Security Misconfiguration (보안설정오류)
애플리케이션 스택의 적절한 보안 강화가 누락되었거나 클라우드 서비스에 대한 권한이 적절하지 않게 구성되었을 때, 불필요한 기능이 활성화 되거나 설치되었을 때, 기본계정 및 암호화가 변경되지 않았을 때, 지나치게 상세한 오류 메세지를 노출할 때, 최신 보안기능이 비활성화 되거나 안전하지 않게 구성되었을 때 발생합니다. 

A06: Vulnerable and Outdated Components (취약하고 오래된 요소)
취약하고 오래된 요소는 지원이 종료되었거나 오래된 버전을 사용할 때 발생합니다. 이는 애플리케이션 뿐만 아니라, DBMS, API 및 모든 구성요소 들이 포함됩니다. 

A07: Identification and Authentication Failures (식별 및 인증 오류)
Broken Authentication(취약한 인증)으로 알려졌던 해당 취약점은 identification failures(식별 실패)까지 포함하여 더 넓은 범위를 포함할 수 있도록 변경되었습니다. 사용자의 신원확인, 인증 및 세션관리가 적절히 되지 않을 때 취약점이 발생할 수 있습니다. 

A08: Software and Data Integrity Failures(소프트웨어 및 데이터 무결성 오류)
2021년 새로 등장한 카테고리로 무결성을 확인하지 않고 소프트웨어 업데이트, 중요 데이터 및 CI/CD 파이프라인과 관련된 가정을 하는데 중점을 둡니다. 

A09: Security Logging and Monitoring Failures (보안 로깅 및 모니터링 실패)
Insufficient Logging & Monitoring(불충분한 로깅 및 모니터링) 명칭이었던 카테고리가 Security Logging and Monitoring Failures (보안 로깅 및 모니터링 실패)로 변경되었습니다. 로깅 및 모니터링 없이는 공격활동을 인지할 수 없습니다. 이 카테고리는 진행중인 공격을 감지 및 대응하는데 도움이 됩니다. 

A10: Server-Side Request Forgery (서버 측 요청 위조)
2021년 새롭게 등장하였습니다. SSRF 결함은 웹 애플리케이션이 사용자가 제공한 URL의 유효성을 검사하지 않고 원격 리소스를 가져올 때마다 발생합니다. 이를 통해 공격자는 방화벽, VPN 또는 다른 유형의 네트워크 ACL(액세스 제어 목록)에 의해 보호되는 경우에도 응용 프로그램이 조작된 요청을 예기치 않은 대상으로 보내도록 강제할 수 있습니다.

 

<SQL injection>

취약점 : 데이터베이스와 연동된 웹 응용프로그램에서 입력된 데이터에대한 유효성 검증을 하지않을경우 직접적으로 DB SQL문을 작성이 가능합니다.

SQL injection 공격 종류 :

1. Form SQL injection : HTML Form 기반 인증을 담당하는 애플리케이션에 injection 하는 기법입니다.

2. Union SQL injection : 한 쿼리 결과에 다른 쿼리의 결과를 결합하여 공격하는 기법입니다.

3. Error-Based SQL injection : 에러값을 기반으로 한단계씩 점진적으로 DB정보를 획득할 수 있는 방법입니다.

4. Blind SQL injection : 오류메시지가 아닌 참과 거짓을 통해 의도하지않은 SQL문으로 공격하는 방법입니다.

대응책 : 모든 입력값에대해 검증절차를 설계하고 구현해야합니다. 또한, DB에 접근하는 프로세스에 최소권한을 설정합니다. 또한 선처리 질의문을 사용하면 고정된 SQL 쿼리값은 컴파일되고 나머지 변수부분은 문자열 변수로 다루기때문에 SQL injection 방어에 효과적입니다.

 

<XSS>

취약점 : 사용자 입력값에대해 필터링이 제대로 이루어지지 않을경우 공격자가 입력이 가능한 폼에 악의적인 스크립트를 삽입, 해당 스크립트가 희생자 측에서 동작하도록 하여 악의적인 행위를 수행하는 공격방법입니다.

XSS 공격 종류 :

1. stored XSS : 단순히 게시판 또는 자료실과 같이 사용자가 글을 저장할 수 있는 부분에 정상적인 평문이 아닌 스크립트 코드를 입력하는 기술입니다.

2. Reflected XSS : 악성 스크립트가 포함된 URL을 사용자에게 보내고 사용자는 그 URL을 통해 악의적인 스크립트를 실행하게됩니다. 보통 URL을 인코딩한 후 전달합니다.

3. DOM based XSS : 공격 스크립트가 DOM 생성의 일부로 실행되며 공격합니다. 페이지 자체는 변하지 않으나 페이지에 포함되어 있는 브라우저 코드가 DOM 환경에서 악성코드로 실행됩니다.

대응책 : 문자열을 검사하여 문자 변환 함수나 메소드로 <>&"'등을 &lt, &gt, &amp, &quot로 치환합니다. 또한 게시판에서 지원하는 HTML 태그의 리스트를 만들어 선정한후 해당 태그만 허용하는 방식으로 지원합니다.

 

<CSRF>

취약점 : 웹서버가 정상적인 경로를 통한 요청과 비정상적인 경로를 통한 요청을 서버가 구분하지못할경우 XSS를 이용하여 조작된 요청을 보내게할 수 있습니다.

대응책 : GET방식보다는 POST방식으로 폼을 적용하고 공격자의 직접적인 URL 사용을 하지 않도록 처리합니다.

 

<파일 다운로드 공격>

취약점 : 파일 다운로드 경로를 조작할 수 있을때 예상밖의 접근 제한 영역에대한 경로 문자열 구성이 가능해서 정보누출을 유발할 수 있습니다.

대응책 : 파일 경로를 검증하고 파일은 외부와 단절 시키며, 파일 명을 랜덤하게하고 무결성 검사를 실시합니다.

 

<파일 업로드 공격>

취약점 : 서버에 파일을 업로드할 수 었는 게시판의 경우 서버가 파일을 검증하지않을때 악성 코드가 실행될 수 있습니다. 특히나 리버스 텔넷을 실행시켜 통제권을 얻을 수 있습니다.

대응책 : 파일을 검증하고 업로드된 파일은 외부와 단절 시키며, 파일 명을 랜덤하게하고 무결성 검사를 실시합니다.

 

<리버스 텔넷>

방화벽에서 인바운드 정책은 80번 포트 이외에 필요한 포트만 빼고 다 막아놓지만 아웃바운드 정책은 별다른 필터링을 수행하지않은 경우가 많습니다. 이때 공격자가 서버에게 텔넷을 요청하는게아닌 그 반대, 서버가 공격자에게 텔넷을 요청하여 통제권을 얻어내는 것을 리버스 텔넷이라고 합니다.

 

<보안설정 취약점>

• 디렉터리 리스팅 : 브라우저가 서버의 폴더를 열면 그 폴더에 있는 모든 파일들을 볼 수 있는 것입니다.
• 백업 및 임시 파일 존재 : 개발자들이 사이트를 개발한 후 웹서버에 백업 파일이나 임시 파일을 삭제하지 않은 채 방치하는 경우가 종종 있습니다. 이때 백업파일을 발견하면 내부 로직및 중요정보를 얻을 수 있습니다. 흔히 login.asp.bak과 같이 남습니다.
• 주석 관리 미흡 : 일반적인 주석은 개발자만 볼 수있지만 웹 애플리케이션의 경우 웹 프락시를 통해 이용자도 볼 수 있습니다. 이는 로직, 구조, 정보, 아이디와 패스워드등을 알아낼 수 있습니다.

<웹의 취약점 보안>

특수문자 필터링 : 외부 입력값들의 특수문자들을 XSS,SQL 삽입공격을 대비해 필터링 해야합니다.

서버측 통제 적용 : 특수 문자 필터링을 할때 주의할점은 Client side script가 아닌 server side script로 검증해야합니다.

지속적인 세션 관리 : URL 접근 제한 실패를 막기위해 기본적으로 모든 웹페이지에대한 세션인증을 해야합니다. 또한 세션 인증 로직을 표준화하고 준수해야합니다.

 

<웹 방화벽>

방화벽은 네트워크 계층에서 실행되지만 웹 방화벽은 애플리케이션 계층에서 실행됩니다.

• 기능 : 접근제어, 과다 요청 제어, 업로드 파일 및 요청 형식 검사, injection 검사, xss 차단을 해줍니다.
• 콘텐츠 보호 : 정보 유출 차단, 웹 변조 방지, 코드 노출을 진단해줍니다.
• 위장 : URL 정보 위장, 서버 정보 위장을 해줍니다. 

<소프트웨어 보안 약점 유형>

• 입력데이터 검증 및 표현 : 프로그램 입력값에 대한 검증 누락 또는 부적절한 검증으로 인해 발생하는 약점입니다.
• 보안 기능 : 보안기능을 적절하지 않게 구현시 발생할 수 있는 약점입니다.
• 시간 및 상태 : 하나 이상의 프로세스가 동작하는 환경에서 시간 및 상태를 부적절하게 관리하여 발생할 수 있는 보안 약점입니다.
• 에러처리 : 에러처리를 하지않거나 불충분하게 처리하여 에러정보에 중요정보가 포함될때 발생할 수 있는 보안약점입니다.
• 코드오류 : 타입변환 오류, 자원의 부적절한 반환등으로 코딩오류에 의해 발생할 수 있는 보안약점입니다.
• 캡슐화 : 중요한 데이터를 불충분하게 캡슐화했을때 인가되지않은 사용자에게 데이터 노출이 가능해지는 보안약점입니다.
• API 오용 : 의도된 사용에 반하는 방법으로 API를 사용하거나, 보안에 취약한 API를 사용하여 발생할 수 있는 보안 약점입니다.