The Invision Community framework is set up with security best practices in mind but there are a few things you should make use of in order to not inadvertently bypass these protections.
Validating User Input
Where your application or plugins request user data the built in Form handling methods should be used. By default form input is protected against vulnerabilities but you should still ensure the correct form types are used for example using email address, number and radio fields etc. where appropriate. This not only provides the best user experience but also means the input is validated using appropriate methods.
When using environment, request and cookie variables you should also be sure to use the \IPS\Request methods that are adjusted to account for environment differences. This data is *not* validated and should be treated as untrusted and validated and sanitised as appropriate.
Escaping Output
Invision Community template syntax automatically escapes variables on output but this can be bypassed with the raw modifier as explained in the template syntax guide. The raw modifier should only ever be used with trusted and sanitised content otherwise a risk of introducing a vulnerability exists.
The database class contains distinct methods for selecting, updating, inserting and deleting data and contains security features to prevent database injection vulnerabilities. The raw query() method should be avoided wherever possible and if used, only ever with sanitised and pre-formatted queries.
Protecting Against Cross Site Request Forgeries
Any methods that alter data/state, or which process any data, should be protected against cross site request forgeries to make sure requests are initiated by the user that intended it.
When using the built in form handling methods this will occur automatically when called in conjunction with the $form->values() method.
Outside of forms you can protect links generated with the built in URL classes by using the built in csrf() method. For example the following;
\IPS\Http\Url::internal( "app=myapp&module=mymodule&controller=mycontroller&do=myaction" )->csrf()
...will add the csrf key to your link.
The controller that acts on the request should then be protected by adding the following before the action is performed. For example;
public function myaction() { \IPS\Session::i()->csrfCheck(); // Your code here }
Both of these steps must be in place for an effective CSRF defense.
When deleting something, you should also implement the deletion
public function delete() { \IPS\Request::i()->confirmedDelete(); //your deletion logic }
In addition, within the admin control panel you should add the following class property to confirm suitable CSRF checks are in place;
/** * @brief Has been CSRF-protected */ public static $csrfProtected = TRUE;
This page is not an exhaustive list of security considerations and serves only as a guide to the most common pitfalls new developers face. Industry best practices should be followed at all times when developing applications and plugins for the Invision Community platform.
Report Document