Roronoa

문제 설명피해자의 이메일을 변경하면 문제를 해결할 수 있다.문제 풀이My Account 페이지에 접근한 후 이메일 변경 요청을 수행한다. 이메일 변경 요청 시 CSRF 토큰이 존재하지 않는다. Referer 헤더를 제거한 후 이메일 변경 요청을 수행할 시 Referer 검증을 통해 에러를 반환한다. Referer 헤더에 google.com?같은 사이트 와 같이 전송하면, Referer 검증을 우회할 수 있다. POCmeta 태그 referrer 속성을 unsafe-url로 설정한다.history.pushState()를 사용하여 페이지를 reload하지 않고 url만 변경한 후 CSRF 공격을 진행한다. 공격 코드를 피해자에게 전송하여 문제를 해결하였다.

문제 설명피해자의 이메일을 변경하면 문제를 해결할 수 있다.문제 풀이My Account 페이지에 접근하여 이메일 변경 요청을 진행한다. 이메일 변경 요청시 CSRF 토큰이 존재하지 않는다. Referer 헤더 변조 시 Referer 검증 로직이 존재하여 에러가 발생한다. Referer 헤더가 포함되지 않은 요청에 대해서도 서버가 정상적으로 응답하므로, Referer 검증이 수행되지 않는 것으로 판단된다. POCmeta 태그 no-referrer 설정을 통해 referrer를 전송하지 않고 CSRF 공격을 수행한다. 공격 코드를 피해자에게 전송하여 문제를 해결하였다.

문제 설명패해자의 email 주소를 변경하면 문제를 해결할 수 있다.문제 풀이로그인 시 social-login 페이지에 접근되며 몇 초후에 login 페이지로 리다이렉트 된다. 로그인 시 session의 samesite 값이 설정되어 있지 않다. samesite가 설정되어 있지 않은 경우 크롬 브라우저에서 2분 후에 Samesite를 Lax로 설정한다. 2분동안 POST 전송시 쿠키가 포함된다. 이메일 변경 요청이 POST 방식으로 처리되며, CSRF 토큰이 존재하지 않아 CSRF 공격이 가능한 것으로 판단된다. CSRF 공격 시 social-login 페이지로 리다이렉트되어 정상적으로 공격이 수행되지 않는다. POC본 코드는 window.onclick 함수를 활용하여 사용자가 공격자 페이지를 클릭하면 ..

문제 설명피해자 계정으로 로그인하면 문제를 해결할 수 있다.문제 풀이/chat 경로에 접속할 시 READY라는 데이터를 서버에 전송하여 기존의 메시지 내용을 불러온다. /resources/js/chat.js 경로에서 Access-Control-Allow-Origin 헤더에 [cms-사이트 주소]가 설정되어 있다. Access-Control-Allow-Origin 헤더가 설정되어 있는 경우 다른 도메인이라도 자원에 접근할 수 있게된다. CMS 페이지에 접근할 경우 로그인 페이지가 표시되며, 이 로그인 페이지의 Username 입력 필드에서 XSS(크로스사이트 스크립팅) 취약점이 발생 한다. CMS 페이지의 로그인 기능에서 username 파라미터에 XSS(크로스사이트 스크립팅) 공격 구문을 삽입할 경우, ..

문제 설명XSS 필터가 존재하는 라이브 채팅 페이지에서 XSS를 통해 alert 구문을 트리거하면 문제가 해결된다.문제 풀이Live chat 페이지에서 XSS 구문 삽입 시 필터링되며 해당 IP가 차단된다. 차단된 IP는 X-Forwarded-For 헤더를 추가하여 IP 우회가 가능하다.POCIP를 우회한 후 iframe srcdoc 속성을 통해 XSS 필터링 우회에 성공하였다.'> XSS 필터링을 우회하여 alert(1) 구문을 트리거하여 문제를 해결하였다.

