Hashing/Cookie/Session

김소희·2023년 5월 12일

Hashing

가장 많이 쓰이는 암호화 방식 중에 하나인 해싱은 암호화만 가능하고 복호화는 불가능합니다.
해싱의 목적은 데이터를 사용하는 것이 아니라, 동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이 목적이기 때문에 유저의 비밀번호를 몰라도 해싱한 값이 일치하는지를 판단하여 비밀번호를 확인할 수 있고, 비밀번호를 모르기 때문에 위험도도 줄어들게 됩니다.
해싱은 해시 함수(Hash Function)를 사용하여 암호화를 진행하는데, 해시 함수는 입력 데이터를 해시값으로 매핑하는 역할을 합니다.

<해싱함수의 특징>

항상 고정된 크기의 출력 값을 생성합니다.
예를 들어, 256비트 해시 함수는 항상 256비트 크기의 해시 값을 반환합니다.
결과값이 문자열이라면 문자 길이는 항상 동일합니다.

다양한 입력에 대해 고르게 분포된 출력을 합니다.
서로 다른 문자열에 동일한 해시 함수를 사용하면 반드시 다른 결과값이 나옵니다.
입력 데이터의 작은 변화도 해시값의 크게 달라지도록 보장합니다.

충돌방지
충돌은 서로 다른 입력에 대해 동일한 해시값이 생성되는 현상을 말합니다. 좋은 해시 함수는 충돌이 발생할 확률을 최소화하여 보장합니다. 그러나 완전히 충돌을 피하는 것은 불가능하며, 충돌이 발생할 수 있는 경우에도 안전한 시스템을 구축하기 위해 충분한 크기의 해시값을 사용합니다.

동일한 문자열에 동일한 해시 함수를 사용하면 항상 같은 결과값이 나옵니다.

해시 함수는 일방향 함수로, 해시값을 통해 입력 데이터를 다시 복원할 수 없습니다. 즉, 해시값으로부터 원래 데이터를 유추하는 것은 매우 어렵습니다. 하지만 항상 같은 결과값이 나온다는 특성을 이용해 해시 함수를 거치기 이전의 값을 알아낼 수 있도록 기록해 놓은 표인 레인보우 테이블이 존재합니다. 레인보우 테이블에 기록된 값의 경우에는 유출이 되었을 때 해싱을 했더라도 해싱 이전의 값을 알아낼 수 있으므로 보안상 위협이 될 수 있습니다.

그래서 해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 더욱 어렵게 만드는 방법인 솔트(Salt)가 있습니다. 솔트를 사용하게 되면 해싱 값이 유출되더라도, 솔트가 함께 유출된 것이 아니라면 암호화 이전의 값을 알아내는 것은 불가능에 가까워집니다.

비밀번호 + 솔트	해시 함수(SHA1) 리턴 값 예시
'password' + 'salt'	'C88E9C67041A74E0357BEFDFF93F87DDE0904214'
'Password' + 'salt'	'38A8FDE622C0CF723934BA7138A72BEACCFC69D4'
'kimcoding' + 'salt'	'8607976121653D418DDA5F6379EB0324CA8618E6'

HTTP 프로토콜은 상태가 없는(stateless) 특징이 있는데 쿠키를 통해 상태 정보를 기억시켜주기 때문에 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용합니다.

HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 HTTP 요청 시 저장된 쿠키 데이터를 함께 전송합니다. 모든 요청마다 쿠키도 함께 전송되기 때문에, (특히 mobile data connections에서) 성능이 떨어지는 원인이 될 수 있습니다.

쿠키의 목적

세션 관리(Session management)
서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리

개인화(Personalization)
사용자 선호, 테마 등의 세팅

트래킹(Tracking)
사용자 행동을 기록하고 분석하는 용도

HTTP 요청을 수신할 때, 서버는 응답과 함께 Set-Cookie 헤더를 전송할 수 있습니다. 쿠키는 보통 브라우저에 의해 저장되며, 그 후 쿠키는 같은 서버에 의해 만들어진 요청(Request)들의 Cookie HTTP 헤더안에 포함되어 전송됩니다.

// 쿠키 만드는법
Set-Cookie: <cookie-name>=<cookie-value>

// 예시) 이 서버 헤더는 클라이언트에게 쿠키를 저장하라고 전달합니다.
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

