XSS: Cross Site Scripting in POST body

  • Resolved born2excite

    (@born2excite)


    5 years, 7 months ago

    Hello. The code below is meant to remove metadata that the WPBakery Page Builder plugin adds to my site HTML. WordFence “Blocked for XSS: Cross Site Scripting in POST body”

    The code is intended to be placed into the functions.php file but I put the code into my Code Snippets plugin so the code survives after changing the theme.

    Can you please advise if you think the WordFence block was a false positive?

    The code is:

    
add_action('wp_head', 'myoverride', 1);
function myoverride() {
  if ( class_exists( 'Vc_Manager' ) ) {
    remove_action('wp_head', array(visual_composer(), 'addMetaData'));
  }
}

    Thank You

Viewing 4 replies - 1 through 4 (of 4 total)

  • Hi @born2excite,

    This is indeed a false positive, however the code isn’t to blame.

    Can you try this:

    1. Go to Wordfence -> Tools -> Live Traffic
    2. Find the row where you were blocked for XSS
    3. Expand to row to see which query parameter exactly was the issue

    From here, we can whitelist that specific query string. Let me know what you see (or take a screenshot of that Live Traffic Row) and I’ll guide you through on how to whitelist it.

    Dave

    Thread Starter born2excite

    (@born2excite)

    Hi Dave,

    Thanks for the quick reply.

    Please see the link below for a screenshot of the row documenting the block for XSS.

    screenshot

    Clicking the link will open a new tab with options to view or download. Just click on view, please.

    I approved and whitelisted the code snippet when WordFence first blocked it for XSS. The Live Traffic row documenting the block for XSS doesn’t seem to show that I whitelisted it but I can confirm that the code snippet is doing what it is supposed to do.

    What do you think?

    Thanks for your help
    Julian

    • This reply was modified 5 years, 7 months ago by born2excite.

    Hi again,

    Wordfence classified the connection as a bot because it was automated, but that does not mean Wordfence will consider it malicious. It’s just letting you know that the connection was not made through a standard browser.

    The live traffic does not document any whitelisting made, but you can find it at Wordfence -> All Options -> Whitelisted URLs.

    I’m guessing that you should see something similar to this example: https://i.imgur.com/Smhhiu0.png

    The URL is /wp-admin/admin.php and the Param is request.body[snippet_description].

    If you indeed see this, then it’s confirmed that it’s whitelisted properly and your script should work fine.

    Dave

    Thread Starter born2excite

    (@born2excite)

    Hi Dave,

    Yes, you’re 100% correct. I found the Param “Whitelisted by via false positive dialogue” as you described.

    Thanks for your excellent support.

    If I may indulge while I have your expert attention.
    On the issue of “Security via Obscurity” regarding the path to the WordPress admin login page. My belief based on the research I’ve done is that Security via Obscurity is not recommended any more because the technique is not effective since bots will still be able to find the new login page. I don’t want to waste your time so a simple answer will be perfect.

    Do you agree that hiding/changing the WP admin login page is NOT a good security practice to harden WordPress?

    All the Best,
    Julian

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘XSS: Cross Site Scripting in POST body’ is closed to new replies.