[OSP] Chat Sanitisation

Users who are viewing this thread

Gishank

Master Knight
This was created in response to the recent revelation that there is a fairly critical vulnerability that exists in the core warband game engine. This vulnerability can be exploited by a malicious player to crash a server through feeding invalid data to custom chat input methods. Vornne released his own work-around for this issue, and this follows the same general principle, by sanitising the message. This system can also be utilised to censor content from your server, if so desired. Currently the system is rather basic; you are free to modify it as you so desire.

How it works
When a client sends a message through a custom chat channel to the server, the message is forwarded to an external (local/remote) set of PHP scripts. The PHP scripts parse the input and remove any prohibited characters, words, or phrases. The output is then read and displayed by the game-server.

Installation (COMPILED)

By default, the compiled files point to the Alera Gaming Persistent World sanitisation backend ("pwsan.aleragaming.com"). This is hosted in North-Eastern France. Unless you predict latency to be a big issue, you are more than welcome to use our backend to filter your server's chat messages.

Should you wish to use the compiled files, but point to a locally hosted webserver, follow this brief guide.

1) Copy and paste the files contained within the compiled RAR to your server's "Modules/PW_4.5" folder.
2) When prompted to overwrite, click YES.
3) Upload the PHP files contained within the backend RAR to your web-server. Make sure they are in a location that is web-accessible.
4) Open the "Modules/PW_4.5/strings.txt" file and scroll to the bottom. Replace "http://pwsan.aleragaming.com" with the folder location where you placed the PHP files, for example: http://myserver.com/joebloggs_stuff/pwsanitisation.
5) ?? Profit



Version History/Changelog
31/05/2016 - Version 2.0.
Backend Changes;
Added a basic logging system. Uses either a local file on the HDD, or MySQL DB.
Added a basic custom filter array.
-- Both of the above can be configured in detail through the new config.php.
Removed "UNRECOGNIZED" and "TOKEN" from filter, as these will block legitimate users using the phrases.

Module System Changes;
Fixed "invalid response" message in logs, due to a incorrectly configured variable.

29/05/2016 - Version 1.0, RELEASE.

Downloads

The download section contains three files. All of these files are protected by the password "alera".

COMPILED - These are vanilla Persistent World 4.5 files with the fix applied.
SOURCE - This is the module system with the fix applied. Further information on how to dissect this information will be supplied in the near future. It is provided "AS IS" for the time being.
BACKEND - These are the PHP files which perform the sanitisation process on the backend.


Iron Europe
Version 2 - Vanilla, COMPILED
Version 2 - Vanilla, SOURCE
Version 2 - Vanilla, BACKEND

Mega
Version 2 - Vanilla, COMPILED
Version 2 - Vanilla, SOURCE
Version 2 - Vanilla, BACKEND

Credits
DanyEle - This is his work primarily, I am merely publishing it with his consent.
 
So, on all faction/local/admin chats it will post the whole chat line into the PHP backend, remove the illegal characters and response with the clear string?
Could lag.
 
Has this been actually tested to fix the crash? The problem happens when the M&B engine tries to compose the string based on formatting tokens, which are used to create the URL string to send to the web server, so probably the server would still crash before the chat message could be sanitised. Not certain, since I don't have time to test, but that is my guess. Also, how does it work with sending space characters to and from the web server?
 
I can confirm that it has been tested prior to publishing the files; however, as it has only been tested internally, it is perfectly possible that there may be something that has been overlooked. I've set up a server called "Alera_Gaming_Sanitise_Test" for any interested party to test the system further, without needing to install it themselves.

Regarding "sending space characters": the information sent to the PHP backend by the warband server is encoded, the output is plaintext. Hopefully DanyEle will pop by this thread in the near future to provide some further clarity on the details though!



@Illuminati;
Could it? Certainly! Without proper stress testing by a large-pop server, it's impossible to know. I don't think it'd be any more taxing than already-existing PW scriptset additions.
 
Vornne said:
Has this been actually tested to fix the crash? The problem happens when the M&B engine tries to compose the string based on formatting tokens, which are used to create the URL string to send to the web server, so probably the server would still crash before the chat message could be sanitised. Not certain, since I don't have time to test, but that is my guess. Also, how does it work with sending space characters to and from the web server?

Gishank already answered the first point, so about space characters: messages are encoded upon sending them to the server (str_encode_url) to prevent data from being along along the way and these get automatically decoded in PHP. When sending data back, this gets automatically encoded from PHP and decoded in Warband receive_url_response method.

domipoppe said:
So, on all faction/local/admin chats it will post the whole chat line into the PHP backend, remove the illegal characters and response with the clear string?
Could lag.

The whole system is actually very similar to the one underlying chat commands and the amount of data sent with them, since all messages need to be sent to PHP and a response is received in case a certain condition is met. Do chat commands make servers lag? I doubt it's the case, as we could see from servers implementing them, but for this specific implementation, actually more data is sent from the server back to the client, so I guess we'll need to have someone brave enough to test this  :lol:
 
Updated the files in the OP with a few minor changes;

31/05/2016 - Version 2.0.
Backend Changes;
Added a basic logging system. Uses either a local file on the HDD, or MySQL DB.
Added a basic custom filter array.
-- Both of the above can be configured in detail through the new config.php.
Removed "UNRECOGNIZED" and "TOKEN" from filter, as these will block legitimate users using the phrases.

Module System Changes;
Fixed "invalid response" message in logs, due to a incorrectly configured variable.
 
I think there is a way to get around this. OP if you want PM me on the forum and I'll tell you a way to crash even when sending messages to a web server. We can try to fix it.
 
False alarm boys. If you were to implement this on your own, make sure that you're using a dynamic string ("@") and not a static one from module_strings. That's the crucial part for this to work.
Thanks to DanyEle for help.
 
You can only remove the code manually from the source code. However, the source code is not available, so you cannot remove it. This is for your own good through: people may type the "nuke codes" and crash your server without this OSP.
 
gedizz said:
instead of wasting your time on this, use WSE to sanitize without external filtration.

Depending on the level of access that a person has, they may not have the ability to implement WSE. Plus, WSE can cause other issues.
 
Back
Top Bottom