12/9[TIL]Authentication

HTTPS

http 프로토콜 내용을 암호화한 것이다.

 

https의 특징에는 인증서 / CA / 비대칭 키 암호화가 있다.

 

인증서

도메인 종속되며 데이터를 보내준 서버가 정말 데이터를 보내준 서버인지 인증 확인하는 용도이며 데이터 제공자 신원보장을 한다고 생각하면 된다.

서버는 인증서와 함께 응답을 전송하고 그럼 응답을 받은 클라이언트는 인증서에 작성된 도메인과 응답객체에 작성된 도메인을 비교한다. 만약 도메인이 같지 않다면 이는 제 3자가 개입 된 상황이기 때문에 이는 클라이언트가 서버가 아닌 다른 제공자인 것을 이러한 경우 알 수있다.

 

CA

공인인증서 발급기관이다.

 

비대칭 암호화 방식

전혀 다른 키한쌍으로 암호화 및 복호화가 가능하다. 어느 한 키로 암호화를 진행했다면 복호화는 다른 키로 가능하다.

하나는 비밀로 숨겨두고 다른 하나는 클라이언트에 공개해 데이터를 안전하게 전송할 수 있게 한다.

하지만 모든 통신에 대해서 공개키 방식을 사용하는 것이 아닌데 연산이 복잡하기에 통신의 초창기에서만 비밀키를 생성하기 위해 사용한다.

출처 : https://urclass.codestates.com/dada8af3-1f90-443b-81a0-9aa8f46c919b?playlist=426

 

Encryption(암호화)

일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 알고리즘을 이용하여 정보를 관리하는 과정으로 hashing과 salt를 알아보고자 한다.

 

 

Hashing

어떠한 문자열에 임의의 연산을 적용하여 다른 문자열로 변환하는 것으로 지켜야 할 조건들이 있는데

 

1. 모든 값에 대해 해시 값을 계산하는 데 오래 걸리지 않아야 한다.

2. 최대한 해시 값을 피해야 하며 모든 값은 고유한 해시 값을 가진다.(만약의 중복 값의 경우 때문에)

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

 

 

Salt

암호화해야 하는 값에 어떤 별도의 값을 추가하여 결과를 변형하는 것으로 salt를 사용하면 좋은 점은 

 

1. 암호화만 해놓는다면 해시된 결과과 늘 동일하기에 해시된 값과 원래 값을 테이블(레인보우 테이블)로 만들어 디코딩 해버리는 경우가 생긴다.

2. 원본 값에 임의로 약속된 별도의 문자열을 추가하여 해시를 진행한다면 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출되더라도 원본 값을 보호할 수 있도록 하는 안전장치라고 생각하면 된다.

 

구조적으로 본다면 암호화 하려는 값 + 솔트 값 => 해시 값 으로 표현할 수 있다.

 

salt를 사용할 시 주의점이 존재하는데 

salt는 유저와 패스워드 별로 유일한 값을 가져야 하며 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 salt를 사용하여 해싱해야 한다. 그리고 salt는 절대 재사용하지 말아야 하며 salt는 DB의 유저 테이블에 같이 저장되어야 한다.

 

 

 

Cookie

어떤 웹사이트를 들어갔을 때 서버가 일방적으로 클라이언트에 전달하는 작은 데이터로 서버가 웹브라우저에 정보를 저장하고 불러올 수 있는 수단이다. 해당 도메인에 대해 쿠키가 존재하면 웹브라우저는 도메인에게 http 요청 시 쿠키를 함께 전달하며 삭제를 하지 않는 다면 사라지지 않는다. 그렇기에 사용자 선호, 테마 등 장시간 보존해야하는 정보 저장에 적합하다. 예로는 로그인 상태유지 것이 있다. 쿠키는 중요한 정보이기 때문에 해싱 처리 되어 있는 경우가 많다. 

쿠키는 유저가 삭제하지 않고 유효 기간도 정해지지 않는다면 영원히 존재할 수 있다. 그렇기에 인증정보를 담아 보관하기에는 좋지 못한 방법이라고 볼 수 있다.

 

