[인증/보안]

Sprint - HTTPS, Session, Token, OAuth

: 스프린트를 통해 배우는 것

인증(authentication)개념을 통한 회원 가입 및 로그인, 로그아웃과 같은 기능을 구현
클라이언트, 서버, 데이터베이스 모두를 다루면서, Full Stack 개발 환경에서의 전체적 흐름 및 작동을 직접 확인

Achievement Goals

Advanced

기존에 작성한 서버를 ngrok을 이용해서 HTTPS로 터널링을 시켜보기.
- ngrok : HTTP로 만들어진 서버를 HTTPS 프로토콜로 터널링 해주는 프로그램.

용어

HTTP : 인터넷에서 데이터를 주고 받을 수 있는 통신 프로토콜

: HTTP는 중간에 누군가가 요청을 그대로 들여다 볼 수 있었다. 개인정보 쉽게 노출.

HTTPS(HTTP + Secure) : HTTP프로토콜 내용을 암호화를 통해 보안성이 추가됨.

: HTTPS는 요청의 내용을 암호화 되기 때문에 정확한 키가 없다면 내용을 알 수 없다.

Hashing

Cookie

Session

CSRF

Token

Authentication

OAuth

로컬호스트, IP, 포트, DNS, LAN

127.0.0.1 과 localhost의 차이

로컬호스트(localhost) 주소

Web - IP, 포트, 그리고 로컬호스트

express.js : NodeJS를 사용하여 쉽게 서버를 구성할 수 있게 만든 클래스와 라이브러리의 집합체

Node JS : 자바스크립트를 브라우저 밖에서 사용하게 해주는 프로그램

HTTPS

Hyper Text Transfer Protocol Secure Socket layer, HTTP over SSL(TLS), HTTP over Secure
HTTPS : HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송하는 방법입니다.

질문: SSL, TLS는 무엇인가요? SSL과 인증기관(CA)은 어떤 관계가 있나요?

SSL(Secure Socket Layers)은 웹사이트와 브라우저(혹은, 두 서버) 사이에 전송된 데이터를 암호화하여 인터넷 연결을 보안을 유지하는 표준 기술입니다. 이는 해커가 개인 정보 및 금융 정보를 포함한 전송되는 모든 정보를 열람하거나 훔치는 것을 방지합니다.

TLS (Transport Layer Security)은 가장 최신 기술로 더 강력한 버전의 SSL입니다. 그러나 SSL이 더 일반적으로 사용되는 용어이기에, 여전히 보안 인증서는 SSL이라 불립니다.

SSL과 TLS 두 가지 프로토콜은 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정 에서 전송계층 종단간 보안과 데이터 무결성을 확보 할 수 있게 합니다.

인증에서 HTTPS 프로토콜을 사용해야만 하는 이유
: HTTP보다 상대적으로 안전한 방법이고, 데이터 제공자의 신원을 보장받을 수 있어서.
데이터 제공자의 신원을 확인하고 보장받는 게 인증에서 중요한 이유
: 클라이언트는 데이터 제공자가 제공해 준 데이터를 사용할 수밖에 없다.
클라이언트는 서버에 데이터 요청을 하고 이후 받은 데이터를 이용해서 화면을 렌더링하는 등의 작업을 해야 합니다. 그렇기 때문에 요청 및 응답을 중간에서 가로채는 중간자 공격에 취약합니다. 데이터가 중간에 다른 도메인을 거쳐서 전달되기 때문에 서버가 해당 데이터는 https://example.com 도메인에서 제공되었습니다.라는 추가 데이터를 응답 객체에 실어 보낸다면 '중간자 공격'으로 인해 다른 도메인에서 데이터를 받은 클라이언트는 데이터를 제공한 도메인과 전달받은 내용의 도메인을 비교하여 '중간자 공격'이 존재하는지 아닌지 확인 가능. 중간자 공격으로 인해 이런 추가 데이터 또한 변조 가능하므로 해당 데이터를 암호화시키는 작업이 필요!!
- 중간자 공격 : 은 클라이언트와 서버 사이에서 공격자가 서로의 요청, 응답의 데이터를 탈취 및 변조하여 다시 전송하는 공격입니다.

HTTPS 특징

