Post by jrr » Tue Apr 20, 2021 9:24 am

I just spotted this in my errors - never seen anything like it before and there are now fourteen pages of it!
PHP Fatal Error: Uncaught Exception: Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'uNiOn/**/AlL /**//**/sElEcT 0x393631353738343330312e39,0x393631353738343330322e3' at line 1<br />Error No: 1064<br />UPDATE `oc_online_plus` SET last_click='2021-04-19 20:44:01', exit_page='/catalog_oc/index.php?route=product+category999999.9%27+%2f**%2f%2f**%2fuNiOn%2f**%2fAlL+%2f**%2f%2f**%2fsElEcT+0x393631353738343330312e39%2c0x393631353738343330322e39%2c0x393631353738343330332e39%2c0x393631353738343330342e39%2c0x393631353738343330352e39%2c0x393631353738343330362e39%2c0x393631353738343330372e39%2c0x393631353738343330382e39%2c0x393631353738343330392e39%2c0x39363135373834333031302e39%2c0x39363135373834333031312e39%2c0x39363135373834333031322e39%2c0x39363135373834333031332e39%2c0x39363135373834333031342e39%2c0x39363135373834333031352e39%2c0x39363135373834333031362e39%2c0x39363135373834333031372e39%2c0x39363135373834333031382e39%2c0x393631353738343330 in /usr/.../catalog_oc/system/library/db/mysqli.php on line 40

Occurrences 2 First appeared on: 2021-04-19 20:44:01 Last appeared on: 2021-04-19 20:44:01
Any ideas what happened?
The store appears to be running...I will be tracking down what IP this appears to have come from in my logs but perhaps someone else has seen it before. No luck tracing IP so far...
Thanks!
Last edited by jrr on Fri Apr 30, 2021 2:25 am, edited 2 times in total.

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by Cue4cheap » Tue Apr 20, 2021 10:48 am

SQL injection attack.

Mike

cue4cheap not cheap quality


Expert Member

Posts

Joined
Fri Sep 20, 2013 4:45 am

Post by DBI » Tue Apr 20, 2021 12:20 pm

As you probably know, the presence of those lines in your error log means that someone is successfully getting your scripts to run arbitrary SQL. Tracking down the IP will do you no good, as long as the vulnerability is there, anyone can exploit it. And the attackers are no doubt cycling IP addresses.

If you find out what the attack vector is, please post! If it's in the core code it potentially impacts everyone running the same OC version.

DBI
New member

Posts

Joined
Tue Oct 14, 2014 10:58 am

Post by jrr » Tue Apr 20, 2021 1:20 pm

DBI wrote:
Tue Apr 20, 2021 12:20 pm
As you probably know, the presence of those lines in your error log means that someone is successfully getting your scripts to run arbitrary SQL. Tracking down the IP will do you no good, as long as the vulnerability is there, anyone can exploit it. And the attackers are no doubt cycling IP addresses.

If you find out what the attack vector is, please post! If it's in the core code it potentially impacts everyone running the same OC version.
I turned off the most recent extension I had added and the SQL injection attacks appear to have stopped. I will talk with the developer of that extension (purposefully not naming yet!) and see if they agree that might be the problem source. If sorted out I will then report, if not then I shall continue to monitor and report.

Of course it might be that the person instituting these attacks follows the OC forums and spotted my report and is lying low for now.

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by DBI » Tue Apr 20, 2021 1:33 pm

An extension causing it is the most likely explanation so it sounds like you found the problem. Glad to hear it.

I'd recommend finding a third party to review the code before you install that extension again, even after it's "fixed".

Also, assume that your database has been compromised. Your logs were only showing you the failed queries, some queries might have run without errors, giving the attacker (potentially) full access.

DBI
New member

Posts

Joined
Tue Oct 14, 2014 10:58 am

Post by jrr » Tue Apr 20, 2021 3:33 pm

