부트캠프

인증/보안 - 기초

hunm719 2023. 3. 15. 20:54
1.HTTPS

 -HTTPS(Hyper Text Transfer Protocol Secure Socket Layer) : 암호화를 사용하여 웹사이트와 사용자 간의 통신을 보호하는 보안 프로토콜

 -HTTPS는 아래의 목적을 가지고 사용함

  ● 암호화(encryption)

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

    ○ HTTPS에서는 클라이언트와 서버가 데이터를 주고받을 때는 대칭키를 사용하고, 대칭키를 주고받을 때는 비대칭키 방식을 사용함

      ◎ 대칭키 방식 : 양쪽이 공통의 비밀키를 공유하여 데이터를 암호화 및 복호화하는 것(암호화 비밀키 = 복호화 비밀키)

      ◎ 비대칭키 방식 : 각각 공개키와 개인키를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인키로 복호화하는 것(암호화 비밀키 != 복호화 비밀키)

 

  ● 인증서

    ○ 서버의 신원을 보증하는 역할

    ○ 이를 보증할 수 있는 제 3자를 CA(Certificate Authority)라고 하며, 인증서를 발급해주는 공인된 기관들을 말함

    ○ 브라우저들은 인증된 CA가 발급한 인증서를 이용하여 데이터를 제공하는 안전한 서버를 사용자가 사용하도록 유도함

 

 + 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 TLS 혹은 SSL이라고 함(*SSL과 TLS는 사실상 동일한 규약을 뜻하며 SSL이 표준화되며 바뀐 이름이 TLS)

 

 + 복호화(decryption)

더보기

  ● 암호화된 데이터를 원래의 평문으로 되돌리는 과정

    ○ 대칭키 암호화의 복호화

      ◎ 대칭키는 데이터를 암호화할 때 사용된 비밀키와 동일한 비밀키를 사용하여 복호화를 수행함

    ○ 비대칭키 암호화의 복호화

      ◎ 비대칭키는 암호화와 복호화에 사용되는 키가 서로 다름. 공개키와 개인키를 이용하여 데이터를 암호화하고, 이를 복호화하기 위해서는 반대의 키를 사용해야함. 즉, 공개키로 암호화된 데이터는 개인키로만 복호화할 수 있음

 

2.Hashing

 -어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것

 -Hashing의 세가지 철칙

  • 해시값을 해독(decoding)할 때는 긴 시간이 걸려야 하지만, 해시값을 만드는 데엔 오래 걸리지 않아야 함
  • 해시값들은 최대한 다른 해시값을 피해야 하며, 모든 값은 고유한 해시값을 가짐
  • 아주 작은 단위의 변경이 있더라도 반환되는 해시값은 완전히 다른 해시값을 가져야함

 -예를 들어 입력 받은 문자열을 입력받은 숫자의 값만큼 알파벳 순서를 건너뛴 문자로 변환하는 메서드라면 abcde, 3을 입력받을 경우 defgh 가 출력될 것임

 -하지만 암호화만으로는 해시된 결과가 매번 동일하기에(abcde, 5를 입력하면 값이 항상 defgh) 해시값과 원본값을 대조한 테이블(*Rainbow table)이 있다면 쉽게 원본 비밀번호를 알아낼 수 있음

 -추가적인 보안 기술(Salt와 Spice)를 사용하면 보안을 더욱 강화시킬 수 있음

 

 -Salt : 암호화해야 하는 값에 어떤 '별도의 값'을 추가하여 결과를 변형하는 것

  • Salt의 길이와 값은 보안성을 강화하기 위해 임의로 설정되며, 보통은 8~16바이트 길이의 무작위 문자열이 사용됨
  • Salt값은 일반적으로 데이터베이스의 사용자 계정과 함께 저장되고, 절대 재사용되어선 안 됨

 +Rainbow table : 해시 함수의 취약점을 이용하여 해시값을 역산하여 비밀번호를 찾는 공격 기법 중 하나로, 대규모의 미리 계산된 해시값의 집합을 사용하여 비밀번호를 빠르게 추측함. 미리 계산된 해시값과 해당 값에 대응하는 입력 값을 짝지어 놓은 테이블(=Rainbow table)을 사용해 저장된 해시값과 일치하는 해시값을 찾아내고, 이를 통해 원래 입력 값을 추측하는 방식

Salt 와 Hashing을 사용하는 과정

 

