이번 강의에서는
웹 애플리케이션에서 할 수 있는
CSRF 공격 대처 방법을 적용해보겠습니다
CSRF 공격 해결방안에 다루기 전에
웹 애플리케이션의
질문을 하나 드리겠습니다
Contact, Register 같은 API를 만들었습니다
Post 메소드와 비슷한 역할을 하는 것입니다
이는 전부 공공 API입니다
아무나 스스로 등록할 수 있습니다
누구든 REST API를 통해
연락처 정보과 문의 정보을 제출할 수 있습니다
이런 종류의 API는 보호할 필요가 있을까요?
누군가 연락처 정보를 제출하고
애플리케이션을 등록하는 데에
큰 위험이 없기 때문에
이런 종류의 공공 API는
CSRF 공격을 다룰 필요가 없습니다
민감한 정보가 없기 때문입니다
공공 API로는 해커가 뭔가 할 수 있는
보안 취약성이 없습니다
그러므로 이번 강의에서 첫 번째로
Spring Security 프레임워크에게 이것들을 공공 API라고 해줍니다
기본 CSRF 보호를 적용시키지 말아야 합니다
그럼 공공 API를 불러올 때
발생하는 403 에러는
어떻게 해결할수 있을까요?
Spring Security 프레임워크와 소통하고 싶고
특정 공공 URL에서
CSRF 보호도 필요 없는 경우
어느 정도 CSRF 설정이 필요합니다
Security FilterChain의 bean을 정의하려던
같은 메소드 안에
이 메소드를 가지고 무엇을 할 것인가 하면
CorsConfiguration 후에
and 메소드를 불러오고
CORS와 CSRF 설정을
합치고 싶기 때문에
이 and 메소드를 post 합니다
CSRF 메소드를 불러옵니다
이 메소드 이후에는 ignoringRequestMatchers을 호출해야 합니다
이 ignoringRequestMatchers(일치하는 요청 무시하기)에는
공공 API URL들을 통과해야 하고
Spring Security 프레임워크를 통해
CSRF 보호는 적용되지 않습니다
이제 3개의 공공 API URL들이 보입니다
"contact"와 "register"를 복사하고
여기에 똑같이 언급합니다
이제 여러분께 또 질문 해보겠습니다
CRSF와 일치되는 요청을 무시하는 중에
왜 notices API를 언급하지 않았는지 알고 계십니까?
생각해 보십시오
5초 드리겠습니다
1, 2, 3, 4, 5
잘 맞추셨는지 보겠습니다
notice API를 언급하지 않은 이유는
이 ignoringRequestMatchers는
GET API이기 때문입니다
항상 백엔드에서
데이터를 가져온다는 뜻입니다
절대 백엔드에 새로운 데이터를 게시하거나
데이터를 업데이트하지 않습니다
그래서 http GET 메소드도
Spring Security 프레임워크가
CRSF 보호를 하지 않는 것입니다
이해되셨기 바랍니다
변경 사항들을 저장해보겠습니다
여기에서 빌드를 수행하여 이러한 변경 사항을 검증할 수 있도록 하십시오
먼저 새로운 유저를 복구시키려면
이것은 post 메소드이며
Easy bytes 라고 이름을 언급할 수 있으며
이름을 지었으면 이메일도 쓰고
tutor@therateeasybytes.com 처럼 그리고 전화번호도
10자리 숫자 중에 아무거나 괜찮습니다
그리고 비밀번호는
일단 1, 2, 3, 4, 5로 하십시오
역할(role)도 그대로 유저로 하겠습니다
이제 이 전송 버튼을 눌러
API를 불러오려고 합니다
요청이 중단점에서
registerUser 메소드에서 멈춘 것을 볼 수 있습니다
이 중단점을 없애보겠습니다
그리고 중단점을 끝내고
새로운 유저가 데이터베이 안에 생성되도록 합니다
이제 성공적인 응답을 받는 게 보일 것입니다
왜냐하면 Spring Security에게
어떠한 CSRF 보호도 하지 말라고 했기 때문입니다
이 /register 경로에서는 말입니다
Contacts도 마찬가지인지 검증해보겠습니다
Contacts 공간에
이번에는 Easy Bytes와 같은 이름과
이메일과 내용을 작성하여 샘플 메시지를 만들어줍니다
여기서는 자세한 메시지 내용을 적고
이 전송 버튼을 누르면
메시지가 성공적으로 제출되었고
Reference ID은 SR(service request number)는
이러이러하다는 메시지를 받았습니다
이 메시지는 우리가 문의하기 페이지에
성공적으로 저장했다는 것을 확인시켜 줍니다
그럼 데이터베이스도 빠르게 검증해 보겠습니다
우선 contact_messages 테이블을 열면
전에 제출한 정보와 동일한
기록들을 볼 수 있습니다
customer 테이블에서도
새로운 유저가 있고
Easy Bytes 라는 이름과 비밀번호는 역시 해시 처리되어 있습니다
똑같은 1, 2, 3, 4, 5 비밀번호를 줬는데도 말입니다
전에 설명한 것처럼 다른 비밀번호들과 겹치지 않습니다
Bcrypt 해싱의 미학입니다
우리가 ProjectSecurityConfig 클래스에서
만든 설정들도
Spring Security가
특정 공공 API에서 CSRF 보호는 무시하도록 요청합니다
하지만 이걸로는 진짜 CSRF 공격을 해결하지 못합니다
CSRF 공격은 조금 더
제한되고 보호되는 API들에서 의미있기 때문입니다
그래서 다음 강의에서는
보다 완벽한 CSRF 솔루션을 구현해 보도록 하겠습니다
보호된 API로 말입니다
잘 이해되셨기 바랍니다
감사합니다 다음 강의 때 뵙겠습니다
수고하셨습니다