웹 구조와 HTTP 보안

4장 1절부터는 세 번째 과목인 어플리케이션보안을 다룹니다.

지금까지는 시스템과 네트워크를 봤습니다.

시스템보안 = 서버와 운영체제를 지키는 영역
네트워크보안 = 데이터가 이동하는 통신 경로를 지키는 영역
어플리케이션보안 = 웹사이트, 앱, API, DB 연동 기능을 지키는 영역

어플리케이션보안은 정보보안기사에서 매우 중요합니다.
특히 실기에서는 아래 주제가 자주 답안형으로 나온다.

SQL Injection
XSS
CSRF
인증과 인가
세션 관리
쿠키 보안
파일 업로드 취약점
접근통제 취약점
시큐어 코딩

이번 절에서는 본격적인 공격기법에 들어가기 전에, 웹의 기본 구조와 HTTP 보안 기초를 정리합니다.

학습 목표

이번 절의 학습 후 다음 질문에 답할 수 있어야 한다.

질문	목표
웹 애플리케이션이란 무엇인가?	브라우저와 서버가 HTTP로 통신하는 서비스라고 설명
클라이언트와 서버의 차이는?	요청하는 쪽과 응답하는 쪽으로 구분
HTTP의 특징은?	요청·응답 구조, 무상태 프로토콜이라고 설명
GET과 POST의 차이는?	조회 중심과 데이터 전송 중심으로 구분
쿠키와 세션은 왜 필요한가?	로그인 상태 유지를 위해 필요하다고 설명
인증과 인가의 차이는?	인증은 신원 확인, 인가는 권한 확인
HTTP 상태코드는 무엇인가?	서버 응답 결과를 숫자로 표현한다고 설명
HTTPS는 왜 필요한가?	통신 암호화, 무결성, 서버 인증을 위해 필요
웹 로그는 왜 중요한가?	공격 탐지와 침해사고 분석에 활용된다고 설명

어플리케이션보안의 큰 그림

어플리케이션보안은 사용자가 직접 이용하는 서비스의 보안을 다룹니다.

예를 들어 다음과 같은 서비스가 있습니다.

쇼핑몰
인터넷뱅킹
회사 그룹웨어
관리자 페이지
게시판
로그인 시스템
모바일 앱 API
예약 시스템
결제 시스템

이런 서비스에는 보통 다음 기능이 있습니다.

기능	보안 이슈
로그인	인증 우회, 비밀번호 공격
회원가입	개인정보 수집, 입력값 검증
게시판	XSS, 파일 업로드 취약점
검색	SQL Injection
결제	요청 변조, 재전송 공격
관리자 페이지	접근통제 취약점
API	인증 토큰 탈취, 권한 검증 누락
DB 연동	데이터 유출, SQL Injection

어플리케이션보안의 핵심 질문은 다음입니다.

사용자 입력값을 신뢰해도 되는가?
로그인한 사용자가 정말 그 사람인가?
그 사용자가 해당 기능을 사용할 권한이 있는가?
중요 정보가 암호화되어 전송되는가?
세션과 쿠키가 안전하게 관리되는가?
웹 서버와 DB가 불필요한 정보를 노출하지 않는가?

웹 서비스의 기본 구조

웹 서비스는 보통 다음 흐름으로 동작합니다.

사용자 브라우저
→ 인터넷
→ 웹 서버
→ 애플리케이션 서버
→ DB 서버
→ 응답 반환

조금 더 자세히 보면 다음과 같습니다.

구성요소	역할
클라이언트	사용자의 브라우저 또는 앱
웹 서버	HTTP 요청을 받고 정적 파일 또는 애플리케이션으로 전달
WAS	로그인, 검색, 결제 같은 동적 로직 처리
DB 서버	회원정보, 게시글, 주문정보 등 데이터 저장
WAF	웹 공격 요청 탐지·차단
로드밸런서	여러 서버로 트래픽 분산
CDN	정적 콘텐츠를 분산 제공

예를 들어 사용자가 로그인하면 다음 흐름이 발생합니다.

1. 사용자가 로그인 화면에서 아이디와 비밀번호 입력
2. 브라우저가 서버로 HTTP 요청 전송
3. 서버가 입력값을 확인
4. DB에서 사용자 계정 정보 조회
5. 인증 성공 시 세션 생성
6. 브라우저에 세션 쿠키 전달
7. 이후 요청마다 쿠키를 보내 로그인 상태 유지

이 흐름 안에 어플리케이션보안의 핵심이 거의 다 들어 있습니다.

클라이언트와 서버

클라이언트

클라이언트는 요청을 보내는 쪽입니다.

예시는 다음입니다.

웹 브라우저
모바일 앱
API 호출 프로그램
사용자 PC

클라이언트는 보통 사용자가 직접 조작할 수 있습니다.

그래서 보안상 중요한 원칙이 있습니다.

클라이언트 입력값은 신뢰하면 안 된다.

왜냐하면 사용자는 브라우저 개발자 도구나 프록시 도구 등을 이용해 요청 값을 바꿀 수 있기 때문입니다.
따라서 서버는 클라이언트에서 들어온 값을 반드시 검증해야 합니다.

서버

서버는 요청을 처리하고 응답하는 쪽입니다.

서버는 다음 역할을 합니다.

로그인 처리
권한 확인
DB 조회
결제 처리
파일 업로드 처리
응답 생성
로그 기록

중요한 보안 원칙은 다음입니다.

중요한 검증은 반드시 서버에서 수행해야 한다.

예를 들어 가격, 권한, 사용자 ID, 결제 금액 같은 값을 클라이언트가 보냈다고 그대로 믿으면 안 됩니다.

HTTP란?

HTTP는 HyperText Transfer Protocol입니다.

시험식 정의는 다음입니다.

HTTP는 웹에서 클라이언트와 서버가 요청과 응답을 주고받기 위한 응용 계층 프로토콜이다.

