# csrf

jjing9

웹 개발자라면 당연히 알아야하는 공격중 하나! 근데 생각해보니 나.. 제대로 알고 있나..? 한번쯤 정리하면 좋겠다 싶어서 정리를 해보려고 한다. CSRF란 CSRF는 Cross-Site Request Forgery의 약자로, 사이트 간 요청 위조를 의미한다. 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹 사이트에 요청하게 하는 공격을 말한다. CSRF 공격이 가능한 이유는 웹 브라우저가 사용자가 인증한 상태를 유지하기 때문이다. 공격자는 사용자가 인증된 상태를 악용해 공격자가 의도한 행위를 하도록 유도한다. 예를 들어, 공격자는 사용자가 이메일에 포함된 악성 링크를 클릭하도록 유도할 수 있다. 이 악성 링크는 사용자가 인증된 웹사이트에 요청을 전송하도록 한다. 이 요청은 사용자가 직접 전송한 것이 아니기 때문에 사용자는 이를 인지하지 못할 수 있다. CSRF 공격 계정 탈취 데이터 유출 결제 요청 CSFR 공격을 방지 **C

woojjam

1. 들어가며 Spring 으로 로그인을 구현하다보니 반드시 Spring Security에 대해서 공부가 필요하게 되었고 Security에 대해서 정리가 필요하여 작성하게 되었다. Spring Security의 여러개의 예제 코드를 보면 http.csrf().dsiable() 이라는게 있었는데 csrf가 무엇이며, 왜 disable 하는 것 일까? 또한 cors를 설정해주는데 설정하는 이유가 무엇이며, cors가 무엇일까? 2. CSRF 2.1. CSRF란? Cross site Request forgery의 줄임말로 사이트간 위조 요청으로 웹 사이트 취약점 공격중 하나 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(CRUD)를 특정 웹사이트에 요청하게 되는 공격 CSRF protetion은 spring security에서 default로 설정되며, csrf 토큰을 통해 위조 요청을 방지하게 됨 > 1. 특정 웹사이트에 접

gamgam330

프로젝트에서 spring security를 사용하는 중인데, spring 6.0 이후부턴 Adapter을 상속받아오지 못하고, Bean으로 등록해야 한다고 한다. 이렇게 바뀌면서 좀 많은 부분이 바뀐거같아 바뀐부분과 CSRF오류에대해 작성해보도록 하겠다. 👍변경 전 이렇게 WebSecurityConfigurerAdapter를 상속받아 configure 메서드를 Override해서 사용했었다. 내가 알고있는 바뀐부분에대해 정리해보겠다. Override -> Bean등록으로 변경 authorizeRequests() -> authorizeHttpRequests() antMatchers() -> requestMatchers() access() -> hasAnyRo

rkdls7815

