웹 보안

정보보안기사

웹 보안

SNNP 2023. 1. 22. 19:33

웹 트래픽 보안 방법

IPSec 사용으로 사용자의 응용에 투명성 제공, 범용 해결책 제시
TCP 바로 위에서 보안을 구현(안전소켓계층SSL과 전송계층보안TLS)
네트워크계층 IPsec, 전송계층 : SSL/TLS, 응용계층 : S-HTTP SET OTP

월드와이드웹과 HTTP

서버는 포트 80번을 사용하고 클라이언트는 임시 포트 번호 사용

영속성

HTTP 1.0은 비영속적 연결, 1.1은 영속적 연결

비영속적 연결 : 각 요구/응답에 하나의 TCP 연결이 만들어짐, end-of-line 표시가 나타나면 연결을 닫음

영속적 연결 : 1.1 버전부터 Connection 헤더에 Keep-alive 옵션 추가, 일정시간 지속시키는 옵션

HTTP 트랜잭션 : 요청 메시지

요청 헤더라인 : Method, URL, Version

메소드

지시자	설명
GET	웹 서버에 저장된 정보를 단순히 요청하기 위해 사용
HEAD	서버 응답 시 응답 메시지의 바디는 제외하고 헤더만 응답해주는 메소드
POST	클라이언트에서 웹 서버로 데이터 전송 시 사용
PUT	몸체에 콘텐츠 내용을 덧붙여 원격지 서버에 지정한 콘텐츠를 저장하기 위한 목적 (홈페이지 변조에 악용)
DELETE	클라이언트가 권한이 있다면 서버에서 웹페이지를 제거하는 것을 허용
TRACE	디버깅에 사용, 클라이언트는 서버가 요청들을 받고 있는지 여부 확인을 위해 echo back을 서버에 요청
OPTIONS	시스템에서 지우너되는 메소드 종류 확인
CONNECT	서버에 프락시 기능을 요청할 때 사용

요청 헤더라인

요청 라인 이후 0개 이상 요청 헤더라인

Host : 요청의 대상이 되는 서버의 도메인명/호스트명과 포트 정보
User-Agent : 요청 클라이언트 애플리케이션/OS 정보
Referer : 현재 요청 URL 정보를 담고 있는 이전 문서의 URL 정보

빈 라인

빈 라인으로 끝을 식별

본체

송신될 주석이나 웹사이트에 게시될 파일

HTTP 트랜잭션 : 응답 메시지

상태라인 상태 코드 필드

정보 : 100 continue, 101 switching
성공 : 200 ok, 201 created, 202 accepted, 204 no content
재지정 : 300 multiple choice, 301 moved permanently, 302 moved temporarily, 304 mot modified
클라이언트 오류 : 400 bad request, 401 unauthorized, 403 forbidden, 404 not found, 405 method not allowed, 406 not acceptable
서버 오류 : 500 internal server error, 501 server unavailable

응답 헤더 라인

상태 라인 이후 0개 이상의 응답 헤더 라인, 서버에서 클라이언트로 추가적 정보를 보냄

Content-Type : 메시지 바디의 데이터 형식
Content-Length : 메시지 바디의 전체 크기 (단위 : 바이트)

빈 라인

빈 라인을 통해 끝 식별

본체

서버에서 클라이언트로 전송되는 문서 포함, 오류 메시지가 아니면 본체가 있음

SSL/TLS

클라이언트는 브라우저만 있고, 모든 것은 서버단에 설치

클라이언트-서버 환경에서 TCP 기반의 종단간 보안서비스 제공을 위해 만들어진 전송계층 보안 프로토콜

IPSec과 비슷하게 Application에 대해 독립적

📍SSL
세션 계층(전송계층과 응용계층 사이)에서 적용, 표준화 기구에 의해 TCP 443 번 포트 사용
FTP, TELNET, HTTP 등의 응용계층 프로토콜의 안전성 보장

SSL/TLS 상의 HTTP

