2가지 주제
: 회원가입 및 로그인, 로그아웃같은 기능 구현. 이와 더불어 큰 개념인 인증(authentication)에 대해서 알아본다.
: 클라이언트, 서버, 데이터베이스 모두를 다루면서 풀스텍 개 발 환경에서의 전체적 흐름 및 작동을 직접 확인해본다.
HTTPS (HTTP + Secure)
: 인터넷에서 데이터를 주고 받을 수 있는 통신 프로토컬(http) 여기서 보안기능이 붙은것!
:HTTP 프로토컬 내용을 암호화
중요한 개인정보 쉽게 유출될 수 있어서 암호화를 시켜 정확한 키가 없다면 어떤 내용인지 알 수 없다.
인증서 : 데이터 제공자 신원 보장, 도메인 종속
요청을 받는다면 서버는 인증서와 함께 응답을 전송한다.
응답을 받은 클라이언트는 인증서/응답객체
도메인을 확인한다.
: 연결이 비공개로 설정되어 있지 않습니다.
이러한 경고창이 띄워져있다면 브라우저 인증서에서
해당 인증서를 발급한 CA 정보를 확인하고 CA가 발급한
인증서 아니라 안전하지 않다는것을 보여준다.
-> 브라우저는 인증서의 도메인와 데이터를 제공한 제공자의 도메인을 비교할 수 있기 때문에 중간자 공격을 감지하여 보안 위협으로부터 데이터 보호가 가능하다.
CA : 공인 인증서 발급 기관, 인증서를 발급한 공인된 기관
자격이 계속 유지되는게 아니라 자격을 박탈 당할 수도 있다.
비대칭 키 암호화 : 전혀 다른 한 쌍으로 암호화를 진행할 수 있고 복호화 가능하다.
(하나는 키를 숨기고 다른 하나는 공개해서)
hand shake: 서버를 ㅗ학인하고 공개, 인증서 정보 전달
비밀 키 생성 : client, server 각각 암호화해서 전송
상호 키 검증 : 만들어진 기능키 복호화하고 전달
HTTPS 사설 인증서 발급 및 서버 구현
:mkcert 라는 프로그램을 이용해서 로컬 환경에서 신뢰할 수 있는 인증서 만들 수 있다.
ubuntu
$ sudo apt install libnss3-tools
$ wget -O mkcert https://github.com/FiloSottile/mkcert/releases/download/v1.4.3/mkcert-v1.4.3-linux-amd64
$ chmod +x mkcert
$ sudo cp mkcert /usr/local/bin/
인증서 생성
.로컬을 인증된 발급기관으로 추가
mkcert -install
.로컬 환경에 대한 인증서 만들기
mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1
여기서 발급되는 ket, cert 스프린트에서 계속 활용하므로
저장경로 확인!
** key.pem -> 개인키이므로 git 커밋하지않고 암호처럼 다루어야 한다.
암호화의 기본 :Hashing
pw를 암호화를 해서 저장한다면 !!
암호화 : 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 '알고리즘'을 이용해 정보를 관리하는 과정.
어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로
변환하는 것.
1. 모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야 한다.
2. 최대한 해시 값을 피해야 하며, 모든값은 고유한 해시 값을 가진다.
3. 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.
외부에서 만들어진 알고리즘을 이용하여 hasing을 진행한다고 했을 때, 비번이 뚫린다해도 해시값이 달라서 악용될 여지에 대한 걱정을 크게 덜 수 있다.
salt
: 암호화해야 하는 값이 어떤 '별도의 값'을 추가하여 결과를 변형하는 것.
1.
암호화만 해놓는다면 해시된 결과가 늘 동일
해시된 값과 원래 값을 테이블(레인보우 테이블)로 만들어서 decoding 해버리는 경우도 생긴다.
2.
원본값에 임의로 약속된 '별도의 문자열'을 추가하여 해시를 진행한다면 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출되더라도 원본값을 보호할 수 있도록 하는 안전 장치
3.
기존: (암호화 하려는 값) => (hash 값)
salt사용 :(암호화 하려는 값) + (salt 용 값) => (hash 값)
salt 사용 시 주의점
-
salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.
-
사용자 계정을 생성할 때와 비밀번호를 변경할 때 마다 새로운 임의의 salt를 사용해서 해싱해야 한다.
-
salt는 절대 재사용하지 말아야 한다.
-
salt는 DB의 유저 테이블에 같이 저장되어야 한다.
유저마다 salt를 다르게 하면?
db에서도 각자 다르게 가지고 있어야 한다.
비밀번호를 받은 뒤에 패스워드를 암호화를 하는데
디비에서 받은 솔트값을 가지고 해싱을 해서 비교를 하게 되는 것. 그러면 좀 더 보안적으로 알고리즘이 노출이 되더 라도 안전할 수 있다.Cookie
: 인증에 필요한 기본 지식.
: 어떤 웹사이트에 들어갔을때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터
: 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단
: 해당 도메인에 대해 쿠키가 존재하면, 웹 브라우저는 도메인에게 도메인에게 http요청 시 쿠키를 자동으로 전달
: 삭제하지않는다면 사라지지 않는다는 특성이 있다.** HTTP는 stateless(무상태성)인데 어떻게
우리의 정보가 유지가 될까요?
쿠키덕분에!
cookie 이용법
:사용자 선호, 테마 등 장시간 보존해야 하는 정보 저장에 적합.
Domain : 작성된 요청과 도메인이 일치하는 경우 쿠키 전송
Path: 작성된 요청과 세부경로가 일치하는 경우 쿠키 전송
MaxAge or Expires : 쿠키의 유효기간 설정
:PC방에가서 로그아웃을 안 한 경우
:서버에서 쿠키에 MaxAge 혹은 Expires 옵션을 통해 유효 기한 지정에서 일정 시간 후 자동소멸할 수 있게 만들 수 있다.
HttpOnly: 스트립트의 쿠키 접근 가능 여부 결정
:쿠키는 <> script 태그로 접근 가능 -> XSS 공격에 취약!
Secure: HTTPS 프로토콜에서만 쿠키 전송 여부결정
SameSite: CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정
: 은행 사이트에 로그인 되어 있는 상태에서 CSRF 공격을 받은 경우
김코딩 은행사이트 로그인
은행은 김코딩에서 유효한 토큰할당
이때 스팸메일 통해 해커가 어떤 링크 클릭하게 만들어서
돈 이체하는 악의적인 공격이 발생 (CSRF 공격임)
이러한 공격을 방지할 수 있는 막을 수 있는 효과적인 옵션이다.
어떤 옵션을 쓰느냐에 따라 쿠키의 전송여부를 결정할 수 있다.
Lax : GET 요청에 대해서만 쿠키전송가능
Strict : 어떤 요청 메소드에 대해서도 쿠키 전송 불가
None : cors 대해서 모든 메서드 요청에 대해 쿠키 전송 가능 그래서 위험하다.
장점: 서버에 부담을 덜어줌
단점: 쿠키 그 자체는 인증이 아님
Session
: 서버가 client에 유일하고 암호화된 id를 부여
: 중요 데이터는 서버에서 관리
: 접속 상태를 서버가 가짐
: 접속 상태와 권한 부여를 위해 세션아이디를 쿠키로 전송
쿠키에는 그 데이터에 대한 아이디만 부여를 한다.
장점:
신뢰할 수 있느 ㄴ유저인지 서버에서 추가로 확인 가능
보안성을 가진다.
단점:
하나의 서버에서만 접속 상태를 가지므로 분산에 불리
(토큰을 배우면 불리한 점을 보안할 수 있다.)
: 서버의 메모리에 세션 데이터를 저장하고 있어서 가용 메모리가 줄어들어서 서버의 성능이 안좋아질 수 있다.
: 기존 쿠키를 완전히 대체한게 아니라서 여전히 쿠키를 사용하고 있다. xss 공격으로 인해 세션 쿠키가 탈취된다면 여전히 개인정보가 유출될 문제가 있다.
공공장소에 가면 반드시 로그아웃을 해야한다.
CSRF
web application security?
:개발자들이 웹사이트, 모바일 어플, 웹api 등을 만들 때에 해커들의 공격을 막기 위해서 보안은 필수사항!
: 여러가지공격들
- SQl ingection, XSS, CSRF
CROSS SITE REQUEST FORGERY
: 다른 사이트에서 유저가 보내는 요청을 조작한다.
이메일에 첨부된 링크를 누르면 내 은행게좌의 돈이 빠져나감.
: 해커가 직접 데이터를 접근할 수 없다.
공격을 하기 위한 조건
1. 쿠키를 사용한 로그인
유저가 로그인 했을 때, 쿠키로 어떤 유저인지 알 수 있어야 함.
2. 예측할 수 있는 요청/ 파라미터를 가지고 있어야함.
리퀘스트에 해커가 모를 수 있는 정보가 담겨있으면 안됨.
EX) 계좌이체에 사용되는 GET 요청
POST 요청으로 CSRF 공격하기
CSRF 방지하기 위한 방법
-CSRF 토큰 사용하기
서버측에서 CSRF 공격에 보호하기 위한 문자열을
유저의 브라우저와 웹 앱에만 제공
- Same-site cookie 사용하기
같은 도메인에서만 세션/쿠키를 사용할 수 있다. 