쿠키와 세션 / 로그인 로직

HTTP는 연결성이 없다. 하지만 로그인을 할 때 사용자가 아이디와 비밀번호를 보내면 A 사용자와 B 사용자를 구분할 수 있어야 한다. 로그인은 동적 페이지이기 때문에 웹 서버가 WAS로 데이터를 넘겨주고 WAS는 로그인 검증을 하게 된다.

DB의 데이터와 비교해서 진짜 사용자인지 검증을 하고 로그인 성공 후 다음과 같은 요청을 한다.

"이제부터는 이 포스트잇을 붙이고 로그인 해!"

여기서 말하는 포스트잇은 데이터를 요청할 때 사용자를 구분할 수 있게끔 하는 일종의 정보이다.

쿠키(Cookie)

위에서 말한 사용자 구분 정보가 바로 쿠키이다. 쿠키를 사용하는 이유는 웹 서버가 사용자 정보를 저장하고 있지 않기 때문에 매번 로그인 하기 불편하여 편리성을 위하여 쿠키에 저장해 놓았다가 다음번에 사용자가 로그인 할 때 쿠키의 정보로 로그인하는 것이다. 이러한 쿠키를 직접 붙이는 건 서버 측이 아닌 클라이언트이다.

쿠키 변조

하지만 클라이언트의 정보를 곧이 곧대로 믿는 것은 위험한 일이다. 쿠키는 클라이언트 측 정보이기 때문에 쉽게 변조가 가능하고 이를 악용할 수 있기 때문이다.

세션

세션은 쿠키와 달리 서버 측 정보이다. 쿠키처럼 사용자의 정보를 저장하지만 그렇다고 해서 쿠키가 쓰이지 않는 것은 아니고 쿠키에 세션 아이디를 같이 포함하여 전달한다. 쿠키에서 넘어온 세션 아이디로 검색하여 사용자를 인증한다.

하지만 위에 말했듯이 쿠키는 변조가 가능하므로 세션 아이디를 변조해서 서버에 전달할 수 있기 때문에 세션 아이디는 난수값으로 생성된다. ( 아마 의사 난수일 것이다. 소프트웨어는 난수를 생성할 수 없기 때문에..)

만약 세션 아이디를 유추할 수 있게 만들면 세션 아이디로 다른 사용자의 정보를 탈취할 수 있다. 세션 아이디를 알게 되면 비밀번호 없이 그 사용자로 접속할 수 있기 때문에 공격자가 굉장히 많이 노린다.

(+세션은 서버 정보가 맞지만 쿠키로 같이 전달되는 세션 id는 클라이언트 정보가 맞다.)

 

로그인 과정 분석

1) 식별 - 그 사람의 정보를 가져오는 것

식별 정보는 대표적으로 아이디가 있으며 primary key(기본키 / 중복 x 고유해야 함)

2) 인증 - 그 사람의 정보가 맞는지 확인하는 것

인증 정보는 대표적으로 비밀번호, OTP가 있으며 중복되어도 괜찮다.

로그인 로직

1) 식별 / 인증 동시 - SQL 질의문 한 번으로 식별과 인증을 동시에 한다.

e.g.) id = user , pw = 1234 인 경우

select * from member where id = 'user' and pw = '1234'

if ( SQL 질의 결과가 존재한다면 )

          로그인 성공

else

          로그인 실패

 

2) 식별 / 인증 분리 

e.g.) id = user , pw = 1234 인 경우

select pw from member where id = 'user'

if ( 사용자가 입력한 패스워드와 db의 패스워드가 일치한다면 )

          로그인 성공

else

          로그인 실패

+)Hash를 적절히 조합해보자 :)