핵심 의미는 다음과 같다.

HTTP = 브라우저와 웹 서버가 대화하는 규칙

HTTP의 기본 구조는 단순합니다.

클라이언트가 요청한다.
서버가 응답한다.

예를 들어 사용자가 웹페이지에 접속하면

브라우저: /login 페이지 요청
서버: 여기 로그인 페이지입니다.

HTTP의 핵심 특징

HTTP의 중요한 특징은 다음입니다.

특징	설명
요청·응답 구조	클라이언트 요청에 서버가 응답
무상태	이전 요청 상태를 자동으로 기억하지 않음
응용 계층 프로토콜	OSI 7계층에 해당
기본 포트 80	HTTP 기본 포트
평문 통신	암호화가 없으면 도청·변조 위험
확장성	헤더, 쿠키, 메서드 등을 통해 다양한 기능 제공

가장 중요한 것은 무상태입니다.

HTTP는 무상태 프로토콜이다.

무상태란 서버가 각 요청을 독립적으로 처리하며, 이전 요청을 자동으로 기억하지 않는다는 뜻입니다.

그래서 로그인 상태를 유지하기 위해 쿠키와 세션이 필요합니다.

HTTP 요청 구조

HTTP 요청은 보통 다음 요소로 구성됩니다.

요청 라인
헤더
본문

예시는 다음과 같습니다.

POST /login HTTP/1.1
Host: example.com
User-Agent: Chrome
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=abc123

id=user01&password=pass1234

각 항목의 의미는 다음입니다.

항목	의미
POST	HTTP 메서드
/login	요청 경로
HTTP/1.1	HTTP 버전
Host	요청 대상 서버
User-Agent	클라이언트 정보
Content-Type	전송 데이터 형식
Cookie	클라이언트가 보내는 쿠키
Body	실제 전송 데이터

보안 관점에서는 요청의 모든 부분이 중요합니다.

URL
Query String
Header
Cookie
Body
File Upload

공격자는 이 모든 영역에 악의적인 값을 넣을 수 있습니다.

HTTP 응답 구조

HTTP 응답은 보통 다음 요소로 구성됩니다.

상태 라인
헤더
본문

예시는 다음과 같습니다.

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionid=abc123; HttpOnly; Secure

<html>
로그인 성공
</html>

각 항목의 의미는 다음입니다.

항목	의미
200 OK	응답 상태코드
Content-Type	응답 데이터 형식
Set-Cookie	서버가 브라우저에 쿠키 저장 지시
Body	HTML, JSON 등 실제 응답 내용

보안 관점에서 중요한 응답 요소는 다음입니다.

상태코드
Set-Cookie
보안 헤더
오류 메시지
응답 본문

예를 들어 오류 메시지에 DB 쿼리나 서버 경로가 노출되면 공격자가 시스템 구조를 파악할 수 있습니다.

HTTP 메서드

HTTP 메서드는 클라이언트가 서버에 어떤 작업을 요청하는지 나타냅니다.

메서드	의미	보안상 주의
GET	데이터 조회	민감정보를 URL에 넣지 않기
POST	데이터 전송, 등록, 처리	입력값 검증 필요
PUT	전체 수정 또는 업로드	인증·권한 검증 필요
PATCH	일부 수정	권한 검증 필요
DELETE	삭제	강한 인증·인가 필요
HEAD	헤더만 조회	정보 노출 주의
OPTIONS	지원 메서드 확인	불필요한 메서드 노출 제한

정보보안기사에서는 특히 GET과 POST를 많이 봅니다.

GET과 POST 비교

구분	GET	POST
주 용도	조회	데이터 전송, 등록, 처리
데이터 위치	URL Query String	요청 본문
노출성	URL, 로그, 브라우저 기록에 남기 쉬움	URL에는 덜 노출
캐싱	캐싱될 수 있음	일반적으로 캐싱 부적합
민감정보 전송	부적절	HTTPS와 함께 사용 필요
예시	게시글 조회, 검색	로그인, 회원가입, 결제

중요한 점은 다음입니다.

POST라고 해서 자동으로 안전한 것은 아니다.
민감정보 전송에는 반드시 HTTPS가 필요하다.

실기형 답안

GET은 주로 데이터 조회에 사용되며 요청 데이터가 URL에 포함될 수 있어 민감정보 전송에 부적절하다. POST는 요청 본문에 데이터를 포함하여 전송이나 등록 처리에 사용되지만, 암호화가 보장되는 것은 아니므로 로그인 정보나 개인정보 전송 시 HTTPS를 적용해야 한다.

Query String과 Body

Query String

Query String은 URL 뒤에 붙는 파라미터입니다.

예

/search?keyword=security&page=1

여기서

keyword=security
page=1

이 부분이 Query String입니다.

보안상 주의할 점은 다음입니다.

URL에 민감정보를 넣으면 로그, 브라우저 기록, 프록시 기록 등에 남을 수 있다.

나쁜 예

/login?id=user01&password=1234

비밀번호가 URL에 노출되므로 부적절합니다.

Body

Body는 요청 본문입니다.
POST, PUT, PATCH 요청에서 많이 사용됩니다.

예

{
  "id": "user01",
  "password": "pass1234"
}

하지만 Body에 넣는다고 자동으로 안전한 것은 아닙니다.

HTTP라면 Body도 평문으로 전송될 수 있다.

따라서 민감정보는 HTTPS로 전송해야 합니다.

HTTP 상태코드

HTTP 상태코드는 서버가 요청을 어떻게 처리했는지 숫자로 알려줍니다.

범위	의미
1xx	정보 응답
2xx	성공
3xx	리다이렉션
4xx	클라이언트 오류
5xx	서버 오류

자주 나오는 상태코드는 다음입니다.

