[Section 4] 인증/보안 기초

현이·2023년 5월 10일
0

백엔드 부트캠프 TIL

목록 보기
30/37
post-thumbnail

사진은 학교 도서관에서 공부하다 보인 너무 예쁜 무지개 사진! - 학교 들어간지 2일차인가 3일차 정도밖에 안됐었는데 공부하겠다고 도서관가서 코테 문제 푼게 지금봐도 신기함.. 물론 작심삼일이었지만 예쁜 무지개를 얻었으니^0^
새로운 섹션에 들어왔다 드디어! 섹션3과는 독립적으로 공부할 수 있어 새로운 마음으로 다시 열심히 하게되었다. 평소에 많이 쓰는 보안 용어들에 대한 정확한 개념을 공부하니 더 재미있었던것 같기도 하다 ㅎㅎ



HTTPS

  • HTTP + Secure

  • HTTP 통신 과정에서 데이터 암호화해서 전송
    +) HTTP 는 stateless

  • 대칭키 방식 + 비대칭 키 방식
    -> 대칭 키 방식: Client와 Server가 데이터 주고받을 때
    -> 비대칭 키 방식: 대칭키를 주고받을 때

  • 서버로부터 응답받을 때 인증서도 같이 받음! (서버의 신원 보증 역할)

  • 인증서 제공은 CA(Certificate Authority)가

  • 인증서는 CA의 비밀키로 암호화되어있고, 클라이언트는 CA의 공개키로 복호화해서 서버 믿을만한지 확인
    => 이렇게 CA를 통해 서버 인증하고 데이터 암호화하는 과정 = TLS(=SSL)

자바가 지원하는 인증서 형식
1. PKCS12 : 업계에서 널리 쓰임, 여러 인증서와 키 포함 가능, 암호로 보호된 형식
2. JKS : Java환경으로 제한, 독점 형식




Hashing

  • 암호화만 가능
  • 해시 함수(Hash Function)으로만 암호화 진행 (e.g. SHA1)

    해시 함수
    -항상 같은 길이의 문자열 리턴
    -같은 문자열 IN -> 항상 같은 결과값 OUT
    -다른 문자열 IN -> 항상 다른 결과값 OUT




레인보우 테이블& 솔트(Salt)

  • input이랑 해싱 값 기록해둔 표 -> 테이블에 기록되면 보안 위협
  • 솔트 : 해싱 이전값에 임의의 값 더해서 데이터 유출되어도 해싱 이전 값 알아내기 어렵게 함
    => 해싱값 유출되어도 솔트가 같이 유출된거 아니면 암호화 이전 값 알아내는건 불가능에 가깝

해싱 목적

  • 복호화 불가능해도 해싱 값 일치 여부로 로그인 요청 처리 (이전 값 같으면 해싱 값도 같으니까)
  • 관리자가 해싱 이전 값 알면 그게 더 문제
    => 민감한 데이터 다루는 단방향 암호화 방식



  • 웹사이트 접속 시, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터
  • 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단
  • 사용자 선호, 테마 등 장시간 보존해야하는 정보 저장에 굿

쿠키 전달 방법

  • Server가 Client에 Set-Cookie 라는 쿠키 보냄
    -> Client가 Server에 Cookie 로 다시 보냄
    -> Server는 이 쿠키 장기 저장
  • Domain: 도메인 같아야 쿠키 전송
  • Path : 세부 경로 같아야 쿠키 전송
  • MaxAge/Expires : 유효 기간 지정해서 일정 시간 후 자동 소멸(e.g. PC방 로그아웃 안했을 때)
  • HttpOnly : 쿠키는
  • Secure
  • SameSite : CORS 요청에 의해 메서드에 따라 쿠키를 보낼지 안보낼지 결정
    -> 옵션 (Lax-GET 요청에만 쿠키 전송 가능, Strict-쿠키 전송 불가, None-모든 메서드 요청에 쿠키 전송 가능)
    -> sameSite='none' 옵션은 Secure 쿠키 옵션 필요



Session

  • 서버가 Client에 유일하고 암호화된 ID 부여
  • 중요 데이터는 세션에 저장

Cookie vs Session

  • 쿠키
    -> 쿠키는 그냥 http의 stateless함을 보완해주는 거
    -> 클라이언트가 접속상태 저장
    -> 유저가 삭제하지 않고, 유효기간 지나지 않는 이상 계속 저장됨
    -> 쿠키 그 자체는 인증이 x
  • 세션
    -> 접속상태 서버가 가짐(stateful)
    -> 세션아이디를 쿠키로 전송
    -> 서버가 접속 상태 저장
    -> 하나의 서버에만 접속 상태를 가져서 분산에는 불리

세션 단점

  • 서버의 메모리에 세션 저장 -> 서버 이용자 많아지면 항상 차지하는 세션 메모리 때문에 서버의 가용메모리 줄어듦
  • 세션도 쿠키 이용하므로 XSS 공격에 취약



웹 보안 공격

SQL Injection(SQL 삽입)

  • Input Form에 사용자가 무언가 작성할 수 있는 곳에서 보통 발생
  • 이어지게 말이되는 SQL문 삽입해서 데이터 조작으로 피해 입힘

SQL Injection 대응 방안

  1. 입력(요청) 값 검증 - 화이트리스트 방식(모든 경우 차단 후 예외적으로 접근가능한 키워드 받아들임)
  2. Prepared Statement 구문 사용 - 사용자 입력을 SQL문으로부터 분리시키고 단순 텍스트로 적용
  3. Error MEssage 노출 금지 - 에러메시지로 DB정보 얻을 수 있으므로 에러내용 노출❌ 에러핸들링 필요



CSRF(Cross Site Request Forgery)

  • 다른 사이트에서 유저가 보내는 요청을 조작(이메일 링크 누르면 돈 빠져나감)
  • 해커가 직접 데이터 접근 ❌

CSRF 공격 조건

  • 쿠키를 사용한 로그인(쿠키로 어떤 유저인지 알 수 있어야 함)
  • 예측할 수 있는 요청/parameter 가져야함

CSRF 대비 방법

  • CSRF 토큰 사용(CSRF공격으로부터 보호하기 위한 문자열을 브라우저와 웹앱에만 제공)
  • Same-site cookie 사용(같은 도메인에서만 세션/쿠키 사용할 수 있게 하기)



질의 응답 라이브 세션

  • 요즘 최신 트렌드 좋아하는 기업들은 코틀린 요구 => Java, Spring 안씀
  • 언어는 수단에 불과
  • NodeJS 서버, Python+Flask, Kotlin+Spring 조합 자주 사용하심
  • (개인의견) 프로그래머스 > 백준 > 릿코드 > 탑코드
    • 프로그래머스 : 최신 트렌드 반영
    • 백준 : 취업 이상의 것도 있음,,,
  • DevOps - 배포는 남들 도움없이 혼자 할 수 있을 정도로 할 수 있어야

0개의 댓글