Stored XSS in Sitename in answerdev/answer
Reported on
Feb 22nd 2023
Description
There is a presence of stored xss in username, which directly gets rendered whenever the page is opened.
Proof of Concept
1: use the below command to clone the repo in your machine
git clone https://github.com/answerdev/answer.git
2: Navigate inside the repo
cd answer
3: Use docker-compose to spin it up locally
sudo docker-compose up
4: The installation will now be available in http://localhost:9080/install -> open the same in browser
5: While setting up the installation, choose SQLite
6: In the next page it will ask for the sitename. Use <script>alert(1)</script> as the sitename and fill up the rest of the details of the page as it is.
Once the page is opened, it will pop up the stored xss payload directly.
Impact
An attacker can perform javascript injections on victim browser that will lead to cookie stealing, installing javascript malware and keyloggers, performing remote actions etc.
SECURITY.md exists
9 months ago
Hi, sorry for the newbie question, I am new to this portal so asking. How can I get to see the cve that has been assigned to me?
I don't think this is a security vulnerability because the attacker didn't have permission to install the site, much less change sitename. Attacks don't happen in the real world
On the contrary, an attacker can self-host the site, and post the link in a forum, once the visitor opens the link, javascript will render in their browser causing the attack.
Also https://nvd.nist.gov/vuln/detail/CVE-2023-1239 , would not be a vulnerability if what you are saying is to be abided, not only that, based on your logic, all open source CMS, even WordPress issues like authenticated XSS, SQLI etc are not security vulnerabilities, since they require authentication that too of an admin. Before answering about chaining, please do show me some actual documentation where a researcher who discovered authenticated XSS, SQLI in cms like WordPress etc chained the vulnerability to fetch cookie of an admin via another xss to conduct the next xss attack just to proof that the vulnerability is valid :)
(https://nvd.nist.gov/vuln/detail/CVE-2023-1239) It is also not a security vulnerability in the real sense. The key to the problem is that the attacker who can launch the attack already has the administrator rights. He cannot make further profits through this vulnerability and do more than his rights.
I'm not saying that authenticated XSS is not a vulnerability. If you find an xss whose injection point requires authenticated normal user permissions, and whose trigger point can attack other normal users or administrators, then it is a vulnerability. But if you find an xss where the injection point requires super administrator access, and the trigger point only attacks regular users and other administrators, it's not really a vulnerability. Why wouldn't the super administrator just change the passwords of other users and take over their accounts?
Many CMS super administrators can add traffic statistics code in the management background. If the xss authenticated by the super administrator is a real vulnerability, the function points of adding traffic statistics code will be vulnerable. In fact, however, the Bounty project doesn't see this as a bug, but as a feature
@shangrui-hash , I think what you are saying is not correct. This is indeed a vulnerability. You can check there are huge number of registered cve's in multiple CMS like Joomla Wordpress and others where authenticated attacks which can be performed only by superadmins are present. For example https://nvd.nist.gov/vuln/detail/CVE-2022-1565 or https://nvd.nist.gov/vuln/detail/CVE-2022-4373 Even I saw just now, the topmost issue in hacktivity of huntr which got a cve assigned https://huntr.dev/bounties/16bc74e2-1825-451f-bff7-bfdc1ea75cc2/ goes through the same authenticated attack as an admin. In open source community, vulnerability does not only include exploits that can be conducted by an external attacker, rather it includes anything that arises due to faulty coding and insecure implementation in the original release. Even you pointed out that https://nvd.nist.gov/vuln/detail/CVE-2023-1239 is not a vulnerability when in fact it is also a vulnerability.
OK, I compromised, you are absolutely right, it is a security vulnerability and has a CVSS score of Critical (9.3)! Good job!