61일차: 인증/보안 기초

웹사이트에서 보안은 중요한 요소 중 하나이다. Spring에서는 Spring Security를 통해 보안 관련 기능을 지원한다.

그 전에 인증과 보안에 대한 기초적인 내용에 대해 학습하고자 한다.

❯ HTTPS

HTTPS(Hyper Text Transfer Protocol Security Socket layer)의 약자이다. 

HTTP요청에 SSL 혹은 TLS 알고리즘을 이용해 암호화를 적용해서 전송시키는 방법이다.

기밀성(제3자가 데이터를 볼 수 없는것)과 무결성(데이터 전송중에 수정되지 않는것)이 보장된다.

암호화

서버와 클라이언트가 합의한 방법을 통해 데이터를 암호화해서 주고받는것을 의미한다.

따라서 제3자는 주고받는 데이터를 탈취할 수 없다.(내용을 알아볼 수 없다.)

HTTPS에서는 암호화를 위해 비대칭키 방식과 대칭키 방식을 혼용하여 사용한다.

• 대칭키 방식: 양쪽이 공통의 비밀키를 공유하여 암호화/복호화 하는것
• 비대칭키 방식: 각각 공개키와 개인키(비밀키)를 가지고 암호화, 복호화 하는것

데이터를 주고받을때는 대칭키를 사용하며, 이러한 대칭키를 주고받을때 비대칭키 방식을 사용한다.

인증서

HTTPS에서는 클라이언트와 서버를 연결하기 전에 인증과정을 거친다.

서버가 디지털 인증서를 제공하고 클라이언트는 서버에서 받은 인증서를 확인해서 신원을 검증한다.

인증서 신원을 보증하는 제3자를 CA(Certificate Autority)라고 한다.

CA는 서버의 공개키와 정보(전자서명)를 CA의 비밀키로 암호화하여 인증서를 발급한다.

클라이언트는 OS 또는 브라우저에 미리  내장된 CA 리스트를 통해 인증된 CA에서 발급받은 인증서인지 확인한다.

인증서가 확인되고나면 해당 CA기관의 공개키로 서버 인증서를 복호화하고, 안전한 서버인지 확인한다.

❯ Hashing

가장 많이 쓰이는 암호화 방식 중 하나이다. 해싱은 임의의 데이터를 고정된 해시값으로 변환하는것을 말한다.

해싱은 암호화만 가능하다.(복호화는 기본적으로는 불가능함)

해싱은 해시함수를 통해 암호화를 수행하는데 항상 같은 길이의 문자열을 리턴하며, 서로 다른 문자열에 다른 해시함수를 적용하면 다른 결과값이 나오며, 동일한 문자에 동일한 해시함수를 사용하면 항상 같은값이 나온다는 특징이 있다.

 

복호화가 불가능한데도 사용하는 이유는 해싱을 통해 데이터 그 자체를 사용하는것이 아니라 동일한 데이터의 값을 가지고 있는지(사용하는지) 여부를 확인할 수 있기 때문이다. 예를들어 비밀번호의 경우 서버 관리자가 알아서는 안된다. 따라서 해싱값을 저장하면 입력한 비밀번호의 해싱값과 동일한 값이 있는지 확인하며  비밀번호를 안전하게 보호할 수 있다.

하지만, 해싱은 충돌(Collision)이 발생할 수 있다. 길이가 한정적이므로 서로 다른 입력데이터가 같은 해시값을 가질 수 있다.

이를 방지하기 위해 안전한 해시 알고리즘을 사용해야한다.

대표적인 해시 알고리즘으로 MD5, SHA-1, SHA-256 등이 있다.

 

해시값은 같은 데이터에 같은 해시함수를 사용하면 항상 동일한 결과를 리턴한다는 특징이 있다.

이를 통해 해싱 전의 값을 기록해놓은 테이블을 레인보우 테이블이라고 한다. 레인보우 테이블에 기록된 값은 유출되었을때 복호화가 될 위험이 있다.

레인보우테이블 예시 (출처: 코드스테이츠)

