불완전한 Reflected XSS 패치로 인한 Reflected XSS 취약점 재발생

개요

[취약점 제보에 대한 개요를 작성해 주세요]
다른 파라미터의 경우 " 를 ” (비슷하지만 다른문자)로 치환하여서 " 태그가 깨지는 것을 방지하였고 , reflected 취약점을 막을 수 있었지만
no parameter의 경우 " 가 "로 치환되면서 "를 다른 문자로 제대로 치환해주지 않았습니다.
이로 인해 태그가 깨지게 되었고 , 여러 필터링이 있었지만 아래와 같은 과정으로 Reflected XSS 사이트 취약점이 여전히 존재하게 됩니다.

재현 과정

[취약점 재현을 하기 위한 과정을 서술해 주세요]
1.https://www.soosanint.com/board/board_view.php?board_id=notice&no=-10%22%3E%3Cimg%20src=1%22%20onerror=alert%60XSS%60%3E

예상되는 취약점 발생 원인

[해당 취약점이 발생하는 예상 원인을 서술해 주세요]
"를 &quot나 다른 문자로 치환하지 않은 채 "로 치환되어 "가 계속 살아있게 되고 , 태그가 깨지면서 XSS 취약점을 다시 발생시킵니다.

패치 방법

[해당 취약점을 패치하기 위한 대응 방법을 서술해 주세요]
다른 파라미터 처럼 " => /" 로 바뀔때 "도 다른 문자로 치환해주세요! (다른 파라미터 조치한것과 동일한 방식으로 패치해도 됩니다!)

예상 결과 및 파급력

[해당 취약점으로 인해 예상되는 결과 및 파급력을 서술해 주세요. 시나리오가 포함되어도 좋습니다.]
이전에 제보한 위험성과 비슷합니다.

기타사항 및 레퍼런스

[그 외에 추가할 내용이 있다면 이곳에 작성해주세요.(스크린샷, 로그 등)]
XSS 우회기법은 정말 많습니다. 심지어 방화벽에서 필터링을 해도 , 뚫리는 경우가 상당합니다.
다만 reflected 취약점의 경우 case에 따라 다르지만 이번의 경우 "를 다른문자로 치환하는 것만으로도 여러 필터링 없이 XSS를 막을 수 있습니다.
현재 취약점을 " 치환이 아닌 alert 나 다른 문자열 필터링을 할 경우 , 다른 우회기법으로 다시 취약점이 발현될지도 모릅니다.

재발 상태를 막기 위해서 취약점 패치 후 , 취약점 제보자에게 검증을 요청하는 과정이 있으면 좋을 것 같습니다! (hackerone이나 네이버 등등에서도 제보자로부터의 검증과정을 거칩니다!)