목차

---

1. 암호화와 hashing, salting
2. 권한 부여(Authorization)와 인증(Authentication)
3. 쿠키의 작동 원리

배운 내용

---

Https

• http + secure
• http프로토콜 내용을 암호화
• HTTPS는 HTTP요청을 SSL혹은 TLS라는 알고리즘을 이용해, HTTP통신을 하는 과정에서 데이터를 암호화하여 전송하는 방법
• 비대칭키 방식과 대칭키 방식을 혼용하여 사용
  • 대칭키 방식: 양쪽이 공통의 비밀 키를 공유하여 데이터를 암호화 및 복호화하는 것
  • 비대칭키 방식 : 각각 공개키와 비밀키를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화하는 것
  • 클라이언트와 서버가 데이터를 주고받을 때는 대칭키를 사용
  • 비대칭키 알고리즘은 대칭키 알고리즘보다 훨씬 복잡
  • 대칭키를 주고받을 때는 비대칭키 방식으로 주고받도록 한다 → 중간에 대칭키가 탈취되더라도 개인키가 없이는 이를 복호화할 수 없기 때문

인증서(Certificate)

• 서버의 공개키와 정보를 CA의 비밀키로 암호화하여 인증서를 발급
• 도메인 종속
• 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다
• 브라우저는 인증서의 도메인과 데이터를 제공하는 서버의 도메인을 비교할 수 있으므로 '중간자 공격'을 감지하여 보안 위협으로부터 사용자 및 사용자의 데이터를 보호할 수 있습니다.
• 서버의 신원을 보증하여 우리가 접속한 Naver가 해커가 정교하게 따라 한 가짜 Naver가 아님을 보장해주는 역할
  • 인증서의 도메인과 응답객체의 도메인 비교해서 확인 같다면 서버가 보낸내용이란느걸 입증가능
• 해커는 중간에서 도메인을 변경하여 클라이언트인척, 서버인척 하며 정보를 빼돌림

CA(Certificate Authority)

• 공인 인증서 발급 기관
• 데이터 제공자 신원 보장해주는 제 3자
• 서버가 클라이언트에게 CA에서 발급받은 인증서를 전달하면 클라이언트는 OS 또는 브라우저에 미리 내장되어 있던 CA 리스트를 통해 브라우저에서 인증된 CA에서 발급받은 인증서인지 먼저 확인합니다. 만약 인증된 CA에서 발급한 인증서가 아니라면 화면에 경고창을 띄워 서버와 연결이 안전하지 않다는 화면을 보여줍니다.
• 그후, 인증서가 확인되었다면 브라우저에 제공된 해당 CA 기관의 공개키로 서버 인증서를 복호화
• 서명을 복호화해 얻은 공개키로 클라이언트는 서버를 믿을만한 대상인지 신뢰할수있다.
• 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 TLS 또는 SSL이라고 말합니다

비대칭 키 암호화

• 전혀다른 키로 암호화 및 복호화 가능
• ex) 키 A로 암호화 → 키 B로만 복호화 가능!
• 키중에서 하나는 숨겨두고 하나는 클라이언트 한테 공개
• 공개키 방식은 매 통신마다 사용하기에는 연산이 복잡 → 통신 초창기에만 비밀키를 만들어 내기위해 사용

**암호화**

• 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여, 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 '알고리즘'을 이용해 정보를 관리하는 과정
• 제 3자가 서버와 클라이언트가 주고받는 정보를 탈취할 수 없도록 하는 것

해싱

• 어떠한 문자열에 ‘임의의 연산’을 적용하여 다른 문자열로 변환하는것
  • 해시값을 해독(decoding)할 때는 많은 시간이 걸려야하지만 반대로 해시값을 만드는 데엔 오래걸리지 않아야 한다.
  • 최대한 해시값을 피해야하며, 모든 값은 고유한 해시값을 가진다.
  • 아주 작은 단위의 변경이라도 완전히 다른 해시값을 가져야한다.
• 대표적인 해시 알고리즘으로는 SHA1이 있고, 요즘엔 SHA256을 많이 사용

Salt

• 암호화해야 하는 값에 어떤 ‘별도의 값’을 추가하여 결과를 변형하는것
• 암호화만 해놓는다면 해시된 결과가 늘 동일 해시된 값과 원래 값을 테이블(레인보우 테이블)로 만들어서 decoding 해버리는 경우도 생긴다.
  
• 원본값에 임의로 약속된 ‘별도의 문자열을 추가하여 해시를 진행한다면 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출 되더라도 원본값을 보호 할수 있도록 하는 안전장치
  
• 기존: (암호화 하려는 값) → hash 값 salt 사용 : (암호화 하려는값) + (salt 용 값) ⇒hash 값
  
• salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.
• 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 salt를 사용해서 해싱해야 한다.
• Salt는 절대 재사용해선 안된다.
• Salt는 DB의 유저테이블에 같이 저장되어야 한다.

Cookie