코드	의미	보안 관점
200	OK, 정상 처리	정상 응답
301	영구 이동	리다이렉션
302	임시 이동	로그인 후 이동 등
400	잘못된 요청	입력값 오류
401	인증 필요	로그인 필요
403	접근 금지	권한 없음
404	찾을 수 없음	존재하지 않는 경로
500	서버 내부 오류	상세 오류 노출 주의
503	서비스 이용 불가	장애, DDoS 가능성

시험과 실무에서 특히 중요한 것은 다음입니다.

401 = 인증 필요
403 = 권한 없음
404 = 없음
500 = 서버 오류

401과 403의 차이는 자주 헷갈립니다.

코드	의미
401	인증이 필요하거나 인증 실패
403	인증은 되었지만 접근 권한 없음

HTTP 헤더

HTTP 헤더는 요청이나 응답에 대한 부가 정보를 담습니다.

대표 헤더는 다음입니다.

헤더	의미
Host	요청 대상 도메인
User-Agent	클라이언트 프로그램 정보
Referer	이전 페이지 주소
Cookie	클라이언트가 서버에 보내는 쿠키
Set-Cookie	서버가 클라이언트에 쿠키 저장 지시
Content-Type	데이터 형식
Authorization	인증 정보 또는 토큰
X-Forwarded-For	프록시 뒤의 원래 클라이언트 IP 정보

보안상 헤더는 공격자가 조작할 수 있습니다.

User-Agent 조작
Referer 조작
X-Forwarded-For 조작
Authorization 토큰 탈취
Cookie 탈취

따라서 서버는 헤더 값을 무조건 신뢰하면 안 됩니다.

웹 보안 헤더 기초

웹 보안 헤더는 브라우저에게 보안 동작을 지시하는 응답 헤더입니다.

보안 헤더	역할
Secure Cookie	HTTPS에서만 쿠키 전송
HttpOnly Cookie	JavaScript에서 쿠키 접근 제한
SameSite Cookie	CSRF 위험 감소
HSTS	HTTPS 접속 강제
CSP	허용된 스크립트만 실행하도록 제한
X-Frame-Options	클릭재킹 방지
X-Content-Type-Options	MIME 타입 혼동 방지

이번 절에서는 쿠키 관련 속성 3개를 우선 기억하면 됩니다.

HttpOnly
Secure
SameSite

쿠키

쿠키란?

쿠키는 서버가 클라이언트 브라우저에 저장하도록 하는 작은 데이터입니다.

시험식 정의는 다음입니다.

쿠키는 서버가 클라이언트 브라우저에 저장하도록 전달하는 작은 데이터로, 이후 요청 시 브라우저가 서버로 함께 전송하여 사용자 식별이나 상태 유지에 활용된다.

예

Set-Cookie: sessionid=abc123

브라우저는 이후 요청에 쿠키를 포함한다.

Cookie: sessionid=abc123

쿠키의 용도

용도	설명
세션 ID 저장	로그인 상태 유지
사용자 설정	언어, 테마
장바구니	쇼핑몰 장바구니 정보
추적	방문 이력, 분석

보안상 가장 중요한 것은 세션 쿠키입니다.

세션 쿠키가 탈취되면 공격자가 로그인한 사용자처럼 행동할 수 있습니다.

쿠키 보안 속성

속성	의미	효과
HttpOnly	JavaScript에서 쿠키 접근 제한	XSS로 인한 쿠키 탈취 완화
Secure	HTTPS 통신에서만 쿠키 전송	평문 전송 방지
SameSite	다른 사이트 요청 시 쿠키 전송 제한	CSRF 완화
Expires / Max-Age	쿠키 유효기간 설정	장기 쿠키 위험 감소
Path / Domain	쿠키 적용 범위 제한	불필요한 전송 제한

실기형 답안

세션 쿠키 보호를 위해 HttpOnly 속성으로 스크립트 접근을 제한하고, Secure 속성으로 HTTPS에서만 전송되도록 설정해야 한다. 또한 SameSite 속성을 적용하여 다른 사이트에서 발생한 요청에 쿠키가 자동 전송되는 것을 제한함으로써 CSRF 위험을 줄일 수 있다.

세션

세션이란?

세션은 서버가 사용자의 상태를 관리하기 위해 생성하는 정보입니다.

시험식 정의는 다음입니다.

세션은 서버가 사용자별 상태를 유지하기 위해 생성·관리하는 정보이며, 일반적으로 클라이언트는 세션 ID를 쿠키로 전달하여 서버가 사용자를 식별한다.

로그인 흐름은 다음과 같습니다.

1. 사용자가 로그인 정보를 입력한다.
2. 서버가 인증을 수행한다.
3. 인증 성공 시 서버가 세션을 생성한다.
4. 서버가 세션 ID를 쿠키로 전달한다.
5. 브라우저는 이후 요청마다 세션 ID를 전송한다.
6. 서버는 세션 ID를 확인해 사용자 상태를 유지한다.

쿠키와 세션 비교

구분	쿠키	세션
저장 위치	클라이언트 브라우저	서버
역할	상태 정보나 식별자 저장	사용자 상태 관리
보안성	상대적으로 낮음	상대적으로 높음
위험	탈취, 변조	세션 탈취, 세션 고정
예시	sessionid 쿠키	서버의 로그인 상태 정보

한 줄 정리

쿠키는 클라이언트에 저장되고, 세션은 서버에서 사용자 상태를 관리한다.

세션 관리 보안

세션 관리는 실기에서 중요합니다.

주요 보안 대책은 다음입니다.

대책	설명
예측 불가능한 세션 ID	난수성 높은 세션 ID 사용
로그인 후 세션 재발급	세션 고정 공격 방지
세션 타임아웃	장시간 미사용 세션 만료
로그아웃 시 세션 폐기	서버 측 세션 무효화
HTTPS 적용	세션 ID 도청 방지
HttpOnly·Secure·SameSite	쿠키 보안 속성 적용
중요 기능 재인증	비밀번호 변경, 결제 등에서 추가 인증
동시 접속 관리	이상 접속 탐지
IP·기기 변경 탐지	세션 탈취 가능성 확인

