diff options
| author | Sebastien Blot | 2017-09-20 10:11:01 +0200 |
|---|---|---|
| committer | Sebastien Blot | 2017-09-20 10:11:01 +0200 |
| commit | 868f96c759b6650d88ff9f4fbc5c048302134248 (patch) | |
| tree | c0de0af318bf77a8959164ef11aeeeb2b7bab294 /doc/source/features.rst | |
Initial import
Diffstat (limited to 'doc/source/features.rst')
| -rw-r--r-- | doc/source/features.rst | 352 |
1 files changed, 352 insertions, 0 deletions
diff --git a/doc/source/features.rst b/doc/source/features.rst new file mode 100644 index 0000000..89cd756 --- /dev/null +++ b/doc/source/features.rst | |||
| @@ -0,0 +1,352 @@ | |||
| 1 | Features | ||
| 2 | ======== | ||
| 3 | |||
| 4 | Snuffleupagus has a lot of features that can be divided in two main categories: bug-classes | ||
| 5 | killers and virtual-patching. The first category provides primitives to kill various | ||
| 6 | bug families (like arbitrary code execution via ``unserialize`` for example) or rise the | ||
| 7 | cost of exploitation, the second one is a highly configurable system to patch functions in php itself. | ||
| 8 | |||
| 9 | Bug classes killed | ||
| 10 | ------------------ | ||
| 11 | |||
| 12 | ``system`` injections | ||
| 13 | ^^^^^^^^^^^^^^^^^^^^^ | ||
| 14 | |||
| 15 | The ``system`` function execute an external program and displays the output. | ||
| 16 | It's used to interract with various external tools, like file-format converters for example. | ||
| 17 | Unfortunately, passing user-controlled parameters to it often leads to an arbitrary command execution. | ||
| 18 | |||
| 19 | When allowing user-supplied data to be passed to this function, | ||
| 20 | use `escapeshellarg()` or `escapeshellcmd()` to ensure that users cannot trick | ||
| 21 | the system into executing arbitrary commands. | ||
| 22 | |||
| 23 | --- `The PHP documentation about system <https://secure.php.net/manual/en/function.system.php>`_ | ||
| 24 | |||
| 25 | We're kind of killing it by filtering the ``$``, ``|``, ``;``, ````` and ``&`` chars in our | ||
| 26 | default configuration, making it a lot harder for an attacker to inject arbitrary commands. | ||
| 27 | |||
| 28 | This family of vulnerabilities lead to various CVE, like: | ||
| 29 | |||
| 30 | - `CVE-2017-7981 <https://tuleap.net/plugins/tracker/?aid=10159>`_: Authenticated remote code execution on Tuleap | ||
| 31 | - `CVE-2014-4688 <https://www.pfsense.org/security/advisories/pfSense-SA-14_10.webgui.asc>`_: Authenticated remote code execution on pfSense | ||
| 32 | - `CVE-2014-1610 <https://www.rapid7.com/db/modules/exploit/multi/http/mediawiki_thumb>`_: Unauthenticated remote code execution on DokuWiki | ||
| 33 | - `CVE-2013-3630 <https://www.rapid7.com/db/modules/exploit/multi/http/moodle_cmd_exec>`_: Authenticated remote code execution on Moodle | ||
| 34 | - Every single shitty `modem/router/switch/IoT <https://twitter.com/internetofshit>`_. | ||
| 35 | |||
| 36 | |||
| 37 | ``mail``-related injections | ||
| 38 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| 39 | |||
| 40 | This vulnerability is known `since 2011 <http://esec-pentest.sogeti.com/posts/2011/11/03/using-mail-for-remote-code-execution.html>`_, | ||
| 41 | and was popularized by `RIPS <https://www.ripstech.com/blog/2016/roundcube-command-execution-via-email/>`_ in 2016. | ||
| 42 | The last flag of the `mail` function can be used to pass various parameters to | ||
| 43 | the underlying binary used to send emails: this can lead to an arbitrary file write, | ||
| 44 | often meaning an arbitrary code execution. | ||
| 45 | |||
| 46 | The ``additional_parameters`` parameter can be used to pass additional flags | ||
| 47 | as command line options to the program configured to be used when sending mail | ||
| 48 | |||
| 49 | --- `The PHP documentation about mail <https://secure.php.net/manual/en/function.mail.php>`_ | ||
| 50 | |||
| 51 | We're killing it by preventing any extra options in additional_parameters. | ||
| 52 | |||
| 53 | This family of vulnerabilities lead to various CVE, like: | ||
| 54 | |||
| 55 | - `CVE-2017-7692 <https://legalhackers.com/advisories/SquirrelMail-Exploit-Remote-Code-Exec-CVE-2017-7692-Vuln.html>`_: Authenticated remote code execution in SquirrelMail | ||
| 56 | - `CVE-2016-10074 <https://legalhackers.com/advisories/SwiftMailer-Exploit-Remote-Code-Exec-CVE-2016-10074-Vuln.html>`_: remote code execution in SwiftMailer | ||
| 57 | - `CVE-2016-10033 <https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html>`_: remote code execution in PHPMailer | ||
| 58 | - `CVE-2016-9920 <https://www.ripstech.com/blog/2016/roundcube-command-execution-via-email/>`_: Unauthenticated remote code execution in Roundcube | ||
| 59 | |||
| 60 | Session-cookie stealing via XSS | ||
| 61 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| 62 | |||
| 63 | The goto payload for XSS is often to steal cookies. | ||
| 64 | Like *Suhosin*, we are encrypting the cookies with a secret key, the IP of the user | ||
| 65 | and its user-agent. This means that an attacker with an XSS won't be able to use | ||
| 66 | the stolen cookie, since he (often) can't spoof the IP address of the user. | ||
| 67 | |||
| 68 | This feature is roughly the same than the `Suhosin one <https://suhosin.org/stories/configuration.html#transparent-encryption-options>`_. | ||
| 69 | |||
| 70 | Users behind the same IP address but with different browsers won't be able to use each other stolen cookies, | ||
| 71 | except if they can manage to guess the user agent. This isn't especially difficult, | ||
| 72 | but an invalid decryption will leave a trace in the logs. | ||
| 73 | |||
| 74 | Finally, having a secret server-side key will prevent anyone (even the user himself) | ||
| 75 | from reading the content of the cookie, reducing the impact of an application storing sensitive data client-side. | ||
| 76 | |||
| 77 | The encryption is done via the [tweetnacl library](https://tweetnacl.cr.yp.to/), | ||
| 78 | thus using curve25519, xsalsa20 and poly1305 for the encryption. We chose this | ||
| 79 | library because of its portability, simplicity and reduced size (a single `.h` and | ||
| 80 | `.c` file.). | ||
| 81 | |||
| 82 | Remote code execution via file-upload | ||
| 83 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| 84 | |||
| 85 | Some PHP applications allows users to upload contents, like avatars for a forum. | ||
| 86 | Unfortunately, sometimes, content validation isn't implemented properly (if at all), | ||
| 87 | meaning arbitrary file upload, often leading, contrary to what the documentation is saying, | ||
| 88 | to an arbitrary code execution. | ||
| 89 | |||
| 90 | Not validating which file you operate on may mean that users can *access sensitive information* in other directories. | ||
| 91 | |||
| 92 | --- `The PHP documentation about file uploads <https://secure.php.net/manual/en/features.file-upload.common-pitfalls.php>`_ | ||
| 93 | |||
| 94 | We're killing it, like Suhosin, by automatically calling a script upon file upload, | ||
| 95 | if it returns something else than ``0``, the file will be removed (or stored in a quarantine, | ||
| 96 | for further analysis). | ||
| 97 | |||
| 98 | We're recommending to use the `vld <https://derickrethans.nl/projects.html#vld>`_ project | ||
| 99 | inside the script to ensure the file doesn't contain any valid PHP code, with something like this: | ||
| 100 | |||
| 101 | :: | ||
| 102 | |||
| 103 | $ php -d vld.execute=0 -d vld.active=1 -d extension=vld.so $file | ||
| 104 | |||
| 105 | Unserialize-related magic | ||
| 106 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| 107 | |||
| 108 | PHP is able to *serialize* arbitrary objects, to easily store them. | ||
| 109 | Unfortunately, it's often possible to gain arbitrary code execution upon deserialization | ||
| 110 | of user-supplied serialized objects. | ||
| 111 | |||
| 112 | Do not pass untrusted user input to ``unserialize()`` regardless of the options value of allowed_classes. | ||
| 113 | Unserialization can result in code being loaded and executed due to object instantiation and autoloading, | ||
| 114 | and a malicious user may be able to exploit this. | ||
| 115 | |||
| 116 | --- `The PHP documentation about serialize <https://secure.php.net/manual/en/function.serialize.php>`_ | ||
| 117 | |||
| 118 | We're killing it by exploiting the fact that PHP will discard any garbage found at the end of a serialized object, | ||
| 119 | allowing us to simply append a `HMAC <https://en.wikipedia.org/wiki/Hash-based_message_authentication_code>`_ | ||
| 120 | at the end of strings generated by the ``serialize``, | ||
| 121 | hence guaranteeing that any object deserialized came from the application, | ||
| 122 | and wasn't tampered with, | ||
| 123 | |||
| 124 | We're not encrypting it, like we do with the cookies, | ||
| 125 | allowing this feature to be disabled (or switch into leaning mode) | ||
| 126 | without the need to invalidate any data. | ||
| 127 | |||
| 128 | .. warning:: | ||
| 129 | |||
| 130 | This feature can't be deployed on websites that already stored serialized | ||
| 131 | objects (ie. in database), since they are missing the HMAC, and thus will be detected as | ||
| 132 | an attack. If you're in this situation, you should use this feature with the | ||
| 133 | ``simulation`` mode, and switch it off once you don't have any messages in your | ||
| 134 | logs. | ||
| 135 | |||
| 136 | A nice side-effect of this feature is that it'll defeat various memory corruption | ||
| 137 | issues related to the complexity of ``unserialize``'s implementation, | ||
| 138 | and the amount of control if provides to an attacker, like `CVE-2016-9137, CVE-2016-9138 <https://bugs.php.net/bug.php?id=73147>`_, | ||
| 139 | `2016-7124 <https://bugs.php.net/bug.php?id=72663>`_, `CVE-2016-5771 and CVE-2016-5773 <https://www.evonide.com/how-we-broke-php-hacked-pornhub-and-earned-20000-dollar/>`_, … | ||
| 140 | |||
| 141 | This family of vulnerabilities lead to various CVE, like: | ||
| 142 | |||
| 143 | - `CVE-2016-???? <https://www.computest.nl/advisories/CT-2016-1110_Observium.txt>`_: Unauthenticated remote code execution in Observium (leading to remote root) | ||
| 144 | - `CVE-2016-5726 <http://seclists.org/oss-sec/2016/q2/521>`_: Unauthenticated remote code execution in Simple Machines Forums | ||
| 145 | - `CVE-2016-4010 <http://netanelrub.in/2016/05/17/magento-unauthenticated-remote-code-execution/>`_: Unauthenticated remote code execution in Magento | ||
| 146 | - `CVE-2017-2641 <http://netanelrub.in/2017/03/20/moodle-remote-code-execution/>`_: Unauthenticated remote code execution in Moodle | ||
| 147 | - `CVE-2015-8562 <https://www.rapid7.com/db/modules/exploit/multi/http/joomla_http_header_rce>`_: Unauthenticated remote code execution in Joomla | ||
| 148 | - `CVE-2015-7808 <https://www.rapid7.com/db/modules/exploit/multi/http/vbulletin_unserialize>`_: Unauthenticated remote code execution in vBulletin | ||
| 149 | - `CVE-2014-1691 <http://seclists.org/oss-sec/2014/q1/153>`_: Unauthenticated remote code execution in Horde | ||
| 150 | - `CVE-2012-5692 <https://www.rapid7.com/db/modules/exploit/unix/webapp/invision_pboard_unserialize_exec>`_: Unauthenticated remote code execution in IP.Board | ||
| 151 | |||
| 152 | |||
| 153 | |||
| 154 | Weak-PRNG via rand/mt_rand | ||
| 155 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| 156 | |||
| 157 | The functions ``rand`` and ``mt_rand`` are often used to generate random numbers used | ||
| 158 | in sensitive context, like password generation, token creation, … | ||
| 159 | Unfortunately, as said in the documentation, the quality of their entropy is low, | ||
| 160 | leading to the generation of guessable values. | ||
| 161 | |||
| 162 | This function does not generate cryptographically secure values, and should not be used for cryptographic purposes. | ||
| 163 | |||
| 164 | --- `The PHP documentation about rand <https://secure.php.net/manual/en/function.rand.php>`_ | ||
| 165 | |||
| 166 | We're addressing this issue by replacing every call to ``rand`` and ``mt_rand`` with | ||
| 167 | a call to the ``random_int``, a `CSPRNG <https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator>`_. | ||
| 168 | |||
| 169 | It's worth noting that the PHP documentation contains the following warning: | ||
| 170 | |||
| 171 | ``min`` ``max`` range must be within the range ``getrandmax()``. i.e. ``(max - min) <= getrandmax()``. | ||
| 172 | Otherwise, ``rand()`` may return poor-quality random numbers. | ||
| 173 | |||
| 174 | --- `The PHP documentation about rand <https://secure.php.net/manual/en/function.rand.php>`_ | ||
| 175 | |||
| 176 | This is of course addressed as well by the ``harden_rand`` feature. | ||
| 177 | |||
| 178 | .. warning:: | ||
| 179 | |||
| 180 | Activating this feature will raise an `Error <https://secure.php.net/manual/en/class.error.php>`_ | ||
| 181 | exception if ``min`` is superior to ``max``, while the default dehaviour is simply to swap them. | ||
| 182 | |||
| 183 | This family of vulnerabilities lead to various CVE, like: | ||
| 184 | |||
| 185 | - `CVE-2015-5267 <https://moodle.org/mod/forum/discuss.php?d=320291>`_: Unauthenticated accounts takeover in in Moodle | ||
| 186 | - `CVE-2014-9624 <https://www.mantisbt.org/bugs/view.php?id=17984>`_: Captcha bypass in MantisBT | ||
| 187 | - `CVE-2014-6412 <https://core.trac.wordpress.org/ticket/28633>`_: Unauthenticated account takeover in Wordpress | ||
| 188 | - `CVE-2015-???? <https://hackerone.com/reports/31171>`_: Unauthenticated accounts takeover in Concrete5 | ||
| 189 | - `CVE-2013-6386 <https://www.drupal.org/SA-CORE-2013-003>`_: Unauthenticated accounts takeover in Drupal | ||
| 190 | - `CVE-2010-???? <http://www.sektioneins.com/advisories/advisory-022010-mybb-password-reset-weak-random-numbers-vulnerability.html>`_: Unauthenticated accounts takeover in MyBB | ||
| 191 | - `CVE-2008-4102 <https://sektioneins.de/en/advisories/advisory-042008-joomla-weak-random-password-reset-token-vulnerability.html>`_: Unauthenticated accounts takeover in Joomla | ||
| 192 | - `CVE-2006-0632 <https://www.cvedetails.com/cve/CVE-2006-0632/>`_: Unauthenticated account takeover in phpBB | ||
| 193 | |||
| 194 | XXE | ||
| 195 | ^^^ | ||
| 196 | |||
| 197 | Despite the documentation saying nothing about this class of vulnerabilities, | ||
| 198 | `XML eXternal Entitiy <https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing>`_ (XXE) are often leading to arbitrary file reading, SSRF, and sometimes even arbitrary | ||
| 199 | code execution. | ||
| 200 | |||
| 201 | XML documents can contain a `Document Type Definition <https://www.w3.org/TR/REC-xml/#sec-prolog-dtd>`_ (DTD), | ||
| 202 | enabling definition of XML entities. It's possible to define an (external) entity by an | ||
| 203 | URI, that the parser will access, and embed its content back into the document | ||
| 204 | for further processing. | ||
| 205 | |||
| 206 | For example, providing an url like ``file:///etc/passwd`` will read | ||
| 207 | this file's content, and since it's not valid XML, the application | ||
| 208 | will spit it out in an error message, thus leaking its content. | ||
| 209 | |||
| 210 | We're killing this class of vulnerabilities by calling | ||
| 211 | the `libxml_disable_entity_loader <https://secure.php.net/manual/en/function.libxml-disable-entity-loader.php>`_ | ||
| 212 | function with its parameter set to ``true`` at startup, | ||
| 213 | and then *nop'ing* it, so it won't do anything if ever called again. | ||
| 214 | |||
| 215 | This family of vulnerabilities lead to various CVE, like: | ||
| 216 | |||
| 217 | - `CVE-2015-5161 <https://legalhackers.com/advisories/eBay-Magento-XXE-Injection-Vulnerability.html>`_: Unauthenticated arbitrary file disclosure on Magento | ||
| 218 | - `CVE-2014-8790 <https://github.com/GetSimpleCMS/GetSimpleCMS/issues/944>`_: Unauthenticated remote code execution in GetSimple CMS | ||
| 219 | - `CVE-2011-4107 <https://www.phpmyadmin.net/security/PMASA-2011-17/>`_: Authenticated local file disclosure in PHPMyAdmin | ||
| 220 | |||
| 221 | |||
| 222 | Cookie stealing via HTTP MITM | ||
| 223 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| 224 | |||
| 225 | While it's possible to set the ``secure`` flag on cookies to prevent them from being | ||
| 226 | transmitted over HTTP, and only allow its transmission over HTTPS. | ||
| 227 | Snuffleupagus can automatically set this flag if the client is accessing the | ||
| 228 | website over a secure connection. | ||
| 229 | |||
| 230 | This behaviour is suggested in the documentation: | ||
| 231 | |||
| 232 | On the server-side, it's on the programmer to send this kind of cookie only | ||
| 233 | on secure connection (e.g. with respect to ``$_SERVER["HTTPS"]``). | ||
| 234 | |||
| 235 | --- `The PHP documentation about setcookie <https://secure.php.net/manual/en/function.setcookie.php>`_ | ||
| 236 | |||
| 237 | |||
| 238 | Exploitation, post-exploitation and general hardening | ||
| 239 | ----------------------------------------------------- | ||
| 240 | |||
| 241 | Virtual-patching | ||
| 242 | ^^^^^^^^^^^^^^^^ | ||
| 243 | |||
| 244 | PHP itself exposes a number of functions that might be considered **dangerous** and that have limited legitimate use cases. | ||
| 245 | ``system()``, ``exec()``, ``dlopen()`` - for example - fall into this category. By default, PHP only allows to globally disable some functions. | ||
| 246 | |||
| 247 | |||
| 248 | However, (ie. ``system()``) they might have legitimate use cases in processes such as self upgrade etc., making it impossible to effectively | ||
| 249 | disable them - at the risk of breaking critical features. | ||
| 250 | |||
| 251 | SnuffleuPagus allows the user to restrict usage of specific functions per files, or per | ||
| 252 | files with a matching (sha256) hash, thus allowing the use of such functions **only** in the intended places. | ||
| 253 | |||
| 254 | Furthermore, running the `following script <FIXME>`_ will generate an hash and line-based whitelist | ||
| 255 | of dangerous functions, droping them everywhere else: | ||
| 256 | |||
| 257 | |||
| 258 | .. literalinclude:: ../../scripts/generate_rules.php | ||
| 259 | :language: php | ||
| 260 | |||
| 261 | |||
| 262 | The intent is to make post-exploitation process (such as backdooring of legitimate code, or RAT usage) a lot harder for the attacker. | ||
| 263 | |||
| 264 | |||
| 265 | Global strict mode | ||
| 266 | ^^^^^^^^^^^^^^^^^^ | ||
| 267 | |||
| 268 | By default, PHP will coerce values of the wrong type into the expected one | ||
| 269 | if possible. For example, if a function expecting an integer is given a string, | ||
| 270 | it will be coerced in an integer. | ||
| 271 | |||
| 272 | PHP7 introduced a **strict mode**, in which variables won't be coerced anymore, | ||
| 273 | and a `TypeError <https://php.net/manual/en/class.typeerror.php>`_ exception will | ||
| 274 | be raised if the types aren't matching. | ||
| 275 | `Scalar type declarations <https://secure.php.net/manual/en/migration70.new-features.php#migration70.new-features.scalar-type-declarations>`_ | ||
| 276 | are optional, but you don't have to used them in your code to benefit from them, | ||
| 277 | since every internal function from php has them. | ||
| 278 | |||
| 279 | This option provide a switch to globally activate this strict mode, | ||
| 280 | helping to uncover vulnerabilities like the classical | ||
| 281 | `strcmp bypass <https://danuxx.blogspot.fr/2013/03/unauthorized-access-bypassing-php-strcmp.html>`_, | ||
| 282 | and various other types mismatch. | ||
| 283 | |||
| 284 | This feature is largely inspired from the | ||
| 285 | `autostrict <https://github.com/krakjoe/autostrict>`_ module from `krakjoe <krakjoe.ninja>`_. | ||
| 286 | |||
| 287 | |||
| 288 | Preventing execution of writable PHP files | ||
| 289 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| 290 | |||
| 291 | If an attacker manages to upload an arbitrary file or to modify an existing one, | ||
| 292 | odds are that (thanks to the default `umask <https://en.wikipedia.org/wiki/Umask>`_) | ||
| 293 | this file is writable by the PHP process. | ||
| 294 | |||
| 295 | Snuffleupagus can prevent the execution of this kind of files. A good practise | ||
| 296 | would be to use a different user to run PHP than for administrating the website, | ||
| 297 | and using this feature to lock this up. | ||
| 298 | |||
| 299 | |||
| 300 | |||
| 301 | Dumping capabilities | ||
| 302 | ^^^^^^^^^^^^^^^^^^^^ | ||
| 303 | It's possible to apply the ``dump(:str)`` filter to any virtual-patching rule, | ||
| 304 | to dump the complete web request, along with the filename and the corresponding | ||
| 305 | line number. By using the *right* set of restrictive rules (or by using the | ||
| 306 | *overly* restrictives ones in ``simulation`` mode), you might be able | ||
| 307 | to gather interesting vulnerabilities used against your website. | ||
| 308 | |||
| 309 | |||
| 310 | Misc low-hanging fruits in the default configuration file | ||
| 311 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| 312 | |||
| 313 | Snuffleupagus is shipping with a default configuration file, containing | ||
| 314 | various examples and ideas of things that you might want to enable (or not). | ||
| 315 | |||
| 316 | Available functions recon | ||
| 317 | """"""""""""""""""""""""" | ||
| 318 | |||
| 319 | After compromising a website, most of the time, the attacker does some recon | ||
| 320 | within its webshell, to check which functions are available to execute arbitrary code, | ||
| 321 | since it's not uncommon for some web-hoster to disable things like ``system`` or ``passthru``, | ||
| 322 | or to check if mitigations are enabled, like ``open_basedir``. | ||
| 323 | This behaviour can be detected by preventing the execution of functions like ``ini_get`` | ||
| 324 | or ``is_callable`` with *suspicious* parameters. | ||
| 325 | |||
| 326 | ``chmod`` hardening | ||
| 327 | """"""""""""""""""" | ||
| 328 | |||
| 329 | Some PHP applications are using broad rights when using the ``chmod`` function, | ||
| 330 | like the infamous ``chmod(777)`` command, effectively making the file writable by everyone. | ||
| 331 | Snuffleupagus is preventing this kind of behaviour by restricting the parameters | ||
| 332 | than can be passer to ``chmod``. | ||
| 333 | |||
| 334 | Arbitrary file inclusion hardening | ||
| 335 | """""""""""""""""""""""""""""""""" | ||
| 336 | |||
| 337 | Arbitrary file inclusion is a common vulnerability, that might be detected | ||
| 338 | by preventing the use of anything else than a whitelist of extensions in calls | ||
| 339 | to ``include`` or ``require``. | ||
| 340 | |||
| 341 | *Cheap* SQL injections detection | ||
| 342 | """""""""""""""""""""""""""""""" | ||
| 343 | |||
| 344 | In some SQL injections, attackers might need to use comments, a feature that is | ||
| 345 | often not used in production system, so it might be a good idea to filter | ||
| 346 | queries that contains some. The same filtering idea can be used against | ||
| 347 | SQL functions that are frequently used in SQL injections, like ``sleep``, ``benchmark`` | ||
| 348 | or strings like ``version_info``. | ||
| 349 | |||
| 350 | Still about SQL injections, if a function performing a query returns ``FALSE`` | ||
| 351 | (indicating an error), it might be useful to dump the request for further analysis. | ||
| 352 | |||
