From reviewing lots of vulnerability reports one of our big takeaways is that the proper testing of suspected vulnerabilities often isn’t being done by security researchers. Without doing that you miss an easy to chance to catch things happening that nullify potential vulnerabilities in part or sometimes in full.
One recent example we noticed repeating an issue from a previous false report of a vulnerability, involves a correctly identified cross-site scripting (CSRF) vulnerability in a plugin that the discoverer then extrapolated could be lead to persistent cross-site scripting (XSS) due to what the CSRF vulnerable function does:
Looking at the relevant code you can certainly see why they might believe this since you can see in the plugin’s code that no sanitization is done on the POST variable “content” before modifying a post:
//edit post $slide_type = htmlspecialchars($_POST['slide_type']); $title = htmlspecialchars($_POST['title']); $content = $_POST['content']; // Create post object $my_post = array( 'post_title' => $title, 'post_content' => $content, 'ID'=>$id ); // Insert the post into the database wp_update_post( $my_post );
Testing this out though would have shown that the sanitization is being done at some point and therefore the cross-site scripting can not occur.
The harder method to find this out would be to follow the path the data takes from the plugin into WordPress. If you do that you can see that the function wp_update_post() ends by calling the function wp_insert_post(), which in turns
passes data through sanitize_post(), which itself handles all necessary sanitization and validation (kses, etc.).
So that is what prevents the persistent cross-site scripting (XSS) from occurring, but with proper testing you wouldn’t need to know that to have avoid this type of mistake.