Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSRF token not present in delete posting request in admin panel | Manage posting #468

Closed
sagar2117 opened this issue May 6, 2019 · 18 comments

Comments

Projects
None yet
3 participants
@sagar2117
Copy link

commented May 6, 2019

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.

  1. Delete request is a simple GET request :-

GET /ASLI_mylittleforum/index.php?mode=posting&delete_posting=2&back=index&delete_posting_confirm=true HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/ASLI_mylittleforum/index.php?mode=index
DNT: 1
Connection: close
Cookie: mlf2_last_visit=1557082267.1557090644; mlf2_usersettings=0.1.0.1.0; PHPSESSID=llq9hot05hudh5j0i255pk2k52
Upgrade-Insecure-Requests: 1

  1. Delete request is a post request but without CSRF token.

POST /mylittleforum/index.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/mylittleforum/index.php?mode=posting&delete_posting=5&back=entry
Content-Type: application/x-www-form-urlencoded
Content-Length: 87
Connection: close
Cookie: mlf2_usersettings=0.1.1.1.0; mlf2_last_visit=1557079919.1557091419; PHPSESSID=gur1it6pciu091fs0s3bi3d36a
Upgrade-Insecure-Requests: 1

mode=posting&delete_posting=5&back=entry&category=-1&delete_posting_confirm=OK+-+Delete

In both the cases application is vulnerable to CSRF, where attacker can trigger delete request when a victim clicks on a vulnerable link.

@loesler loesler added the bug label May 6, 2019

@loesler loesler self-assigned this May 6, 2019

@loesler loesler added this to the 2.5 milestone May 6, 2019

@auge8472

This comment has been minimized.

Copy link
Collaborator

commented May 6, 2019

@loesler Did you find the problems? I started to inspect the code only a few minutes ago and was not successful until now. :-)

@loesler

This comment has been minimized.

Copy link
Collaborator

commented May 6, 2019

@auge8472, I think so. The delete function is somewhat special because the mod/admin can delete the posting via an Ajax GET-call and via POST-call. Both result in an $action = 'delete_posting', where the CSRF is not evaluated - see my source code comment. ;-)

@auge8472

This comment has been minimized.

Copy link
Collaborator

commented May 6, 2019

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.

<meta name="csrf-param" content="authenticity_token" />
<meta name="csrf-token" content="..." />

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.?

mlf2-delete-posting-issue

@loesler

This comment has been minimized.

Copy link
Collaborator

commented May 6, 2019

If JavaScript is enabled, the second used a GET-request. Moreover, the JS itself used a GET request, too.

@loesler

This comment has been minimized.

Copy link
Collaborator

commented May 6, 2019

FYI: The delete option of an individual posting is also affected.

@auge8472

This comment has been minimized.

Copy link
Collaborator

commented May 6, 2019

For the case of 1.+3. the solution would be a CSRF-token in the confirmation page. For option 2. I have no idea at the moment.

@loesler

This comment has been minimized.

Copy link
Collaborator

commented May 6, 2019

What do you think about adding the CSRF-Token as additional uri parameter?

@loesler loesler referenced this issue May 6, 2019

Merged

CSRF token #469

@loesler

This comment has been minimized.

Copy link
Collaborator

commented May 6, 2019

@auge8472 I added a pull request on this topic. I will merge the pr, if you have no objections.

@auge8472

This comment has been minimized.

Copy link
Collaborator

commented May 7, 2019

fixed with #469

@sagar2117

This comment has been minimized.

Copy link
Author

commented May 14, 2019

Do you provide CVE id ? :)

@auge8472

This comment has been minimized.

Copy link
Collaborator

commented May 14, 2019

Do you provide CVE id ? :)

You as the issuer told us none. So no, we can't with certainty. After using the search on cve-mitre.org I assume it is CVE-2019-15569

@sagar2117

This comment has been minimized.

Copy link
Author

commented May 14, 2019

I wrote an email to cve-mitre.org asking them to provide one. And CVE-2018-15569 is different as CSRF token was missing on different parameter.

@auge8472

This comment has been minimized.

Copy link
Collaborator

commented May 14, 2019

The problem is, that the linked document with the details is not reacheable (references block). So I was not able to compare the report on cve-mitre.org with yours.

@sagar2117

This comment has been minimized.

Copy link
Author

commented May 14, 2019

yes it is block, But, in description it is written that "my little forum 2.4.12 allows CSRF for deletion of users." . So, it seems like a different issue. :-)

@auge8472

This comment has been minimized.

Copy link
Collaborator

commented May 14, 2019

Ahem, yes. Overread it. :-/

@sagar2117

This comment has been minimized.

Copy link
Author

commented May 14, 2019

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? :-)

@auge8472

This comment has been minimized.

Copy link
Collaborator

commented May 14, 2019

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‽

@sagar2117

This comment has been minimized.

Copy link
Author

commented May 14, 2019

They might not be relevant to you. But, it is important for me. Anyways, I will send a follow up email to CVE-mitre asking them for update.
Thanks :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.