annyoung

피해자 환경은 공격자 서버로 요청할 수 있게끔 iframe의 src attribute에 삽입해서 userAgent를 확인했을때 IE11+Windows로 파악했다. 더 확실하게 확인하기 위해서 iframe의 src에 http://localhost와 file:///C:\\ 했을때 결과를 봤다. iframe에서 에러난 화면이 ie11로 보였다. ie11 익스를 하려고 했는데 장애가 있을까봐 시도해보진 못했다. 우선 file 스키마나 cors는 브라우저가 이미 애초에 로컬 리소스를 띄워줬기 때문에 접근이 가능했지 않았을까 하는 생각이든다. 아니면 애초에 레거시 브라우저라서 가능했을 수도 있다. 아무튼 ec2 metadata 엔드포인트에 요청했고 다행히 credentials을 받아낼 수 있었다. 하지만 변수가 있..

2024년 7월 25일에 추가된 WebAPI oncontentvisibilityautostatechange 덕분에 input type이 hidden인 경우에도 XSS를 트리거할 수 있게 되었다.  * 페이로드 출처: https://x.com/kinugawamasato/status/1816234368714871185

개인적으로 느끼는게 SSRF가 pdf generator에서 많이 발생하곤 한다. pdf 파일을 vi나 xxd로 확인해보면 Chromium이거나, Skia/PDF인 경우 chromedriver에서 렌더링하기 때문에 XSS로 인해 SSRF가 많이 발생한다. 사이트 기능중에 pdf generator가 있다면 한번쯤 테스트 해보는걸 추천한다. 테스트 하는 방법은 다음과 같다. pdf generator에서 필요한 값에 위처럼 입력하면 fetch로 공격자 서버에 요청보내게 되어 SSRF가 발생하는걸 볼 수 있다.

시간이 지나면서 해킹에 있어 XSS는 가지각색의 케이스가 있으며 다양한 이름으로 불린다. 대부분 서버에 저장되어 발생하는 저장형(Stored XSS)과 저장되지 않고 클라이언트 HTML에만 반영되는 반사형(Reflected XSS)으로 나눌 수 있으며, 여기서 더 상세하게 나눠보면 파라미터 입력값 파싱을 위해 클라이언트 JS에서 반영되어 발생하는 DomXSS, 더 나아가서 XSS가 발생했는지 여부를 모르는 경우 Blind XSS라 칭한다. 이를 방어하기 위해서는 필자가 생각하기엔 다음과 같은 두가지 방법이 있다. 1) 애초 당시에 XSS를 방지하기 위해서 입력되는 모든 값에 대해 HTML이 반영되지 않도록 Entity Character로 변환하는 과정을 거쳐야 한다. 는 >로 치환하여 클라이언트 사이드에..