• Resolved conducivedata

    (@conducivedata)


    I found two issues with the handling of the [passster]…[/passster] shortcode when only a password is set (no “full” or “area” in use) and Ajax is enabled. The problems are with the regex used to find the shortcode within the post content in PS_Helper::get_shortcode_content():

    '/\\[passster+.*.".*' . $password . '.*".*?[\\]]/'

    1. The .* flanking the $password variable allow any substring of the shortcode’s password–or even no password at all!–to pass. For example, if you used the shortcode:

    [passster password="TestPassword"]Password-protected content.[/passster]

    password inputs like “Test”, “Pass”, “word”, “or”, “s”, or even an empty input would pass.

    2. This regex also consumes third-party shortcodes within the Passster shortcode, even if they’ve been added to the list of allowed third-party shortcodes in the Passster options. For example, the shortcode:

    [passster password="TestPassword"]Password-protected content. [gravityform id="1" title="false" description="false" ajax="true"] Even more password-protected content![/passster]

    outputs the following:

     Even more password-protected content!

    And due to the ‘ajax=”true”‘ bit at the end of the Gravity Forms shortcode, the regex intended for CAPTCHA accepts random strings as valid passwords, not just an empty string or a subset of the defined password.

    I have not been able to find how CAPTCHA is supposed to be used in the shortcode, so I don’t know how to fix that regex. Here are my fix for the password regex and my total guess on how to fix the CAPTCHA regex:

    preg_match( '/\[passster.*password="' . $password . '".*?\]/', $content, $matches );
    preg_match( '/\[passster.*captcha="true".*?\]/', $content, $captcha_matches );
    

    Removing the unnecessary “.*”s and prepending the password with “password=” fixes the issues with accepting password substrings and empty passwords as well as the issue of consuming shortcodes within the content. Applying a similar treatment to the CAPTCHA line–again, taking a guess here–fixes the issue specific to this Gravity Forms usage.

    Please evaluate, alter as necessary, and incorporate these fixes into your next release.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Hey @conducivedata,

    thanks for the detailed explanation!

    While this shortcode has been deprecated since 2019 and was replaced entirely by Protected Areas (which has a different shortcode and can’t be tricked this way), I agree that a little patch should follow soon.

    Just for explanation:

    The deprecated shortcode wasn’t updated to work with ajax. With protected areas, I also completely removed the regex patterns. They are not fail-safe and maintainable for the variety of use cases required.

    Thanks again,

    Patrick

    Hey @conducivedata,

    it’s now patched and included in version 4.1.1 of Passster.

    I also removed the old captcha regex (there isn’t a feature like this anymore) to keep the code cleaner.

    Thanks for your help, and have a nice weekend!

    Patrick

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Critical security issue when using Shortcode method with Ajax’ is closed to new replies.