Admin Tools

Saturday, 01 February 2025 16:39 CST

5uwebsite

Hi,

I tried to import articles from Google Sheet automatically via a Joomla component named RO CSVI, and it got a 403 forbidden error for a website. After contacting hosting provider and the component developer, they thought it should be blocked by the website itself.

Then I checked the WAF blocked request log and found these records, which are exactly the URLs that I got trouble with:

https://example.com/administrator/index.php?option=com_csvi&view=template&layout=edit&csvi_template_id=12

https://example.com/administrator/index.php?option=com_csvi&view=import

I therefore then tried to create WAF Exceptions per the instructions at:

https://www.akeeba.com/documentation/admin-tools-joomla/wafexceptions.htmIl

and setup a very board rule to allow everything of this component to run by leaving the view and parameters empty:

https://mrkr.io/s/679ea1952afeca85783b259e/0

I also tried to add view's value "template", and parameter "csvi_template_id=12" but no luck still.

I then observed 2 things:

1) The URL https://example.com/administrator/index.php?option=com_csvi&view=import is no longer in the blocked request log;

2) Other websites on the same hosting company (but on a different IP/server) without the WAF Exceptions could run the import well;

Not sure what was wrong in my setup, and what the correct setup should be if i just need to also

https://example.com/administrator/index.php?option=com_csvi&view=import

Thank you.

Monday, 03 February 2025 02:32 CST

nicholas

Admin Tools only applies very few features to the Joomla administrator application:

Away schedule
Allowed domains
Administrator secret URL parameter
Administrator exclusive IP allow list (formerly: admin IP whitelist)
Browser console warning
Cache cleaner [deprecated]
Cache expiration [deprecated]
Clean temporary directory [deprecated]
Periodically import settings [deprecated]
Global configuration monitoring
Critical files monitoring
Renaming the administrator folder [unsupported]
Delete inactive users
Disable obsolete admin users
Block creation of new admin users
Emails on failed / successful admin login, PHP exceptions, blocked requests
Enforcing the temporary IP auto-ban
Enforcing the IP permanent ban (IP Deny List)
Prevent deactivation of the System - Admin Tools plugin
Prevent password login when passkey login is enabled
Remove old blocked request entries
Session cleaner
Session optimiser
Monitor Super Users
Temporary Super Users
Treat failed logins as blocked requests
Warn about leaked passwords

As you can see, these are all custodian or global features. There are no features active in administrator which could block a specific component, view, or URL parameter.

For this reason, WAF Exceptions DO NOT apply to the administrator. In fact, the only features where WAF Exceptions apply to are:

Bad words filtering
SQLiShield
SessionShield
DFIShield
PHPShield
RFIShield
Suspicious core parameters

As you can see, none of these features are used in the administrator application.

If you see that administrator URL in the blocked request log you can also see a reason. What is it? Is it the administrator URL parameter because you try to access an administrator URL without being logged in?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 03 February 2025 13:16 CST

5uwebsite

Thanks a lot for your reply. It is always fast, detail and informative.

The reason is "Admin Query String". I have no idea what it means and how to whitelist it.

It seems that Admin Tools is not blocking other websites of the same hosting provider (but the other websites are probably on a different IP/server). This one is blocked.

I also got the same block even if I turned off all these:

https://mrkr.io/s/67a115ad78361739216d303a/0

Therefore, I am thinking whether the 403 Error was blocked by the server, rather than Admin Tools, since the timestamp for the block were still the 3 days ago ones...

Strange....

Thank you.

Monday, 03 February 2025 14:13 CST

5uwebsite

The App Developer also suggested that the .htaccess file may caused the problem. And regarding your second question:

Is it the administrator URL parameter because you try to access an administrator URL without being logged in?

Yes the RO CSVI extension could setup a cron job, and use a secret key to access the component without login to the administrator area to perform the auto-import.

The URLis: https://example.com/administrator/index.php?option=com_csvi&view=import

And the same problem is seen even if we login at the backend, and try to run it manually.

Thank you

Tuesday, 04 February 2025 06:22 CST

nicholas

The reason is "Admin Query String". I have no idea what it means and how to whitelist it.

Okay, that's what I thought.

You have enabled the Administrator Secret URL Parameter in Web Application Firewall, Configure WAF. This means that this parameter needs to be used whenever you access the administrator/index.php file without being already logged in. This, of course, includes the CRON jobs.

