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.

Sign up for GitHub

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

Jump to bottom

Critical : Remove Blog Post using CSRF attack #477

Closed
rudSarkar opened this issue Jun 30, 2017 · 3 comments
Closed

Critical : Remove Blog Post using CSRF attack #477

rudSarkar opened this issue Jun 30, 2017 · 3 comments
Labels
bug
Milestone
4.2.0

Comments

@rudSarkar
Copy link

Hi subrion security team,

Bug Description

Cross-site request forgery(CSRF), also known as a one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.

Steps to reproduce

<html>
  <body>
    <form action="http://localhost/subrion/blog/delete/<post id>/">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>
  1. Save this as whatever.html
  2. Replace to post number which post you want to delete.
  3. now open whatever.html via browser where you logged in with Subrion CMS
  4. Click on Submit request button.
  5. the post will delete automatically.

Impact

An attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

How to fix this vulnerability

Check if this form requires CSRF protection and implement CSRF countermeasures if necessary.

Regards,
Rudra Sarkar
rudrasarkar815@gmail.com
@Haxor-Injector
Copy link

yes very critical ;)

ghost pushed a commit that referenced this issue Jul 3, 2017
@jangaraev
#477
8c08d7b
@ghost
Copy link

ghost commented Jul 6, 2017

Hello @rudSarkar!

Thanks for this report.

Because of inadequate permissions settings in this plugin, this vulnerability could only be exploited in case if currently logged in user is a member of administrators usergroup. Regarding the vulnerability itself, here really was no owner check. Both these issues have been fixed.

The fix has been included into automatic upgrade patch which has been released two days ago. It includes several security fixes as well. It uses the script's built-in critical upgrades feature and automatically applied to all the script installations.

Thanks for your report and efforts again!

@ghost ghost closed this as completed Jul 6, 2017
@vbezruchkin vbezruchkin added the bug label Jul 6, 2017
@vbezruchkin vbezruchkin modified the milestone: 4.1.6 Jul 6, 2017
@rudSarkar
Copy link
Author

Hi @Batry,

Thank you for the fix.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
4.2.0
Development

No branches or pull requests
3 participants
@vbezruchkin @rudSarkar @Haxor-Injector