실기형 답안

세션 보안을 위해 예측 불가능한 세션 ID를 사용하고, 로그인 성공 후 세션 ID를 재발급하여 세션 고정 공격을 방지해야 한다. 또한 HTTPS, HttpOnly·Secure·SameSite 쿠키 설정, 세션 타임아웃, 로그아웃 시 세션 폐기, 중요 기능 재인증 등을 적용해야 한다.

인증

인증이란?

인증은 사용자가 누구인지 확인하는 절차입니다.

시험식 정의

인증은 사용자가 주장하는 신원이 실제로 맞는지 확인하는 절차이다.

핵심 의미

인증 = 너 누구야?

인증 수단은 다음과 같습니다.

유형	예시
지식 기반	비밀번호, PIN
소유 기반	OTP, 보안카드, 인증서, 토큰
생체 기반	지문, 얼굴, 홍채
위치·행위 기반	접속 위치, 행동 패턴

다중인증, MFA

MFA는 Multi-Factor Authentication입니다.

서로 다른 인증 요소를 2개 이상 사용하는 방식입니다.

예

비밀번호 + OTP
비밀번호 + 인증서
비밀번호 + 지문

시험식 표현

MFA는 지식, 소유, 생체 등 서로 다른 인증 요소를 2개 이상 결합하여 계정 탈취 위험을 줄이는 인증 방식이다.

인가

인가란?

인가는 인증된 사용자가 어떤 자원이나 기능에 접근할 수 있는지 결정하는 과정입니다.

시험식 정의

인가는 인증된 사용자가 허용된 권한 범위 내에서 자원이나 기능에 접근할 수 있도록 통제하는 절차이다.

핵심 의미

인가 = 너 이거 해도 돼?

예를 들어 사용자가 로그인했습니다.

사용자	접근 가능 기능
일반 사용자	본인 정보 조회
관리자	전체 회원 관리
감사자	로그 조회
결제 담당자	환불 처리

인증과 인가를 구분해야 합니다.

구분	인증	인가
질문	너는 누구인가?	너는 무엇을 할 수 있는가?
시점	로그인 시	기능 접근 시
예시	ID/PW 확인	관리자 페이지 접근 허용
실패 결과	로그인 실패	권한 없음, 403

접근통제 취약점 기초

웹에서 자주 발생하는 문제가 “로그인은 했지만 권한 검사가 제대로 되지 않는 상황”이다.

예를 들어 일반 사용자가 아래 URL에 접근한다고 합시다.

/admin/users

서버가 관리자 권한을 확인하지 않으면 일반 사용자도 관리자 기능을 사용할 수 있습니다.

또 다른 예

/user/profile?id=100
/user/profile?id=101

사용자 ID만 바꿨는데 다른 사람 정보를 볼 수 있다면 접근통제 취약점입니다.

보안 원칙은 다음입니다.

서버는 모든 요청마다 인증과 인가를 확인해야 한다.

실기형 답안

웹 애플리케이션은 로그인 여부뿐 아니라 사용자가 해당 자원이나 기능에 접근할 권한이 있는지 서버 측에서 매 요청마다 검증해야 한다. 권한 검증이 누락되면 일반 사용자가 관리자 기능이나 타인의 개인정보에 접근하는 접근통제 취약점이 발생할 수 있다.

HTTPS와 TLS

HTTPS란?

HTTPS는 HTTP에 TLS를 적용한 보안 통신입니다.

시험식 정의

HTTPS는 TLS를 이용하여 HTTP 통신을 암호화함으로써 클라이언트와 서버 간 데이터의 기밀성, 무결성, 서버 인증을 제공하는 프로토콜이다.

기본 포트

HTTPS = 443

HTTPS가 제공하는 보안 효과

보안 효과	설명
기밀성	통신 내용을 암호화하여 도청 방지
무결성	전송 중 데이터 변조 탐지
서버 인증	인증서를 통해 접속 서버 신원 확인

로그인, 결제, 개인정보 처리에는 HTTPS가 필수입니다.

HTTPS만으로 충분한가?

중요한 점은 다음입니다.

HTTPS는 통신 구간을 보호하지만, 웹 애플리케이션 취약점 자체를 없애지는 않는다.

예를 들어 HTTPS를 사용해도 다음 공격은 가능할 수 있습니다.

SQL Injection
XSS
CSRF
접근통제 취약점
파일 업로드 취약점
취약한 비밀번호 정책

따라서 HTTPS는 필수지만, 이것만으로 웹 보안이 완성되지는 않습니다.

실기형 답안

HTTPS는 TLS를 통해 통신 구간의 도청과 변조를 방지하고 서버 인증을 제공한다. 그러나 SQL Injection, XSS, 접근통제 취약점 같은 애플리케이션 내부 취약점까지 제거하는 것은 아니므로 입력값 검증, 권한 검증, 세션 보호, WAF 등 추가 보안 대책이 필요하다.

웹 로그

웹 로그란?

웹 로그는 웹 서버가 클라이언트 요청과 서버 응답을 기록한 로그입니다.

웹 로그에는 보통 다음 정보가 포함됩니다.

접속 IP
접속 시간
HTTP 메서드
요청 URL
상태코드
응답 크기
User-Agent
Referer

예시는 다음과 같습니다.

203.0.113.10 "GET /login HTTP/1.1" 200
203.0.113.20 "POST /admin/login HTTP/1.1" 403
203.0.113.30 "GET /search?q=test HTTP/1.1" 200

웹 로그로 확인할 수 있는 것

확인 항목	의미
접속 IP	누가 접속했는가
요청 시간	언제 접속했는가
URL	어떤 자원에 접근했는가
메서드	조회인지 전송인지
상태코드	성공, 실패, 권한 없음, 서버 오류
User-Agent	브라우저 또는 자동화 도구 여부
Referer	어느 페이지에서 왔는가
요청 빈도	공격성 대량 요청 여부