// 이제 서버로 요청시 브라우저는 Cookie 헤더를 사용하여 저장했던 모든 쿠키들을 회신할 것입니다.
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

서버는 쿠키를 이용하여 데이터를 저장하고 원할 때 이 데이터를 다시 불러와 사용할 수 있습니다.
하지만 데이터를 저장한 이후 특정 조건들이 만족하는 경우에만 다시 가져올 수 있습니다.
이런 조건들은 쿠키 옵션으로 표현할 수 있습니다.

Cookie Options
Domain	서버와 '요청 도메인'이 일치하면 쿠키 전송	naver에서 받은 쿠키 google전송 불가
Path	서버와 '요청 세부경로'가 일치하면 쿠키 전송	Path에 설정된 URL를 만족하면 쿠키 전송
MaxAge or Expires	쿠키의 유효기간 설정	세션쿠키와 영속성 쿠키로 나누어짐
HTTP Only	스크립트의 쿠키 접근 가능 여부 결정	true인 경우, 자바스크립트에서 쿠키 접근불가
Secure	HTTPS 프로토콜에서만 쿠키 전송 여부 결정	true로 설정된 경우 HTTPS만 쿠키 전송
SameSite	CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정	Lax, Strict, None

웹 환경에서의 데이터 저장소 고려사항

웹 애플리케이션에서 정보나 데이터를 저장할 때는 저장 위치에 대한 신중한 고려가 필요합니다. 이때 두 가지 주요 기준점을 고려해야 합니다:

보안: 데이터의 중요성에 따른 보안 수준 결정
소멸성: 데이터의 지속 기간 (일시적 vs 영속적)

클라이언트 측 저장소 (Local PC)

웹 브라우저를 통해 클라이언트 측에서 데이터를 저장할 수 있는 방법들:

1. Cookie

메모리 쿠키: 브라우저 메모리에 임시 저장
파일 쿠키: 로컬 디스크에 암호화된 텍스트 파일로 저장 (소멸 시간 설정 가능)
단점: 크기 제한 (4096byte), 보안 취약성 (사용자 삭제 가능, 해커 파일 노출 위험)

2. Local Storage

Key-Value 형태로 데이터 저장
JSON 형태로 읽기/쓰기 가능
장점: 큰 저장 용량, 객체 형태의 의미 있는 데이터 저장 가능

서버 측 저장소

1. Server Memory - Session 객체

사이트 접속하는 각 사용자마다 고유하게 부여되는 메모리 공간
서버 재부팅이나 개발 코드 변경 시 소멸 후 재생성

2. Server Memory - Application 객체

사이트 접속하는 모든 사용자에게 공유되는 메모리 공간
서버 재부팅이나 개발 코드 변경 시 소멸 후 재생성

3. Server 영속적 저장 - 파일

텍스트 파일 등으로 데이터 저장
관리의 어려움이 있음

4. DB Server

보안과 영속적인 데이터 관리에 최적화
비용 발생 (클라우드 서비스 이용 시)

JSP에서 쿠키 구현 예시

쿠키 생성 및 전송

<%
// 서버에서 쿠키 생성
Cookie mycookie = new Cookie("cname","1004");

// 클라이언트에게 쿠키 전달 (서버 -> 클라이언트)
response.addCookie(mycookie);
%>

위 코드는 서버 측에서 쿠키를 생성하고 HTTP 응답을 통해 클라이언트에게 전달하는 기본적인 방법을 보여줍니다. 쿠키가 생성된 후에는 클라이언트의 브라우저에 저장되며, 이후 동일한 서버로의 요청 시 자동으로 함께 전송됩니다.

쿠키 읽기 및 정보 확인
서버에 접속한 클라이언트가 가지고 있는 도메인별로 기록되어 있는 쿠키를 읽어오는 방법:

<%
// 현재 도메인에 해당되는 모든 쿠키 정보 가져오기
Cookie[] cs = request.getCookies();

if(cs != null && cs.length > 0){
    for(Cookie c : cs){
        out.print(c.getName() + " > 쿠키 이름<br>");
        out.print(c.getValue() + " > 쿠키 값<br>");
        out.print(c.getMaxAge() + " > 만료 시간 (초)<br>");  // -1이면 세션 쿠키
        out.print(c.getDomain() + " > 도메인<br>");
        out.print("<hr>");
    }
}
%>

쿠키 속성별 의미

