• Resolved KARAM SIDHU

    (@iamkaramsidhu)


    I just realised, the reCAPTCHA configuration page with the option of none is fetching the user’s sensetive credential [password] in the site key and site secret column even upon clearing [erasing] it from the column and followed by saving changes and clearing cache. This occured upon selecting the version 3 option and then re-selecting the none option.

    [Suggestion]: Do you mind to extend the reCAPTCHA option to support Cloudflare’s turnstile as well?

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author WP24

    (@wp24dotorg)

    I’ll fix the reCAPTCHA options with the next update of the plugin, so that the keys get deleted when setting the type to “none”.

    Will take a look at Cloudflare Turnstile and think of adding support for it in one of the next updates.

    Thread Starter KARAM SIDHU

    (@iamkaramsidhu)

    I’ll wait for an update over the vulnerability reported.

    On regards for the support for turnstile, I think it would be a solid choice due to its ability to automatically manage which makes the lookup function more user friendly rather than the usual user required to solve + in terms of security, its has proven its effectiveness against bots. Basically, Single Option that does enhance User Experience and adds some values towards Security as well.

    Thread Starter KARAM SIDHU

    (@iamkaramsidhu)

    Hi and Good Day

    I realised that your end had pushed an update recently, however, the vulnerability as mentioned above Did Not Resolve which leads me to disable and delete the plugin for the second time here [The first was when the vulnerability was found]. One more thing that i’ve realised recently is that your plugin is now being labelled as less-secure by my Application Layer Security [Security Plugin] after this recent update which means there could either be multiple vulnerabilities together [in the Code] with the one reported previously here or maybe a false positive [somehow, I don’t think so] and even if i tend to override [Security Bypass] at the App Layer, Somehow the functionality would be blocked at my Server Layer which i definitely do not practice bypassing in all circumstances.

    Therefore, with all due respect, Kindly make sure your plugin meets the highest security standard within all means as there is two scenarios here whereby the first one is where i personally captured a vulnerability in one glance and now the Application layer marked it as such as well. I requested to add function support for turnstile to Enhance the Security at the Search Form/Lookup Bar [to Avoid/Drastically Reduce the Abuse Usage] which is for a betterment, but then, what i see here is turnstile function isn’t added and the latest update seem to be less favourable when it comes to security aspect when compared to the previous.

    Highest level of Cooperation is Much Appreciated.

    Plugin Author WP24

    (@wp24dotorg)

    The vulnerable you reported was fixed with the last update. If you set the recaptcha type to “none” the site and secret key were removed.

    I don’t now which leads to label the plugin less secure as before. Do you use a security plugin for determine that? Or could you give more detailled information?

    The cloudflare turnstile will be added, but I could not guarantee to do that in the near future.

    Thread Starter KARAM SIDHU

    (@iamkaramsidhu)

    Based on my Checkings, It was still there in the current update as per how it was in the previous. The captcha key option is not being utilised and its option is set as none as per how it should be. However, it still fetches the Logged In User’s Password as in my case it fetches My [Administrator] Password which i found it to be not safe [Even when i have additional authentication layers upon passing the Password Authentication] as on my opinion somehow it should not fetch/display the Logged In User’s Password and that causes an obvious “?!” here.

    The probability here is within your plugin’s codebase, I highly encourage to examine and verify its codebase. To be precise [which might assist you], From my outer layer of perspective [Previous – First Impression] ,it was more likely due to a bug in the Plugin Codebase that causes an Improper data handling and fetching, and, yes, upon enhancing the site security at the Application layer, i am pretty sure that it is definitely due to that as mentioned but then with the presence of additional security layers, it blocks the attempt which makes it an Unauthorised Data Fetching from the Database. When i had a close look on the triggered event, Yes, that is the reason and probably it comes with other aspects as well such as No Input Validation and Sanitisation. This is why i highly encourage to examine and verify the entire Plugin Codebase.

    Plugin Author WP24

    (@wp24dotorg)

    If the recaptcha type is set to “none” the site and secret key get removed. You need to save the recaptcha setting once.
    it does not use any user credentials, maybe this is cause by a password manager.

    The plugin already validates and sanitize all inputs, but I’ll take a closer look on the codebase regarding security.

    Thread Starter KARAM SIDHU

    (@iamkaramsidhu)

    maybe this is cause by a password manager = A Password Manager shouldn’t be a part of the diagnosis for this issue. Why is that because, A Password Manager wouldn’t fetch the information and credentials it stores for each into another, as password managers identifies the fields before automatically inserting via few criteria such as Url, Tags, Attributes, Field Id’s and others. In this case, those belongs to the Login Page and your Plugin’s Captcha Key page isn’t the same, On top of that since when Password Manager’s automatically insert without a user clicking on the field as when the field is deactivated or set to something which symbolises non-applicable [in your case, Set to “none”] and + without even a one time prompt? Irrelevant. When it comes to Preference, Let me tell you that, Password Manager is the last thing i would ever utilise due to the risk it could impose where single unauthorised access would lead to a total unauthorised access risk. Password Manager is a very far type of thing, I don’t even utilise a Centralised Site Manager or any facility where multiple sites could be managed over one single access except for a Host. This should eliminate the “Maybe” impression.

    The plugin already validates and sanitize all inputs = The Input Validation and Sanitisation aspect is a Sub-Aspect of the Primary Aspect which is Data Handling and Fetching. As mentioned, From my Outer Layer of Perspective, it has something to do with the Primary Aspect but then due to the Broadness, You could probably begin your diagnosis with the Validation and Sanitisation aspect first – as actually in fact, in my previous pentest that i’ve conducted on site, a part of the pentest which was SQLi attempt [Union Based – Hex Encoded] failed on your lookup form however the Application Layer Sec somehow blocked it and when i overide, the Server Layer does it as well. But then, Can you imagine in real attack scenarios for those users which if both layers doesn’t present or maybe present with a poor configuration on top of this inappropriate data fetch and it was a second-order SQLi? Total Chaos. But then, due to the nature [type] of your plugin, Somehow i know that it would be primarily utilised by Developers such as Web Developers and this aspect is usually handled carefully by default such as ensuring proper security layers etc, therefore decided to hint it out just here.

Viewing 7 replies - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.