I don't think it was the extension, talking with the developer he pointed out:
Not related, it's most likely a "Script kiddie" sending out requests to try and get access to the website. Could be specifically someone trying to hack. They don't tend to last long and stop shortly after they start.

They type this in to the address bar:

/catalog_oc/index.php?route=product+category+or+1%27%3d%271%27+%2f**%2f%2f**%2fuNiOn%2f**%2fAlL+%2f**%2f%2f**%2fsElEcT+0x393631353738343330312e39%2c0x393631353738343330322e39%2c0x393...(on and on)...

In the hope that they can get something.
So, it is just punks trying to brute force their way into a loophole in the site.
Probably needs some .htaccess work to beat, but I'm tired now and heading off to sleep...
However I did find this site (and others) that offer suggestions on beating them at their own game https://www.ma-no.org/en/security/htacc ... s-and-xss# Note I revised this link to an earlier dated one that might be the original source. The other link was simply a copy.
Last edited by jrr on Wed Apr 21, 2021 3:45 am, edited 1 time in total.

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by DBI » Tue Apr 20, 2021 4:15 pm

The part that's missing from that story is that the error was coming from MySQL, they were successfully getting OC to run queries they originated. Even if they all failed it's a huge security risk. It shouldn't be possible to execute ANY MySQL via a URL.

That example URL you posted should result in a page not found error. If it doesn't something is wrong, if you can't isolate it to an extension or some other change you've made, I'd recommend installing a fresh copy of OC (keeping your database and templates of course).

DBI
New member

Posts

Joined
Tue Oct 14, 2014 10:58 am

Post by paulfeakins » Tue Apr 20, 2021 6:00 pm

jrr wrote:
Tue Apr 20, 2021 3:33 pm
Probably needs some .htaccess work to beat, but I'm tired now and heading off to sleep...
No, your code needs to sanitize its database inputs.

You should get a developer to check this.

UK OpenCart Hosting | OpenCart Audits | OpenCart Support - please email info@antropy.co.uk


User avatar
Guru Member
Online

Posts

Joined
Mon Aug 22, 2011 11:01 pm
Location - London Gatwick, United Kingdom

Post by jrr » Wed Apr 21, 2021 1:11 am

paulfeakins wrote:
Tue Apr 20, 2021 6:00 pm
jrr wrote:
Tue Apr 20, 2021 3:33 pm
Probably needs some .htaccess work to beat, but I'm tired now and heading off to sleep...
No, your code needs to sanitize its database inputs.

You should get a developer to check this.
In the meantime is there any reason not to use .htaccess to try to block these attacks?
I have added the suggested .htaccess code to block the script attempts and am now getting a 403 error when I try to run my own attacks.

Code: Select all

# Block access to the .htaccess file
<files .htaccess>
order allow,deny
deny from all
</files>

# No web server version and indexes
ServerSignature Off
Options -Indexes
Options FollowSymLinks

<IfModule mod_rewrite.c>
# Enable rewrite engine
RewriteEngine On

# Block suspicious request methods
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]

# Block WP timthumb hack
RewriteCond %{REQUEST_URI} (timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC]
RewriteRule . - [S=1]

# Block suspicious user agents and requests
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]
RewriteCond %{THE_REQUEST} (%0A|%0D) [NC,OR]

# Block MySQL injections, RFI, base64, etc.
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http%3A%2F%2F [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]
RewriteCond %{QUERY_STRING} (\.\./|\.\.) [OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>).* [NC,OR]
RewriteCond %{QUERY_STRING} (NULL|OUTFILE|LOAD_FILE) [OR]
RewriteCond %{QUERY_STRING} (\./|\../|\.../)+(motd|etc|bin) [NC,OR]
RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]

# PHP-CGI Vulnerability
RewriteCond %{QUERY_STRING} ^(%2d|\-)[^=]+$ [NC,OR]

#proc/self/environ? no way!
RewriteCond %{QUERY_STRING} proc\/self\/environ [NC,OR]

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]