인증서(Certificate)
- 데이터 제공자 신원 보장 : 데이터를 제공하는 서버가 정말 데이터를 보낸 서버인지 인증 확인하는 용도.
- 도메인 종속 : 인증서 내용에 서버의 도메인 관련한 정보가 있어서 데이터 제공자의 인증을 용이하게 한다.
- 요청을 받으면... 서버(domain: A.com) -> 클리이언트 (인증서, 응답을 보냄)
-> 클라이언트는 인증서의 domain과 응답객체의 domain을 같은지 비교한다.
-> 같으면 Confirmed!

-> 다르면 Not Confirmed( 제 3자 공격 : 중간에 해커가 요청을 탈취해서 클라이언트인척, 서버인척 정보를 탈취 )
- CA(Certificate Authority) : 인증서 발급하는 공인된 기관(공인인증서발급기관).
  - 각 브라우저는 각자 신뢰하는 CA 정보를 가지고 있다. 각 브라우저는 인증서도 다 차이가 난다.
  - CA 자격은 영구유지가 아님. 자격이 박탈 당할 수 있다.
- 비대칭 키 암호화 : 전혀 다른 키 한쌍으로 암호화 및 복호화를 진행 할 수 있다.
  
  - 어떤 키(A)로 암호화를 했다면 복호화는 한쌍의 키 중 다른키(B)로만 진행 가능하다.
  - HTTPS 프로토콜을 이용하는 서버는 한쌍의 키 중 하나의 키는 비밀로 숨겨두고 다른 하나는 클라이언트에 공개해서 데이터를 안전하게 전송할 수 있게 한다.
  - 모든 통신에 대해 공개 키 방식을 사용하는 것은 아니다.
  : 많은 클라이언트 대상으로 매번 사용하기에는 매우 연산이 복잡한 알고리즘이라서 통신의 초창기서만 비밀키로 사용하기 위한 키를 만들어내기 위해 사용.
  - 통신과정
  - 1. Hand Shake : 서버 인증서 검증
  : 서로(서버-클라이언트)를 확인. 서버는 클라이언트의 공개 키 한쌍 중 하나를 전달. 클라이언트가 요청을 보낸다. 서버는 공개키와 인증서를 보낸다.
  - 2. 비밀 키 생성 : client, Server 각각 세션 키 생성
  : 클라이언트는 전달받은 키를 이용해서 서버와 키를 만들어낼 임의의 정보를 암호화해서 전송한다. 이에 서버도 임의의 정보를 암호화해서 전송한다. 클라이언트와 서버는 서로 만들고 교환한 임의의 정보를 바탕으로 비밀키를 생성하게 된다. 비밀키로 만들 랜덤스트링을 보낸다. 클라이언트와 서버에 각각 세션키(비밀키)를 만든다.
  - 3. 상호 키 검증 : HTTPS 연결 성립
  : 각자 생성한 키를 바탕으로 클라이언트가 테스트용 데이터를, 만들어낸 비밀키로 암호화를 해서 전달한다. 서버도 만들어진 비밀키로 복호화 후 다시 암호화해서 클라이언트에 전달한다. 클라이언트가 같은 내용의 데이터를 복호화 하는 것에 성공했다면 성공적으로 비밀키가 만들어진 상태 = HTTPS 연결이 성립한 상태가 된다. 세션키를 서버에 확인차 보낸다. 서버에서 확인하면 https로 연결된 것이다.
  - 4. 이 비밀키를 바탕으로 데이터 송수신에 필요한 동일한 암호화 및 복호화를 진행한다.
  
  비대칭키 암호화 자세한 설명

암호화

: HTTPS는 암호화된 데이터를 주고받기 때문에, 중간에 인터넷 요청이 탈취되더라도 정확한 키로 복호화하기 전까지는 그 내용을 알아볼 수 없다. 기존에 배웠던 HTTP 프로토콜은 요청 및 응답을 탈취한다면 프로그램을 이용하여 아래와 같이 해당 요청으로 전달되는 데이터의 내용을 확인 가능.(wireshark : 패킷 분석 프로그램. http요청에서 개인정보를 빼낼수있다.)

인증서