웹 로그 이상 징후

로그 징후	의심 가능한 공격
`/admin`, `/manager`, `/phpmyadmin` 반복 접근	관리자 페이지 탐색
404 요청이 대량 발생	디렉터리 스캔, 취약점 탐색
403 요청이 대량 발생	권한 없는 접근 시도
로그인 실패 반복	무차별 대입 공격
동일 URL에 과도한 요청	HTTP Flood
긴 Query String 또는 특수문자 포함 요청	Injection 시도 가능
스크립트 태그 형태 입력	XSS 시도 가능
파일 업로드 URL 반복 접근	웹셸 업로드 시도 가능
비정상 User-Agent	자동화 도구, 봇 가능성

실기형 답안

웹 로그는 접속 IP, 요청 URL, HTTP 메서드, 상태코드, User-Agent 등을 기록하므로 웹 공격 탐지와 침해사고 분석에 활용된다. 예를 들어 관리자 페이지 반복 접근, 로그인 실패 증가, 404·403 응답 급증, 특수문자가 포함된 요청, 동일 URL 대량 요청 등은 취약점 탐색이나 공격 시도로 의심할 수 있다.

오류 메시지와 정보 노출

웹 애플리케이션은 오류가 발생했을 때 너무 자세한 정보를 보여주면 위험합니다.

나쁜 오류 메시지 예

SQL syntax error near 'SELECT * FROM users'
/var/www/html/app/login.php line 37
Database user: root

이런 정보는 공격자에게 힌트를 줍니다.

노출 정보	위험
DB 오류	SQL Injection 공격 힌트
서버 경로	시스템 구조 노출
프레임워크 버전	알려진 취약점 검색 가능
계정명	계정 공격에 활용
내부 IP	내부망 구조 파악

보안 원칙은 다음입니다.

사용자에게는 일반 오류 메시지만 보여주고, 상세 오류는 서버 로그에 기록한다.

실기형 답안

웹 애플리케이션의 상세 오류 메시지는 DB 구조, 서버 경로, 프레임워크 버전 등 내부 정보를 노출하여 공격자가 취약점을 파악하는 데 악용될 수 있다. 따라서 사용자에게는 일반화된 오류 메시지를 제공하고, 상세 오류 내용은 서버 로그에만 기록하여 관리자만 확인하도록 해야 한다.

입력값 검증 기초

웹 보안의 핵심은 입력값 검증입니다.

공격자는 입력 가능한 모든 곳에 악의적인 값을 넣을 수 있습니다.

로그인 폼
검색창
댓글
게시글 제목
파일명
쿠키
HTTP 헤더
API 파라미터
URL Query String

입력값 검증의 기본 원칙은 다음입니다.

원칙	설명
서버 측 검증	클라이언트 검증만 믿지 않음
허용목록 방식	허용된 문자와 형식만 통과
길이 제한	과도하게 긴 입력 차단
형식 검증	이메일, 전화번호, 숫자 등 형식 확인
특수문자 처리	문맥에 맞게 인코딩 또는 이스케이프
파일 업로드 검증	확장자, MIME, 크기, 저장 경로 점검

이번 절에서는 개념만 기억하면 됩니다.

클라이언트 입력값은 신뢰하지 말고 서버에서 검증한다.

학습 내용 연결 정리

사용자가 쇼핑몰에 로그인하고 상품을 구매한다고 가정해봅시다.

1. 브라우저가 로그인 요청을 보낸다.
2. HTTP 요청에는 메서드, URL, 헤더, 쿠키, Body가 포함된다.
3. 서버는 입력값을 검증한다.
4. 서버는 사용자를 인증한다.
5. 인증 성공 시 세션을 생성한다.
6. 세션 ID를 쿠키로 전달한다.
7. 이후 사용자는 세션 쿠키로 로그인 상태를 유지한다.
8. 결제 요청 시 서버는 인가를 확인한다.
9. HTTPS로 민감정보를 암호화해 전송한다.
10. 모든 요청과 응답은 웹 로그에 기록된다.

이 과정에서 보안상 중요한 점은 다음입니다.

GET으로 비밀번호를 보내면 안 된다.
민감정보는 HTTPS로 전송해야 한다.
쿠키에는 HttpOnly, Secure, SameSite를 적용해야 한다.
서버는 인증과 인가를 매번 확인해야 한다.
입력값은 서버에서 검증해야 한다.
상세 오류 메시지를 사용자에게 보여주면 안 된다.
웹 로그를 분석해 공격 징후를 확인해야 한다.

시험에 나오는 포인트

이번 절 내용 중 필기와 실기에서 중요한 포인트입니다.

주제	시험 포인트
HTTP	웹 요청·응답 프로토콜
HTTP 무상태	이전 요청 상태를 자동 기억하지 않음
쿠키·세션	상태 유지와 로그인 관리에 사용
GET	조회 중심, URL에 데이터 노출 가능
POST	데이터 전송 중심, HTTPS 필요
Query String	URL 파라미터, 민감정보 포함 부적절
상태코드 401	인증 필요
상태코드 403	권한 없음
상태코드 404	자원 없음
상태코드 500	서버 오류
쿠키	클라이언트 저장
세션	서버 측 상태 관리
HttpOnly	스크립트 쿠키 접근 제한
Secure	HTTPS에서만 쿠키 전송
SameSite	CSRF 완화
인증	신원 확인
인가	권한 확인
HTTPS	TLS 기반 암호화 통신
웹 로그	공격 탐지와 사고 분석
오류 메시지	상세 정보 노출 제한
입력값 검증	서버 측 검증, 허용목록 방식

필기형 문제풀이

문제 1

HTTP의 특징으로 가장 적절한 것은?