</IfModule>
This is an improvement!
When I have time I'll ask one of my OC developer friends to look over my setup and see what the problem most likely is...hopefully they won't charge me too much beer money!

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by jrr » Wed Apr 21, 2021 3:35 am

I had to comment out one line near the bottom of that .htaccess file as it turned out they blocked the display of the error results in my error management extension:

Code: Select all

RewriteRule ^(.*)$ - [F,L]
With the above in place no errors were displayed, deleting it brought them back. I don't understand code enough to know why, but at least it was easy to find!
Last edited by jrr on Fri Apr 23, 2021 1:27 am, edited 1 time in total.

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by Cue4cheap » Wed Apr 21, 2021 5:21 am

jrr wrote:
Wed Apr 21, 2021 3:35 am
I had to delete the lines near the bottom of that .htaccess file as it turned out they blocked the display of the error results:

Code: Select all

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]
With the above in place no errors were displayed, deleting it brought them back. I don't understand code enough to know why, but at least it was easy to find!
Um... Displaying errors may not be what you want. Why not log them only?
Plus I feel you may want to have someone investigate if your database was compromised.
Mike

cue4cheap not cheap quality


Expert Member

Posts

Joined
Fri Sep 20, 2013 4:45 am

Post by ADD Creative » Wed Apr 21, 2021 6:11 am

jrr wrote:
Tue Apr 20, 2021 3:33 pm
I don't think it was the extension, talking with the developer he pointed out:
Not related, it's most likely a "Script kiddie" sending out requests to try and get access to the website. Could be specifically someone trying to hack. They don't tend to last long and stop shortly after they start.

They type this in to the address bar:

/catalog_oc/index.php?route=product+category+or+1%27%3d%271%27+%2f**%2f%2f**%2fuNiOn%2f**%2fAlL+%2f**%2f%2f**%2fsElEcT+0x393631353738343330312e39%2c0x393631353738343330322e39%2c0x393...(on and on)...

In the hope that they can get something.
So, it is just punks trying to brute force their way into a loophole in the site.
Probably needs some .htaccess work to beat, but I'm tired now and heading off to sleep...
However I did find this site (and others) that offer suggestions on beating them at their own game https://www.ma-no.org/en/security/htacc ... s-and-xss# Note I revised this link to an earlier dated one that might be the original source. The other link was simply a copy.
If you are getting "PHP Fatal Error: Uncaught Exception: Error: You have an error in your SQL syntax" errors like the one you posted, then you do most likely have a SQL vulnerability. It's clear that data is being passed to that query without being properly escaped. It could just be someone testing, but it's possible that a attacker will make setval attempts before working out the correct input. You need to get that query fixed.

jrr wrote:
Wed Apr 21, 2021 3:35 am
I had to delete the lines near the bottom of that .htaccess file as it turned out they blocked the display of the error results:

Code: Select all

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]
With the above in place no errors were displayed, deleting it brought them back. I don't understand code enough to know why, but at least it was easy to find!
You absolutely do not want to display any errors at all. An attacker can use the errors to gradually work out how to correctly inject. There are also SQL injection techniques that need display errors on in order to pull out information from the database. You need to make sure display errors in off in three places in total, your PHP settings, your config and your settings.

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by jrr » Wed Apr 21, 2021 8:38 am

ADD Creative wrote:
Wed Apr 21, 2021 6:11 am

If you are getting "PHP Fatal Error: Uncaught Exception: Error: You have an error in your SQL syntax" errors like the one you posted, then you do most likely have a SQL vulnerability. It's clear that data is being passed to that query without being properly escaped. It could just be someone testing, but it's possible that a attacker will make setval attempts before working out the correct input. You need to get that query fixed.

jrr wrote:
Wed Apr 21, 2021 3:35 am
I had to delete the lines near the bottom of that .htaccess file as it turned out they blocked the display of the error results:

Code: Select all

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]
With the above in place no errors were displayed, deleting it brought them back. I don't understand code enough to know why, but at least it was easy to find!
You absolutely do not want to display any errors at all. An attacker can use the errors to gradually work out how to correctly inject. There are also SQL injection techniques that need display errors on in order to pull out information from the database. You need to make sure display errors in off in three places in total, your PHP settings, your config and your settings.
Right you are, I had indeed forgotten to turn off error reporting in my php.ini file - that stopped the error displays which - as you say - gives way too much info to miscreants!

Now I am back to (if I enable the last ReWriteRule line in .htaccess) no error messages in System>Maintenance>Errors, and the world sees my home-made 403 Forbidden page (ugly), or I disable that line, now I can see (as admin only) the System>Maintenance>Error messages, and the world sees a white page. Obviously I need to figure out what exactly that line is doing in .htaccess that stops me from seeing the errors. Gah. It's not like I don't have other stuff to do...

Thanks for the advice, it is helping me understand how OC is put together!
(edited to reflect only the ReWriteRule line is affecting the error management display)
Last edited by jrr on Fri Apr 23, 2021 1:29 am, edited 2 times in total.

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by ADD Creative » Wed Apr 21, 2021 5:12 pm

jrr wrote:
Wed Apr 21, 2021 8:38 am
Right you are, I had indeed forgotten to turn off error reporting in my php.ini file - that stopped the error displays which - as you say - gives way too much info to miscreants!

Now I am back to (if I enable the above two ReWrite... lines in .htaccess) no error messages in System>Maintenance>Errors, and the world sees my home-made 403 Forbidden page (ugly), or I disable the two lines, now I can see (as admin only) the System>Maintenance>Error messages, and the world sees a white page. Obviously I need to figure out what exactly those two lines are doing in .htaccess that stops me from seeing the errors. Gah. It's not like I don't have other stuff to do...

Thanks for the advice, it is helping me understand how OC is put together!
I think you will be wasting your time trying to block in htaccess. As you can see from the error message, there are many ways they can try to encode the SQL they want to inject. There is no guarantee that your rules will block everything. You will also likely cause yourself more issues with false positives.

It clear from the error you posted that the is a issue with how they are setting exit_page in the query. It's also clearly part of an extension and not the Opencart core. You need to get the extension fixed or fully uninstall it.

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by paulfeakins » Wed Apr 21, 2021 6:48 pm

ADD Creative wrote:
Wed Apr 21, 2021 5:12 pm
I think you will be wasting your time trying to block in htaccess. As you can see from the error message, there are many ways they can try to encode the SQL they want to inject. There is no guarantee that your rules will block everything. You will also likely cause yourself more issues with false positives.
It might reduce server load slightly but it's possible you'll break stuff.

Are orders still coming through ok for example?

UK OpenCart Hosting | OpenCart Audits | OpenCart Support - please email info@antropy.co.uk


User avatar
Guru Member
Online

Posts

Joined
Mon Aug 22, 2011 11:01 pm
Location - London Gatwick, United Kingdom

Post by jrr » Thu Apr 22, 2021 6:03 am

paulfeakins wrote:
Wed Apr 21, 2021 6:48 pm
ADD Creative wrote:
Wed Apr 21, 2021 5:12 pm
I think you will be wasting your time trying to block in htaccess. As you can see from the error message, there are many ways they can try to encode the SQL they want to inject. There is no guarantee that your rules will block everything. You will also likely cause yourself more issues with false positives.
It might reduce server load slightly but it's possible you'll break stuff.

Are orders still coming through ok for example?
Orders are still coming through. No calls from irate customers! Most of my customers seem rather patient with us...

I have not seen any signs of the script kiddies since enacting the .htaccess additions.

The system is still logging errors even if I can't see them on Error Manager from Isenselabs - I've sent them a note now their web site is up again. If I turn off the one line Isenselab's Error Manager will then display any new errors since the last time I enabled the "RewriteRule ^(.*)$ - [F,L] " .htaccess line. I do have a friendly developer looking into this so perhaps it will be sorted out soon. I will report the results!