통신 내용을 암호화해주는 프로토콜로 SSL이나 TLS 사용, SSL/TLS 상에 HTTP를 올림

SSL/TLS로 통신 수행 시 URL은 https://로 시작 (상태표시줄에 좌물쇠 모양 표시)

SSL/TLS 보안 서비스

기밀성 서비스 : DES, RC4와 같은 대칭키 암호화 알고리즘 사용, 비밀키는 Handshake protocol을 통해 생성

클라이언트와 서버 상호 인증 : 인증에는 RSA 같은 비대칭키 암호 알고리즘, DSS와 같은 전자서명, X.509 공개키 인증서 사용

메시지 무결성 서비스 : 안전한 해시 알고리즘을 사용해서 메시지 인증코드(MAC)를 만들어 포함시킴

TLS 프로토콜

SSL을 아직 사용하나 IETF에서 사용 중지를 선언했고, 대부분의 기업에서 TLS 소프트웨어로 대체

TLS 프로토콜은 TLS 레코드 프로토콜과 TLS 핸드셰이크 프로토콜 2개의 프로토콜이 겹쳐서 구성 (SSL도 마찬가지)

TLS는 TCP 기반, DTLS는 UDP 기반

TLS 구조

Record protocol : 운반자, 응용 계층으로부터 오는 데이터, TLS 상위 프로토콜로부터 오는 메시지 전송

Handshake protocol : record protocol에 대한 보안 매개변수 제공, 상호 인증

ChangeCipherSpec protocol(암호명세 변경 프로토콜) : 암호학적 비밀을 신속하게 보냄

Alert protocol : 비정상 조건을 알리는데 사용

heartbeat protocol : 가용성을 모니터링할 때 사용하는 프로토콜

Handshake 프로토콜

서버와 클라이언트가 서로 인증하고 암호화

MAC 알고리즘 그리고 TLS 레코드 안에 보낸 데이터를 보호하는데 사용할 암호키를 협상

--- 보안 기능 확립 ---

1. HelloRequest

서버가 아무때나 협상을 시작하자고 보내는 메시지

2. ClientHello

세션 식별자 : 처음일 때 empty, 재사용 시 재사용 ID

cipherSuite 리스트 : 키 교환 알고리즘, 암호 알고리즘, MAC 알고리즘

클라이언트가 지원하는 압축 알고리즘 리스트

클라이언트 SSL 버전

클라이언트가 생성한 난수 : replay 공격을 막기 위함를 서버에 보냄

--- 서버 인증과 키 교환 ---

3. SeverHello

실패한 경우 : Handshake Failure Alert 메시지

세션 식별자, 선택한 CipherSuite, 선택한 압축 방법, 서버 SSL 버전, 서버가 생성한 난수를 클라이언트에 전달

4. ServerCertificate

서버의 인증이 필요한 경우 ServerHello 뒤에 바로 서버의 인증서가 포함된 certificate를 보내야 함

서버 인증서는 cipher suite의 키 교환 알고리즘에 맞는 타입이어야 함

5. ServerKeyExchange

서버의 인증서를 보내지 않았거나, 보낸 인증서에서 키 교환에 필요한 정보가 부족할 때 전송

6. CertificateRequest

서버가 클라이언트에게 인증 요구(선택)

7. ServerHelloDone

서버가 보낼 메시지를 다 보냈음을 알리는 메시지

--- 클라이언트 인증과 키 교환 ---

8. ClientCertificate

서버가 클라이언트의 인증서를 요구할 경우 보냄

9. ClientKeyExchange

클라이언트가 세션키 생성을 위해 48바이트의 pre_master_secret 생성

선택된 공개키 알고리즘으로 pre_master_secret 을 서버와 공유

10. CertificateVerify

클라이언트가 핸드셰이크 메시지를 전자서명하여 전송(개인키로 서명)

--- 종료 단계 ---

11. ChangeCipherSpec, Finished

서버가 보내며 핸드셰이크 수행 완료

