The text botter in a field causes PHP to crash

The code does an integrity check and extracts modules that have been tampered with from a zip file.

I’ve disabled this functionality. Please check it.

also please remove your changes (displays) when you are finished as the client does not want to see them :slight_smile:

Thank you.

I did some testing and I’m convinced. There is no other way I can think of that could explain this behavior except for a server filter. Simply replacing the echo $output with an echo strlen(output) results in content, so it’s definitely not your code that’s getting lost somewhere.

I’ve asked iFastNet for clarification on this.


excellent thanks Admin for all your help.
Hopefully we can get some answers soon.

I had gone so far as to even look that it might not be a reserved word for MariaDB and MySQL in general,
but it’s not… even if it was reserved it shouldn’t behave that way

In most cases, if there is something in the blacklist on the server, then it returns 403
so maybe it’s not that either


hide your /includes/ folder because it reveals a lot

make some dummy index.html/php file there so that the server serves something

or with .htaccess file

this is better to have on root

#Disable Directory Listings in this Directory and Subdirectories
Options -Indexes

or full block (but .htaccess file only in inc. folder)

Require all denied


That’s what threw me off too. We have reserved keywords but then the server clearly says 403 Forbidden, which makes it clear that it’s blocked.

That said, those errors are generated by bad data in the request. This issue seems to be caused entirely by the response of the page. Sending botter to the server works fine, it’s just that a page that contains this word in the response appears to get discarded. It may be that these checks are too late in the process to switch the response to a Forbidden error.


Thanks, I’ve created one. Please check it out.

I’ve re-enabled the tamper functionality- which has also reversed all changes.
What is the next step?

I contacted iFastNet about this. They stated that, yes, this is indeed a security restriction placed on the servers. This was done to help stop DDoS Booters mostly, which bad actors were hosting with us and causing trouble for us and for others. I agree that this is a crude measure, but sometimes drastic measures are necessary to stop abuse.

Unfortunately, that means I have bad news for you. These restrictions were installed on purpose, and we cannot and will not disable these restrictions for everyone or for your account specifically. So we cannot “fix” this issue as our systems are working as intended.

This means that you’ll either need to accept that these using these keywords in the form will result in this error, or find a way to work around it. For example, perhaps change your website logic so the form input is not included in the output. So instead of saying “email X is not a valid email Address”, you can say “the submitted email address is not a valid email address”.

This has the added benefit of preventing Cross Site Scripting vulnerabilities on the page. Because right now your site is wide open to these kinds of hacks: if I enter <script>alert('This is a security problem!');</script> in the email field, this Javascript code is executed on the resulting page and a popup is shown with that text.


It’s okay - I see that you also created a 403 for the mail* (I avoid naming) folder,
but it is only for that dir and not for a subdir like mail*/examples/
You can delete that examples directory, there is no need to have it on the server.

Before the admin found out the reason and published it here, yesterday I went to see what happens exactly step by step after the POST
so I sent this abbreviated version (marked with an arrow)

and nothing happens in between, the server simply returns headers, without content = 0byte

end of story


At least we know that its a supplier block. I’ll pass it on.

Thanks for that, I’ve made the change. It reduces the vulnerability of my site but not the issue, as we where using the logon screen for you to test. But the real issue was reported entering that name for a client. We will have to deal with it :slight_smile:
Thanks again for all your help.

Thanks Oxy. Its now Deleted.
Thanks for all your help.


Maybe you can turn the problem into an advantage ( it’s not a bug it’s a feature :joy: )

According to the code you published, I assume that this does some validation (at least by name)

Screenshot 2023-02-23 103228

I’m talking strictly about the email input field but it should probably be done for the username as well

So you can intercept the input there and disallow special characters except @ (alphanumeric + @ = allow - also convert everything to lowercase),
but apart from that, you also make an additional check to see if the input contains “bad words”
and you can store the list of bad words somewhere,

and present it to the customer (user) as another advantage of your program
"filtering of bad words" when creating acc and when checking
"filtering of reserved words" like admin, owner, moderator, system, etc.

So on the input, you go through the array of “bad words list”
and then if there is a match → your script does not return a full email as a result (current problem)
but write something else

With that, you keep the main function of printing the result as before (emailXY is listed in the result), and in the case of a bad word you skip that action and make it not list the email but some descriptive error/exception like “that word/email is blacklisted”.


Yes. On the logon, I check the email/username is nonsense or has ‘bad’ characters. Unfortunately as the admin pointed out, when I re-displayed the error email, that caused an issue that has since been fixed.

The real issue was once the user had logon on and tried to use ‘botter’ as part of their clients name. It added it to the db then failed trying to re-display it. Even examining the log where botter was in the middle of a bunch of other text, caused the failure- as we have seen.

I have thought about allowing ‘botter’ to be stored in the DB, but during display changing it to ‘bot ter’. But my client is now resigned to the fact that they are using ‘b0tter’ (a zero). So I’m going to let ‘sleeping dog lie’.
If they come across another client that has ‘botter’ in their name, then I may have to do something.

Thanks again for all your help and attention :slight_smile:


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.