Change the CRON job URL to include the Administrator Secret URL Parameter. For example, let's say your Secret URL Parameter is specimen. Your CRON job URL goes from this:

https://example.com/administrator/index.php?option=com_csvi&view=import

To this:

https://example.com/administrator/index.php?option=com_csvi&view=import&specimen

Further to that, it's very likely that you have automatically blocked your site's IP address since that is what is used by the CRON job which is getting automatically and repeatedly blocked.

Go to Components, Admin Tools, Web Application Firewall and click on Unblock an IP. Enter your server's IP address. If you are not sure, ask your host. Click on Unblock This IP.

Then, again, go to Components, Admin Tools, Web Application Firewall and click on Unblock an IP. Enter 127.0.0.1. Click on Unblock This IP.

The App Developer also suggested that the .htaccess file may caused the problem.

This might also be the case.

You gave me a URL, and you tell me there is a CRON job. A URL is not an executable. You have to use an executable program to access it. Typically, it's either wget or curl. If it's the former go to Components, Admin Tools for Joomla, .htaccess Maker and find the “User agents to block” setting. There's WGet in there; click on the X button next to it to remove it. Then, click on Save & Create .htaccess.

I would like to stress that none of that would be an issue had the developer of this extension been using Joomla the way it's supposed to be used (which, admittedly, has never been put down in writing for stupid reasons; it's a long story), instead of him creating an ad-hoc automation method. Here are some pointers I would urge you to share with him:

The administrator/index.php entry point is to be used ONLY for user-interactive, authenticated backend access. It must never be used for unauthenticated access, including automation; that's a violation of the implied trust model of the Joomla Administrator Application.
At the most basic level, Joomla has included com_ajax the past 12 years to accommodate for components, plugins, modules, or even templates in need of unauthenticated, unattended access. So, even back in Joomla! 3 he had no excuse using an ad-hoc, security model violating automation method. I am not suggesting he should use that; there are newer, more appropriate automation methods in modern versions of Joomla.
Joomla! 4 and later includes the Joomla CLI Application (cli/joomla.php) which allows the developer to create console plugins to extend it. This is meant to be the primary way to offer automation through CRON jobs.
Joomla! 4.1 and later includes the Scheduled Tasks feature which allows the developer to create task plugins. These can be used to create automation tasks, either scheduled to run through Joomla itself, or be run through a CRON job (CLI or URL). This is meant to fill the automation gap for servers which do not allow the aforementioned Joomla! CLI Application to be used in CRON jobs.

The extension's author should have implemented the latter two. If he needs to remain compatible with Joomla! 3 he can use com_ajax; it's not the best choice for Joomla! 4.0 and later, but it still works and it's much more secure than what he's currently doing.

Everything I described I use and have –obviously, as per the links above– documented myself. I will be happy to help him out if he wants. My blog site, in the links above, has a contact form where he can contact me. I don't charge for helping out fellow developers. I view it as an investment into the welfare of the Joomla community which, ultimately, benefits all of us who work with or on Joomla.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 04 February 2025 20:16 CST

5uwebsite

Thanks a lot for your super detail reply. I am always impressed by your reply and just can't imagine how much time and effort you had dedicated to it. Really, I truly appreciate it!

Regarding the issue, I had not actually set a cron job for this website yet. It always got the 403 error when I login at the backend and try to run the import function manually.

I do have cron jobs setup for 2 other websites, and they could be run without any issues.Those websites could run the import at the backend, and were never blocked by Admin Tools.

I did checked the blocked IP list, and could not find any IP addresses being blocked. I also tried to provide both the server ip and the 127.0.0.1 ip for unblocking, both returned: "Unblocking the IP failed. The IP was not found to be automatically blocked."

As the "Admin Query String" blocks only happened about a week ago, and never shows up again for my attempts later, I am thinking that those are either from true attackers, or from the developer that tried to see what happened. I think the 403 problem is not related.

At the backend, when I ran import, i could see the preview data from Google Sheet, it just failed and displayed the web hosting's 403 page when it tried to import. Therefore I am thinking whether the hosting/server is blocking it.

Thanks again for all the help! I will provide the link of this post to the other developer and see whether this could lead to the final answer.

Thanks again!

Wednesday, 05 February 2025 00:41 CST

nicholas

OK, let's take stock of what you have discovered so far.

Disabling the System - Admin Tools plugin does not rectify the 403, therefore the problem is not caused by Admin Tools' Web Application Firewall.

