웹 애플리케이션 보안: 정찰, 공격, 방어 세 단계로 배우는 웹 애플리케이션 보안의 모든 것

317

23

장

CSRF 공격 방어

if (!session.isAuthenticated) { return res.sendStatus(401); }

if (!validateHeadersAgainstCSRF(req.headers)) { return res.sendStatus(401); }

return transferFunds(session.currentUser, req.query.to_user, req.query.amount);

};

module.exports = transfer;

가능하다면 두 헤더를 모두 확인해야 한다. 그중 아무 것도 없다면 해당 요청은 표준에 맞지 않

는 것으로 간주해 거절해야 한다.

이 헤더들은 일차 방어선에 해당이지만 때로는 실패할 수도 있다. 공격자가 허용 목록에 속한

원점에

XSS

를 해서 그곳으로부터 공격을 일으킨다면 그 요청은 정당한 것처럼 보일 것이다.

이 사례에서 사용자가 작성한 콘텐츠를 웹사이트에 게시하도록 허용한다면 더욱 우려스럽다.

이 경우 요청이 여러분의 웹 서버에서 온 것인지 확인하기 위해 헤더의 유효성을 검증하는 것

은 아무 소용이 없다. 따라서 헤더 검증에서 그치지 말고 여러 겹의

CSRF

방어를 구현하는 것

이 최선이다.

23.2

CSRF

토큰

CSRF

공격에 대한 가장 강력한 방어는

안티

CSRF

토큰

anti

-

CSRF ...