XSS Point 4
DATE : 2023/12/22
Last updated
DATE : 2023/12/22
Last updated
이번엔 XSS Point 찾기, 네 번째 문제이다.
마이페이지도 확인해봤지만 별 다른 취약점을 찾지는 못했다.
내용은 이전 문제와 비슷하니 생략하도록 한다.
바로 공지 사항 페이지로 넘어가 보자.
공지 사항 페이지에서는 게시물을 작성할 수 있었다. 이번에도 마찬가지로 제목과 내용을 간단히 작성해
create 버튼을 누르면 게시물이 등록된다.
이때의 Packet을 확인해보면 아래와 같다.
create_title, create_body 라는 이름으로 사용자가 작성한 게시물의
제목과 본문 내용이 전달되고 있는 걸 볼 수 있다.
게시물을 작성하게 되면 그 내용이 DB에 저장되었다가
상세 페이지로 이동할 시, 해당 페이지의 정보를 DB에서 꺼내와 화면에 출력해주는 것인데
이를 잘 생각해보면 Stored XSS를 수행할 수 있는 조건임을 이해할 수 있을 것이다.
그렇다면 스크립트를 실행할 수 있을 지, 삽입해보도록 하자.
일단 제목에 스크립트를 삽입해보기로 했다.
위와 같이 create_title 내용을 수정해 Forward!
일단 게시물은 성공적으로 업로드 되었다.
하지만 스크립트가 동작하는 지의 여부는 상세 페이지로 들어가 봐야 알 것!
게시물을 클릭해 상세 페이지로 이동해보면 아무 일도 일어나지 않는다.
다만, 페이지 내용을 확인해보았더니 제목이 작성한 바와 다르게 출력 되고 있다는 걸 알게 되었다.
Packet 내용을 확인해보면
제목으로 출력 되고 있는 값이 아래와 같이 나오고 있는 걸 볼 수 있는데
원래 작성했던 내용과 비교해보면 현재 이 사이트에서는
alert, script 라는 단어를 필터링하고 있다는 걸 눈치챌 수 있을 것이다.
그렇다면 이 페이지에서
(1) alert가 아닌 confirm OR prompt는 실행이 가능한가
(2) script를 대소문자를 섞어 쓰거나 대문자로 작성해도 필터링 되는가
의 여부를 체크해볼 필요가 있을 거 같다.
상세 페이지에서 수정 버튼을 누른 다음에 alert -> confirm으로 수정해본 결과
confirm은 출력이 잘 되는 걸 확인할 수 있었다. 그럼 prompt는 어떨까?
prompt도 잘 나오는 걸 보면 이 페이지에서는 alert만 필터링하고 있는 듯하다.
그럼 alert 대신 prompt, confirm을 사용하면 되는데 문제는 script 또한 필터링 된다는 점이다.
과연 script라는 단어 자체를 못 사용하는 것인지 확인하기 위해, 우선 대문자로 수정해보기로 했다.
script -> SCRIPT로 수정한 다음, 변경 내용을 업데이트 해준다.
이제 해당 게시물을 요청해볼 건데, 만약 script를 필터링 하는 기능이 소문자의 경우에만 동작한다면
대문자로 변경한 후에는 <script> tag가 실행되면서 confirm() 함수의 결과를 확인할 수 있을 것이다.
결과를 확인해보면! 성공적으로 confirm 함수가 실행된 팝업 창을 볼 수 있다.
prompt 함수를 사용했을 때도 결과는 마찬가지이다!
즉 이번 문제는 특정 단어를 필터링 하는 기능이 구현되어 있던 것이고
이를 우회하기 위해서 소문자를 대문자로, 비슷한 기능을 수행하는 다른 함수로 대체함으로써
Stored XSS 공격을 성공할 수 있었다. 😄
