CSRF (Cross Site Request Forgery)

다른 사이트에서 유저가 보내는 요청을 조작하는 공격. 예시로는 이메일에 첨부된 링크를 누르면 내 은행계좌의 돈이 빠져나가는 방식의 해킹 등이 있다.

해커는 말그대로 다른 사이트에 있으므로, 응답 객체에 담긴 정보자체를 탈취할 수는 없어서, 요청을 조작하는 것이다.

CSRF 공격이 이루어지기 위한 조건

• 쿠키를 사용한 로그인: 유저가 로그인 했을 때, 쿠키로 어떤 유저인지 알 수 있어야 함
• 예층할 수 있는 요청/parameter를 갖고 있어야 함: 리퀘스트에 해커가 모를 수 있는 정보가 담겨있으면 안 됨. 예를 들어 은행에서 돈을 빼내려고 할 때, 이미 로그인 되어 있어서 처음은 로그인할 필요가 없지만, 나중에 로그인을 또 요구하면 해커는 로그인 못 함!

CSRF 과정

• 유저가 은행 웹사이트에 로그인을 한다 -> 세션이 활성화된다. 로그인 정보가 쿠키에 담긴다.
• 이 때 해커가 겟요청을 활성화하는 링크를 유저에게 전송한다.
• 유저가 해당 링크를 클릭하면 의도하지 않은 겟요청이 은행 웹사이트로 보내진다.

CSRF는 어떻게 막을 수 있을까?

• CSRF 토큰 사용하기: 서버측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹앱에만 제공
• Same-site cookie 사용하기: 같은 도메인에서만 세션/쿠키를 사용할 수 있다.

토큰기반 인증 절차 (JWT)

세션 기반 인증은 서버에 부담을 준다. 매번 인증을 할 때마다 DB를 살펴야하고, 우선 데이터 양 자체가 주는 부담도 존재한다. 그렇다면 자연스럽게 클라이언트에게 이 부담을 넘겨줄 수는 없을까, 고민할 것이다. 그렇게 고안된 것이 바로 토큰 기반 인증이다!

인증의 핵심을 어떻게 클라이언트에 보관할 수 있지? 하는 고민이 틀 수 있지만, 토큰은 암호화되어 있다는 점을 기억해야 한다.

토큰의 구조를 살펴보자.

토큰의 구조!

가장 범용적으로 사용되는 토큰인 jwt 공식 페이지에 들어가보면 메인페이지에서 부터 위와 같은 화면을 볼 수 있다.
이 부분이 바로 토큰의 구조를 설명하고 있다.

• Header: 어떤 종류의 토큰인지, 어떤 알고리즘으로 암호화할 것인지
• Payload: 어떤 정보에 접근 가능한지에 대한 권한, 사용자의 유저네임 등 (암호화가 되긴 하지만 민감한 정보는 담지 않는 편이 좋다.)
• Signature: Header와 Payload에 secret 값까지 더 해 암호화한 부분

토큰의 인증 로직!

Step1: 로그인 요청을 보낸다!

    axios
      .post("https://localhost:4000/login", {
        userId: this.state.userId,
        password: this.state.password,
      })

Step2: 아이디와 비밀번호를 확인하고, 토큰을 생성한다.

// 아래 코드에서 userInfo는 클라이언트에서 보낸 아이디와 비밀번호로 DB에서 조회한 정보
    let userInfoWithoutPW = Object.assign(userInfo.dataValues);
    // 패스워드는 삭제해주어야 한다. 민감한 정보이므로!
    delete userInfoWithoutPW.password;
    const accessToken = jwt.sign(userInfoWithoutPW, process.env.ACCESS_SECRET, {
      expiresIn: "1h",
    });
    const refreshToken = jwt.sign(
      userInfoWithoutPW,
      process.env.REFRESH_SECRET,
      {
        expiresIn: "7d",
      }
    );
    res.cookie("refreshToken", refreshToken);
    res.json({
      data: { accessToken },
      message: "ok",
    });

• jwt.sign()메소드에 첫 번째 인자로 들어갈 정보는 자유롭게 넣어둘 수 있다. accessToken과 refreshToken에 동일한 정보를 넣을 필요도 없다. 모쪼록 유저를 구분할 수 있는 값이면 된다.

Step3: 클라이언트는 서버로부터 받은 토큰을 저장한다

 this.props.issueAccessToken(res.data.data.accessToken);

• 저장하는 위치는 local storage, cookie, react의 state 등 다양하다.

Step4: 클라이언트가 HTTP 헤더(authorization 헤더)에 토큰을 담아 보낸다

    axios({
      method: "get",
      url: "https://localhost:4000/accesstokenrequest",
      headers: { authorization: "Bearer " + this.props.accessToken },
    }).then((res) => {
      this.setState(res.data.data.userInfo);
    });

• 이 때 Bearer를 붙여주는 이유는 accessToken으로 bearer Token을 넘겨준다는 의미이다. 사실 아직 Bearer Token이 무엇인지 정확히 이해하지는 못했으나, Basic과 Bearer라는 포맷이 존재하고, Basic은 별도의 key없이 복호화가 가능한 안전하지 않은 방식이라는 점, 그리고 "보호된 리소스에 대한 접근 권한을 부여받기 위해 제시하는 유일한 작업이 토큰을 전달하는 것 뿐"일 때 해당 토큰을 bearer 토큰이라 한다는 것 정도 이해했다.

서버는 토큰을 해독해 인증과정을 거친다.

  if (!req.headers.authorization) {
    res.status(401).send({ data: null, message: "invalid access token" });
  } else {
    let token = req.headers.authorization.split("Bearer ")[1];
    let userInfo = jwt.verify(token, process.env.ACCESS_SECRET);
    delete userInfo.iat;
    res.status(200).send({ data: { userInfo }, message: "ok" });
  }

토큰 기반 인증 장점

1) 무상태성 & 확장성: 클라이언트가 인증 정보를 갖고 있으므로, 서버가 여러 개인 서비스라 하더라도, 하나의 토큰으로 해결 가능하다.

2) 안정성: 암호화 키를 노출할 필요가 없다.

3) 어디서나 생성 가능: 특정한 서버가 꼭 토큰을 만들 필요가 없다.

4) 권한 부여에 용이: 토큰의 payload 안에 어떤 정보에 대한 접근이 가능한지 임의로 정의가 가능하다. (부분적 접근권한을 줄 수 있다)

Access Token & Refresh Token

token이 탈취될 것에 대한 우려로, token을 둘 발급하여, access token과 refresh token으로 사용한다. access token에는 짧은 유효기간을 줘 탈취되더라도 오랫동안 사용될 수 없도록하고, access token의 기한기 만료되면, refresh token으로 새 access token을 발급받는다.

그러나 refresh token도 탈취될 수 있고, 보안이 엄청 중요한 서비스라면 refresh token을 사용하지 않는 경우도 있다고 한다! (그럼 기한 만료되면 매번 새로 access token 발급받음...?)