CSRF > Cross Site Request Forgrey 웹 어플리케이션 취약점 중 하나로 인터넷 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정한 웹 사이트에 요청하게 하는 공격 ex) 해커가 사용자의 SNS 계정으로 광고성 글을 올리는 것 -> 사용자가 웹 사이트에 로그인한 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면 공격 대상이 되는 웹 사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출됨 아래의 조건이 만족할 때 실행 사용자가 해커가 만든 피싱 사이트에 접속한 경우 위조 요청을 전송하는 서비스에 사용자가 로그인을 한 상황 대응 기법 리퍼러(R

sunghoon1216

CORS(Cross Origin Resource Sharing)의 약자로, 클라이언트와 서버간의 포트 번호가 다를 경우에(요청을 주고 받는 곳이 다를 경우에) 리소스를 주고받을 때, 해당 데이터를 신뢰할 수 있는지 판단할 수 없기 때문에 브라우저에서 발생하게 되는 오류를 말한다. 브라우저는 결과의 헤더값을 통해 CORS를 확인하게 된다. 포스트맨과 같은 툴로 서버에 요청을 보냈을 때는 제대로 응답할 수 있어도, 브라우저에 띄워 실행했을 때 오류가 발생할 가능성이 있다. 위의 코드처럼, CORS문제를 해결하기 위해 모든 경로에 대해 CORS를 허용하는 방법은 공부할 때에는 유용한 방법일지 몰라도, 실 배포 상황에서는 좋지 않은 방법이다. 가장 좋은 방법은 특정 도메인만 허용하게 하는 것이 가장 좋은 방법이다. CORS 문제를 살펴보면서, CSRF(Cross-Site Request Forgery) 이슈와 느낌이 비슷하다는 생각이 들어 Chat GPT에 물어봤는데, 두 가지

sue6e2

저번에 리액트 프로젝트를 하면서 로그인 api 찌를 때 header에 X-Requset-With를 써주지 않으면 cors 에러가 떠서 찾아본 적이 있었다. 같은 내용을 백엔드 팀 동료가 질문했는데 '보안 강화' 라는 것만 어렴풋이 생각나서 이번 기회에 관련 내용들을 다시 공부하고 정리한다. X-Request-With 필요한 이유 해당 요청이 Ajax라는 것을 의미한다. X-Requested-With을 쓰는 이유는 CORS를 통해 서버 동의 없이 Ajax 요청을 할 수 없기에 CSRF 공격을 방지할 수 있다. 즉 보안을 강화시켜준다. 위 설명에서 CORS, CSRF가 뭐냐고 물어보면 명확하게 대답하기 어려워서 더 찾아 보았다. CORS란? Cross Origin Resource Sharing 한 도메인 또는 Origin의 웹 페이지가 다른 도메인을 가진 리소스에 엑세스 할 수 있게 하는 보안 메커니즘이다. CORS는 서버와 클라이언트가 정해진 헤더를 통해

tnwjd6236

Security 실습해보기. 파일: springboot-thymeleaf-todo-230803 https://mvnrepository.com/ Spring Boot Starter Security 복사해서 build.gradle에 security 추가 ![](https://velog.velcdn.com/images/tnwjd6236/

choidongkuen

들어가면서 안녕하세요 오늘은 CSRF(Cross-Sirte Request Forgery Attack) 에 대해 알아보겠습니다. 요즘 프로젝트 진행을 하면서 사용자 인증 & 인가 부분을 담당하고 있습니다. 이때 Spring Security 와 Oauth2.0 을 사용하고 있는데요. 이때 Spring Security 설정을 위해 작성하는 코드에서 대부분에 코드에 CSRF 을 비활성화 해놓습니다. 지금까지는 다른 사람의 코드를 참고했기 때문에 당연하게 비활설화 했지만 이유를 알고 사용하자는 생각에 이번 기회에 CSRF 에 대해 자세히 알아보고자 합니다 👨‍💻 CSRF, Cross-Site Request Forgery 본격적으로 CSRF 에 대해 알아보겠습니다

wldbs35

프로젝트를 하던 중, 프론트와 백엔드를 서로 다른 프레임워크로 구현하였다. 이 두 프레임워크 간의 데이터 통신을 해야하는데 CORS 정책을 지켜줘야 한다고 한다. 이 CORS 정책이 뭔지 알아보자~! CORS 브라우저(클라이언트)에서 설정한다. 자신과 origin이 다른 곳으로 요청을 못하게 막는다. origin이란, "프로토콜+도메인+포트번호"의 조합으로 각자의 '출처'를 의미한다. CORS를 하는 이유, 브라우저에서 해야하는 이유 CSRF 같은 해킹을 막을 수 있게 도와주는데, 예를 들어 내 이메일로 온 하나의 url을 나도 모르게 클릭했을 때, 나와 출처가 다른 url로 아무 제지 없이 접속이 된다면 내 정보가 바로 흘러들어갈 수 있다. 1. 단순 요청 브라우저가 요청을 보낼 때, 헤더의 Origin에 자신의 출처를 적어 보낸다. 서버는 응답 헤더의 Ac

thdcodud01

csrf : CSRF란, Cross Site Request Forgery의 약자로, 한글 뜻으로는 사이트간 요청 위조를 뜻합니다. CSRF는 웹 보안 취약점의 일종이며, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(데이터 수정, 삭제, 등록 등) 을 특정 웹사이트에 요청하게 하는 공격입니다. 예를 들어, 피해자의 전자 메일 주소를 변경하거나 암호를 변경하거나 자금이체를 하는 등의 동작을 수행하게 할 수 있습니다. 특성에 따라, 공격자는 사용자의 계정에 대한 완전한 제어권을 얻을 수 있을 수도 있습니다. cookie & session 사용자가 특정 서버에 로그인하면 일반적으로 다음과 같은 작업들이 수행됩니다. 서버는 로그인 시 인증된 사용자의 정보를 세션(session)에 저장하고, 이를 찾을 수 있는 sessionID을 만듭니다. 서버는 저장된 세션 정보를 클라이언트(브라우저)가 사용할 수 있도록 sessionID를 Set-Cookie 헤더에 담아서

kimmin0411

login에서 guest,guest로 로그인후 flag에다가 csrf-1에서 사용했던 코드를 사용하면 될 것 같아서 비슷하게 접근을 했는데 계속 오류가 진행이 안 됐다. 알고보니 계속 잘못 적고 있던 것이다. 내가 계속 잘못적고 있던 코드 : ->이렇게 적는 건 줄 알고 계속 헛발질 했다. 원래 적어야 하는 코드 : > 제대로 된 코드를 적으니 위의 사진 같이 뜨고 메인화면으로 가니 아래화면 처럼 flag가

inmo

CSRF (Cross Site Request Forgery) 피해자 세션을 사용해 피해자 의도와 상관없이 서버로 위조된 요청을 보내는 공격 게시판, 메일함과 같이 로그인 해야만 사용 가능한 서비스에서 발생하는 취약점이다. 어디서 발생하는가? 모든 요청에서 발생한다. 하지만 비밀번호 변경, 이메일 주소 변경, 관리자 계정 등록, 계정 삭제, 글 작성, 수정 등과 같은 민감한 요청에서 더욱 취약하다. CSRF vs XSS 둘다 클라이언트 측을 공격하는 점을 동일하다. CSRF 피해자가 자신의 의도와 상관없이 서버로 임의의 요청을 하게 만드는 공격 XSS 피해자 브라우저 측에서 악성 스크립트를 실행하는 공격 공격 기법 GET Method 로그인 한 다음에 볼 수 있는 페이지에 URL을 삽입해 공격한다. POST Method 반드시 XSS 취약점을 찾아야 한다. 세션을 이용해

inmo

취약점 설명 CSRF 공격이란 피해자 세션을 사용해 피해자 의도와 상관없이 서버로 위조된 요청을 보내는 공격이다. 게시판, 메일함과 같이 로그인 해야만 사용 가능한 서비스에서 발생하는 취약점으로 모든 요청에서 발생한다. 하지만 비밀번호 변경, 이메일 주소 변경, 관리자 계정 등록, 계정 삭제, 글 작성, 수정 등과 같은 민감한 요청에서 더욱 취약하다. 개념 증명 CSRF 공격을 이용해 피해자 의도와 상관없이 비밀번호 변경을 시도하겠다. 그리고 해당 취약점에 대한 개념 증명을 위해 Burpsuite Proxy 모드의 Intercept, HTTP History 기능으로 CSRF 공격을 진행했다. 패스워드 수정 요청 우선 취약점 발생 여부를 확인하기 위해 마이페이지에서 test 패스워드를 입력 후 수정을 진행한다. ![](https://velog.velcdn.com/images/inmo/post/c4695797-7322-4dd9-8396-edb7890cd71

inmo

취약점 설명 CSRF 공격이란 피해자 세션을 사용해 피해자 의도와 상관없이 서버로 위조된 요청을 보내는 공격이다. 게시판, 메일함과 같이 로그인 해야만 사용 가능한 서비스에서 발생하는 취약점으로 모든 요청에서 발생한다. 하지만 비밀번호 변경, 이메일 주소 변경, 관리자 계정 등록, 계정 삭제, 글 작성, 수정 등과 같은 민감한 요청에서 더욱 취약하다. 개념 증명 CSRF 공격을 이용해 피해자 의도와 상관없이 비밀번호 변경을 시도하겠다. 그리고 해당 취약점에 대한 개념 증명을 위해 Burpsuite Proxy 모드의 Intercept, HTTP History 기능으로 CSRF 공격을 진행하였다. 취약점 확인 우선 취약점 발생 여부를 확인하기 위해 마이페이지에서 test 패스워드를 입력 후 수정을 진행한다. ![](https://velog.velcdn.com/images/inmo/post/c26b910e-d54c-45ae-a359-fa0a7ec9ce5e

inmo

취약점 설명 CSRF 공격이란 피해자 세션을 사용해 피해자 의도와 상관없이 서버로 위조된 요청을 보내는 공격이다. 게시판, 메일함과 같이 로그인 해야만 사용 가능한 서비스에서 발생하는 취약점으로 모든 요청에서 발생한다. 하지만 비밀번호 변경, 이메일 주소 변경, 관리자 계정 등록, 계정 삭제, 글 작성, 수정 등과 같은 민감한 요청에서 더욱 취약하다. 개념 증명 CSRF 공격을 이용해 피해자 의도와 상관없이 비밀번호를 변경하고 피해자 계정으로 글을 작성하겠다. 그리고 해당 취약점에 대한 개념 증명을 위해 Burpsuite Proxy 모드의 Intercept, HTTP History, Repeater 기능으로 CSRF 공격을 진행하였다. 취약점 확인 우선 취약점 발생 여부를 확인하기 위해 마이페이지에서 test 비밀번호를 입력 후 수정을 진행하였다. Burpsuite HTTP history 탭에서 Request 확인 결과, 비밀번호와

minjun7410

(CSRF Token을 포함하지 않을 시 django의 응답) 배경 Global AD Platform 보드에서 Create 요청을 보낼 때 form 태그에 감싸서 보내는 형태를 사용한다. 따라서 CSRF verification이 불가피하다. 원래라면 프론트엔드에서 작업할 때 CSRF Token을 사용해야하지만 프론트엔드 개발자에게 넘기기 전에 간단하게 Postman으로 작동하는 지 검사하려고 했다. 때문에 우리는 테스트할 때만 CSRF를 스킵할 필요가 있었다. 해결 View에서 데코레이터를 통해 csrf를 스킵하고 Create를 할 수 있었다. ! 릴리즈 전에는 꼭 csrf를 사용하도록 하자. 해커가 유저의 행위를 도용할 수 있는 통로가 된다 !

ned4spd

ajax로는 beforeSend 안에 xhr.setRequestHeader(header, token) 을 첨부하면 csrf 값을 전송할 수 있는데 axios에서는 그 방법을 몰라 찾아봤다. 반드시 [ ] 안에 csrfheader값을 넣어야한다. 출처 : https://okky.kr/questions/587528 https://docs.spring.io/spring-security/site/docs/5.0.x/reference/html/csrf.html#csrf-include-csrf-token-ajax

shwncho

문제 원인 Spring Boot 3.x 버전을 사용하면서 Spring security도 6.x를 사용하게 됐다. 그런데 Spring Boot 2.x 버전과 Spring security 5.x 버전을 사용하면서 나타나지 않았던 문제가 생겼다. 보통 csrf랑 연관되서 403 에러가 나지만, Jwt를 사용하기 때문에 SecurityConfig에서 이미 disable을 해준 상황이다. 그래서 Spring security 5.x -> Spring security 6.x 의 변화된 부분을 공식문서를 통해 확인한 결과 더 이상 모든

sojeong630

ClientSide: CSRF 이용자의 신원 정보가 포함된 쿠키는 일종의 서명과 같은 역할을 한다. 이용자의 식별 정보가 포함된 쿠키는 클라이언트에서 보내진 요청이 이용자로부터 왔으며, 이용자가 동의했고, 따라서 요청에 이용자의 권한이 부여돼야함을 의미한다. 사이트 요청 위조(Cross Site Request Forgery, CSRF) 이용자를 속여서, 의도치 않은 요청에 동의하게 하는 공격이다. ex) 웹 페이지를 만들어 이용자의 입력을 유도해, 입력된 값을 은행 등의 사이트로 전송해 이용자가 동의한 것 같은 요청을 발생시킨다. 웹 서비스는 쿠키나 세션을 사용해 이용자를 식별한다. 이용자를 속여서, 의도치 않은 요청에 동의하게 하는 공격 임의 사용자의 쿠키를 사용할 수 있다? -> 임의 이용자의 권한으로 웹 서비스의 기능을

sojeong630

https://dreamhack.io/wargame/challenges/269/ 오늘 풀 csrf 연습문제 접속해보니, 페이지가 나오고 로그인을 해달라는 창이 나온다. 코드 확인하니 guest의 비밀번호는 guest! admin의 비밀번호를 알아내는게 문제다. 우선 guest로