Stored XSS

[newb3ast]

Hi,

I reported a stored xss last August 18 and it was marked as informative. Can you help me understand why it was marked as informative.

I add reply in huntr.dv and supporting references regarding this matter.

https://huntr.dev/bounties/9afabff1-2a5b-4205-bd20-5202d517b0d6/

[fuzegit]

Hi Because inserting in the field you specified is consciously allowed everything. Okay, we'll run this field through the typographer. But you should realize for the future that admin panel is the place where many things are allowed. And if an attacker has already gained access there, he doesn't need any XSS, even to update the session.

In OctoberCMS in the admin panel php files are editable, so it must be one huge XSS?

On huntr.dev I gave you an answer, let's continue there.

[newb3ast]

And if an attacker has already gained access there, he doesn't need any XSS, even to update the session.

My answer here: In the event of Admin found out his account was hacked, he will change his password. A very skilled hacker will not just leave any backdoor and Stored XSS here is one way that will served as backdoor to obtain an updated session admin

**just want to remind also that the payload I made can also affect normal users

Here is a reference which is why admin panel xss is still valid findings: https://blog.wpscan.com/why-admin-xss-is-a-valid-security-issue/

[fuzegit]

I read your reply to huntr. And replied there as well. The link for WP does not apply to us. We will process the text from the field you specified. There is no way to change the status of your report (huntr does not provide this option).

[newb3ast]

@fuzegit There is a way sir I already talked to an admin attached is our convo from discord (huntr.dev)

[newb3ast]

@fuzegit

Huntr’s admin already reset the report hoping to get a CVE here. If I'm not mistaken there’s a xss sanitation here but I was just a bit lucky to by pass it. I find it really challenging crafting xss payload but I was able to help you guys finding this issue. Looking forward for your re-assessment. Thank you!

[fuzegit]

@newb3ast You're too clingy. I saw the message on huntr. Be patient. And just in case I clarify for the future: such "XSS" that are not actually XSS will not be accepted anymore.

[newb3ast]

@fuzegit I was reading some report and there's one report that captured my attention

https://huntr.dev/bounties/069bb1f3-0805-480d-a6e1-b3345cdc60f3/

he reported it at session fixation upon checking that is not vulnerable to session fixation I already tried it before this should be tagged as session hijacking.

The session fixation attack is not a class of Session Hijacking, which steals the established session between the client and the Web Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim’s browser, so the attack starts before the user logs in.

Reference: https://owasp.org/www-community/attacks/Session_fixation

I'm not here to argue. I just want to share what I learned on the webapp testing that I'm currently taking right now and also I'm checking if my 2 reports are published for CVE (hehehe) thanks!

[fuzegit]

There are a lot of Hunters, not enough of us. As soon as we make a fix (and post CVE), you'll know about it. Just a little patience.

[newb3ast]

Hi Sir, just checking out if your program is still up for bug hunting. Thanks!

[newb3ast]

Hi @fuzegit,

Can I request a CVE for these reports:

https://huntr.com/bounties/94a3639a-b409-4816-9b0b-f6dd575e0ba0/ https://huntr.com/bounties/9afabff1-2a5b-4205-bd20-5202d517b0d6/

Thanks,

[fuzegit]

Once this is done, the report will be closed. What you have described is nothing critical.