More on this - I did find the actual line of the added .hataccess code that was stopping the error manager from displaying anything relating to errors (the top part of the error manager displayed normally, just the errors are hidden) - and it is this line of code:

Code: Select all

RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]
Now to see what that particular line does - so much stuff buried in it. I wish the creator of this had commented a bit more...

Found a site that goes into .htaccess protection from sql attacks and it explains better.
https://www.pccybersecurity.com/index.p ... e-htaccess
I can understand this level of coding...

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by by mona » Fri Apr 23, 2021 4:00 pm

I had to delete the lines near the bottom of that .htaccess file as it turned out they blocked the display of the error results:
RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]
With the above in place no errors were displayed, deleting it brought them back. I don't understand code enough to know why, but at least it was easy to find!
Those two lines are part of the entire block of conditions starting from:
# Block suspicious user agents and requests

by deleting the last line:
RewriteRule ^(.*)$ - [F,L]

The entire block is futile as there is no action taken on any of the conditions in that entire block.

In other words, your problem could be caused by any of those conditions as they are in a massive [OR] string and goes away by just removing the RewriteRule (the last line).

Having said that, it is not very smart to copy and paste htaccess definitions snippets from the internet unless you fully understand what they do.
It is even less smart to blindly alter them to see what happens.

There rarely are htaccess definitions of the "one fits all" category so make sure you fully understand how these definitions work so you can be sure they only do good and no harm for your particular website implementation or have a professional do it for you.

DISCLAIMER:
You should not modify core files .. if you would like to donate a cup of coffee I will write it in a modification for you.


https://www.youtube.com/watch?v=zXIxDoCRc84


User avatar
Expert Member

Posts

Joined
Mon Jun 10, 2019 9:31 am

Post by jrr » Sat Apr 24, 2021 5:36 am

.htaccess is fun. Really. Well, almost fun, but it can do a lot if you are on shared hosting (like me) and can't get directly at your php.ini or apache.ini files to set parameters to protect the site.
Anyway, the problem I was having with the line of code in .htaccess turned out that it was interferring with the admin/extension I was using for error management. However reading this page on .htaccess:
https://www.whoishostingthis.com/resources/htaccess/
pointed out that the rules in .htaccess apply to sub-directories UNLESS you have another .htacess in that sub-directory which then overrules the higher level one. So I simply took the default .htaccess, made a few minor changes, and dropped it in my (renamed) admin directory - that turned of the RewriteCond functions and now I have normal functionality of all my admin extensions, and menus.

I suggest that folks gain a better understanding of .htaccess and test each line as you add it, and be aware that any changes affect the current directory level and all sub-directories of that directory and plan accordingly.

Fun, eh?

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm

Post by jrr » Fri Apr 30, 2021 2:24 am

If anyone has read down to here I did find the .htaccess suggestions above had a problem - they blocked crontab from running timed events!

It turned out to be this line of code:

Code: Select all

# Block suspicious user agents and requests
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
and specifically the word "curl" which is the .htaccess command for some timed functions. Removing "curl|" cleared up that issue.

How did I find it? Thanks for asking!

My web host (pair.com, great support!) tech person suggested that I use "-L" as part of the curl command as that would tell me where the redirects were going, so that coupled with "-v" and "mailto:(my email)" and setting the time to every minute "*/1 * * * *" gave me an update every minute of what crontab was up to so I could see the results quickly.

My command line looked like this:

Code: Select all

*/1 * * * * curl -v -L "https://...(rest of command url)"
And I got an email every minute and could poke away at .htaccess or whatever other suspect, wait two minutes just to be sure, and read the email results.

Hope this helps someone else track down problems in .htaccess!

jrr
Active Member

Posts

Joined
Mon Nov 20, 2017 1:48 pm
Who is online

Users browsing this forum: No registered users and 94 guests