: HTTPS는 브라우저(클라이언트)가 응답과 함께 전달된 인증서 정보를 확인 가능.
브라우저(클라이언트)는 인증서에서 해당 인증서를 발급한 CA 정보를 확인하고 인증된 CA가 발급한 인증서인지 확인하여 아니라면 경고창을 띄워 서버와 연결이 안전하지 않다는 것을 알려줌. 브라우저는 인증서의 도메인과 데이터를 제공한 제공자의 도메인을 비교할 수 있기 때문에 인증서의 도메인 정보와 데이터 제공자의 도메인 정보가 다른 '중간자 공격'을 감지하여 보안 위협으로부터 사용자 및 사용자의 데이터를 보호 가능.

경고창 기능 : 브라우저들은 인증된 CA가 발급한 인증서를 이용하여 데이터를 제공하는 안전한 서버를 사용할 수 있게 사용자를 유도한다.

사설 인증서 발급 및 HTTPS 서버 구현

로컬 환경(localhost)에서 인증서를 생성하고, 인증서를 이용해 HTTPS 서버를 만드세요.
1. 설치 : mkcert라는 프로그램을 이용해서 로컬 환경(내 컴퓨터)에서 신뢰할 수 있는 인증서를 만든다. 및 서브 도메인 정보, 세부 경로를 포함하지 않습니다.
- Ubuntu

$ sudo apt install libnss3-tools
$ wget -O mkcert https://github.com/FiloSottile/mkcert/releases/download/v1.4.3/mkcert-v1.4.3-linux-amd64
$ chmod +x mkcert
$ sudo cp mkcert /usr/local/bin/

인증서 생성
- 로컬을 인증된 발급기관으로 추가 : $ mkcert -install
- 로컬 환경에 대한 인증서를 만들기: $ mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1
  : 이제 옵션으로 추가한 localhost,127.0.0.1(IPv4), ::1(IPv6)에서 사용할 수 있는 인증서가 완성됨. cert.pem, key.pem 이라는 파일이 생성된 것을 확인 가능.
cert.pem 과 key.pem 두가지 파일은 세션이나 쿠키, 토큰을 발급받는데 필수적으로 필요한 것. 이 두가지 파일은 packege.json 이 있는 폴더 내에 존재해야 한다.
- cert.pem 은 공개적인 키로, 인증기관의 서명을 포함하고 있으므로 공개되어도 상관이 없지만, key.pem의 경우 개인 키이므로 git에 커밋하지 않고, 암호처럼 다루어야 합니다. (key.pem은 공개되면 안된다.)

질문: key와 cert의 다른 점은 무엇일까요?

cert.pem 은 공개적인 키로, 인증기관의 서명을 포함하고 있으므로 공개되어도 상관이 없지만, key.pem의 경우 개인 키이므로 git에 커밋하지 않고, 암호처럼 다루어야 합니다. (key.pem은 공개되면 안된다.)

HTTPS 서버 작성
: Node.js 환경에서 HTTPS 서버를 작성하기 위해서는 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정하게 된다.
- 사용 가능한 옵션 : https 내장 모듈을 이용, express.js를 이용해 https 서버를 만들 수 있다.
- 생성한 인증서 파일들을 HTTPS 서버에 적용해 주는 작업
1. Node.js https 모듈 이용하는 경우

const https = require('https');
const fs = require('fs');

https
  .createServer(
    {
      key: fs.readFileSync(__dirname + '/key.pem', 'utf-8'),
      cert: fs.readFileSync(__dirname + '/cert.pem', 'utf-8'),
    },
    function (req, res) {
      res.write('Congrats! You made https server now :)');
      res.end();
    }
  )
  .listen(3001);

: 이제 서버를 실행한 후 https://localhost:3001로 접속하면 브라우저의 url 창 왼쪽에 자물쇠가 잠겨있는 HTTPS 프로토콜을 이용한다는 것을 알 수 있다!

2.express.js 이용하는 경우

const https = require('https');
const fs = require('fs');
const express = require('express');

const app = express();

https
  .createServer(
    {
      key: fs.readFileSync(__dirname + '/key.pem', 'utf-8'),
      cert: fs.readFileSync(__dirname + '/cert.pem', 'utf-8'),
    },
  // https.createServer의 callback 함수를 Express 미들웨어로 교체
    app.use('/', (req, res) => {
      res.send('Congrats! You made https server now :)');
    })
  )
  .listen(3001);

Hashing

: 암호화의 기본. 어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것.
1. 모든 값에 대해 해시 값을 계산하는데 빨라야 한다.
2. 최대한 해시값을 피해야 하며, 모든 값은 고유한 해시 값을 가진다.
3. 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.

