SEB_BE_43 / 23.03.14 회고

오늘

• 인증/보안 기초

HTTPS

= HTTP 요청을 SSL, TLS라는 알고리즘을 이용해 HTTP 통신을 하는 과정에서 데이터를 암호화하여 전송하는 방법.

인증과 권한이란
편의점에 맥주를 사러감.
신분증 검사를 진행하는 것 = 인증(내가 누구인지)
맥주를 살 수 있는 권한이 주어짐. = 권한

TSL / SSL 암호화 알고리즘도 버전이 업데이트가 됨.
SSL 버전에 참여하게 된 회사가 더 이상 참여하지 않게 되어서 이름을 TLS 로 변경.
그래서 TLS 가 더 상위버전.

암호화

제 3자가 서버와 클라이언트가 주고받는 정보를 탈취 할 수 없도록 암호화 하는 것.

HTTP는 요청 및 응답을 제 3자가 중간에서 탈취한다면 데이터의 내용을 다 확인 할 수 있었다.

출처 : 코드스테이츠 유어클래스

그렇기에 로그인정보나 개인정보 같은 공유되면 안되는 정보가 공유 될 수도 있다.

HTTPS 를 사용하면 데이터를 암호화 하여 전송하기 때문에 제 3자가 중간에서 응답을 가로채도 유출될 가능성이 적어진다.

출처 : https://www.hanbit.co.kr/media/channel/view.html?cms_code=CMS2766336216

비대칭 키, 대칭키

HTTPS 는 클라이언트와 서버가 데이터를 암호화하여 주고받기 위해 비대칭키 방식과 대칭키 방식을 혼용하여 사용한다.

대칭키

대칭키 : 하나의 키로 암호화, 복호화가 가능하기 때문에 보안에 취약. 하나의 키가 탈취되면 모두가 그 데이터를 사용 할 수 있기 때문에.

비대칭 키

각각 공개키와 비밀키를 가지고 있음. 나의 공개키로 암호화하면 상대의 비밀키로 복호화하는 방법.

서버의 공개키는 인증서안에 있는 공개키다.

인증서

인증서란?
브라우저에서 접속한 서버가 "제대로된" 서버임을 보장 = 전자 서명
브라우저와 서버가 통신할 때 암호화 할 수 있도록 서버의 공개키 제공.

위 예시는 네이버의 인증서다.
인증서는 서버의 신원을 보증 하여 우리가 접속한 사이트가 제대로된 사이트임을 보장하는 것.
이때 이를 보증할 수 있는 제 3자를 Certificate Authority, CA라고 부른다.

위 예시는 구글.

Hashing

입력받은 데이터를 고정된 길이의 데이터로 변환 할 때 이전 데이터를 알아 볼 수 없게 만드는 것.

데이터를 요청할 때 패스워드 같은 민감한 정보가 노출되면 안되기 때문에 Hashing 을 이용해서 암호화를 할 수 있다.

세 가지 철칙

• 모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야 한다.
  해독은 오래 걸려야하지만, 만드는 시간은 오래걸리지 않아야한다.

• 최대한 해시 값을 피해야하며, 모든 값을 고유한 값을 가진다.
  Hashing 이란 어떠한 수학적 알고리즘을 통하여 입력받은 문자열을 다른 문자열로 반환해 주기 때문에 극히 낮은 확률로 문자열은 다르지만 해시값이 같은 경우가 나올 수 있다.
  이런 경우를 최대한 발생하지 않도록 해야한다.

• 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야한다.

Cookie

Http 특징 = 무상태성을 보안하기 위해 만들어졌다
서버에서 클라이언트에 데이터를 Cookie 를 이용해 저장 할 수 있다.

데이터를 저장한 이후 아무때나 데이터를 가져 올 수 없다. 쿠키 옵션을 이용해 해당 조건을 만족 할 때만 가져 올 수 있게 할 수 있다.

HttpOnly

자바 스크립트에서 브라우저의 쿠키 접근 여부를 설정 할 수 있다.
해당 옵션이 true 라면 자바 스크립트는 쿠키에 접근이 불가능 하다.

기본으로는 false 로 지정되어있다.
자바 스크립트에서 접근이 가능 하게 될 경우 XSS 공격에 취약해진다.