A. 운영체제 파일 권한을 변경하는 프로토콜이다
B. 웹에서 클라이언트와 서버가 요청과 응답을 주고받는 프로토콜이다
C. IP 주소를 MAC 주소로 변환한다
D. 사용자의 로그인 상태를 서버가 자동으로 영구 저장하는 프로토콜이다

정답: B

HTTP는 웹에서 클라이언트와 서버가 요청과 응답을 주고받기 위한 응용 계층 프로토콜입니다.

문제 2

HTTP가 무상태 프로토콜이라는 의미로 적절한 것은?

A. 모든 요청 상태를 서버가 자동으로 기억한다
B. 쿠키 없이도 로그인 상태가 항상 유지된다
C. 이전 요청 상태를 자동으로 기억하지 않는다
D. 세션 저장소가 필요 없다는 뜻이다

정답: C

HTTP는 기본적으로 각 요청을 독립적으로 처리하므로 상태 유지를 위해 쿠키와 세션이 필요합니다.

문제 3

GET 방식의 보안상 주의점으로 적절한 것은?

A. POST보다 항상 안전하므로 민감정보 전송에 적합하다
B. HTTPS를 사용하면 URL 기록 노출 위험이 모두 사라진다
C. 주로 로그인 세션 정보를 서버에 저장하는 방식이다
D. 요청 데이터가 URL에 포함될 수 있어 민감정보 전송에 부적절하다

정답: D

GET 요청의 Query String은 URL, 로그, 브라우저 기록 등에 남을 수 있으므로 비밀번호 같은 민감정보 전송에 부적절합니다.

문제 4

POST 방식에 대한 설명으로 적절한 것은?

A. 요청 데이터가 반드시 URL Query String에만 포함된다
B. 무조건 암호화되므로 HTTPS가 필요 없다
C. 데이터가 요청 본문에 포함될 수 있다
D. 서버가 요청 상태를 자동으로 계속 기억한다

정답: C

POST는 데이터를 요청 본문에 포함할 수 있지만, 암호화를 위해서는 HTTPS가 필요합니다.

문제 5

401 상태코드의 의미로 적절한 것은?

A. 인증 필요 또는 인증 실패
B. 권한은 있지만 파일 없음
C. 서버가 정상 처리
D. 영구 이동

정답: A

401은 인증이 필요하거나 인증에 실패했음을 의미합니다.

문제 6

403 상태코드의 의미로 적절한 것은?

A. 서버 내부 오류
B. 접근 권한 없음
C. 정상 처리
D. 임시 이동

정답: B

403은 인증 여부와 별개로 해당 자원에 접근할 권한이 없음을 의미합니다.

문제 7

쿠키에 대한 설명으로 적절한 것은?

A. 반드시 서버 메모리에만 저장된다
B. 세션 ID와 무관하게 항상 전송되지 않는다
C. HTTP 요청 본문을 암호화하는 방식이다
D. 클라이언트 브라우저에 저장될 수 있는 데이터이다

정답: D

쿠키는 클라이언트 브라우저에 저장되는 데이터입니다.

문제 8

세션에 대한 설명으로 적절한 것은?

A. 브라우저에만 영구 저장되는 로그인 정보이다
B. 쿠키 값을 암호화하면 자동으로 생성되는 DB 백업이다
C. 서버가 사용자 상태를 관리하기 위해 사용하는 정보이다
D. HTTP 요청의 URL 길이를 제한하는 속성이다

정답: C

세션은 서버가 사용자 상태를 유지하기 위해 관리하는 정보입니다.

문제 9

HttpOnly 쿠키 속성의 목적은?

A. JavaScript에서 쿠키에 접근하는 것을 제한한다
B. HTTP를 Telnet으로 변경한다
C. 쿠키가 모든 사이트의 요청에 항상 포함되도록 허용한다
D. 쿠키를 HTTPS가 아닌 평문 HTTP에서도 전송하게 한다

정답: A

HttpOnly는 XSS로 인한 쿠키 탈취 위험을 줄이는 데 도움이 됩니다.

문제 10

Secure 쿠키 속성의 설명으로 적절한 것은?

A. HTTPS 통신에서만 쿠키가 전송되도록 한다
B. 쿠키를 항상 평문으로 전송한다
C. 쿠키를 모든 도메인에 무조건 전송한다
D. 쿠키 유효기간을 무한대로 만든다

정답: A

Secure 속성은 쿠키가 HTTPS 연결에서만 전송되도록 합니다.

문제 11

인증과 인가의 차이로 올바른 것은?

A. 인증은 신원 확인, 인가는 권한 확인이다
B. 인증은 권한 확인, 인가는 신원 확인이다
C. 둘은 완전히 같은 의미이다
D. 인증은 암호화, 인가는 압축이다

정답: A

인증은 사용자가 누구인지 확인하는 것이고, 인가는 해당 사용자가 무엇을 할 수 있는지 확인하는 것입니다.

문제 12

HTTPS의 보안 효과로 적절하지 않은 것은?

A. 통신 내용 암호화
B. 전송 중 변조 탐지
C. 서버 인증
D. SQL Injection 취약점 자동 제거

정답: D

HTTPS는 통신 구간을 보호하지만 SQL Injection 같은 애플리케이션 취약점을 자동으로 제거하지는 않습니다.

실기형 답안 훈련

실기 예제 1

문제: HTTP의 무상태 특성과 쿠키·세션이 필요한 이유를 설명하시오.

좋은 답안

HTTP는 각 요청을 독립적으로 처리하며 이전 요청 상태를 자동으로 기억하지 않는 무상태 프로토콜이다. 따라서 로그인 상태와 사용자 식별 정보를 유지하기 위해 쿠키와 세션을 사용하며, 일반적으로 서버는 세션을 생성하고 클라이언트는 세션 ID를 쿠키로 전송한다.

채점 포인트

요소	포함 여부
HTTP는 무상태	필수
이전 요청 상태를 기억하지 않음	필수
로그인 상태 유지	중요
쿠키와 세션 사용	필수
세션 ID	좋음