-ex) 대표적인 Hash 알고리즘 : SHA1, SHA256(요즘 많이 씀)

인증과 로그인 과정

No Authentication : 인증과정이 없이 이메일 관련 정보 얻으면 보안상 이슈 생김. 누구라도 이메일 정보만 알면 모든 정보에 접근 할 수 있음.
Authentication(Plain text) : 간단한 비밀번호를 넣은 과정. 클라이언트가 서버에게 이메일과 비밀번호를 보냄. 서버는 DB에서 해당 이메일과 비밀번호를 가져옴. 비교해서 맞으면 서버는 DB에서 해당 이메일의 정보를 요청해서 클라이언트에 반환한다.

그러나, 비밀번호는 이메일과 다르게 공개되면 안되는 정보이다. 사용자의 정보를 악의적으로 사용하려는 해커가 알면 은행, SNS에 접속할 수 있게 될 수 있다.
-> 이러한 비밀번호를 DB에 암호화해서 저장하면 이런 문제를 방지할 수 있다.

Encryption(암호화) : 암호화는 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 '알고리즘'을 이용해 정보를 관리하는 과정.

: DB는 비밀번호를 plain하게 노출하지 않고, 특정 알고리즘으로 암호화된 문자열로 저장함. 서버는 알고리즘을 가지고 있고, 클라이언트의 로그인 요청이 올때마다 알고리즘을 통해 암호화시켜준 뒤에 DB에서 확인해서 맞는 데이터를 가져와서 반환해준다. 따라서 DB의 비밀번호가 털려도 알고리즘을 모르기 때문에 다른 사이트에서 유사한 패턴을 시도해보는 것을 막을 수 있다.

Salt

: 암호화해야 하는 값에 어떤 '별도의 값'을 추가하여 결과를 변형하는 것.
1. 암호화만 해놓는다면 해시된 결과가 늘 동일
: 해시된 값과 원래 값을 테이블(레인보우 테이블)로 만들어서 decoding해버리는 경우도 생김.
2. 원본값에 임의로 약속된 '별도의 문자열'을 추가해서 해시를 진행한다면 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출되더라도 원본값을 보호할 수 있도록 하는 안전장치
3. - 기존: (암호화 하려는 값) => (hash 값)

Salt 사용: (암호화 하려는 값) + (Salt용 값) => (hash 값)

Salt 사용 시 주의점

서버가 아닌 유저마다 고유한 값 : Salt는 유저와 패스워드 별로 유일한 값을 가져야 합니다.
계정, 비번변경시 같이 변경 : 사용자 계정을 생성할 때와 비밀번호를 변경할 때 마다 새로운 임의의 Salt를 사용해서 해싱해야 한다.
재사용X : Salt는 절대 재사용하지 말아야 한다.
DB에 저장함 : Salt는 DB의 유저 테이블에 값이 저장되어야 한다.

Cookie

질문: HTTP는 stateless(무상태성)인데 어떻게 우리의 정보가 유지가 될까요?

원래 서버는 클라이언트의 요청을 일회성으로만 사용하는데.. 쇼핑몰 웹사이트에서는 여러 페이지를 돌아다니면서 독립된 요청을 보내는데 장바구니가 동일하게 유지되는 방법은 ?

쿠키덕분이다.

서버에서 클라이언트에 데이터를 저장하는 방법의 하나. 서버가 웹브라우저에 정보를 저장하고 불러올 수 있는 수단.
서버가 원한다면 서버는 클라이언트에서 쿠키를 이용하여 데이터를 가져올 수 있다. 쿠키는 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 쿠키를 전송하는 것도 포함한다.
어떤 웹사이트에 들어갔을 때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터. (서버 -> 클라이언트)
서버가 쿠키를 저장해주고, 해당 도메인에 대해 쿠키가 존재하면, 웹 브라우저는 도메인에게 http요청 시 자동으로 쿠키가 함께 전송된다.
쿠키의 특성은 삭제하지 않는다면 사라지지 않는다.
-> Cookie 이용법 : 장기간 보존해야하는 옵션을 클라이언트에 저장하기 적합하다.(장바구니, 30일동안 로그인상태 유지, 테마같은 개인정보를 장기간 저장에 사용 / 로그인,로그아웃의 인증정보를 쿠키를 통해 저장.)
- 쿠키는 노출이 쉽다(브라우저 설정창에서 확인가능. 자바스크립트로 쿠키접근 가능). 보안상 위험하고 변조도 쉽다. 따라서 보통 쿠키는 알아보기 힘들게 암호화된 내용으로 채워짐. 인증정보 같은 민감한 정보는 해싱처리가 되어있다.
- 회사가 필요한 마케팅정보를 쿠키에 저장한다.
- 쿠키에는 노출되어서는 안되는 개인정보나 인증에 관한 정보는 포함되지 않아야 함.