Further to that, I had you check and change anything that could cause Admin Tools' Web Application Firewall to block that script, further ensuring the Web Application Firewall is not an issue.

The main .htaccess file is not a problem if you removed WGet from the list of blocked agents, so we can rule this out.

This leaves us with the possibility of an administrator/.htaccess or server issue.

Delete the administrator/.htaccess file and try again.

If it works: You were using the Administrator Password Protection feature to create an administrator/.htaccess file which protects your site's backend. Since this extension is using /administrator/index.php for automation (which, as I explained, is the wrong thing to do) any attempt to access without having already provided the username and password will result in an HTTP 401 Unauthorized response from the server. If the server is misconfigured, this might be converted to a 403 Forbidden response. You can work around it in the CRON job; for WGet you need to add --auth-no-challenge --user=my_user --password=my_password where my_user is the username you used with Administrator Password Protection, and my_password is the password you used.

If it doesn't work, or the file isn't there: it's a server (hosting) issue I cannot help with.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 05 February 2025 14:49 CST

5uwebsite

Thanks a lot Nicholas! I could not find a .htaccess file under the administrator/ directory, therefore I believe that this is a server issue. We will contact the server provider in this case.

Thank you.

Wednesday, 05 February 2025 16:35 CST

5uwebsite

And the hosting provider confirms that, it should be the import extension's issue:

Hello Bary,

Thank you for contacting our Help Desk.

I reviewed the context of your application and I can confirm that there is no blockage on our end.

I reviewed the logs and your video and found this:

206.12.6.187 example.com - [05/Feb/2025:20:47:26 +0000] "POST /administrator/index.php?option=com_csvi&view=imports HTTP/2.0" 303 0 "https://example.com/administrator/index.php?option=com_csvi&view=import" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" | TLSv1.3 | 0.040 0.040 0.041 - 0 NC:000100 UP:-DT
206.12.6.187 example.com - [05/Feb/2025:20:47:26 +0000] "GET /administrator/index.php?option=com_csvi&view=templates HTTP/2.0" 200 11670 "https://example.com/administrator/index.php?option=com_csvi&view=import" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" | TLSv1.3 | 0.107 0.109 0.109 BYPASS 0 NC:000100 UP:-
206.12.6.187 example.com - [05/Feb/2025:20:47:33 +0000] "GET /administrator/components/com_csvi/rantai/rantai.php?task=import&runId=20&_=1738788453293 HTTP/2.0" 403 11868 "https://example.com/administrator/index.php?option=com_csvi&view=import" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" | TLSv1.3 | 0.002 0.002 0.003 BYPASS 0 NC:000100 UP:-
206.12.6.187 example.com - [05/Feb/2025:21:17:18 +0000] "POST /administrator/index.php?option=com_csvi&view=imports HTTP/2.0" 303 0 "https://example.com/administrator/index.php?option=com_csvi&view=import" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" | TLSv1.3 | 0.166 0.166 0.165 - 0 NC:000100 UP:-DT
206.12.6.187 example.com - [05/Feb/2025:21:17:18 +0000] "GET /administrator/index.php?option=com_csvi&view=templates HTTP/2.0" 200 11670 "https://example.com/administrator/index.php?option=com_csvi&view=import" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" | TLSv1.3 | 0.184 0.186 0.186 BYPASS 0 NC:000100 UP:-
206.12.6.187 example.com - [05/Feb/2025:21:17:51 +0000] "GET /administrator/components/com_csvi/rantai/rantai.php?task=import&runId=21&_=1738790271645 HTTP/2.0" 403 11868 "https://example.com/administrator/index.php?option=com_csvi&view=import" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" | TLSv1.3 | 0.003 0.003 0.003 BYPASS 0 NC:000100 UP:-

As you can see at the end of those requests there is a GET request for a specific path:
206.12.6.187 example.com - [05/Feb/2025:20:47:26 +0000] "POST /administrator/index.php?option=com_csvi&view=imports HTTP/2.0" 303 0 "https://example.com/administrator/index.php?option=com_csvi&view=import" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" | TLSv1.3 | 0.040 0.040 0.041 - 0 NC:000100 UP:-DT

This file path leads to a non-existing file, so your 'GET' request is failing, because it is looking for a non-existent component.

Inside the folder com_csvi, there is no folder rantai and of course no file rantai.php inside a folder rantai, thus the get request results in 403.