출처 : https://urclass.codestates.com/dada8af3-1f90-443b-81a0-9aa8f46c919b?playlist=426

MaxAge or Expires 같은 경우 설정한 유효기간이 지나면 자동으로 소멸되는 메서드이다.

HttpOnly는 스크립트의 쿠키 접근 가능 여부 결정을 하는 메서드로써쿠키는 <script> 태그 접근 가능하기에 이를 방비하기 위한 옵션이라고 생각하면 되고 결론적으로는 쿠키에는 앞에서 언급했다시피 민감한 정보나 개인정보는 포함하지 않는 것이 좋다.

Samesite 같은 경우 GET 메서드 요청만 쿠키전송가능한 lax와 쿠키 전송이 불가능한 strict 그리고 모든 메소드 요청에 대해 쿠키 전송이 가능한 none이 있다. none 옵션을 사용하기 위해서 https와 secure 쿠키 옵션이 필요하다

 

 

Session

서버에 client에 유일하고 암호화된 id를 부여하고 중요한 데이터는 서버에서 관리한다. 앞서 쿠키는 client에 저장한다고 했는데 다른 점이다. 

보안의 위협 때문에 중요 유저 데이터를 암호화된 세션 아이디로 저장한다. 이 것을 Set-Cookie 메소드에 담아서 client에 전달해준다. 그 후부터는 저장된 세션 아이디로 필요한 작업을 수행하게 된다.

Cookie와 Session의 차이점을 보자면

출처 : https://urclass.codestates.com/2a42f462-da59-4b21-9b16-a7913b88efd4?playlist=426

상대적으로 변조가 쉬운 cookie 보다 서버에서 여러 번 검증을 하는 세션 방식은 조금 더 좋은 보안 방식을 가진다.

하지만 하나의 서버에서만 접속 상태를 가지므로 분산에 불리하나 이 부분을 보완할 토큰이란 것이 존재한다.

 

그리고 Session의 단점이 있는데...

서버의 메모리에 세션 정보를 저장하기에 가용 메모리 양이 줄어든다. 서버의 성능이 안 좋아질 수도 있다.

세션은 기존의 쿠키를 완전히 대체한 것이 아니기 때문에 여전히 쿠키를 사용한다. 쿠키의 한계를 그대로 가지고 있다. xss공격 등을 유의해야 한다. 공공장소에 가서 로그아웃을 필히 해주어야 하는 것도 똑같은 맥락이라고 볼 수 있다.

 

 

Web application Security?

개발자들이 웹사이트, 모바일, 어플, 웹 API 등을 만들 때에 해커들의 공격(SQL injection / XSS / CSRF)을 막기 위해서 보안은 필수사항이다.

 

CSRF를 알아보자면 쉽게 말해 주소가 다른 사이트에서 요청을 조작하는 것이다.

다른 오리진에서 유저가 보내는 요청을 조작하는 것으로(이메일에 첨부된 링크를 누르면(내 은행계좌로 요청을 보내는 악성코드) 내 은행계좌에서 돈이 빠져나가는 맥락과 같은 것이다.) 해커가 요청만 조작하는 것으로 벌인 일이다.

해커가 직접 데이터를 접근할 수 없다(다른 오리진이기 때문에 응답에 직접 접근할 수 없다)

 

CSRF 공격을 하기 위한 조건에는

쿠키를 사용한 로그인으로

유저가 로그인했을 때 쿠키로 어떤 유저인지 알 수 있어야 한다.

 

그리고 예측할 수 있는 요청/parameter를 가지고 있어야 한다.

응답에 해커가 모를 수 있는 정보가 담겨있으면 안 된다는 것이다.

 

Get 요청으로 CSRF 공격하기 -> (ex) 계좌이체에 사용되는 GET 요청)

Post 요청으로 CSRF 공격하기 -> (ex) 비밀번호 변경에 사용되는 POST 요청)

 

그렇다면 해결책에는 무엇이 있을까?

 

CSRF 토큰 사용하는 것이다.

이는 서버 측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공한다.

 

Same-site cookie 사용하는 것이다.

같은 도메인에서만 세션/쿠키를 사용할 수 있다.