이 정도는 해야 제대로 된 거 아닌가 싶다.
1. 비밀번호/개인 정보 암호화
당연하다. 그런데 너무 안 지킨다. 최근 일어난 일련의 보안 침해 사례를 가만히 보면서
'과연 비밀번호를 암호화했을까?' 하는 고민에 빠졌다.
이에 대해서는 내가 내부 개발자도 아니고 공식적인 입장을 들은 바도 없으므로
그냥 '과연? 과연?'이라고 추측만 할 뿐이지만
만약 비밀번호나 개인 정보를 암호화하지 않았다면
정말 안타까운 일이 아닐 수 없다.
물론 가만히 있는 사이트를 먼저 침해한 해커가 나쁘다.
그런데 웹 사이트도 만일의 사태에 항상 대비할 책임은 있다.
기본적인 비밀번호, 개인 정보까지 암호화를 하지 않았다면
정말 유감이다.
2. 비밀번호 솔트
이건 선택 항목이지만 필수처럼 생각하고 꼭 적용하기를 바란다.
비밀번호 솔트를 적용하면 레인보우 테이블 같은 공격을 피할 수 있다.
예를 들어 해커가 충분히 많은 값을 입력해 레인보우 테이블 공격을 하면
비밀번호 암호화를 했다 하더라도 비밀번호를 역추적할 수 있다.
하지만 여기에 소금(salt)을 뿌려서 해커를 혼란케 하면
레인보우 테이블 공격조차도 무력화할 수 있다.
즉, 자동화된 프로세스만으로는 비밀번호를 알아내 사용자 계정에 침입하기가
몹시 어려워지는 것이다.
3. 보안 프로토콜의 사용
익명 접근이 가능한 곳에서는 http 프로토콜을 사용하더라도 상관없지만
일단 로그인한 후에는 https 프로토콜을 사용해 패킷을 암호화하는 게 좋다.
4. 사용자 크리덴셜 요청
사용자 인증 정보를 제공해 한번 로그인하면 쿠키가 만료될 때까지
자동 로그인을 지원하는 사이트라 하더라도
주요 개인 정보에 접근해야 할 때는 꼭 별도로 로그인을 거치게 하는 게 좋다.
예를 들어 온라인 쇼핑 사이트라면 카트에 담는 것까지는 익명으로 또는
자동 로그인 인증 정보를 바탕으로 얼마든지 지원할 수 있지만
실제 구매 시에는 항상 로그인을 명시적으로 요청하는 게 좋다. 이렇게 하지 않으면
중간자 공격 등을 통해 다른 사용자 계정에 침입한 해커가
사용자의 주요 개인 정보를 마음대로 사용해 이를테면
값 비싼 물품을 웹사이트에서 구매하거나
개인 정보를 빼갈 수 있다.
5. 웹 사이트의 권한 영역을 세분화한다
4번과도 일맥상통하는 얘기인데 이를테면 guest/user/purchaser/admin 등으로
웹 사이트의 권한 영역을 세분화하고 각 권한 역할에 따라 보안을 강화한다.
6. 기왕이면 보안 프레임워크를 활용한다.
보안 프레임워크를 활용하지 않으면 전체 사이트에 보안을 적용하기가 몹시 어렵다.
예를 들어 한 곳에는 보안을 제대로 적용했지만 다른 곳에서는 특정 보안 요소를 빼먹기 일쑤고
이를 검증하기도 쉽지 않으며, 더불어 똑같은 보안 요소를
적용하기 위한 코드를 반복적으로 적용(boilerplate 코드의 양산)해야 한다.
따라서 가능하다면 스프링 시큐리티 같은 프레임워크를 사용해 사이트 전체에 보안을
일관되게 적용하는 게 좋다.
7. 지금까지의 내용은 모두 내가 번역한 스프링 시큐리티 3 책 (위키북스)에 나오는 내용들이다.
-끝-
Posted by joshy21