ChangeCipherSpec : 핸드셰이크 프로토콜에 미포함, 새롭게 협상된 알고리즘과 키를 이용할 것임을 나타냄

Finished : 클라이언트가 이 메시지를 통해 협상한 결과를 확인

Record 프로토콜

TCP 프로토콜 사용

전송할 응용 메시지를 다룰 수 있는 크기의 블록으로 단편화
옵션으로 데이터를 압축
MAC 적용
암호화
헤더를 추가
TCP 단편으로 전송

TLS 레코드 프로토콜 제공 서비스

기밀성 : 핸드셰이크에서 TLS 페이로드를 관용 암호화(대칭키 암호화)하는데 쓸 공유 비밀키 정의
메시지 무결성 : 핸드셰이크에서 메시지 인증코드(MAC) 생성하기 위한 공유 비밀키 정의

ChangeCipherSpec 프로토콜

종단 간에 협상된 보안 파라미터를 이후부터 적용/변경함을 알리기 위해 사용하는 프로토콜

Alert 프로토콜

SSL/TLS 통신 과정에서 발생하는 오류를 통보하기 위해 경고할 때 사용

프로토콜 메시지는 2byte로 구성

level(1byte) : 경고(warning) or 심각(fatal)
alert(1byte) : 경고를 나타내는 코드

하트비트 프로토콜

정상적으로 동작한다는 걸 나타내기 위해 또는 시스템 다른 부분과 동기화를 하기 위해 생성하는 주기적 신호

일반적으로 프로토콜 개체의 가용성을 모니터링할 때 사용하는 프로토콜

SSL/TLS 공격

OpenSSL의 HeartBleed 취약점(2014년 4월)

확장 모듈에서 클라이언트 요청 메시지를 처리할 때 데이터 길이 검증을 수행하지 않아

시스템 메모리에 저장된 64KB 크기의 데이터를 아무런 제한 없이 탈취할 수 있는 취약점

노출 가능한 정보 : SSL 서버 비밀키, 세션키, 쿠키 및 개인정보(ID/PW, 이메일 주소 등)

OpenSSL 갱신하거나 하트비트 확장을 사용하지 않는 옵션을 부착해 재컴파일하는 등의 조치 필요

SSL 3.0의 취약점과 POODLE 공격(2014년 10월)

TLS를 사용하고 있다 해도 SSL 3.0으로 다운그레이드 당하여 POODLE 공격을 받을 수 있음

MITM 공격을 통해 암호화되어 송수신되는 쿠키정보나 데이터를 추출하는 공격이 가능

대책은 SSL 3.0을 사용하지 않는 것

FREAK 공격과 암호 수출 규제(2015년 2월)

SSL을 통해 강제로 취약한 RSA로 다운그레이드 시킬 수 있는 취약점 발견

FREAK는 Factoring RSA Export Keys(수출용 RSA 키의 소인수 분해)의 약자

SSL/TLS 서버에 대한 RSA Export Suites라고 불리는 약한 암호 스위트를 사용하게 하는 공격

MITM 공격을 통해 512 비트 RSA로 다운그레이드 시켜 정보 유출

완전 순방향 비밀성(PFS, Perfect Forward Secrecy)

SSL/TLS 통신의 서버 개인키 노출 시 MITM 공격

해결을 위해 등장한 암호학적 성질이 순방향 비밀성(FS) 또는 완전 순방향 비밀성(PFS)

완전 순방향 비밀성 : 이전 트래픽 정보의 기밀성은 그대로 유지되는 암호학적 성질

📍PFS
새로운 세션 키 정보가 수학적으로 예전의 키 정보와 관련이 있어 안정성에는 영향을 미칠 수 없는 성질

HTTPS와 S-HTTP

📍웹 캐시(프락시 서버)
웹 서버 대신 HTTP 요청을 충족시키는 네트워크 개체
브라우저는 사용자의 모든 HTTP 요청이 먼저 프락시 서버에 보내지도록 구성될 수 있음
이렇게 설정되면 객체에 대한 각각의 브라우저 요청들은 가장 먼저 프락시에 보내진다

