설명
CSRF는 브라우저가 자동으로 보내는 인증 정보를 이용해 사용자가 의도하지 않은 상태 변경 요청을 처리하게 만드는 공격입니다. CSRF 검증 뒤에 HTTP 메소드를 바꾸면, 검증에서 제외한 요청이 나중에 상태 변경 요청으로 처리될 수 있습니다. 실제 우회 가능성은 허용한 원래 메소드와 변환 설정에 달려 있습니다.
잠재적 영향
- 피해자의 인증된 권한으로 데이터나 설정을 무단 변경할 수 있습니다.
- CSRF 자체가 세션 비밀 값을 탈취하는 것은 아니지만, 피해자의 브라우저가 인증된 요청을 보내는 데 악용될 수 있습니다.
해결 방법
- 메소드를 변환하는 미들웨어를 CSRF 검증보다 먼저 적용하세요.
- 변환을 허용할 원래 메소드를 제한하고, 최종 메소드 기준으로 상태 변경 요청의 CSRF 토큰을 검증하세요.
- 현재
method-override의 기본 원래 메소드는POST입니다.GET등으로 확장하면 보안 영향도 검토하세요.
예시
지원이 종료된 Express 3의 미들웨어 순서만 비교하는 역사적 발췌입니다. 본문 파싱, 쿠키·세션 설정과 토큰 발급은 생략했습니다. 새 코드에서는 지원되는 Express와 CSRF 구현을 사용하세요.
변경 전
javascript
const express = require('express');
const app = express();
app.use(express.csrf()); // ❌ CSRF 미들웨어가 먼저 사용됨
app.use(express.methodOverride());
app.post('/update', function(req, res) {
// 중요 데이터 처리 코드
res.send('done');
});
변경 후
javascript
const express = require('express');
const app = express();
app.use(express.methodOverride()); // ✅ methodOverride가 먼저
app.use(express.csrf()); // 그 뒤에 CSRF 미들웨어 적용
app.post('/update', function(req, res) {
// 중요 데이터 처리 코드
res.send('done');
});
설명:
- 변경 전: CSRF 검증이 메소드 변환 전의 요청을 판단합니다. 변환 설정에 따라 검증에서 제외된 요청이 상태 변경 경로에 도달할 수 있습니다.
- 변경 후: 메소드 변환을 먼저 적용해 CSRF 미들웨어가 최종 메소드를 기준으로 판단하게 합니다. 올바른 토큰 검증과 세션 설정도 필요합니다.