문제 설명크로스 사이트 웹소켓 하이재킹 공격을 통해 피해자의 채팅 기록을 유출한 다음 피해자의 계정을 탈취하면 문제가 해결된다.문제 풀이Live chat 페이지에 웹 소켓을 통한 채팅이 이루어진다. Live chat 페이지 접근시 먼저 웹 소켓으로 READY를 전송하여 채팅 기록을 가져온다. POC1. 피해자가 공격자 페이지 접근2. 웹 소켓 연결이 성공할 경우 onopen 핸들러를 통해 READY 데이터 전송3. 웹 소켓 onmessage 핸들러를 메시지가 수신될 경우 fetch 함수를 통해 기존 채팅 기록을 base64로 인코딩하여 유출 POC 전송 후 로그 확인 결과 base64로 인코딩된 데이터를 확인할 수 있다. base64 디코딩하여 carlos의 비밀번호를 확인할 수 있다. carlos 계정..

문제 설명WebSocket 메시지를 사용하여 담당자 브라우저에 alert()를 띄우면 문제가 해결된다.문제 풀이Live chat 페이지에 접근하여 alert()를 페이지에 띄우는 XSS 공격 구문을 입력한다. XSS 구문 입력 시 가 html 엔티티로 치환되어 웹 소켓 메시지가 전송된다. 웹 소켓을 변조하여 XSS 구문을 전송한다. 웹 소켓 메시지 재전송 시 alert(1) 구문이 발생하면서 문제가 해결된다.

문제 설명CSRF 공격을 통해 사용자 email을 변경하면 문제가 해결된다.문제 풀이로그인 시 session의 SameSite 값이 Strict로 설정되어 있다. My Account 페이지에 접근한 후 이메일 변경을 요청한다. 이메일 요청 결과 Burpsuite 패킷에서 csrf 토큰이 존재하지 않는다. GET 메소드로 변환하여 전송할 시 csrf 토큰 없이도 이메일 변경이 가능하다. 하지만 SameSite가 Strict로 설정되어 다른 Origin에서 CSRF 공격을 성공할 수 없기 때문에 같은 Origin에서 CSRF 공격을 성공할 수 있는 취약점을 찾아 연계하여야한다. 블로그 포스트에 접근한 후 Comment를 작성한다. 블로그 Comment 작성 후 /post/comment/confirmation..

문제 설명CSRF 공격을 통해 사용자 이메일을 변경하면 문제를 해결할 수 있다.문제 풀이wiener 계정으로 로그인을 진행한다. wiener 계정 로그인 성공 후 session을 확인한 결과 SameSite 속성이 지정되지 않았기 때문에 SameSite가 default인 lax로 설정된다. wiener 계정으로 로그인한 상태에서, 이메일 변경을 진행한다. 이메일 변경 요청 패킷을 분석한 결과, CSRF 토큰이 존재하지 않음을 확인하였다. 하지만 session의 SameSite가 lax로 설정되어 있기 때문에 POST로 CSRF 공격을 수행할 수 없다. 이메일 변경 요청을 HTTP GET 메서드로 변경한 후, 요청 파라미터에 _method=POST를 추가하여 전송한 결과, 해당 요청이 정상적으로 처리되는..

문제 설명CSRF 공격을 통해 사용자의 email을 변경하면 문제를 해결할 수 있다.문제 풀이wiener 계정으로 로그인한 상태에서 이메일 변경 요청을 진행하였다. 이메일 변경 요청 시 csrf 쿠키와 요청 파라미터의 csrf 값이 일치하는 것을 확인하였다. csrf 쿠키와 csrf 파라미터의 값을 모두 1로 변조한 후 요청을 수행하였으며, 해당 요청이 정상적으로 처리되는 것을 확인하였다. 해당 웹 페이지에서 검색 기능이 존재하며, 검색을 진행하였다. 검색 기능에서 사용자가 입력한 검색어가 응답에 반영되는 것을 확인하였다. CRLF 인젝션을 통해 사용자가 임의의 HTTP 헤더 삽입이 가능하며, Set-Cookie 헤더를 이용하여 csrf 쿠키 임의로 지정하는 것이 가능하였따. CSRF POC먼저 img..