HTTP 메소드는 정보 검색과 같은 read-only 작업을 수행하는 데에 사용될 때 안전합니다. 반대로, 안전하지 않은 HTTP 메소드는 웹 사이트의 유저의 프로필을 변경하는 것과 같은 애플리케이션의 상태를 변경하는 데에 사용됩니다.
일반적으로 안전한 HTTP 메소드는 GET, HEAD, OPTIONS 입니다.
일반적으로 안전하지 않은 HTTP 메소드는 POST, PUT, DELETE 입니다.
안전한 HTTP 메서드와 안전하지 않은 HTTP 메서드가 모두 웹 애플리케이션에서 특정 작업을 수행하도록 허용하면 보안에 영향을 미칠 수 있습니다. 예를들어 CSRF 보호는 안전하지 않은 HTTP 메소드에 의해 수행되는 작업에 대해서만 보호합니다.
스스로에게 자문하세요
- 애플리케이션의 컨트롤러 / 경로 에 대해 HTTP 메소드가 정의되어있지 않습니다.
- 애플리케이션의 상태를 변경할 수 있는 경로 / 컨트롤러에 대해 안전한 HTTP 메서드가 정의되고 사용됩니다.
다음의 질문에 예라고 답하는 경우, 문제가 발생할 가능성이 있습니다.
권장되는 보안 코딩 방법
애플리케이션의 모든 경로 / 컨트롤러에 대해 인증된 HTTP 메소드는 명시적으로 정의되어야하며, 안전한 HTTP 메소드는 read-only 작업을 수행하는 데만 사용해야 합니다.
민감한 코드의 예
@RequestMapping("/delete_user") // 민감한 코드: 기본적으로 모든 HTTP 메소드가 허용됩니다.
public String delete1(String username) {
// 애플리케이션의 상태가 이곳에서 변경됩니다.
}
@RequestMapping(path = "/delete_user", method = {RequestMethod.GET, RequestMethod.POST}) // 민감한 코드: 안전한 HTTP 메소드와 안전하지 않은 HTTP 메소드가 모두 허용됩니다.
String delete2(@RequestParam("id") String id) {
// 애플리케이션의 상태가 이곳에서 변경됩니다.
}
규칙을 준수한 해결책
@RequestMapping("/delete_user", method = RequestMethod.POST) // 규칙을 준수한 코드
public String delete1(String username) {
// 애플리케이션의 상태가 이곳에서 변경됩니다.
}
@RequestMapping(path = "/delete_user", method = RequestMethod.POST) // 규칙을 준수한 코드
String delete2(@RequestParam("id") String id) {
// 애플리케이션의 상태가 이곳에서 변경됩니다.
}
참고
- OWASP Top 10 2021 Category A1 - Broken Access Control
- OWASP Top 10 2021 Category A4 - Insecure Design
- OWASP Top 10 2017 Category A5 - Broken Access Control
- MITRE, CWE-352 - Cross-Site Request Forgery (CSRF)
- OWASP: Cross-Site Request Forgery
- SANS Top 25 - Insecure Interaction Between Components
- Spring Security Official Documentation: Use proper HTTP verbs (CSRF protection)
If you like SONARKUBE, don’t forget to give me a star. 