: [쿠키가 클라이언트에 저장되고 자동으로 요청되게 된다.] ::
1. 서버가 응답헤더에 Set-Cookie라는 property에 쿠키의 이름, 값, 경로등의 옵션을 저장한다.
2. 쿠키가 담긴 응답을 받은 클라이언트는 응답헤더에 존재하는 Set-Cookie를 확인하게 된다. 3. 클라이언트는 다음에 존재하는 매 요청시 마다 쿠키의 이름과 값을 서버에게 전달하게 된다. (이처럼 서버가 쿠키를 저장하면, 이후로는 해당 웹사이트를 이용할 때 매 요청에 자동으로 쿠키가 함께 전송된다.)
4. 서버는 클라이언트에 저장 된 쿠키내용을 바탕으로 로그인 유지, 테마를 보여준다는 등의 현상을 보여준다.

Cookie Options

: 서버는 쿠키를 이용하여 데이터를 저장하고 원할 때 이 데이터를 다시 불러와 사용 가능. 하지만 데이터를 저장한 이후 아무 때나 데이터를 가져올 수는 없고, 데이터를 저장한 이후 특정 조건들이 만족하는 경우에 가져올 수 있는데, 이런 조건들은 쿠키 옵션으로 표현 가능하다.

이러한 옵션들을 지정한 다음, 서버 -> 클라이언트로 쿠키를 처음 전송하게 된다면 헤더에 Set-Cookie라는 property에 쿠키를 담아 쿠키를 전송. 이후 쿠키 전송 시 한다면 클라이언트는 헤더에 Cookie라는 property에 쿠키를 담아 서버에 쿠키를 전송. - Set-Cookie
Domain : 서버와 요청(작성 된)의 도메인이 일치하는 경우 쿠키 전송
- 도메인 : www.google.com과 같은 서버에 접속할 수 있는 이름.
- 쿠키 옵션에서 도메인 : 포트 및 서브 도메인(www 같은 도메인 앞에 추가로 작성되는 부분) 정보, 세부 경로를 포함하지 않는다. 따라서 요청해야 할 URL이 http://www.localhost.com:3000/users/login 이라 하면 여기에서 Domain은 localhost.com이 됩니다.
- 옵션 사용방법 : 쿠키 옵션에서 도메인 정보가 존재 -> 클라이언트에서는 쿠키의 도메인 옵션 = 서버의 도메인이 일치해야만 쿠키를 전송 가능.
Path : 서버와 요청(작성 된)의 세부경로가 일치하는 경우 쿠키 전송
- 세부 경로 : 서버가 라우팅할 때 사용하는 경로.
  -> 요청해야 하는 URL이 http://www.localhost.com:3000/users/login 인 경우, 여기에서 Path(세부 경로)는
  /users/login
- 옵션 사용방법
  - 명시하지 않으면 기본으로 / 으로 설정됨.
  - Path 옵션의 특징 : 설정된 path를 전부 만족하는 경우 요청하는 Path가 추가로 더 존재하더라도 쿠키를 서버에 전송 가능.
    -> Path가 /users로 설정되어 있고, 요청하는 세부 경로가 /users/login 인 경우라면 쿠키 전송이 가능.
    -> Path가 /user/login으로 전송되는 요청은 Path 옵션을 만족하지 못하기 때문에 서버로 쿠키를 전송 불가능.