getName(): 쿠키의 이름을 반환
getValue(): 쿠키에 저장된 값을 반환
getMaxAge(): 쿠키의 만료 시간을 초 단위로 반환
- -1: 세션 쿠키 (브라우저 종료 시 삭제)
- 0: 즉시 삭제
- 양수: 해당 초 후 만료
getDomain(): 쿠키가 유효한 도메인을 반환

이 방식을 통해 서버는 클라이언트로부터 전송받은 모든 쿠키 정보를 확인하고, 필요한 데이터를 추출하여 사용자 식별이나 상태 유지 등의 작업을 수행할 수 있습니다.

쿠키를 사용하는 것은 보안에 취약하기 때문에 민감한 정보는 쿠키에 담아서는 안됩니다.

세션(Session)

쿠키가 데이터를 클라이언트에 저장하는 방식이었다면, 세션은 데이터를 서버에 저장하고, 데이터에 대한 ID를 암호화하여 쿠키에 담아서 클라이언트에 전달하여 사용하는 방식입니다.

세션 전달을 통해 서버는 클라이언트의 상태와 데이터를 유지하고, 클라이언트와의 연속성을 유지할 수 있습니다. 이를 통해 로그인 상태 유지, 장바구니 기능, 사용자 지향적인 경험 제공 등을 구현할 수 있습니다.

세션의 구조와 작동 원리

서버 메모리의 두 가지 객체

웹 서버(WAS)에는 두 가지 중요한 메모리 객체가 존재합니다:

session 객체: 사이트 접속하는 각 사용자마다 고유하게 부여되는 메모리 객체
application 객체: 사이트 접속하는 모든 사용자에게 공통으로 부여되는 메모리 객체

세션 객체의 특징

고유성 보장: 각 세션 객체마다 고유한 key 값(Session ID)을 가지며, 이 key는 클라이언트에도 전달됩니다
활용 범위: 로그인 ID, 장바구니(사용자마다 다른 내용), 사용자 정보, 접속 시간, 마지막 접속 시간 등을 저장
생명 주기: 서버 리부팅이나 개발 코드 변경 시 소멸되고 다시 생성됩니다

세션 전달 과정

1. 클라이언트의 첫 번째 요청

클라이언트 → 서버: http://192.168.0.29:8090/WebJSP/_Session.jsp 요청

2. 서버의 응답과 세션 생성

서버는 클라이언트의 요청을 받고 응답을 생성합니다
세션 ID(Session Identifier) 생성: 예) JSESSIONID: 43AE93C6D0A5CD99BBCF73149DC1FB14
세션 ID를 쿠키를 통해 클라이언트에 전달합니다

3. 세션 저장과 동기화

서버는 세션 ID를 사용하여 클라이언트의 상태와 데이터를 세션 저장소에 저장합니다
클라이언트와 서버 간 "동기화" 상태가 됩니다 (서로 연결된 상태)

4. 후속 요청 처리
클라이언트가 추가 요청을 보낼 때마다:

클라이언트의 세션 ID가 서버로 전달됩니다
서버는 세션 ID를 사용하여 해당 클라이언트의 세션 데이터를 찾습니다
필요한 정보를 가져와 응답을 생성하고, 필요시 세션 데이터를 업데이트합니다

실제 구현 예시

<%
   Date time = new Date();
   SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
%>

<h3>Session 객체 정보</h3>
session 객체 식별값: <%=session.getId() %>

<%
   time.setTime(session.getCreationTime());
%>
[session 생성된 시간]: <%= formatter.format(time) %>

<%
   time.setTime(session.getLastAccessedTime());
%>
[session 마지막 접속 시간]: <%= formatter.format(time) %>

이 코드는 실제로 세션의 핵심 정보들을 보여줍니다:

session.getId(): 고유한 세션 식별자
session.getCreationTime(): 세션이 생성된 시간
session.getLastAccessedTime(): 클라이언트가 마지막으로 접속한 시간

로그아웃 처리

로그아웃은 사용자가 현재 세션 또는 인증된 상태를 종료하고, 웹 애플리케이션에서 더 이상 접근할 수 없도록 하는 동작입니다.

로그아웃 시 필요한 두 가지 작업

서버 측: 세션 정보를 삭제 (session.invalidate())
클라이언트 측: 쿠키를 갱신 (set-cookie로 무효한 값으로 갱신)

로그아웃 과정

