Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
CSRF token not present in delete posting request in admin panel | Manage posting #468
Application is vulnerable for CSRF as CSRF token is not sent when a delete posting request is triggered.
There are two scenarios which I have observed in this request.
GET /ASLI_mylittleforum/index.php?mode=posting&delete_posting=2&back=index&delete_posting_confirm=true HTTP/1.1
POST /mylittleforum/index.php HTTP/1.1
In both the cases application is vulnerable to CSRF, where attacker can trigger delete request when a victim clicks on a vulnerable link.
In cforum (the software, which is used for the SelfHTML forum) the CSRF-token of the page is placed in the head-section of the HTML-document.
Additionally every form gets an own, different token and because every button (i.e. mark thread as read, close the thread tree, hide from the main view) has it's own form, there are many forms on the main page.
It would not be a problem to add the token to the head-section, to read it from there with JS and to send it together with the payload in a POST-request (i.e. with Ajax) but I don't like the idea to do the same in a GET-request.
Which functions are actually affected? Is ist 1. in combination with 3. or is it 2.?
I wrote an email as well as submitted a request to CVE-mitre when this defect was fixed. And I have heard that CVE-mitre will not be able to assign CVE id to every request due to large number of request they receive for different applications. It is easy for them to assign CVE id if vendor requests it. Do you by any chance know how other CVE Id's were assigned for this application? :-)
No, I don't. Every when and then someone finds a security issue. Some people report it to a CVE repo, some report it to us (here, per e-mail or in the forum), some report to both sides. So the CVE numbers in itself are not very relevant for us. They exists or they don't. So what‽