HTTPS

HTTP + SSL, 현재 모든 웹브라우저에 내장

HTTP는 80번 포트, HTTPS는 443번 포트 사용

기밀성, 클라이언트-서버 인증, 데이터 무결성 제공

암호화 대상 : 요청문서 URL, 문서 내용, 브라우저 양식 내용, 브라우저<>서버 서로 보낸 쿠키, HTTP 헤더 내용

S-HTTP

기존 HTTP에 보안 기능을 추가하기 위해 확장, HTTP로 전송하는 내용을 보호하는 데 중점

S-HTTP는 HTTP 메시지가 암호화 및 서명되어 기존 TCP/IP 망을 통해 전송 (HTTPS는 SSL 터널링 기법 사용)

SHTTP	HTTPS
보안 기능이 추가된 HTTP	HTTP over SSL/TLS
shttp:// 국제 표준	https:// (netscape -> 국제 표준)
대중화X (client page 수정 필요)	대중화
80번 포트	443번 포트

웹서버 보안

IIS 보안 설정

권한 설정

업로드한 파일이 저장되는 폴더에 실행권한을 주었을 경우, webshell이 실행될 수 있어 매우 위험

관리자 페이지 접근 통제

관리자 페이지에 접근하는 IP를 설정하지 않은 상태에서 노출되면 관리자 페이지에 접근할 수 있어 공격 받을 수 있음

메소드 제한

불필요한 메소드 설정(DELETE 등)을 할 경우 주요 자원이 삭제될 수 있어서 GET,POST 제외한 메소드 제거

헤더 정보 숨김

사용자 요청에 의해 서버가 응답 보낼 때 헤더에 포함되는 정보, 기본 값으로 설정하게 되면 서버에 대한 정보가 포함됨

공격자에게 정보 노출을 막기 위해 웹 사이트의 맞춤형 오류 페이지 생성

Apache 보안설정

서버 실행 계정 확인

구 버전의 아파치는 root 권한으로 실행되는 경우가 많음

아파치는 nobody라는 이름 대신 apache라는 별도의 계정을 권한으로 만들어 아파치 웹 프로세스에 대한 권한으로 할당

httpd.conf 파일

ServerType(standalone) : standalone(사용자 요청을 웹 데몬이 직접 받아서 처리) / inetd(사용자 요청을 inetd 데몬이 처리)

Timeout(300) : 서버의 통신 장애로 인해 300초 동안 클라이언트가 완벽한 처리를 못할 때, 클라이언트와의 연결 해제

KeepAlive(On) : 한 번의 요청이 아닌 또 다른 요청을 기다리게 할지 설정

MaxKeepAliveResponse(100) : keepalive 상태에서 처리할 최대 요청 건수

MaxClients(150) : 아파치 서버의 동시 접속자 수 정의

ErrorLog(/usr/local/apache/logs/error_log) : 아파치 서버 접속 에러를 기록할 이름 설정

ServerSignature(On) : 서버 정보를 보여줌 (EMail - 서버 정보와 관리자 이메일을 보여줌)

ServerTokens(ProductOnly) : 서버 정보 표시 제한 설정(productonly - 웹 서버 종류만 표시, minimal, OS, full)

검색엔진 정보 노출 취약점

검색엔진의 성능 향상에 따라 문서파일 내용까지 검색하여 주소록이나 회원정보 등 개인정보 노출 위험성 증가

robot.txt 파일은 웹사이트의 최상위 주소(루트 디렉터리)에 저장해야 함

웹 보안위협 및 대응책

OWASP TOP10(2021년)

A1 - Broken Access Control 취약한 접근 통제

A2 - Cryptographic Failure 암호학적 실패

A3 - Injection 인젝션

A4 - Insecure Design 안전하지 않은 설계 (신규)

A5 - Security Misconfiguration 보안 오류 설정

A6 - Vulnerable and Outdated Components 취약하고 오래된 컴포넌트