실기 예제 2

문제: GET과 POST의 차이와 보안상 주의점을 설명하시오.

좋은 답안

GET은 주로 데이터 조회에 사용되며 요청 데이터가 URL에 포함될 수 있어 브라우저 기록이나 로그에 남기 쉽기 때문에 민감정보 전송에 부적절하다. POST는 요청 본문에 데이터를 포함하여 전송이나 등록 처리에 사용되지만, 암호화가 보장되는 것은 아니므로 로그인 정보나 개인정보 전송 시 HTTPS를 적용해야 한다.

채점 포인트

요소	포함 여부
GET = 조회	필요
URL 노출	필수
민감정보 부적절	필수
POST = Body 전송	필요
HTTPS 필요	중요

실기 예제 3

문제: 쿠키 보안 속성 HttpOnly, Secure, SameSite를 설명하시오.

좋은 답안

HttpOnly는 JavaScript에서 쿠키에 접근하지 못하도록 하여 XSS로 인한 쿠키 탈취 위험을 줄인다. Secure는 HTTPS 통신에서만 쿠키가 전송되도록 하며, SameSite는 다른 사이트에서 발생한 요청에 쿠키가 자동 전송되는 것을 제한하여 CSRF 위험을 완화한다.

채점 포인트

요소	포함 여부
HttpOnly = 스크립트 접근 제한	필수
Secure = HTTPS에서만 전송	필수
SameSite = 타 사이트 요청 제한	필수
XSS 완화	중요
CSRF 완화	중요

실기 예제 4

문제: 인증과 인가의 차이를 설명하시오.

좋은 답안

인증은 사용자가 주장하는 신원이 실제로 맞는지 확인하는 절차로, 로그인, OTP, 인증서 등이 예시이다. 인가는 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 확인하는 절차로, 관리자 페이지 접근 허용 여부나 타인 정보 조회 제한 등이 예시이다.

채점 포인트

요소	포함 여부
인증 = 신원 확인	필수
인가 = 권한 확인	필수
인증 예시	좋음
인가 예시	좋음

실기 예제 5

문제: HTTPS의 필요성과 한계를 설명하시오.

좋은 답안

HTTPS는 TLS를 이용해 클라이언트와 서버 간 통신을 암호화하여 도청과 변조를 방지하고, 인증서를 통해 서버 신원을 확인할 수 있게 한다. 그러나 SQL Injection, XSS, 접근통제 취약점과 같은 애플리케이션 내부 취약점을 자동으로 제거하지는 못하므로 입력값 검증, 권한 검증, 세션 보호 등 추가 보안 대책이 필요하다.

채점 포인트

요소	포함 여부
TLS 암호화	필수
도청·변조 방지	중요
서버 인증	중요
웹 취약점 자동 제거 아님	필수
추가 대책 필요	중요

실기 예제 6

문제: 웹 로그가 침해사고 분석에 중요한 이유를 설명하시오.

좋은 답안

웹 로그는 접속 IP, 요청 시간, HTTP 메서드, 요청 URL, 상태코드, User-Agent 등을 기록하므로 공격 시점과 공격 경로, 피해 범위를 분석하는 데 활용된다. 관리자 페이지 반복 접근, 로그인 실패 증가, 404·403 응답 급증, 특수문자 포함 요청, 동일 URL 대량 요청 등은 웹 공격 징후로 의심할 수 있다.

채점 포인트

요소	포함 여부
접속 IP·URL·상태코드	필요
공격 시점 분석	중요
공격 경로 분석	중요
이상 징후 예시	좋음
침해사고 분석 활용	필수

핵심 요약

개념	한 줄 요약
웹 애플리케이션	브라우저와 서버가 HTTP로 통신하는 서비스
클라이언트	요청을 보내는 쪽
서버	요청을 처리하고 응답하는 쪽
HTTP	웹 요청·응답 프로토콜
무상태	이전 요청 상태를 자동으로 기억하지 않음
GET	조회 중심, URL에 데이터 포함 가능
POST	요청 본문에 데이터 전송
Query String	URL 뒤에 붙는 파라미터
HTTP 상태코드	서버 응답 결과를 숫자로 표현
401	인증 필요
403	권한 없음
404	자원 없음
500	서버 오류
쿠키	클라이언트 브라우저에 저장되는 데이터
세션	서버가 관리하는 사용자 상태 정보
HttpOnly	JavaScript 쿠키 접근 제한
Secure	HTTPS에서만 쿠키 전송
SameSite	다른 사이트 요청 시 쿠키 전송 제한
인증	신원 확인
인가	권한 확인
MFA	서로 다른 인증 요소 2개 이상 사용
HTTPS	TLS 기반 암호화 웹 통신
웹 로그	웹 요청과 응답 기록
오류 메시지	상세 내부 정보 노출 제한 필요
입력값 검증	클라이언트 입력을 서버에서 검증

필수 암기 문장

아래 문장들은 필기와 실기 모두 중요합니다.

HTTP는 웹에서 클라이언트와 서버가 요청과 응답을 주고받기 위한 응용 계층 프로토콜이다.

HTTP는 이전 요청 상태를 자동으로 기억하지 않는 무상태 프로토콜이므로 로그인 상태 유지를 위해 쿠키와 세션이 사용된다.

GET은 요청 데이터가 URL에 포함될 수 있어 민감정보 전송에 부적절하고, POST도 암호화가 보장되는 것은 아니므로 HTTPS가 필요하다.

쿠키는 클라이언트 브라우저에 저장되는 데이터이고, 세션은 서버가 사용자 상태를 관리하기 위한 정보이다.

HttpOnly는 JavaScript의 쿠키 접근을 제한하고, Secure는 HTTPS에서만 쿠키를 전송하며, SameSite는 CSRF 위험을 완화한다.

인증은 사용자의 신원을 확인하는 절차이고, 인가는 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 확인하는 절차이다.