이를 방지하기 위해서는 솔트(Salt)를 적용할 수 있다. (소금을 치는것처럼 원래 값에 임의의 값을 더하는것)

암호화할때 원래 입력값에 추가적인 값을 더해서 해시값을 계산한다. 솔트를 사용하면 해싱값이 유출되어도 솔트가 함께 유출된것이 아니라면 원래 값을 알아내는것은 불가능에 가깝다.

❯ Cookie

클라이언트 데이터를 저장하는 방법 중 하나이다. 

HTTP의 대표적인 특징이 무상태성(stateless)이다. 따라서 종료된 HTTP요청에 대해서는 관련 데이터가 남아있지 않다.

(ex. POST 요청을 통해 로그인을 하고나도 다음 HTTP 요청에 해당 상태가 반영되지 않음)

쿠키를 이용해 데이터를 저장하고 원할때 이 데이터를 다시 불러와서 사용할 수 있다.

대신 특정 조건을 만족하는 경우에만 다시 사용할 수 있다.

• Domain: 쿠키 도메인 옵션과 서버 도메인 옵션이 일치해야 쿠키 전송 가능 (포트, 서브도메인, 세부경로는 포함하지 않음)
• Path: 세부 경로가 설정된 Path를 만족하면 전송 가능(설정된 Path보다 세부 경로가 더 존재해도 가능)
• MaxAge/Expires: 쿠키의 유효 기간을 설정하는 옵션. 옵션 유무에 따라 세션쿠키(옵션 없음)/영속성쿠키(옵션 있음)으로 구분
• Secure: 쿠키를 전송할때 사용하는 프로토콜에 따라 전송 가능여부 결정(true이면 HTTPS를 사용해야만 전송가능)
• HttpOnly: 자바스크립트에서 브라우저의 쿠키에 접근 가능한지 여부를 결정(true이면 JS에서 접근 불가)
• SameSite: Cross-Site 요청에 대한 보호 수준을 결정. Lax(Cross-site요청이면 Get메서드만 쿠키 전송 가능), Strict(Cross-site에서는 쿠키 전송 불가, Same-site에서만 가능), None(Cross-site에 대해 항상 쿠키 전송 가능, 대신 Secure옵션 필요)

❯ Session

웹 애플리케이션에서 클라이언트와 서버 간의 상호작용을 유지하는데 사용되는 메커니즘이다.

클라이언트가 서버에 요청을 보낼때 서버는 그 요청을 처리하고 클라이언트 상태 정보를 유지하기 위해 세션과 고유한 세션ID를 생성한다.

세션ID는 암호화된 후 쿠키를 통해 클라이언트에게 전달된다. 이후 주고받는 쿠키에 해당 세션ID를 포함하여 인증된 클라이언트임을 확인할 수 있다. 세션은 쿠키와 달리 서버측에 저장된다.

반대로 로그아웃의 경우에는 해당 세션을 종료해야한다. 따라서 서버측에서는 세션 정보를 삭제하고, 클라이언트는 해당 세션ID가 담긴 쿠키를 갱신해야한다. (서버가 클라이언트의 쿠키를 임의로 삭제할수는 없음)

❯ 웹 보안 공격

• SQL Injection: 악의적인 사용자가 웹 애플리케이션의 입력 폼 등을 통해 SQL쿼리를 조작하여 데이터베이스에 비정상적인 접근을 시도하거나 조작하는 공격
• XSS(Cross-Site Scripting): 웹 애플리케이션에 악성 스크립트를 삽입하여 다른 사용자의 브라우저에서 실행되도록 하는 공격으로, 사용자의 세션 정보를 탈취하거나 악의적인 동작을 수행할 수 있는 공격
• CSRF(Cross-Site Request Forgery): 인증된 사용자가 의도하지 않은 요청을 악의적으로 실행하게 하는 공격. 사용자의 권한으로 악의적인 동작이 수행되어 데이터 변조나 계정 탈취같은 피해를 입힐 수 있는 공격