MaxAge or Expires : 쿠키의 유효기간 설정.
- PC방에 가서 로그아웃 안 한 경우 : 브라우저에 저장되어 있는 쿠키 정보를 확인하고 탈취 가능. 일정 시간 후 자동 소멸되게 하면 서버에서 쿠키의 유효기간을 지정해준다면, 쿠키가 일정 시간이 지난 뒤에 자동으로 소멸되게 만들 수 있다.
- MaxAge : 앞으로 몇 초 동안 쿠키가 유효한지 설정하는 옵션
- Expires : MaxAge와 비슷, 다만 언제까지 유효한지 Date를 지정
- 지정된 시간(MaxAge), 날짜(Expires)를 초과하게 되면 쿠키는 자동으로 파괴.
- 옵션 사용방법 : 두 옵션이 모두 지정되지 않는 경우 :: 브라우저의 탭을 닫아야만 쿠키가 제거 됨.
HttpOnly : 자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정. (스크립트 태그의 쿠키 접근 가능 여부 결정.) 스크립트 태그로 쿠키접근이 불가능하게 막아서 보안 강화. 브라우저에서만 접근 가능하게 만들 수 있다.
- XSS공격 : 스크립트에 악의적으로 코드를 삽입해놓은 공격.
  -> 쿠키에는 민감한 정보나 개인 정보는 담지 않는 것이 좋다.
- 자바스크립트에서 쿠키에 접근이 가능하므로 'XSS' 공격에 취약합니다.
- 옵션 사용방법 :
  - true로 설정된 경우 :: 자바스크립트에서는 쿠키에 접근이 불가합니다.
  - 명시되지 않는 경우 :: 기본으로 false로 지정. -> 자바스크립트에서 쿠키에 접근이 가능하므로 'XSS' 공격에 취약

명시되지 않는 경우 기본으로 false로 지정되어 있습니다.
만약 이 옵션이 false인 경우 자바스크립트에서 쿠키에 접근이 가능하므로 'XSS' 공격에 취약합니다.

Secure : HTTPS프로토콜에서만 쿠키 전송 한다.
- 옵션 사용방법 :
  - true로 설정된 경우 :: 'HTTPS' 프로토콜을 이용하여 통신하는 경우에만 쿠키를 전송 가능.
SameSite : CORS(Cross-Origin) 요청에 대해서 해당 요청에서 사용한 메서드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부 결정. CSRF공격 막을 수 있다.
- 옵션 사용방법 : 옵션에 따른 서버의 쿠키 전송 여부
  - Lax : GET메서드 요청만 쿠키 전송 가능. 디폴트
  - Strict : 쿠키 전송 불가
  - None : 모든 메서드 요청에 대해 쿠키 전송 가능.
    ->SameSite='none'옵션을 사용하려면 HTTPS포로토콜과 Secure쿠키 옵션을 반드시 사용해야한다.
    -> SameSite='none' 사용 예시 :: 서버에서 쿠키가 전송이 되지 않으면서, 네트워크탭에서 Set Cookie 옆에 경고 아이콘이 보인다면 SameSite='none'으로 설정하면 문제가 해결된다.
- CSRF(CrossSiteRequestForgery(위조)) : 사이트A가 사이트B(은행사이트)에서 사용자가 인증되는 동안 강제로 사이트B에게 원하지 않는 요청을 forgery한 경우. 웹 어플리케이션 취약점 중 하나로 인터넷 사용자(희생자)가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 만드는 공격. CSRF를 통해 해커는 희생자의 권한을 도용하여 중요 기능을 실행하는 것이 가능해진다. 예를들어 페이스북에 희생작의 계정으로 광고성 글을 올리는 것.

쿠키를 이용한 상태 유지

: 이러한 쿠키의 특성을 이용하여 서버 -> 클라이언트에 인증정보를 담은 쿠키를 전송하고, 클라이언트는 전달받은 쿠키를 요청과 같이 전송하여 Stateless 한 인터넷 연결을 Stateful 하게 유지.

기본적으로는 쿠키는 오랜 시간 동안 유지될 수 있고, 자바스크립트를 이용해서 쿠키에 접근할 수 있기 때문에 쿠키에 민감한 정보를 담는 것은 위험. 이런 인증정보를 탈취하여 서버에 요청을 보낸다면 서버는 누가 요청을 보낸 건지 상관하지 않고 인증된 유저의 요청으로 취급하기 때문에, 개인 유저 정보 같은 민감한 정보에 접근이 가능.

Author And Source

이 문제에 관하여([인증/보안] - 기초), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@ez0ez0/인증보안-기초

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)

[인증/보안] - 기초