In this situation, you should review with the developer and upload any missing files required for this action.

If anything else pops up in your mind, feel welcome to open a new support request.

Best Regards,

Thursday, 06 February 2025 01:24 CST

nicholas

If you are using the .htaccess Maker you will also need to add administrator/components/com_csvi/rantai/rantai.php in a new line of “Allow direct access to these files”, and then click on Save And Create .htaccess.

I have to once again point out that this is not a safe way to do it. Joomla has included the com_ajax component for the past 12 years to make it possible for developers to NOT use arbitrary .php files which bypass Joomla. Arbitrary web-accessible .php files bypassing Joomla are a major security risk. They are not protected by Joomla's built-in defenses, nor by any security extension such as Admin Tools. A vulnerability that could've been mitigated by Joomla's core defenses and / or Admin Tools would let an attacker exploit it. The extension really needs to be refactored to follow modern Joomla standards. Shipping code in 2025 riddled with bad security practices known to be extremely unsafe at best for the past 15 years is inexcusable.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Thursday, 06 February 2025 13:56 CST

5uwebsite

Yes adding the line you suggested did solve the problem!

https://mrkr.io/s/67a511c584bdef61cbdfe1a4/0

Not sure why the other 2 websites don't have this problem. They all use Admin Tools but maybe the .htaccess file was not regerated by Admin Tools.

The hosting provider did point to the right direction: .htaccess but failed to provide the solution. The directory and file was there, and we just need to add that to make things work.

There must be a reason for Akebba Backup and Admin Tools to be ranked so high and recommended by so many fellow Joomla developers in the community. We are so glad to have a great developer like you in the Joomla community. For a long time, we think that Joomla is more suitable for coporate websites, especially those that required more complicated strcuture and APIs. WordPress is very popular but it heavily relies on plugins. Joomla relies on extensions for many tasks too, but we are glad to have great developers like you and the one of RO CSVI. Open Source CMS is still the solution for many websites, and I just can't imagine how many people will leave the Joomla community with Akeeba.

Great job! Highly appreciate that!

Edited by 5uwebsite on 2025-02-06 14:02 CST

Friday, 07 February 2025 02:27 CST

nicholas

Thank you for your kind words! Helping people succeed fills me with joy. It's the whole reason I chose to become a Free and Open Source Software developer instead of selling my ~~soul~~ time to some corporate overlord :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 19 February 2025 17:01 CST

5uwebsite

Hmm.... While we have whitelisted the file and got through for what we need to do, today we are getting a new situation of 403, and we expected that is also related to the .htaccess file created by Admin Tools.

The developer needs to know whether the 403 was contributed by Admin Tools. Therefore he wanted me to temporarily disable Admin Tools and use the original Joomla .htaccess file.

I have therefore turned off protection for both frontend and backend:

https://mrkr.io/s/67b661ba69050cc040e651bb/0

and I could see both .htaccess files with the same modification time:

https://mrkr.io/s/67b661ba69050cc040e651bb/0

Is that the right way to temporarily disable Admin Tools for a testing?

Thank you.

Thursday, 20 February 2025 01:30 CST

nicholas

No, you need to remove the administrator/.htaccess file completely, and replace the contents of the .htaccess file in your site's root with the contents of the htaccess.txt which is shipped with Joomla.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Friday, 21 February 2025 16:11 CST

5uwebsite

Thanks a lot, for the always fast and great support!

Saturday, 22 February 2025 04:41 CST

nicholas

You're welcome!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support

#41550 Need help to setup a WAF exception

This is a public ticket

Environment Information

Saturday, 01 February 2025 16:39 CST

Monday, 03 February 2025 02:32 CST

Monday, 03 February 2025 13:16 CST

Monday, 03 February 2025 14:13 CST

Tuesday, 04 February 2025 06:22 CST

Tuesday, 04 February 2025 20:16 CST

Wednesday, 05 February 2025 00:41 CST

Wednesday, 05 February 2025 14:49 CST

Wednesday, 05 February 2025 16:35 CST

Thursday, 06 February 2025 01:24 CST

Thursday, 06 February 2025 13:56 CST

Friday, 07 February 2025 02:27 CST

Wednesday, 19 February 2025 17:01 CST

Thursday, 20 February 2025 01:30 CST

Friday, 21 February 2025 16:11 CST

Saturday, 22 February 2025 04:41 CST

Please wait

Support Information