Tag Archives: security

New in 2.19: Extension Flood Filter

With the release of SmartFoxServer 2.19.0 we have introduced a new Extension Flood Filter that provides fine grained control over the packet rate of Extension requests: it can be used to limit the number of calls per second for specific requests and automatically set rules for warning and banning the offending client(s).

It also includes the ability to catch unknown Extension calls (i.e. requests for which there doesn’t exist a request handler) and apply auto-ban rules as well.

Under normal circumstances, e.g. users playing with the official client app, there shouldn’t be a concern about request spam: limitations can be easily coded in the client itself. However it’s also relatively easy for malicious users to reverse engineer a client made in Javascript, Unity or Java and bypass such limitations.


In the diagram below we show a bird’s eye view of the filter and its position in the Extension invocation chain. For each request handler defined in our Extension code (via the addRequestHandler methods) we can set a limit expressed in number of calls per second.

Extension Flood Filter

In this example we have defined a playerShoot request handler and we’ve also set a limit of 4 requests/sec. If a client sends 20 calls in one second only the first 4 will be passed to the Extension and processed, while the rest will be discarded. Additionally, based on the auto-ban rules, the sender will either be warned or banned.


The Extension Flood Filter is inactive by default. To activate it we need to call the initFloodFilter(…) method available from the parent SFSExtension class.

public class AntiFloodTestExtension extends SFSExtension
    static final String PLAYER_SHOOT = "pShoot";
    static final String PLAYER_MOVE = "pMove";
    public void init()
        ExtensionFloodFilterConfig cfg = new ExtensionFloodFilterConfig();
        cfg.banDurationMinutes = 120;
        cfg.maxFloodingAttempts = 3;
        cfg.secondsBeforeBan = 2;
        cfg.banMessage = "You are now banned. Reason: request flooding.";
        cfg.filterRules = Map.of
                            PLAYER_SHOOT, 4, 
                            PLAYER_MOVE, 15
        addRequestHandler(PLAYER_SHOOT, (sender, param) -> {
        addRequestHandler(PLAYER_MOVE, (sender, param) -> {

The initializer method takes a ExtensionFloodFilterConfig object with with a number of properties for warning and banning clients.

For more details on each setting, default values and further details please check our documentation website here.

Feb 2021 vulnerability reports

At the start of 2021 three vulnerability reports were published describing alleged SmartFoxServer 2.17.0 (the latest version as of March 2021) exploits. We exchanged several emails with the individual who created the reports prior to their publishing, pointing out evident flaws in the findings but they were still published without correcting those glaring mistakes.

The reports

The following are the reports in question:

They all refer to a so called “God Mode Console”, an additional Admin Tool module which is always inactive by default in any SmartFoxServer installation. The module can be activated by an Admin via multiple manual steps and it can be used to debug a live server at runtime, typically when a bug or issue cannot be reproduced locally but it manifests in a live environment.

NOTE: the console cannot be activated or remotely accessed. It requires the server admin to manually activate it and use it.

Given this premise it goes without saying that the first “vulnerability” report is a just an example of bad security reporting. The whole point of the console is to execute arbitrary commands and an attacker that has local access and credentials to enable the console is already in control of the target server. Even after explaining these points to the “researcher” prior to publication, he went ahead and posted the alleged exploit.

The 2nd entry in the list claims that the Admin password is stored in clear text, which is correct, and flags it as medium threat. We agree with the claim and we can also provide further details: there aren’t many better ways to secure such password and a clear text file can be efficiently secured by way of user permission management.

For more info on securing clear-text passwords, please take a look at this discussion on StackOverflow.

The 3rd and last entry reports an XSS (cross site scripting) exploit without actually showing any evidence of the “cross site” part. As already clarified this is an admin-only console that is not accessible to the outside world and disabled by default, but the author willfully ignored it and reported it as a vulnerability.

If there’s any other questions regarding these issues you can get in touch with us via the support section found on our website.