목차
1 시큐어코딩 개요
2 인터넷 작동 방식
3 브라우저 작동 방식
4 웹 서버 작동 방식
5 소프트웨어 개발 생명주기
6 인젝션 공격
7 크로스 사이트 스크립팅 공격
8 사이트 간 요청 위조 공격
9 인증 손상
10 세션 하이제킹
11 권한과 접근 제어
12 디렉터리 접근 공격
13 정보 누출
14 암호화와 HTTPS
15 서드파티와 종속성 보호
16 부속품이 되지 않기 위한 보안
17 서비스 거부 공격
18 오늘 학습한 핵심 정리
1 시큐어코딩 개요
1) 시큐어코딩
(1) 시큐어코딩의 의미
시큐어코딩은 프로그램을 만들 때 보안 취약점이 생기지 않도록 안전하게 코드를 작성하는 방법이다.
단순히 기능이 동작하는 코드를 만드는 것이 아니라, 공격자가 악용할 수 있는 부분까지 고려하며 개발하는 것이다.
(2) 필요한 이유
웹 애플리케이션은 사용자의 요청을 받고, 서버에서 처리하고, 데이터베이스와 연결된다.
이 과정에서 입력값 검증이 부족하거나 권한 확인이 제대로 되지 않으면 공격자가 시스템을 조작할 수 있다.
(3) 오늘 학습의 흐름
오늘은 인터넷과 웹 서버가 동작하는 기본 구조를 먼저 이해하고, 그 위에서 발생할 수 있는 보안 공격과 조치 방안을 학습했다.
인젝션 공격, XSS, CSRF, 세션 하이제킹, 권한 상승, 정보 누출, 암호화, 서비스 거부 공격 등을 정리했다.
2 인터넷 작동 방식
1) 인터넷
(1) 인터넷의 의미
인터넷은 전 세계의 컴퓨터들이 네트워크를 통해 연결되어 정보를 공유하는 구조이다.
컴퓨터들은 정해진 통신 규칙인 프로토콜을 이용해 서로 데이터를 주고받는다.
(2) 프로토콜
프로토콜은 컴퓨터끼리 통신하기 위한 약속이다.
대표적으로 TCP, IP, 도메인 이름, HTTP 등이 있다.
(3) 웹 통신의 기본
사용자가 브라우저에서 주소를 입력하면, 브라우저는 해당 주소에 맞는 서버를 찾아 요청을 보낸다.
서버는 요청을 처리한 뒤 HTML, 이미지, JSON 같은 응답을 다시 브라우저로 보낸다.
2) 프로토콜 스위트
(1) 프로토콜 스위트의 의미
인터넷 초기에 데이터 교환의 신뢰성이 부족했기 때문에 이를 해결하기 위해 TCP가 개발되었다.
TCP를 포함한 여러 네트워크 프로토콜 묶음을 프로토콜 스위트라고 한다.
(2) TCP
TCP는 데이터를 안정적으로 전달하기 위한 전송 제어 프로토콜이다.
발신 측에서는 보내는 메시지를 패킷으로 나누고, 각 패킷에 목적지 주소를 담아 전송한다.
(3) 패킷 재조립
수신 측에서는 전달받은 패킷을 순서에 맞게 다시 조립한다.
이 과정을 통해 원래 메시지가 완성된다.
(4) IP 주소
데이터 패킷은 IP 주소를 기준으로 목적지까지 전달된다.
IP 주소는 네트워크에서 컴퓨터나 서버를 구분하기 위한 고유한 주소이다.
(5) DNS
사람은 숫자로 된 IP 주소를 기억하기 어렵기 때문에 도메인 이름을 사용한다.
DNS는 사람이 입력한 도메인 이름을 실제 IP 주소로 변환해주는 시스템이다.
3) 상태 저장 연결
(1) HTTP의 특징
HTTP는 기본적으로 어떤 사용자에게서 어떤 요청이 오는지 계속 기억하지 못한다.
즉, 요청 하나하나를 독립적으로 처리한다.
(2) 상태 유지가 필요한 이유
현대 웹사이트는 로그인, 장바구니, 게시글 작성처럼 사용자의 상태를 계속 추적해야 한다.
그래서 HTTP 통신에서도 상태가 유지되도록 세션 추적 방식이 필요하다.
(3) 세션 추적
세션은 사용자가 로그인한 상태나 사용자의 활동 정보를 일정 시간 동안 유지하기 위해 사용한다.
웹 서버는 세션을 통해 사용자를 구분하고 이전 요청과 다음 요청을 연결할 수 있다.
4) 암호화
(1) 암호화의 필요성
HTTP 요청과 응답은 중간에서 가로채질 수 있다.
공격자가 통신 내용을 훔쳐보거나 조작할 수 있기 때문에 암호화가 필요하다.
(2) TLS
TLS는 인터넷 통신을 안전하게 보호하기 위한 암호화 기술이다.
데이터를 암호화해서 중간에서 누군가 가로채더라도 내용을 쉽게 읽지 못하게 만든다.
(3) HTTPS
TLS를 이용한 HTTP 통신을 HTTPS라고 한다.
HTTPS는 HTTP보다 안전한 통신 방식이며, 로그인이나 결제처럼 민감한 정보를 다룰 때 반드시 필요하다.
3 브라우저 작동 방식
1) 웹 페이지 렌더링
(1) 렌더링
렌더링은 HTML, CSS, JavaScript 같은 웹 자원을 사용자가 볼 수 있는 화면으로 변환하는 과정이다.
브라우저는 서버에서 받은 응답을 해석해 화면에 보여준다.
(2) 렌더링 파이프라인
렌더링 파이프라인은 HTML을 화면에 보이는 시각적 표현으로 바꾸는 브라우저 내부 처리 과정이다.
브라우저는 HTML을 읽고 DOM 구조를 만든 뒤, CSS를 적용해 화면을 구성한다.
(3) DOM
DOM은 HTML 문서를 트리 구조로 표현한 것이다.
각 HTML 태그는 DOM 노드가 되고, 브라우저는 이 구조를 바탕으로 화면을 만든다.
(4) CSS 적용
브라우저는 CSS 파일이나 style 정보를 이용해 각 요소의 색상, 크기, 위치 같은 스타일을 결정한다.
이후 계산된 결과를 화면에 그린다.
(5) 브라우저의 추가 작업
브라우저는 화면을 그리는 일만 하는 것이 아니다.
DNS 주소 확인, DNS 캐시, 보안 인증서 해석과 검증, 쿠키 저장과 전송 같은 작업도 함께 수행한다.
4 웹 서버 작동 방식
1) 정적 자원
(1) 정적 자원의 의미
정적 자원은 서버에 저장된 파일을 그대로 사용자에게 전달하는 자원이다.
HTML 파일, 이미지 파일, CSS 파일, JavaScript 파일 등이 여기에 해당한다.
(2) 초기 웹사이트
인터넷 초기 웹사이트는 대부분 정적 자원으로 구성되었다.
개발자는 HTML 파일을 직접 작성했고, 사이트는 여러 개의 HTML 파일로 구성되었다.
(3) URL 결정
사용자가 URL을 요청하면 웹 서버는 URL에 해당하는 자원 파일을 찾아 그대로 반환한다.
예를 들어 이미지 URL을 요청하면 서버는 해당 이미지 파일을 응답한다.
(4) CDN
CDN은 콘텐츠 전송 네트워크이다.
정적 자원의 복사본을 전 세계 여러 데이터 센터에 저장해 사용자에게 더 빠르게 전달한다.
(5) 콘텐츠 관리 시스템
콘텐츠 관리 시스템은 웹 페이지 제작 도구를 제공한다.
WYSIWYG 방식처럼 사용자가 화면에서 보는 그대로 콘텐츠를 작성할 수 있게 도와준다.
2) 동적 자원
(1) 동적 자원의 의미
동적 자원은 요청에 따라 서버에서 실행 결과가 달라지는 자원이다.
현재 대부분의 웹사이트는 정적 자원뿐만 아니라 동적 자원을 사용한다.
(2) 코드와 템플릿
동적 자원은 해석되는 코드나 템플릿을 통해 생성된다.
예를 들어 JSP, Servlet, 템플릿 엔진 등을 이용해 사용자의 요청에 맞는 HTML을 만든다.
(3) 템플릿
동적 자원을 구성하는 코드가 복잡하면 HTML을 직관적으로 작성하기 어렵다.
그래서 템플릿을 사용해 화면 구조와 동적 데이터를 결합한다.
(4) 데이터베이스
웹 서버는 동적 자원을 만들 때 데이터베이스에서 데이터를 읽어오는 경우가 많다.
게시판 목록, 회원 정보, 상품 목록처럼 사용자에게 보여줄 데이터는 보통 DB에서 가져온다.
(5) DB 인터페이스의 위험성
웹 서버와 데이터베이스 사이의 인터페이스는 해커들의 주요 공격 대상이 된다.
SQL을 잘못 구성하면 SQL 인젝션 같은 공격이 발생할 수 있다.
(6) SQL 데이터베이스와 NoSQL 데이터베이스
데이터베이스는 크게 SQL 데이터베이스와 NoSQL 데이터베이스로 나눌 수 있다.
SQL 데이터베이스는 관계형 구조를 사용하고, NoSQL은 문서형, 키-값형 등 다양한 구조를 사용한다.
5 소프트웨어 개발 생명주기
1) 개발 생명주기
(1) 개발 습관
개발 과정에서는 버그와 보안 취약점의 위험을 줄이는 습관을 가져야 한다.
보안은 개발이 끝난 뒤에만 확인하는 것이 아니라, 개발 전 과정에서 고려해야 한다.
(2) 설계 및 분석
기능을 만들기 전에 어떤 데이터가 오가고 어떤 위험이 있는지 분석해야 한다.
인증, 권한, 입력값 검증, 데이터 보호 방법을 설계 단계에서 고려해야 한다.
(3) 코드 작성
코드를 작성할 때는 보안 취약점이 생기지 않도록 안전한 방식으로 구현해야 한다.
예를 들어 SQL 문자열을 직접 이어 붙이기보다 PreparedStatement를 사용해야 한다.
(4) 배포 전 테스트
배포하기 전에 기능 테스트뿐만 아니라 보안 테스트도 진행해야 한다.
공격자 입장에서 입력값을 바꿔보거나 권한 없는 요청을 보내보며 취약점을 찾아야 한다.
(5) 릴리스 프로세스
배포 과정에서도 설정 정보, 인증서, 서버 구성, 권한 설정이 안전한지 확인해야 한다.
실수로 테스트 계정이나 비밀 키가 노출되지 않도록 주의해야 한다.
(6) 릴리스 후 테스트 및 관찰
배포 후에도 로그를 관찰하고 이상 요청이 있는지 확인해야 한다.
보안 문제는 운영 중에 발견될 수 있으므로 지속적인 모니터링이 필요하다.
(7) 종속성 관리
외부 라이브러리나 프레임워크를 사용할 때는 보안 업데이트를 확인해야 한다.
오래된 라이브러리는 알려진 취약점을 포함할 수 있으므로 관리가 필요하다.
6 인젝션 공격
1) 인젝션 공격
(1) 인젝션 공격의 의미
인젝션 공격은 외부 코드를 애플리케이션에 주입해서 시스템을 조작하거나 민감한 정보를 읽으려는 공격이다.
사용자가 입력한 값이 코드처럼 실행될 수 있을 때 발생한다.
(2) 대표 유형
대표적인 인젝션 공격에는 SQL 인젝션 공격, 커맨드 인젝션 공격, 파일 업로드 취약점이 있다.
2) SQL 인젝션 공격
(1) SQL
SQL은 관계형 데이터베이스에서 데이터를 조회하고 조작하기 위해 사용하는 언어이다.
게시글 조회, 회원 로그인, 데이터 수정 같은 작업에서 SQL이 사용된다.
(2) SQL 인젝션의 원인
웹 서버가 데이터베이스 드라이버에 전달하는 SQL문을 불안전하게 구성할 때 발생한다.
사용자가 보낸 파라미터가 SQL문에 그대로 붙으면, 공격자가 개발자의 의도와 다른 SQL을 실행시킬 수 있다.
(3) 공격 예시
로그인이나 이메일 검색처럼 사용자의 입력값이 SQL 조건에 들어가는 기능은 위험할 수 있다.
예를 들어 이메일 값 뒤에 따옴표나 주석 문자를 넣으면 SQL 조건이 의도와 다르게 바뀔 수 있다.
(4) 위험성
SQL 인젝션이 성공하면 공격자는 로그인 우회, 데이터 조회, 데이터 수정, 데이터 삭제 같은 작업을 시도할 수 있다.
데이터베이스 안의 민감한 정보가 노출될 수 있기 때문에 매우 위험하다.
3) SQL 인젝션 조치 방안
(1) 매개변수화된 구문 사용
SQL문을 만들 때 사용자 입력값을 문자열로 직접 이어 붙이면 안 된다.
바인딩 매개변수를 사용하는 PreparedStatement를 사용해야 한다.
(2) PreparedStatement
PreparedStatement는 SQL 구조와 사용자 입력값을 분리한다.
사용자가 입력한 값은 SQL 명령어가 아니라 단순 데이터로 처리되므로 SQL 인젝션 위험을 줄일 수 있다.
(3) ORM 사용
객체 관계 매핑인 ORM을 사용하면 SQL문의 명시적 구성을 추상화할 수 있다.
ORM은 객체와 DB 테이블을 연결해주며, 안전한 쿼리 구성을 도와준다.
4) 커맨드 인젝션 공격
(1) 커맨드 인젝션의 의미
커맨드 인젝션은 웹 애플리케이션이 시스템 명령어를 실행할 때 발생할 수 있다.
공격자가 입력값을 조작해 서버가 의도하지 않은 시스템 명령을 실행하게 만드는 공격이다.
(2) 위험성
서버 명령어가 실행되면 파일 삭제, 시스템 정보 조회, 악성 코드 실행 같은 심각한 문제가 생길 수 있다.
특히 사용자 입력값이 명령어에 직접 포함되는 경우 위험하다.
(3) 조치 방안
사용자 입력값을 시스템 명령어에 직접 사용하지 않아야 한다.
반드시 필요한 경우 적절한 이스케이프 문자를 사용하고, 허용된 값만 받을 수 있도록 제한해야 한다.
5) 파일 업로드 취약점
(1) 파일 업로드 취약점의 의미
파일 업로드 취약점은 사용자가 업로드한 파일을 제대로 검증하지 않을 때 발생한다.
공격자가 악성 파일을 서버에 올리고 실행할 수 있다면 큰 보안 문제가 된다.
(2) 위험성
웹쉘 같은 악성 파일이 업로드되면 공격자가 서버를 조작할 수 있다.
단순 이미지 업로드 기능도 검증이 부족하면 공격 통로가 될 수 있다.
(3) 조치 방안
업로드 파일의 확장자, MIME 타입, 파일 내용, 저장 위치를 검증해야 한다.
가능하면 CDN에 파일을 업로드하거나, 업로드된 파일이 실행되지 않도록 분리해서 저장해야 한다.
7 크로스 사이트 스크립팅 공격
1) XSS
(1) XSS의 의미
크로스 사이트 스크립팅은 악의적인 JavaScript를 사용자의 브라우저에서 실행하도록 하는 공격이다.
서버가 사용자 입력값을 제대로 검증하거나 이스케이프하지 않으면 발생할 수 있다.
(2) 위험성
XSS가 발생하면 공격자는 사용자의 쿠키를 훔치거나, 화면을 조작하거나, 사용자를 다른 사이트로 유도할 수 있다.
사용자의 브라우저에서 실행되기 때문에 사용자는 정상 사이트를 이용한다고 생각할 수 있다.
(3) 종류
XSS에는 스토어드 XSS, 리플렉티드 XSS, DOM 기반 XSS가 있다.
2) 스토어드 XSS
(1) 스토어드 XSS의 의미
스토어드 XSS는 악성 JavaScript 코드가 데이터베이스에 저장되는 공격이다.
이후 다른 사용자가 해당 데이터가 출력되는 페이지를 방문하면 스크립트가 실행된다.
(2) 예시
게시판 글 내용에 script 태그를 넣어 저장하는 경우를 생각할 수 있다.
서버가 이를 그대로 HTML로 출력하면 다른 사용자의 브라우저에서 script가 실행된다.
(3) 위험성
한 번 저장되면 여러 사용자가 페이지를 볼 때마다 공격 코드가 실행될 수 있다.
그래서 저장형 XSS는 피해 범위가 넓다.
3) XSS 조치 방안
(1) 이스케이프 처리
사용자 입력값을 HTML, JavaScript, CSS에서 출력할 때 특수문자를 적절히 이스케이프해야 한다.
예를 들어 <, >, " ", ' ' 같은 문자가 HTML 태그나 스크립트로 해석되지 않게 처리해야 한다.
(2) 입력값 검증
서버에서 사용자 입력값을 철저히 검증해야 한다.
허용된 형식과 길이만 통과시키고, 위험한 문자는 제거하거나 변환해야 한다.
(3) 콘텐츠 보안 정책
CSP는 사이트에서 JavaScript 실행을 제한하는 보안 정책이다.
허용된 출처의 스크립트만 실행하도록 설정해 XSS 피해를 줄일 수 있다.
4) 리플렉티드 XSS
(1) 리플렉티드 XSS의 의미
리플렉티드 XSS는 URL이나 GET 파라미터에 악성 JavaScript를 넣는 공격이다.
사용자가 해당 링크를 클릭하면 서버 응답에 악성 스크립트가 포함되어 실행된다.
(2) 특징
악성 코드가 DB에 저장되지는 않는다.
대신 공격자가 만든 링크를 피해자가 클릭할 때 공격이 발생한다.
(3) 조치 방안
XSS 조치와 동일하게 사용자 입력값을 이스케이프 처리해야 한다.
URL 파라미터로 받은 값도 화면에 출력하기 전에 검증해야 한다.
5) DOM 기반 XSS
(1) DOM 기반 XSS의 의미
DOM 기반 XSS는 서버가 아니라 클라이언트 측 JavaScript가 DOM을 조작하는 과정에서 발생한다.
URI 조각이나 입력값이 DOM에 삽입될 때 악성 스크립트가 실행될 수 있다.
(2) 특징
클라이언트 측에서만 발생할 수 있다.
브라우저가 DOM을 조작할 때 공격 코드가 실행된다.
(3) 조치 방안
URI 조각에서 가져온 동적 콘텐츠를 DOM에 넣기 전에 이스케이프 처리해야 한다.
innerHTML처럼 HTML로 해석되는 방식에 사용자 입력값을 직접 넣는 것을 피해야 한다.
8 사이트 간 요청 위조 공격
1) CSRF
(1) CSRF의 의미
사이트 간 요청 위조는 사용자가 인증된 세션을 가지고 있는 상태를 악용하는 공격이다.
공격자는 사용자의 의지와 상관없이 특정 요청을 보내도록 유도해 악의적인 작업을 수행하게 만든다.
(2) 예시
사용자가 특정 사이트에 로그인한 상태에서 공격자가 만든 링크나 페이지를 클릭할 수 있다.
이때 브라우저가 자동으로 쿠키를 함께 보내면 서버는 정상 사용자 요청으로 오해할 수 있다.
(3) GET 요청의 위험성
일반적으로 서버 상태를 변경하는 GET 요청은 CSRF에 취약하다.
GET 요청은 요청 내용이 URL에 포함되기 때문에 공격자가 링크 형태로 쉽게 만들 수 있다.
2) CSRF 조치 방안
(1) REST 원칙
GET 요청은 서버 상태를 변경하지 않도록 해야 한다.
자원을 가져올 때는 GET, 새 개체를 만들 때는 PUT, 자원을 수정할 때는 POST, 삭제할 때는 DELETE처럼 HTTP 메서드의 역할을 지켜야 한다.
(2) CSRF 토큰
클라이언트가 요청할 때 쿠키와 함께 CSRF 토큰을 보내게 하고, 서버가 이를 검증해야 한다.
공격자는 정상 토큰을 알 수 없기 때문에 위조 요청을 막을 수 있다.
(3) 쿠키
쿠키는 HTTP 헤더를 통해 브라우저와 웹 서버 사이에서 전달되는 작은 텍스트이다.
서버가 응답에 쿠키를 포함하면 브라우저는 다음 요청에 같은 쿠키를 다시 보낸다.
(4) SameSite 쿠키 속성
SameSite 속성은 다른 웹사이트에서 생성된 요청에 쿠키를 보낼지 제어한다.
Strict는 같은 사이트 요청에만 쿠키를 보내고, Lax는 일부 안전한 크로스 사이트 요청을 허용하며, None은 모든 요청에 쿠키를 보낼 수 있다.
(5) 재인증
중요한 작업을 수행할 때는 로그인 정보를 다시 확인하는 재인증을 적용할 수 있다.
비밀번호 변경, 결제, 회원 탈퇴 같은 작업에 유용하다.
9 인증 손상
1) 인증 구현
(1) 인증의 의미
인증은 사용자가 누구인지 확인하는 과정이다.
로그인은 대표적인 인증 과정이다.
(2) HTTP 인증
인증은 HTTP의 일부로 볼 수 있다.
인증 문제가 발생하면 서버는 401 상태 코드를 응답할 수 있다.
(3) 인증 방식
인증 방식에는 기본 인증, 다이제스트 인증, HTTP 네이티브 인증, 네이티브하지 않은 인증 방식이 있다.
네이티브 인증은 HTTP에 내장된 방식이고, 네이티브하지 않은 인증은 개발자가 원하는 방식으로 구현하는 인증이다.
2) 인증 손상 조치 방안
(1) 서드파티 인증 사용
인증 시스템을 직접 구현하는 대신 검증된 서드파티 인증 서비스를 사용할 수 있다.
직접 구현보다 보안 위험을 줄일 수 있다.
(2) 자체 인증 시스템 보호
자체 인증 시스템을 구현해야 한다면 이름, 암호, 비밀번호 재설정 같은 기능을 안전하게 설계해야 한다.
비밀번호는 평문으로 저장하지 말고 안전하게 해시 처리해야 한다.
(3) Single Sign-on 통합
SSO는 한 번의 로그인으로 여러 서비스에 접근할 수 있게 하는 방식이다.
인증 관리를 중앙화할 수 있어 사용자 경험과 보안 관리 측면에서 도움이 된다.
10 세션 하이제킹
1) 세션 작동 방식
(1) 서버 측 세션
사용자가 HTTP에서 인증하면 웹 서버는 로그인 과정에서 사용자에게 세션 식별자를 할당한다.
서버는 각 요청에 포함된 세션 ID를 확인해 사용자를 식별한다.
(2) 서버 메모리의 세션 상태
서버 측 세션에서는 세션 상태를 서버 메모리에 유지한다.
브라우저와 웹 서버는 세션 식별자를 주고받으며 사용자를 구분한다.
(3) 클라이언트 측 세션
클라이언트 측 세션은 사용자의 브라우저에 직접 데이터를 저장한다.
쿠키, 로컬스토리지, 세션스토리지, JWT 등이 여기에 해당한다.
2) 세션 하이제킹
(1) 세션 하이제킹의 의미
세션 하이제킹은 공격자가 사용자의 세션 ID를 훔쳐 해당 사용자처럼 행동하는 공격이다.
서버가 세션 ID만 보고 사용자를 판단하기 때문에 세션 ID가 노출되면 위험하다.
(2) 쿠키 도난
공격자는 쿠키 헤더 값을 훔쳐 세션 하이제킹을 수행할 수 있다.
XSS, 중간자 공격, CSRF 공격 등이 쿠키 도난으로 이어질 수 있다.
(3) URL에 노출된 세션 ID
URL에 세션 ID가 포함되면 공격자가 이를 가로챌 수 있다.
초기 웹 환경에서는 쿠키 지원이 부족해 URL에 세션 ID를 넣는 경우가 있었지만, 이는 보안상 위험하다.
(4) 쿠키 고정
쿠키 고정은 공격자가 특정 세션 ID를 사용하게 만든 뒤 그 세션을 가로채는 공격이다.
공격자는 취약한 세션 ID를 이용해 사용자 세션에 접근할 수 있다.
(5) 취약한 세션 ID
세션 ID가 쉽게 추측 가능하면 공격자가 세션을 탈취할 수 있다.
세션 ID는 충분히 길고 예측하기 어려워야 한다.
3) 세션 하이제킹 조치 방안
(1) 쿠키 보안 속성
쿠키에 HttpOnly, Secure, SameSite 같은 속성을 설정해야 한다.
HttpOnly는 JavaScript로 쿠키를 읽지 못하게 하고, Secure는 HTTPS에서만 쿠키가 전송되게 한다.
(2) HTTPS 사용
중간자 공격을 막기 위해 HTTPS를 사용해야 한다.
암호화되지 않은 HTTP에서는 세션 쿠키가 노출될 수 있다.
(3) 세션 ID 재발급
로그인 성공 후에는 새로운 세션 ID를 발급하는 것이 좋다.
이를 통해 세션 고정 공격을 줄일 수 있다.
11 권한과 접근 제어
1) 권한 상승
(1) 수직적 권한 상승
수직적 권한 상승은 일반 사용자가 관리자처럼 더 높은 권한을 가진 계정의 기능에 접근하는 것이다.
예를 들어 일반 사용자가 관리자 페이지에 접근하는 경우이다.
(2) 수평적 권한 상승
수평적 권한 상승은 비슷한 권한을 가진 다른 사용자의 계정이나 데이터에 접근하는 것이다.
예를 들어 사용자 A가 사용자 B의 개인정보를 조회하는 경우이다.
2) 접근 제어
(1) 인증과 권한
인증은 사용자가 누구인지 확인하는 것이다.
권한은 인증된 사용자가 어떤 작업을 할 수 있는지 판단하는 것이다.
(2) 접근 제어 전략
접근 제어 전략은 사용자에게 어떤 권한을 적용할지 문서화하는 것이다.
합의된 규칙 집합을 만들어두는 것이 중요하다.
(3) 인증 모델 설계
권한 부여 규칙을 모델링하는 방법에는 접근제어목록, 화이트리스트와 블랙리스트, 역할 기반 접근제어, 소유권 기반 접근 제어가 있다.
(4) 접근 제어 구현
규칙을 정의한 뒤에는 코드로 구현해야 한다.
단순히 화면에서 버튼을 숨기는 것만으로는 부족하고, 서버에서도 권한을 검사해야 한다.
(5) 접근 제어 테스트
공격자처럼 허점을 찾아 테스트해야 한다.
URL을 직접 입력하거나 파라미터를 바꿔보며 권한 없는 접근이 가능한지 확인해야 한다.
(6) 감사 기록
사용자가 사이트를 탐색하거나 중요한 작업을 수행할 때 로그를 남겨야 한다.
감사 기록은 나중에 이상 행위를 추적하는 데 도움이 된다.
12 디렉터리 접근 공격
1) 디렉터리 접근 공격
(1) 의미
디렉터리 접근 공격은 URL이나 파라미터에 파일 경로가 포함되어 있을 때 발생할 수 있다.
공격자가 경로를 조작해 서버 내부 파일에 접근하려고 하는 공격이다.
(2) 상대 경로 위험
서버 코드가 사용자가 전달한 파일 이름이나 상대 경로를 그대로 평가하면 위험하다.
공격자는 ../ 같은 경로를 사용해 원래 접근하면 안 되는 파일을 요청할 수 있다.
(3) 정보 노출
공격자가 임의의 경로로 파일을 다운로드할 수 있으면 중요한 설정 파일이나 소스 코드가 노출될 수 있다.
2) 디렉터리 접근 공격 조치 방안
(1) 웹 서버 동작 이해
웹 서버가 정적 콘텐츠 URL을 어떻게 처리하는지 알아야 한다.
어떤 경로가 외부에 공개되는지 명확히 파악해야 한다.
(2) 호스팅 서비스 사용
정적 파일은 CDN 같은 호스팅 서비스를 활용할 수 있다.
애플리케이션 서버와 파일 저장 공간을 분리하면 위험을 줄일 수 있다.
(3) 간접 파일 참조
파일 경로를 직접 URL에 노출하지 않고 불투명한 ID를 사용할 수 있다.
사용자는 실제 파일 경로가 아니라 파일 ID로 접근하게 된다.
(4) 파일 참조 삭제
파일 참조 값에 경로 구분 문자가 포함되지 않도록 제한해야 한다.
경로를 직접 입력받는 구조는 피하는 것이 좋다.
13 정보 누출
1) 정보 누출
(1) 정보 누출의 의미
정보 누출은 공격자에게 시스템의 내부 정보를 알려주는 문제이다.
작은 정보라도 공격자가 취약점을 찾는 데 단서가 될 수 있다.
(2) 위험성
서버 종류, 프레임워크 버전, 파일 확장자, 오류 메시지, JavaScript 소스 정보가 노출되면 공격자가 공격 방법을 선택하기 쉬워진다.
그래서 불필요한 정보는 숨기는 것이 좋다.
2) 정보 누출 조치 방안
(1) 서버 헤더 비활성화
숨길 수 없는 서버 헤더를 사용하지 않도록 설정해야 한다.
HTTP 응답 헤더에 서버 버전이나 기술 스택이 노출되지 않게 해야 한다.
(2) 깔끔한 URL 사용
.jsp, .php 같은 파일 접미사가 드러나는 URL은 기술 정보를 노출할 수 있다.
가능하면 깔끔한 URL 구조를 사용한다.
(3) 일반 쿠키 매개변수 사용
쿠키 이름이나 값에 내부 구조가 드러나지 않도록 해야 한다.
민감한 의미가 바로 보이는 이름을 피하는 것이 좋다.
(4) 오류 페이지 활용
에러 발생 시 내부 스택 트레이스나 SQL 오류를 그대로 보여주면 안 된다.
사용자에게는 일반적인 오류 페이지를 보여주고, 자세한 오류는 서버 로그에 남긴다.
(5) 클라이언트 측 오류 보고 제한
클라이언트 측에서 너무 자세한 오류 정보를 보여주면 공격자에게 도움이 될 수 있다.
필요한 정보만 보여줘야 한다.
(6) JavaScript 최소화와 난독화
JavaScript 파일을 최소화하거나 난독화하면 소스 코드를 읽기 어렵게 만들 수 있다.
다만 난독화만으로 보안이 완성되는 것은 아니므로 서버 측 보안도 필요하다.
(7) 클라이언트 측 파일 정리
템플릿 파일이나 HTML 주석에 내부 정보가 남아 있지 않도록 삭제해야 한다.
설명 주석이 공격자에게 힌트가 될 수 있다.
14 암호화와 HTTPS
1) 인터넷 프로토콜의 암호화
(1) 패킷 전송
인터넷으로 전송되는 메시지는 데이터 패킷으로 나뉘고 TCP를 통해 목적지로 전달된다.
수신자 컴퓨터는 전달받은 TCP 패킷을 다시 원래 메시지로 조립한다.
(2) 중간자 공격
TCP 통신은 악의적인 제3자가 패킷을 가로채 읽는 중간자 공격에 취약할 수 있다.
이를 막기 위해 TLS 같은 암호화 기술이 필요하다.
(3) HTTPS
TLS를 사용해 수행되는 HTTP 통신을 HTTPS라고 한다.
HTTPS는 데이터를 암호화해 전송하므로 중간에서 내용을 훔쳐보기 어렵다.
2) 암호화 알고리즘
(1) 암호화의 기본
암호화는 입력 데이터를 암호키를 사용해 알아보기 어렵게 바꾸는 과정이다.
복호화 키가 없으면 원래 내용을 해독하기 어렵다.
(2) 대칭암호화 알고리즘
대칭암호화는 암호화와 복호화에 같은 키를 사용하는 방식이다.
속도가 빠르기 때문에 실제 데이터 암호화에 많이 사용된다.
(3) 비대칭암호화 알고리즘
비대칭암호화는 공개키와 개인키를 사용하는 방식이다.
안전하게 키를 교환하거나 인증서를 검증할 때 사용된다.
(4) 해시 함수
해시 함수는 입력값을 고정된 길이의 값으로 변환한다.
비밀번호 저장이나 데이터 무결성 확인에 사용된다.
3) TLS 핸드셰이크
(1) TLS 핸드셰이크의 의미
TLS 핸드셰이크는 클라이언트와 서버가 안전한 통신을 시작하기 위해 암호화 방식과 키를 협상하는 과정이다.
(2) 키 교환 알고리즘
키 교환 알고리즘은 서버와 클라이언트가 안전하게 대칭 키를 교환하도록 돕는다.
이 과정에는 비대칭 암호화가 사용될 수 있다.
(3) 대칭암호화 알고리즘
실제 데이터 암호화와 복호화에는 대칭암호화 알고리즘이 사용된다.
양쪽은 같은 키를 사용해 데이터를 암호화하고 복호화한다.
(4) MAC 알고리즘
MAC 알고리즘은 데이터가 전송되는 동안 변조되지 않았는지 확인하는 역할을 한다.
데이터 무결성을 검증하기 위한 장치이다.
4) 디지털 인증서
(1) 디지털 인증서의 의미
디지털 인증서는 공개 암호화 키의 소유권을 증명하는 전자 문서이다.
TLS에서 암호화 키를 인터넷 도메인과 연결하는 데 사용된다.
(2) 디지털 인증서 획득
인증서를 얻기 위해 키 쌍과 인증서 서명 요청을 생성하고, 도메인 검증 과정을 거친다.
확장 유효성 검사 인증서, 인증서 만료와 해지, 자체 서명 인증서도 고려해야 한다.
(3) 인증서 설치
HTTPS를 사용하려면 웹 서버에 디지털 인증서와 암호화 키를 배포해야 한다.
또한 표준 HTTPS 포트인 443에서 트래픽을 수신하도록 설정해야 한다.
(4) HTTP 처리
표준 HTTP 포트인 80으로 들어오는 암호화되지 않은 트래픽을 어떻게 처리할지도 결정해야 한다.
일반적으로 HTTP 요청을 HTTPS로 리다이렉트한다.
5) 암호화되지 않은 HTTP 공격 방식
(1) 공격 지점
암호화되지 않은 HTTP 통신은 무선 라우터, Wi-Fi 핫스팟, 인터넷 서비스 공급자, 정부 기관 등 여러 중간 지점에서 노출될 수 있다.
(2) HTTPS 필요성
로그인 정보나 개인정보를 다루지 않는 페이지라도 HTTPS를 사용하는 것이 좋다.
통신 경로의 신뢰성을 보장하기 어렵기 때문이다.
15 서드파티와 종속성 보호
1) 종속성 보호
(1) 종속성의 의미
종속성은 애플리케이션이 사용하는 외부 라이브러리, 프레임워크, 운영체제 구성 요소 등을 의미한다.
직접 작성한 코드가 아니더라도 애플리케이션 보안에 영향을 준다.
(2) 실행 중인 코드 파악
어떤 라이브러리와 버전을 사용 중인지 파악해야 한다.
보안 문제가 공개되면 해당 라이브러리가 영향을 받는지 확인해야 한다.
(3) 빠른 패치
보안 문제가 공개되면 소프트웨어를 신속하게 패치해야 한다.
종속성 관리 도구, 운영체제 패치, 무결성 검사를 활용할 수 있다.
(4) 보안 문제 경계 유지
소셜미디어, 메일, 블로그, 보안 자문, 소프트웨어 도구 등을 통해 보안 권고 사항을 빠르게 파악해야 한다.
2) 구성 보안
(1) 구성 보안의 의미
구성 보안은 소프트웨어, 네트워크, 시스템 설정을 안전하게 구성하고 관리하는 과정이다.
잘못된 설정은 보안 취약점이 될 수 있다.
(2) 기본 자격 증명 사용 금지
기본 관리자 계정이나 기본 비밀번호를 그대로 사용하면 안 된다.
공격자는 기본 계정을 먼저 시도할 수 있다.
(3) 디렉터리 리스팅 비활성화
서버가 폴더 목록을 그대로 보여주면 내부 파일 구조가 노출된다.
디렉터리 리스팅은 비활성화해야 한다.
(4) 구성 정보 보호
DB 접속 정보, API 키, 비밀번호 같은 설정 정보는 외부에 노출되면 안 된다.
설정 파일은 권한을 제한하고 안전하게 관리해야 한다.
(5) 테스트 환경 강화
테스트 환경도 실제 운영 환경처럼 보안을 고려해야 한다.
테스트 서버가 공격 통로가 될 수 있기 때문이다.
(6) 보안 관리 프론트 엔드
관리자 페이지나 보안 관리 화면은 접근 권한을 엄격히 제한해야 한다.
인증과 권한 검사를 반드시 적용해야 한다.
3) 사용하는 서비스 보안
(1) API 키 보호
서드파티 서비스를 사용할 때 발급받은 API 키는 안전하게 저장해야 한다.
소스 코드나 클라이언트 화면에 노출되면 안 된다.
(2) 웹훅 보호
웹훅은 서비스 공급자가 특정 이벤트가 발생했을 때 HTTPS 요청을 보내는 방식이다.
웹훅 요청이 진짜 서비스에서 온 것인지 검증해야 한다.
4) 공격 벡터로서의 서비스
(1) 서드파티 서비스의 위험성
서드파티 서비스는 편리하지만 웹사이트를 공격하는 통로가 될 수도 있다.
광고, 외부 스크립트, 위젯 등이 공격 벡터가 될 수 있다.
(2) 악성 코드 전송 방지
외부 서비스가 악성 코드를 전달하지 않도록 신뢰할 수 있는 서비스를 사용해야 한다.
(3) 광고 플랫폼
평판이 좋은 광고 플랫폼을 사용해야 한다.
의심스러운 광고는 검토하고 보고해야 한다.
(4) SafeFrame
SafeFrame을 사용하면 광고 콘텐츠를 더 안전하게 격리할 수 있다.
외부 광고가 사이트 본문을 마음대로 조작하지 못하게 도와준다.
16 부속품이 되지 않기 위한 보안
1) 이메일 사기와 악성 링크
(1) 이메일 사기
공격자는 이메일에 악성 링크를 숨겨 사용자를 속일 수 있다.
웹 메일 공급자는 유해한 도메인의 블랙리스트를 보관해 사용자를 보호하려고 한다.
(2) 열린 리다이렉션
열린 리다이렉션은 공격자가 정상 사이트의 URL을 이용해 사용자를 악성 사이트로 이동시키는 문제이다.
사용자가 신뢰하는 도메인으로 보이기 때문에 속기 쉽다.
(3) 열린 리다이렉션 방지
사용자를 다른 URL로 리다이렉션할 때는 인코딩된 URL이 절대 URL이 아니라 상대 URL인지 확인해야 한다.
외부 URL로 이동시키는 기능은 반드시 검증해야 한다.
(4) 기타 고려 사항
부득이하게 외부 링크를 게시해야 한다면 유해 사이트 블랙리스트와 대조하는 방법을 사용할 수 있다.
예를 들어 세이프 브라우징 API 같은 방식으로 위험 사이트 여부를 확인할 수 있다.
2) 클릭재킹
(1) 클릭재킹의 의미
클릭재킹은 사용자가 의도하지 않은 행동을 하도록 속이는 공격이다.
공격자는 사용자 인터페이스를 투명하게 덮거나 조작해 사용자가 잘못 클릭하게 만든다.
(2) CSP 사용
Content Security Policy는 사이트가 로드할 수 있는 리소스를 제어하는 보안 기능이다.
클릭재킹 방지에도 도움이 된다.
(3) X-Frame-Options
X-Frame-Options 헤더는 웹 페이지가 다른 페이지의 iframe 안에서 로드되는 것을 제한한다.
이를 통해 공격자가 내 사이트를 투명한 iframe으로 덮는 것을 막을 수 있다.
(4) 정확한 UI 구성
중요한 버튼이나 링크는 사용자가 실수로 클릭하지 않도록 명확하게 배치해야 한다.
사용자가 어떤 행동을 하는지 분명히 알 수 있어야 한다.
3) 서버 측 요청 위조
(1) SSRF의 의미
서버 측 요청 위조는 공격자가 서버를 이용해 내부 리소스에 비정상적인 요청을 보내도록 유도하는 취약점이다.
사용자가 입력한 URL을 서버가 그대로 요청할 때 발생할 수 있다.
(2) 입력 검증과 화이트리스트
사용자 입력을 철저히 검증하고 허용된 URL 목록만 요청할 수 있도록 해야 한다.
알 수 없는 외부 주소를 서버가 마음대로 요청하게 하면 위험하다.
(3) 내부 IP 차단
서버가 127.0.0.1 같은 내부 IP 주소로 요청을 보내지 않도록 차단해야 한다.
내부 관리자 페이지나 클라우드 메타데이터 서비스에 접근하는 것을 막기 위해 필요하다.
(4) CORS 설정
CORS는 교차 출처 리소스 공유 설정이다.
외부에서 내부 API에 접근하지 못하도록 적절히 제한해야 한다.
17 서비스 거부 공격
1) 서비스 거부 공격
(1) DoS의 의미
서비스 거부 공격은 특정 서버나 네트워크에 과도한 트래픽이나 리소스 소모 요청을 보내 정상적인 서비스 제공을 방해하는 공격이다.
Denial of Service Attack이라고 한다.
(2) 목적
공격자의 목적은 서버를 완전히 해킹하는 것이 아니라, 정상 사용자가 서비스를 이용하지 못하게 만드는 것이다.
서버 자원, 네트워크 대역폭, 연결 수를 고갈시킨다.
2) 서비스 거부 공격 유형
(1) 인터넷 제어 메시지 프로토콜 공격
ICMP는 네트워크에서 오류 메시지를 보고하거나 연결 상태를 진단할 때 사용되는 제어 메시지 프로토콜이다.
공격자는 악의적인 크기의 ICMP 패킷을 보내 서버나 네트워크에 부담을 줄 수 있다.
(2) 전송 제어 프로토콜 공격
TCP 공격은 핸드셰이크를 완료하지 않고 SYN 메시지를 대량으로 보내는 방식으로 발생할 수 있다.
서버가 연결 대기 상태로 자원을 소모하게 만들어 정상적인 연결 요청도 거부하게 만든다.
(3) 애플리케이션 계층 공격
애플리케이션 계층 공격은 HTTP 같은 애플리케이션 수준에서 서버 자원을 소모하게 만드는 공격이다.
서버 입장에서는 정상 요청처럼 보일 수 있어 탐지가 어려울 수 있다.
(4) 슬로로리스 공격
슬로로리스 공격은 서버에 많은 HTTP 연결을 열어두고 부분 HTTP 요청을 조금씩 전송한다.
연결을 계속 유지시켜 서버의 연결 풀이 모두 소모되게 만든다.
(5) RUDY 공격
RUDY는 긴 Content-Length 헤더 값을 가진 POST 요청을 보내 서버가 의미 없는 데이터를 계속 기다리게 만드는 공격이다.
서버는 요청이 끝나지 않았다고 판단해 자원을 계속 사용하게 된다.
(6) 분산 서비스 거부 공격
DDoS는 여러 협력 소스에서 동시에 공격 트래픽을 보내는 방식이다.
하나의 공격자가 아니라 여러 장비가 동시에 공격하므로 방어가 더 어렵다.
(7) 의도하지 않은 서비스 거부
모든 트래픽 급증이 악의적인 것은 아니다.
이벤트, 뉴스, 갑작스러운 사용자 증가로 인해 의도하지 않게 서비스 거부와 비슷한 상황이 발생할 수도 있다.
3) 서비스 거부 공격 조치 방안
(1) 방화벽과 침입 방지 시스템
방화벽과 침입 방지 시스템을 활용해 비정상적인 트래픽을 차단할 수 있다.
특정 패턴의 공격 요청을 탐지하고 막는 데 도움이 된다.
(2) DDoS 보호 서비스
분산 서비스 거부 공격은 규모가 크기 때문에 전문 DDoS 보호 서비스를 사용할 수 있다.
대규모 트래픽을 분산하거나 필터링해 서버를 보호한다.
(3) 대규모 트래픽 대비
트래픽 급증에 대비해 서버 확장, 로드밸런싱, 캐싱 같은 준비가 필요하다.
악의적 공격뿐만 아니라 정상적인 트래픽 증가에도 대응할 수 있어야 한다.
18 오늘 학습한 핵심 정리
1) 웹 구조와 보안의 연결
(1) 인터넷 구조 이해
TCP, IP, DNS, HTTP 같은 기본 통신 구조를 이해해야 보안 문제도 이해할 수 있다.
데이터가 어떻게 이동하는지 알아야 어디서 공격이 발생하는지 파악할 수 있다.
(2) 브라우저와 서버
브라우저는 HTML을 DOM으로 만들고 CSS를 적용해 화면을 렌더링한다.
서버는 정적 자원과 동적 자원을 응답하며, 동적 자원은 DB와 연결되는 경우가 많다.
(3) DB 연결의 위험성
웹 서버와 DB 사이의 인터페이스는 공격 대상이 될 수 있다.
특히 사용자 입력값을 SQL에 사용할 때는 SQL 인젝션을 반드시 주의해야 한다.
2) 입력값 검증의 중요성
(1) 인젝션 방어
사용자 입력값을 코드나 SQL로 해석하지 않도록 해야 한다.
SQL에서는 PreparedStatement를 사용하고, 시스템 명령어에는 사용자 입력값을 직접 넣지 않아야 한다.
(2) XSS 방어
사용자 입력값을 화면에 출력할 때는 HTML, JavaScript, CSS 문맥에 맞게 이스케이프해야 한다.
입력값 검증과 출력 시 이스케이프가 함께 필요하다.
(3) 파일 업로드 방어
파일 업로드는 확장자만 확인해서는 부족하다.
파일 내용, 저장 위치, 실행 가능 여부까지 확인해야 한다.
3) 인증, 세션, 권한
(1) 인증
인증은 사용자가 누구인지 확인하는 과정이다.
로그인 기능은 인증의 대표적인 예이다.
(2) 세션
세션은 인증된 사용자의 상태를 유지하기 위해 사용한다.
세션 ID가 노출되면 세션 하이제킹이 발생할 수 있으므로 쿠키 보안 속성과 HTTPS가 중요하다.
(3) 권한
권한은 인증된 사용자가 어떤 작업을 할 수 있는지 판단하는 것이다.
서버에서 반드시 권한 검사를 해야 하며, 버튼을 숨기는 것만으로는 보안이 되지 않는다.
4) 요청 위조와 접근 제어
(1) CSRF
CSRF는 로그인된 사용자의 세션을 악용해 원하지 않는 요청을 보내게 만드는 공격이다.
CSRF 토큰, SameSite 쿠키, REST 원칙을 통해 방어할 수 있다.
(2) 디렉터리 접근 공격
사용자가 파일 경로를 직접 제어할 수 있으면 내부 파일이 노출될 수 있다.
간접 파일 참조와 경로 검증이 필요하다.
(3) 정보 누출
서버 헤더, 오류 메시지, 파일 확장자, JavaScript 주석 등 작은 정보도 공격자에게 힌트가 될 수 있다.
불필요한 정보는 숨기고, 오류는 일반적인 메시지로 처리해야 한다.
5) 암호화와 HTTPS
(1) HTTPS 필요성
HTTP 통신은 중간에서 가로채질 수 있으므로 TLS를 적용한 HTTPS를 사용해야 한다.
HTTPS는 로그인, 결제뿐만 아니라 전체 웹사이트에 적용하는 것이 좋다.
(2) TLS 구성
TLS는 키 교환, 대칭 암호화, MAC 알고리즘 등을 통해 안전한 통신을 구성한다.
디지털 인증서는 도메인과 암호화 키를 연결하는 역할을 한다.
6) 운영과 외부 서비스 보안
(1) 종속성 관리
외부 라이브러리와 프레임워크의 취약점을 지속적으로 확인해야 한다.
보안 문제가 공개되면 신속하게 패치해야 한다.
(2) 구성 보안
기본 계정 사용 금지, 디렉터리 리스팅 비활성화, 구성 정보 보호 같은 기본 설정이 중요하다.
잘못된 설정은 코드 취약점만큼 위험할 수 있다.
(3) 서드파티 서비스
API 키, 웹훅, 광고 플랫폼, 외부 스크립트도 보안 위험이 될 수 있다.
신뢰할 수 있는 서비스를 사용하고, 외부 요청은 검증해야 한다.
7) 서비스 안정성
(1) DoS와 DDoS
서비스 거부 공격은 서버 자원을 고갈시켜 정상 사용자의 이용을 방해한다.
ICMP 공격, TCP 공격, 슬로로리스, RUDY, DDoS 같은 유형이 있다.
(2) 방어 방법
방화벽, 침입 방지 시스템, DDoS 보호 서비스, 트래픽 급증 대비가 필요하다.
악의적 공격뿐만 아니라 정상적인 트래픽 폭증에도 대비해야 한다.
8) 오늘 배운 점
(1) 보안은 기능 구현 이후의 문제가 아니다
보안은 설계, 코드 작성, 테스트, 배포, 운영 전 과정에서 고려해야 한다.
기능이 잘 동작해도 공격에 취약하면 안전한 서비스라고 할 수 없다.
(2) 사용자 입력은 항상 의심해야 한다
사용자가 입력한 값은 SQL, HTML, JavaScript, 파일 경로, 시스템 명령어로 직접 사용하면 위험하다.
검증, 이스케이프, 매개변수화, 권한 확인이 필요하다.
(3) 웹 개발 지식과 보안은 연결되어 있다
HTTP, 세션, 쿠키, DB, 브라우저 렌더링, 서버 구조를 알아야 보안 취약점도 이해할 수 있다.
오늘 시큐어코딩을 통해 지금까지 배운 웹 개발 흐름이 보안과 어떻게 연결되는지 이해할 수 있었다.
(4) 실제 개발에서는 방어 코드를 습관화해야 한다
PreparedStatement 사용, 세션 보호, CSRF 토큰, HTTPS, 권한 검사, 에러 정보 숨기기 같은 방식은 선택이 아니라 기본 습관이 되어야 한다.
앞으로 게시판이나 회원 기능을 만들 때도 보안을 함께 고려해야겠다고 느꼈다.