A7 - Identification and Authentication Failure 식별 및 인증 실패

A8 - Software and Data Integrity Failure 소프트웨어와 데이터 무결성 실패 (신규)

A9 - Security Logging and Monitoring Failure 보안 로깅과 모니터링 실패

A10 - Server Side Request Forgery 서버 사이드 요청 변조 (신규)

SQL injection

DB와 연동된 웹 응용프로그램에서 입력된 데이터에 대한 유효성 검증을 하지 않을 경우

공격자가 입력 폼 및 URL 입력란에 SQL 문을 삽입하여 DB 열람 조작할 수 있는 보안약점

취약점 판단 방법

큰따옴표, 작은따옴표, 세미콜론을 입력하여 DB에러가 발생하는지 확인
SQL 문에서 where로 입력되는 조건문을 항상 참으로 만들 수 있는 방법

SQL injection 종류

From SQL injection : 쿼리문의 조건을 임의로 조작하여 인증을 우회하는 기법, 항상 참이되도록 where절 조작
Union SQL injection : 한 쿼리의 결과가 다른 쿼리의 결과에 결합하여 공격하는 기법, select문의 필드 갯수/타입 호환
Error-Based SQL injection : DB 쿼리에 대한 에러값을 기반으로 한 단계씩 점진적으로 DB정보 획득
Blind SQL injection : 오류 메시지가 아닌 쿼리 결과의 참거짓을 통해 의도치 않은 SQL문 실행으로 DB 공격
Boolean based SQL injection : DB로부터 특정한 값이나 데이터를 전달받지 않고, 참거짓 정보만 알 수 있을 때 사용

대응 방법

모든 입력값에 대해 적절한 검증절차를 설계하고 구현
SQL 서버의 에러 메시지를 표시하지 않음
최소 권한이 설정된 계정을 사용
SQL 쿼리문을 동적으로 생성해서 실행하지 않도록 함
선처리 질의문

사이트 간 스크립팅 CSS(XSS)

웹사이트에서 입력을 엄격하게 검증하지 않는 취약점을 이용하는 공격

사용자로 위장한 공격자가 웹사이트에 프로그램 코드를 삽입하여

나중에 이 사이트를 방문하는 다른 사용자의 웹 브라우저에서 해당 코드가 실행되도록 하는 것

stored XSS (저장형XSS) : 사용자가 글을 저장할 수 있는 부분에 정상적인 평문이 아닌 스크립트 코드를 입력하는 기법

Reflected XSS (반사형XSS) : HTML 문서로 반사되어 웹브라우저에서 실행

보안대책

사용자가 문자열에 스크립트를 사용하는 것을 막기 위해 &lt, &gt, &amp, &quot로 치환
HTML 태그를 허용하는 게시판에서 지원하는 HTML 태그의 리스트를 선정한 후 해당 태그만 허용하는 방식

사이트 간 요청 위조 CSRF

웹페이지가 웹사이트를 구성하는 방식과 웹사이트가 동작하는데 필요한 기본과정을 공략하는 공격

브라우저에서 사용자 몰래 요청이 일어나게 강제하는 공격

HTTP 트래픽을 변조하지도 않으며 문자나 인코딩 기법을 악의적으로 사용하지도 않음

공격자가 의도한 행위를 사이트가 신뢰하는 인증된 사용자의 권한을 통해 실행하게 하는 취약점

악성 스크립트가 클라이언트에서 실행되는데 반해, CSRF 공격은 사용자가 악성 스크립트를 서버에 요청

보안대책

CSRF 토큰 사용 : 세션별로 CSRF 토큰을 생성하여 세션에 저장하고, 토큰 값을 체크하여 요청의 유효성 검사
사용자와 상호 처리 기능 적용 : CAPTCHA와 같은 사용자와 상호 처리 가능한 기법 적용하여 위조된 요청 차단
재인증 요구 : 중요기능의 경우 재인증을 통해 안전하게 실제 요청여부 확인

직접 객체 참조