HTTPS는 TLS를 이용해 통신의 기밀성, 무결성, 서버 인증을 제공한다.

HTTPS는 통신 구간을 보호하지만 SQL Injection, XSS 같은 애플리케이션 취약점을 자동으로 제거하지는 않는다.

웹 로그는 접속 IP, 요청 URL, 상태코드, User-Agent 등을 기록하므로 공격 탐지와 침해사고 분석에 활용된다.

상세 오류 메시지는 DB 구조, 서버 경로, 프레임워크 버전 등 내부 정보를 노출할 수 있으므로 사용자에게는 일반 오류 메시지만 제공해야 한다.

클라이언트 입력값은 신뢰하지 말고 서버 측에서 검증해야 한다.

연습 과제

다음 문제에 답한다.
이번 절은 웹보안의 기초이므로 직접 문장으로 작성하는 것이 중요합니다.

A. 단답형

1. 웹 애플리케이션이란 무엇인가?
2. 클라이언트와 서버의 차이를 쓰시오.
3. HTTP란 무엇인가?
4. HTTP가 무상태 프로토콜이라는 의미를 쓰시오.
5. HTTP 요청을 구성하는 주요 요소 3가지를 쓰시오.
6. HTTP 응답을 구성하는 주요 요소 3가지를 쓰시오.
7. GET과 POST의 차이를 쓰시오.
8. Query String에 민감정보를 넣으면 안 되는 이유를 쓰시오.
9. 401, 403, 404, 500 상태코드의 의미를 각각 쓰시오.
10. 쿠키란 무엇인가?
11. 세션이란 무엇인가?
12. 쿠키와 세션의 차이를 쓰시오.
13. HttpOnly, Secure, SameSite 쿠키 속성의 의미를 각각 쓰시오.
14. 인증과 인가의 차이를 쓰시오.
15. MFA란 무엇인가?
16. HTTPS가 제공하는 보안 효과 3가지를 쓰시오.
17. HTTPS만으로 웹 보안이 완성되지 않는 이유를 쓰시오.
18. 웹 로그에 기록되는 주요 항목 5가지를 쓰시오.
19. 웹 로그에서 공격 징후로 볼 수 있는 예시 3가지를 쓰시오.
20. 상세 오류 메시지가 위험한 이유를 쓰시오.
21. 입력값 검증이 필요한 이유를 쓰시오.

B. 상황 매칭 문제

다음 상황에 적합한 개념을 쓴다.

22. 사용자가 로그인했지만 서버가 다음 요청에서 자동으로 로그인 상태를 기억하지 못한다.
23. 서버가 브라우저에 sessionid 값을 저장하도록 전달했다.
24. JavaScript로 쿠키를 읽지 못하게 하고 싶다.
25. HTTPS 연결에서만 쿠키가 전송되게 하고 싶다.
26. 일반 사용자가 관리자 페이지에 접근하려 했으나 권한이 없어 차단되었다.
27. 로그인하지 않은 사용자가 마이페이지에 접근하려 했다.
28. URL에 password=1234가 포함되어 로그에 남았다.
29. 서버 오류 화면에 DB 쿼리와 서버 경로가 노출되었다.
30. 동일 IP에서 /admin, /manager, /phpmyadmin 경로를 반복 요청했다.

C. 실기형 답안 작성

다음 5문제는 2~3문장으로 작성한다.

31. HTTP의 무상태 특성과 쿠키·세션이 필요한 이유를 설명하시오.

32. GET과 POST의 차이와 보안상 주의점을 설명하시오.

33. 쿠키 보안 속성 HttpOnly, Secure, SameSite를 설명하시오.

34. 인증과 인가의 차이를 설명하시오.

35. HTTPS의 필요성과 한계를 설명하시오.

보강 개념: SQL Injection 연결과 보고서형 답안

입력값 검증은 4장 2절 SQL Injection의 직접적인 선행 개념이다. HTTP 요청의 Query String, Body, Cookie, Header에 들어온 값이 서버에서 SQL 쿼리에 안전하지 않게 연결되면 SQL Injection이 발생할 수 있다.

보고서형 답안 예시

취약점명: SQL Injection 가능성
진단 위치: /login 요청의 id 또는 password 파라미터
위험도: 높음
발견 근거: 입력값에 SQL 특수문자 또는 조건식 삽입 시 인증 우회나 오류 메시지 노출 가능
영향: 개인정보 조회, 인증 우회, DB 변조·삭제, 추가 시스템 침투
개선 방안: Prepared Statement 사용, 입력값 검증, 오류 메시지 일반화, DB 계정 최소권한, 로그 모니터링
재점검 기준: 동일 입력값으로 인증 우회와 오류 노출이 재현되지 않아야 함

연습 과제 정답 및 해설

상황 매칭 정답: 22 HTTP 무상태성, 23 쿠키, 24 HttpOnly, 25 Secure, 26 인가 실패 또는 403, 27 인증 실패 또는 401, 28 Query String 민감정보 노출, 29 오류 메시지 정보 노출, 30 웹 스캐닝 또는 관리자 경로 탐색.

단답형 핵심 키워드: HTTP 요청은 요청라인, 헤더, Body로 구성되고 응답은 상태라인, 헤더, Body로 구성된다. GET은 조회와 Query String 중심, POST는 Body 전송 중심이지만 POST도 암호화를 의미하지 않는다. HTTPS는 암호화, 무결성, 서버 인증을 제공하지만 입력값 검증이나 인가 취약점까지 해결하지는 못한다.

실기형 채점 기준: 쿠키·세션 답안은 무상태성 보완을 설명해야 한다. GET/POST 답안은 민감정보 URL 노출과 로그 저장 위험을 포함한다. HTTPS 한계 답안은 SQL Injection, XSS, 인증·인가 오류처럼 애플리케이션 로직 취약점은 별도 대응이 필요하다고 써야 한다.

목차