• Http는 stateless(무상태성)인데 어떻게 우리의 정보가 유지될까? → 쿠키덕분
• 서버가 일방적으로 클라이언트에 전달하는 작은데이터, 클라이언트에 데이터를 저장 할 수있다.
• 서버가 웹브라우저에 정보를 저장하고 불러올 수있는 수단
• 해당 도메인에 대한 쿠키가 존재하면, 웹브라우저는 도메인에게 http 요청시 쿠키를 함께 전달
• 쿠키는
• 쿠키에는 민감한 정보나 개인정보는 담지 않는 것이 좋다.
• 서버는 클라이언트에 인증정보를 담은 쿠키를 전송하고, 클라이언트는 전달받은 쿠키를 요청과 같이 전송하여 Stateless 한 인터넷 연결을 Stateful 하게 유지할 수 있습니다.
• 하지만 기본적으로는 쿠키는 오랜 시간 동안 유지될 수 있고, 자바스크립트를 이용해서 쿠키에 접근할 수 있기 때문에 쿠키에 민감한 정보를 담는 것은 위험합니다.
• 데이터를 저장한 이후 아무 때나 데이터를 가져올 수 없다. 데이터를 저장한 이후 특정 조건들이 만족하는 경우에만 다시 가져올 수 있습니다.
  • 쿠키옵션
    • **Domain**
    • **Path**
    • **MaxAge or Expires**
      • 쿠키가 유효한 기간을 정하는 옵션
    • **Secure**
      • 사용하는 프로토콜에 따른 쿠키전송 여부를 결정(https)
    • **HttpOnly**
      • 자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정
    • **SameSite**
      • Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정

세션

• 사용자가 인증에 성공한 상태
  • 서버는 일종의 저장소에 세션을 저장한다.
• 로그인을 유지하기 위한 수단으로 쿠키를 사용하며, 쿠키에는 서버에서 발급한 세션 아이디를 저장하여 클라이언트에 전달
• 서버가 Client에 유일하고 암호화된 ID를 부여
• 중요 데이터는 서버에서 관리
• 로그아웃 → 서버 : 세션 정보를 삭제, 클라이언트 : 쿠키를 갱신
• 서버가 set-cookie로 클라이언트에게 쿠키를 전송할 때 세션 아이디의 키값을 무효한 값으로 갱신

웹공격

SQL Injection

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

// 보통 사용자가 input form에 직접 무언가 작성하는 상황에서 발생

//  로그인 
SELECT *
FROM users
WHERE auth='admin'
AND id='kimcoding';

//input form에 일반 텍스트(아이디 및 패스워드)가 아닌 SQL문을 작성
// 입력받은 아이디와 패스워드를 통해 데이터베이스를 조회하는데, 패스워드에 ’OR ‘1’ = ‘1을 넣어 보낸다면 다음과 같은 SQL문이 완성

SELECT * 
FROM users
WHERE auth='admin'
AND id='' OR '1'='1';

//WHERE절에서 OR는 AND보다 연산 순위가 낮기 때문에 OR절인 ‘1’ = ‘1’ (항상 참)이 가장 나중에 실행되어 결국 로그인에 성공

//input form에 SQL문을 마무리하는 키워드인 ;와 함께 주요 테이블을 삭제하는 SQL문(e.g. '; DROP TABLES users;--')을 작성한다면 데이터가 모두 삭제되는 큰 피해를 입을 수도 있습니다.
SELECT * 
FROM users
WHERE auth='admin'
AND id='';DROP TABLES users;--';

• **SQL injection 대응 방안**

  • 입력값 검증
    - 블랙리스트가 아닌 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 SQL Injection에 대응

    화이트리스트 : 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 또는 그 지정된 대상들

  • Prepared Statement 구문 사용

    • 사용자의 입력 값이 전달 되기 전에 데이터베이스가 미리 컴파일하여 SQL을 바로 실행하지 않고 대기하며, 사용자의 입력값을 단순 텍스트로 인식합니다. 따라서 입력 값이 SQL문이 아닌 단순 텍스트로 적용되며 공격에 실패

  • Error Message 노출 금지

    • 공격자는 데이터베이스의 Error Message를 통해 테이블이나 컬럼 등 데이터베이스의 정보를 얻을 수 있습니다. 에러가 발생한 SQL문과 에러 내용이 클라이언트에 노출되지 않도록 별도의 에러핸들링이 필요
• CSRF(Cross Site Request Forgery_
  • 다른 사이트에서 유저가 보내는 요청을 조작하는것
    • ex) 이메일에 첨부된 링크를 누르면 내 은행계좌의 돈이 빠져나감
  • 해커가 직접 데이터를 접근 할 수 없다.
  • CSRF 공격을 하기 위한 조건
    • 유저가 로그인 했을 때, 쿠키로 어떤 유저인지 알 수 있어야한다.
    • 예측할 수 있는 요청/parameter를 가지고 있어야 한다.
      • request에 해커가 모를 수 있는 정보가 담겨있으면 안됨
  • 대응 방안
    • CSRF 토큰 사용
      • 서버측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹앱에만 제공
    • Same-site cookie 사용하기
      • 같은 도메인에서만 세션/쿠키를 사용할 수 있다.
• Authentication(인증)
• Authorization(인가, 권한부여)