접근 통제에 의한 확인이나 다른 보호 조치가 없다면 공격자는 권한 없는 데이터에 접근하기 위해 노출된 참조를 조작

디렉터리 탐색 공격(파일 다운로드 취약점)

경로 조작에 사용될 수 있는 문자를 필터링 하지 않으면,

접근제한 영역에 대한 경로 문자열 구성이 가능해져 시스템 정보누출, 서비스 장애 등을 유발할 수 있는 취약점

디렉터리 탐색은 웹 브라우저에서 확인 가능한 경로의 상위로 탐색하여 특정 시스템 파일을 다운로드 하는 공격 방법

파일 업로드 제한 부재

임의의 파일을 보낼 수 있다는 것은 웹 서버가 가질 수 있는 가장 치명적인 취약점

악의적인 파일을 전송, 원격지에서 파일 실행, 웹 서버를 장악하며 추가 내부 침투 공격 수행할 수 있음

게시판에 첨부파일로 악의적인 파일을 업로드하고 실행시키는 게 일반적 (업로드하는 악성코드는 대부분 웹쉘)

리버스 텔넷(리버스 셸, Reverse Shell)

웹 해킹을 통해 시스템의 권한을 획득한 후 해당 시스템에 텔넷과 같이 직접 명령을 입력

방화벽이 존재하는 시스템을 공격할 때 자주 사용

인바운드 정책은 80번 포트 외 모두 막음, 아웃바운드는 필터링을 수행하지 않은 경우가 많음

보안대책

업로드되어 저장되는 파일의 타입, 개수, 크기, 실행권한 제한
업로드되어 저장되는 파일은 외부에서 식별되지 않아야 함
파일 다운로드 요청 시 요청파일명에 대한 검증작업을 수행해야 함
다운로드 받은 소스코드나 실행파일은 무겨렁 검사를 실행해야 함

보안 설정 취약점

디렉터리 리스팅

웹 서버의 특정 디렉터리를 열면 그 디렉터리에 있는 파일과 목록이 모두 나열되는 것을 의미

httpd.conf 파일의 <Directory "/var/www/html">에서 Options에 있는 Indexes를 삭제해야 함

백업 및 임시 파일 존재

웹 서버에 백업 파일이나 임시 파일을 삭제하지 않은 채 방치하는 경우가 있음

백업 파일 발견하면 웹 애플리케이션의 내부 로직 및 데이터베이스 접속 정보 등 중요한 정보 획득 가능

주석 관리 미흡

프락시를 통해 이용자도 주석을 볼 수 있음

주석에 기록되는 정보에 주의할 필요가 있음

웹 취약점 보안

특수문자 필터링
서버측 통제 적용
지속적인 세션 관리

웹 방화벽

유해 HTTP 차단
애플리케이션 레이어(7계층)
규칙+애플리케이션 로직

소프트웨어 개발 보안

소프트웨어 개발보안 방법론

요구사항 분석
설계
구현
테스트
유지보수

소프트웨어 보안약점 유형

입력데이터 검증 및 표현 : 검증 누락 또는 부적절한 검증, 데이터의 잘못된 형식지정으로 인해 발생할 수 있는 보안 약점
보안 기능 : 인증, 접근제어, 기밀성, 암호화, 권한관리를 적절하지 않게 구현시 발생
시간 및 상태 : 지원하는 병렬시스템, 하나 이상의 프로세스가 동작하는 환경에서 시간 및 상태를 부적절하게 관리하여 발생
에러처리 : 에러를 처리하지 않거나 불충분하게 처리하여 에러정보에 중요 정보가 포함될 때 발생할 수 있는 보안약점
코드오류 : 개발자가 범할 수 있는 코딩오류로 인해 유발되는 보안약점
캡슐화 : 중요한 데이터나 가능성을 불충분하게 캡슐화했을 때 인가되지 않은 사용자에게 데이터 노출 가능
API 오용 : 보안에 취약한 API를 사용하여 발생할 수 있는 보안 약점

저작자표시