클라이언트: 로그아웃 버튼 클릭
→ 서버: key(Session ID)를 가져와서 해당 session 객체를 찾음
→ 서버: session.invalidate()로 세션 객체 소멸
→ 클라이언트: 쿠키 갱신으로 세션 ID 무효화

세션의 스코프(Scope) 활용

개발자로서 이해해야 할 중요한 개념은 세션의 스코프 범위입니다:

세션 스코프: 세션에 저장된 변수는 웹 어플리케이션 안의 모든 웹페이지에서 공유할 수 있습니다
요청 스코프: 요청 객체(request)에 저장된 변수는 해당 요청한 페이지에서만 사용할 수 있습니다

// 세션에 데이터 저장
session.setAttribute("userId", "admin123");
session.setAttribute("userName", "홍길동");

// 다른 페이지에서도 접근 가능
String userId = (String) session.getAttribute("userId");

세션 활용의 실용적 접근

세션에 저장하면 유용한 데이터

로그인 정보: 접속한 사용자의 ID가 있는지 없는지 확인
사용자 권한: 관리자, 일반사용자 등의 권한 정보
기본 사용자 정보: 이름, 등급 등 자주 사용되는 정보
임시 상태: 장바구니, 진행 중인 작업 상태

// 공통적으로 사용되는 로그인 체크 예시
<%
    String loginUserId = (String) session.getAttribute("userId");
    if (loginUserId == null) {
        // 로그인 페이지로 리다이렉트
        response.sendRedirect("login.jsp");
        return;
    }
%>

세션 사용 시 주의사항

그렇다고 모든 정보를 세션에 다 담아버리는 것은 위험합니다. 세션에 저장되는 데이터가 많을수록 서버 메모리가 그만큼 더 소모되기 때문입니다.

피해야 할 세션 사용:

대용량 파일이나 이미지 데이터
자주 변경되지 않는 상세 정보 (DB에서 필요할 때 조회하는 것이 효율적)
임시적으로만 사용되는 대량의 데이터

세션의 장단점

장점

서버에서 데이터를 관리하므로 보안성이 높습니다
클라이언트 측 저장 공간 제한이 없습니다
로그인 상태 유지, 장바구니 기능 등을 효과적으로 구현할 수 있습니다
웹 어플리케이션 전체에서 데이터 공유 가능 (세션 스코프)

단점

메모리 사용: 서버 메모리에 세션 정보를 저장하므로 사용자가 많으면 가용 메모리가 줄어들어 서버 성능이 저하될 수 있습니다
메모리 오버헤드: 세션에 너무 많은 데이터를 저장하면 메모리 소모가 급격히 증가합니다
확장성 제한: 여러 서버를 사용하는 분산 환경에서 확장성이 제한될 수 있습니다
보안 위험: 여전히 쿠키를 사용하므로 XSS 공격에 대비해야 합니다

해결 방안

토큰 기반 인증 시스템(JWT 등)을 사용하면 세션의 일부 단점을 보완할 수 있습니다.

실제 시나리오 예시

접속자 1000명이 있는 경우:

웹 서버에는 1000개의 고유한 세션 ID가 생성됩니다
각 세션 ID를 이름표로 달고 있는 session 객체도 1000개 생성됩니다
각 사용자는 자신만의 고유한 세션 공간을 가지게 됩니다

이처럼 세션은 웹 애플리케이션에서 사용자별 상태 관리를 위한 핵심 기술로, 쿠키의 보안 문제를 해결하면서도 효과적인 사용자 경험을 제공하는 중요한 메커니즘입니다.

김소희

개발자 소희의 노트

이전 포스트

HTTPS

다음 포스트

Hashing/Cookie/Session

Hashing

Cookie

웹 환경에서의 데이터 저장소 고려사항

클라이언트 측 저장소 (Local PC)

서버 측 저장소

JSP에서 쿠키 구현 예시

세션(Session)

세션의 구조와 작동 원리

서버 메모리의 두 가지 객체

세션 객체의 특징

세션 전달 과정

실제 구현 예시

로그아웃 처리

로그아웃 시 필요한 두 가지 작업

로그아웃 과정

세션의 스코프(Scope) 활용

세션 활용의 실용적 접근

세션에 저장하면 유용한 데이터

세션 사용 시 주의사항

세션의 장단점

장점

단점

해결 방안

실제 시나리오 예시

HTTPS

Hashing/Cookie/Session

0개의 댓글