3.Cookie

 -쿠키는 서버에서 클라이언트에 데이터를 저장하는 방법 중 하나

 -서버가 원한다면, 서버는 클라이언트에서 쿠키를 이용하여 데이터를 가져올 수 있음

 -그러므로 쿠키를 이용하는 것은 단순히 서버에서 클라이언트에 쿠키를 전송하는것 뿐만 아니라, 클라이언트에서 서버로 쿠키를 전송하는 것도 포함됨

 

 -쿠키는 데이터를 저장한 이후 특정 조건들이 만족하는 경우에만 다시 가져올 수 있으며, 조건들은 쿠키 옵션으로 표현함

  ● Domain

    ○ 쿠키 옵션에서 도메인 정보가 존재한다면 클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있음.

    ○ 쿠키 옵션에서 도메인은 포트 및 서브 도메인 정보, 세부 경로를 포함하지 않음

 

  ● Path

    ○ 설정된 Path를 전부 만족하는 경우 요청하는 Path가 추가로 더 존재하더라도 쿠키를 서버에 전송할 수 있음

    ○ Path 가 /users 로 설정되어 있고, 요청하는 세부 경로가 /users/hunm719 라면 서버로 쿠키 전송이 가능함

    ○ 하지만 요청하는 세부 경로가 /posts/hunm719 라면 Path 옵션(/users)를 만족하지 못하므로 서버로 전송할 수 없음

 

  ● MaxAge or Expires

    ○ 쿠키의 유효 기간을 정하는 옵션

    ○ MaxAge 는 앞으로 몇 초 동안 쿠키가 유효한지 설정하는 옵션

    ○ Expires 는 언제까지 유효한지 Date를 지정하는 옵션

    ○ 클라이언트의 시간을 기준으로 지정된 시간, 날짜를 초과하면 쿠키는 자동으로 삭제됨

    ○ 세션 쿠키(Session Cookie) : MaxAge 또는 Expires 옵션이 없는 쿠키로, 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키이며, 브라우저를 종료하면 삭제됨

    ○ 영속성 쿠키(Persistent Cookie) : 브라우저의 종료 여부와 상관없이 MaxAge 또는 Expires 에 지정된 유효시간만큼 사용가능한 쿠키

 

  ● Secure

    ○ 쿠키를 전송해야할 때 사용하는 프로토콜에 따라 쿠키의 전송 여부를 결정하는 옵션

    ○ true로 설정 시, 'HTTPS' 프로토콜을 이용하여 통신하는 경우에만 쿠키를 전송할 수 있음

    ○ 해당 옵션이 없다면 프로토콜에 상관없이 모두 쿠키를 전송할 수 있음

 

  ● HttpOnly

    ○ 자바스크립트에서 브라우저의 쿠키에 접근할 수 있는지 여부를 결정하는 옵션

    ○ true로 설정 시, 자바스크립트에서는 쿠키에 접근할 수 없음

    ○ default값은 false이며, false로 설정 시 자바스크립트에서 쿠키에 접근할 수 있음('XSS'공격에 취약함)

 

  ● SameSite

    ○ Cross-Origin 요청을 받은 경우, 요청에서 사용한 메서드와 해당 메서드 옵션의 조합으로 서버의 쿠키 전송 여부를 결정하는 옵션

    ○ Lax 로 설정 시, Cross-Origin 요청이면 'GET' 메서드에 대해서만 쿠키를 전송할 수 있음

    ○ Strict 로 설정 시, Cross-Origin 이 아닌 same-site 인 경우에만 쿠키를 전송할 수 있음

    ○ None 으로 설정 시, 항상 쿠키를 전송할 수 있지만 쿠키 옵션 중 Secure 옵션이 필수적으로 필요함

    *same-site 는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우를 말하며 이 중 하나라도 다르다면 Cross-Origin으로 구분됨

 

 

4.Session

 -세션은 웹사이트와 사용자 간의 통신을 유지하는데 사용되는 개념

 -서버가 Client에 유일하고 암호화된 ID를 부여하고, 중요한 데이터는 서버에서 관리함

세션 기반 인증 로그인

  • 사용자가 인증에 성공한 상태를 세션이라고 부름
  • 서버는 일종의 저장소에 2번처럼 세션을 저장함
  • 세션이 만들어지면, 3번처럼 각 세션을 구분할 수 있는 세션 아이디도 만들어지는데, 보통 클라이언트에서 세션 성공을 증명할 수 있는 수단으로써 4번처럼 세션 아이디를 전달함
  • 이 때 웹사이트에서 로그인을 유지하기 위한 수단으로 쿠키를 사용하고, 쿠키에는 서버에서 발급한 세션 아이디를 저장함
  • 5번처럼 쿠키를 통해 유효한 세션 아이디가 서버에 전달되고, 6번처럼 세션 스토어에 해당 세션이 존재한다면, 7,8번처럼 서버는 해당 요청에 접근 가능하다고 판단함

쿠키와 세션의 차이점

 

5.웹 보안 공격

5-1.SQL Injection

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

 -응용 프로그램의 보안상의 허점을 이용해 데이터베이스를 비정상적으로 조작하며, 기록이 삭제되거나 데이터가 유출될 수 있음

 

 -SQL Injection 대응 방안

  ● 입력(요청)값 검증

    ○ 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하는 방식으로 대응

    ○ 보안에서 화이트리스트란 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식

 

  ● Prepared Statement 구문 사용

    ○ Prepared Statement 구문을 사용하면 사용자의 입력이 SQL 문으로부터 분리되어 SQL Injection을 방어할 수 있음

    ○ 사용자의 입력값이 전달되기 전에 데이터베이스가 미리 컴파일하여 SQL을 바로 실행하지 않고 대기하며, 사용자의 입력값을 단순 텍스트로 인식함

 

  ● Error Message 노출 금지

    ○ 공격자는 DB의 Error Message를 통해 데이터베이스의 정보를 얻을 수 있으니 에러가 발생한 SQL 문과 에러 내용이 클라이언트에 노출되지 않도록 별도의 에러핸들링이 필요함

 

 

5-2.CSRF(Cross-Site Request Forgery)

 -다른 사이트(cross-site)에서 유저가 보내는 요청(request)를 조작(forgery)하는 것

 -다른 오리진이기 때문에 response에 직접 접근할 수 없으므로 해커가 직접 데이터에 접근할 수 없음

 

 -CSRF 대응 방안

  ● CSRF 토큰 사용하기

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

 

  ● Same-site cookie 사용하기

    ○ 같은 도메인에서만 세션/쿠키를 사용할 수 있도록 설정

 

 

 

 

 

-이미지 및 내용 출처 : code states

저작자표시 (새창열림)