XSS(Cross Site Scripting) 공격이란?

원래는 CSS 라고 하는게 맞지만 Cascading Style Sheets 의 약어로 CSS 가 이미 사용되고 있어 XSS 라고 한다.

게시판이나 웹 메일 등에 자바 스크립트와 같은 스크립트 코드를 삽입 해 원치않는 기능이 작동 될 수 있다.

이 과정에서 해당 페이지를 이용하는 사용자의 쿠키 정보나 세션 ID 를 획득 할 수 있다.

Domain

www.naver.com 처럼 서버에서 접속 할 수 있는 이름을 도메인 이라고 한다.
하지만 쿠키 옵션에서 도메인은 www 같이 도메인 앞에 추가로 작성되는 서브 도메인을 포함하지 않는다.

포함하지 않는 정보 : 포트, 서브도메인, 세부 경로

그래서 도메인은 naver.com 이 된다.

해당 옵션이 존재한다면 쿠키의 도메인과 서버의 도메인이 일치해야 쿠키를 전송 할 수 있게 된다.

Path

http://www.localhost.com:8080/users/login 이라면 세부경로는 /users/login 이 된다.
Path 옵션의 특징은 설정된 path 를 만족하는 경우 path가 추가로 더 존재하더라도 상관없이 쿠키를 보낼 수 있다.

예를 들어서 /users/abc 라고 한다면 쿠키를 보낼 수 있지만, /abc/aaa 라고 한다면 /users 를 만족하지 않으므로 쿠키를 전송 할 수 없다.

MaxAge or Expires

쿠키의 유효기간을 정하는 옵션이다.
MaxAge 는 앞으로 몇초동안 쿠키가 유효한지를 설정하고, Expires 는 언제까지 유효한지 날짜를 설정한다.

지정된 시간, 날짜가 초과되면 자동으로 파괴된다.

• 세션 쿠키 : MaxAge, Expires 옵션이 없는 쿠키. 브라우저가 사용 중일 때 사용 할 수 있는 임시쿠키이다. 브라우저 종료와 동시에 쿠키 삭제된다.

• 영속성 쿠키 : 브라우저의 종료여부와 상관없이 MaxAge, Expires 에 지정된 시간만큼 사용가능하다.

Secure

쿠키를 전송해야 할 때 사용하는 프로토콜을 설정한다.
true 일 경우 HTTPS 프로토콜일 경우만 쿠키를 전송한다.

SameSite

Cross-Origin 요청을 받은 경우 요청에서 사용한 메서드와 옵션의 조합으로 전송 여부를 결정한다.

옵션

• Lax: Cross-Origin 요청이라면 GET 메서드만 쿠키 전송 가능.

• Strict : Cross-Origin 이 아닌 same-site 인 경우에만 쿠키를 전송 할 수 있다.

• None : 항상 쿠키를 보내 줄 수 있으나, Secure 옵션 true 여야한다.

Session

접속 상태를 서버가 가짐. 쿠키만으로는 부족해서.

예를 들어서 인터넷 쇼핑을 하기 위해 로그인을 했는데, 장바구니에 물건을 담을 때 인증을 또 해야할까?

서버에서 해당 유저가 인증에 성공했다는 것을 알고 있다면 매번 로그인을 할 필요가 없어진다.

사용자가 인증에 성공한 상태를 세션 이라고 부른다.

• 서버는 일종의 저장소에 세션을 저장한다.(in-memory, 세션 스토어 등)
• 세션이 만들어지면 세션 ID 도 만들어진다.

세션ID 를 클라이언트에서 쿠키에 저장해 매번 세션 아이디를 전달하므로 인증을 증명할 수 있다.

SQL Injection

데이터베이스에서 임의의 SQL 문을 실행 할 수 있도록 명령어를 삽입하는 공격 유형이다.

select * from users
where auth='admin'
and id = 'kimcoding';

이 있다고 생각해보자.

select * from users
where auth='admin'
and id =' ' or '1'='1';

라고 공격자가 변경한다면 항상 참이 되어 로그인에 성공 할 것이다.

대응 방안

1. 입력(요청) 값 검증

2. Prepared Statement 구문 사용

3. Error Message 노출 금지