KARAM SIDHU

Hi @reynierc , Thank you for your prompt reply in providing assistance over the raised matter.

I’ve checked my logs in overall as well as the status of the plugin specifically, and, it was as per how it should be with everything related to my site > this plugin > stripe configured accordingly as per how it should. Stripe service connectivity is in allow-list on my set security ecosystem as well as over manually configured security configuration such as at my Security Headers [connect-src etc] However, to ensure effective and seamless connectivity, i’ve optimised my database tables, purged cache entirely over all sectors, re-installed the plugin and re-configured it.

No new changes captured at my end, however, i no longer receiving those emails requesting for required changes which somehow mean either it was due to the email notification was the final sent as mentioned in the email, or, it was specifically due to the minor cached data which was entirely cleared via an overall cache clearance.

@threadi i think you misunderstood the options that i figured out which i am seeking for a recommendation as above.

Referring to my Option 2, Instead of seeking to strengthen htaccess which by default had been done, i am looking forward to implement additional layer to restrict direct access to the sensetive paths from the First Line/Layer of Defense where it could be such as Cloudflare WAF etc to block access to those sensetive paths before the request even reaches the origin.

I’ve did throughout checks to attempt direct access to sensetive paths and it returns as restricted [403 – Forbidden] which means it is not accessible as how it should be, and, the article that you shared had been referred a few days back as well and my current ruleset in htaccess seem to comply with what is there in the article. But then, the option 2 is basically a double layer to complement the existing htaccess based restrictions so that in any circumstance if the default origin based ruleset as set in htaccess goes wrong [rare occurrence – overwritten, corrupted etc], the access to those sensetive paths remains restricted especially if the incident involving the htaccess is unrealised.

In conclusion, maintaining the htaccess with all required lines + imposing additional restrictions [Rulesets that are more aggresive and different in pattern] before the htaccess so that if any one out of the both layers managed to be bypassed in direct access attempts, the other layer is there to avoid the revealance -consequently the damage. The primary focus and intention of this is to better protect sensetive paths rather than solely relying on htaccess itself.

If placing all files under public accessible area is the only way to go which means my option 1 is less suitable to be conducted, then I am looking into to conduct this as per my option 2. I’m looking forward for suggestion if option 1 or 2 would be a better option to go for.

Which basically means, by default wordpress doesn’t store sensetive files outside of the web root. Instead, it stores everything at public accessible directory but restrict access to sensetive – core files via htaccess, Kindly confirm if, this is the default practices? *So that i can confirm if this is how wordpress ecosystem works or it is due to my origin host environment.

My current setup works as such, but somehow i am looking into strengthening the directory aspect which consists of accessibility, permissions and also reachability. As accessibility and permissions are restricted as per how it should, here it comes the reachability [As quiestioned] aspect:

I was looking at the default practice which restricts via htaccessand i found there is a risk of relying on htaccess solely as in any event [rare occurrence] if the htaccess gets overwritten or corrupted, it might impose a risk or a damage. Therefore, instead of relying on the htaccess solely, i thought of conducting any each out of both below:

Option 1 : Isolation of Sensetive Files and Folders – moving out sensetive and core files and folders from the Public Accessible Directory.

Option 2 : Default with Double Layer – Maintain Existing Restriction Ruleset in htaccess + Block access to those sensetive paths in the first line of defense WAF Infrastructure. In any event of anything goes wrong with the htaccess it would still not be accessible publicly due to there is already a blockage [403] before the request can even reach the origin [Nature of First Line Defense].

Well, i am not an expert here but trying to improve the security posture specifically for this directory aspect as i could see a loophole [I Guess?] as described above.

Opinions and Suggestions are Welcomed and Highly Appreciated.

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.

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.

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.

Hi, Apologies for the delay in response.

For now, I think this is not an issue at the woo level, but at the server level itself.

I’ll update with the requested information further if found that the issue is closely related to woo itself.

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.

Yes, you’re right. It only occurs with WP 24.

The issue does not occur at the woocommerce level, I’ve checked on this previously and just checked it again now, The total quantity of a product that could be checked out [purchased] is the exact same as per the number set at the quantity. If a customer attempt to add the product to the cart more than the limit that is set, It doesn’t allow that actions to be conducted. Whereas, upon recieving the number of orders as per the quantity set, the product automatically gets out of stock which is as per how it should as well.

But then, when a user is redirected from your plugin domain lookup page, that doesn’t seem to be the case as even with the out of stock status, the product could still be added to the cart and checked out as well.

It is less-likely a bug in the plugin but most probably it is due to lack of [code] function to listen to whatever is set at the woo level.

I also utilise a licensing plugin which delivers license keys to the customers upon certain events which consists of type of product, delivery difference by variation, number of quantity, delivery on specific status etc. As of now, No similar issue encountered, which confirms that my site configuration does not seem to have any issues by default.

I had also checked my logs if there is any block or overide factors/elements that might causes this issue, so far nothing found to be assumed as a site level issue.

It’s the same product setting.

Except, for the product data in which i am on variable option rather than simple due to i have variations for the specific product, therefore, the stock quantity is managed through the variation AND i’ve checked [ticked] the Virtual box as it is a virtual product.

I had tried by enabling the stock management option as well together with at the variation level but yet the same.

Kindly check with the setting above.

• This reply was modified 1 year ago by KARAM SIDHU.

Page Optimization > JS Settings > Load JS > Changed the Option from Delayed to Deferred.

Error eliminated – The issue had Resolved.

Thank you for the Assistance, Appreciate it.

Kindly refer the WooCommerce > Status via: https://pastebin.com/cNhM0KvB

Do let me know if your end requires further informations.

Uncaught (in promise) DOMException: Failed to execute 'setAttribute' on 'Element': '="async"' is not a valid attribute name.
    at https://kstech.tech/blog/:137:10592
    at Array.forEach (<anonymous>)
    at litespeed_load_one (https://kstech.tech/blog/:137:10567)
    at https://kstech.tech/blog/:137:10227
    at new Promise (<anonymous>)
    at litespeed_load_delayed_js (https://kstech.tech/blog/:137:10212)
(anonymous) @ blog/:137
litespeed_load_one @ blog/:137
(anonymous) @ blog/:137
litespeed_load_delayed_js @ blog/:137

Standard View:

Near View:

Both, The Error that appears specifically and Image of where it appears are provided as above. Kindly zoom to view the images or visit: https://kstech.tech/blog

Done, Refer above.

I’ve tried by enabling Track stock quantity for this product and tested with the quantity as 1. However, still the same in which i was able to place an order that is redirected from the domain lookup page where the product with the selected domain name was automatically added to cart and then by manually adding the product to the cart which sums up the quantity as 2 even when my stock availability is only set as 1 and i was able to place an order sucessfully which shouldn’t be due to the stock availability is only 1.

To check the matter further if it is originating from my woocommerce itself, i re-set the stock to 1 and attempted to manually add to cart the product twice [equivalent to 2] which is more than the quantity i’ve set which is 1 and it was not possible which is how it should be within when redirected from the plugin domain lookup page.

Kindly assist further