[ci skip] 3.1.11 release

1 files changed, 0 insertions, 200 deletions

diff --git a/user_guide_src/source/general/security.rst b/user_guide_src/source/general/security.rst
deleted file mode 100644
index 744a2c934..000000000
--- a/user_guide_src/source/general/security.rst
+++ /dev/null
@@ -1,200 +0,0 @@
-########
-Security
-########
-
-This page describes some "best practices" regarding web security, and
-details CodeIgniter's internal security features.
-
-.. note:: If you came here looking for a security contact, please refer to
-	our `Contribution Guide <../contributing/index>`.
-
-URI Security
-============
-
-CodeIgniter is fairly restrictive regarding which characters it allows
-in your URI strings in order to help minimize the possibility that
-malicious data can be passed to your application. URIs may only contain
-the following:
-
--  Alpha-numeric text (latin characters only)
--  Tilde: ~
--  Percent sign: %
--  Period: .
--  Colon: :
--  Underscore: \_
--  Dash: -
--  Space
-
-Register_globals
-================
-
-During system initialization all global variables that are found to exist
-in the ``$_GET``, ``$_POST``, ``$_REQUEST`` and ``$_COOKIE`` are unset.
-
-The unsetting routine is effectively the same as *register_globals = off*.
-
-display_errors
-==============
-
-In production environments, it is typically desirable to "disable" PHP's
-error reporting by setting the internal *display_errors* flag to a value
-of 0. This disables native PHP errors from being rendered as output,
-which may potentially contain sensitive information.
-
-Setting CodeIgniter's **ENVIRONMENT** constant in index.php to a value of
-**\'production\'** will turn off these errors. In development mode, it is
-recommended that a value of 'development' is used. More information
-about differentiating between environments can be found on the
-:doc:`Handling Environments <environments>` page.
-
-magic_quotes_runtime
-====================
-
-The *magic_quotes_runtime* directive is turned off during system
-initialization so that you don't have to remove slashes when retrieving
-data from your database.
-
-**************
-Best Practices
-**************
-
-Before accepting any data into your application, whether it be POST data
-from a form submission, COOKIE data, URI data, XML-RPC data, or even
-data from the SERVER array, you are encouraged to practice this three
-step approach:
-
-#. Validate the data to ensure it conforms to the correct type, length,
-   size, etc.
-#. Filter the data as if it were tainted.
-#. Escape the data before submitting it into your database or outputting
-   it to a browser.
-
-CodeIgniter provides the following functions and tips to assist you
-in this process:
-
-XSS Filtering
-=============
-
-CodeIgniter comes with a Cross Site Scripting filter. This filter
-looks for commonly used techniques to embed malicious JavaScript into
-your data, or other types of code that attempt to hijack cookies or
-do other malicious things. The XSS Filter is described
-:doc:`here <../libraries/security>`.
-
-.. note:: XSS filtering should *only be performed on output*. Filtering
-	input data may modify the data in undesirable ways, including
-	stripping special characters from passwords, which reduces
-	security instead of improving it.
-
-CSRF protection
-===============
-
-CSRF stands for Cross-Site Request Forgery, which is the process of an
-attacker tricking their victim into unknowingly submitting a request.
-
-CodeIgniter provides CSRF protection out of the box, which will get
-automatically triggered for every non-GET HTTP request, but also needs
-you to create your submit forms in a certain way. This is explained in
-the :doc:`Security Library <../libraries/security>` documentation.
-
-Password handling
-=================
-
-It is *critical* that you handle passwords in your application properly.
-
-Unfortunately, many developers don't know how to do that, and the web is
-full of outdated or otherwise wrongful advices, which doesn't help.
-
-We would like to give you a list of combined do's and don'ts to help you
-with that. Please read below.
-
--  DO NOT store passwords in plain-text format.
-
-   Always **hash** your passwords.
-
--  DO NOT use Base64 or similar encoding for storing passwords.
-
-   This is as good as storing them in plain-text. Really. Do **hashing**,
-   not *encoding*.
-
-   Encoding, and encryption too, are two-way processes. Passwords are
-   secrets that must only be known to their owner, and thus must work
-   only in one direction. Hashing does that - there's *no* un-hashing or
-   de-hashing, but there is decoding and decryption.
-
--  DO NOT use weak or broken hashing algorithms like MD5 or SHA1.
-
-   These algorithms are old, proven to be flawed, and not designed for
-   password hashing in the first place.
-
-   Also, DON'T invent your own algorithms.
-
-   Only use strong password hashing algorithms like BCrypt, which is used
-   in PHP's own `Password Hashing <http://php.net/password>`_ functions.
-
-   Please use them, even if you're not running PHP 5.5+, CodeIgniter
-   provides them for you.
-
--  DO NOT ever display or send a password in plain-text format!
-
-   Even to the password's owner, if you need a "Forgotten password"
-   feature, just randomly generate a new, one-time (this is also important)
-   password and send that instead.
-
--  DO NOT put unnecessary limits on your users' passwords.
-
-   If you're using a hashing algorithm other than BCrypt (which has a limit
-   of 72 characters), you should set a relatively high limit on password
-   lengths in order to mitigate DoS attacks - say, 1024 characters.
-
-   Other than that however, there's no point in forcing a rule that a
-   password can only be up to a number of characters, or that it can't
-   contain a certain set of special characters.
-
-   Not only does this **reduce** security instead of improving it, but
-   there's literally no reason to do it. No technical limitations and
-   no (practical) storage constraints apply once you've hashed them, none!
-
-Validate input data
-===================
-
-CodeIgniter has a :doc:`Form Validation Library
-<../libraries/form_validation>` that assists you in
-validating, filtering, and prepping your data.
-
-Even if that doesn't work for your use case however, be sure to always
-validate and sanitize all input data. For example, if you expect a numeric
-string for an input variable, you can check for that with ``is_numeric()``
-or ``ctype_digit()``. Always try to narrow down your checks to a certain
-pattern.
-
-Have it in mind that this includes not only ``$_POST`` and ``$_GET``
-variables, but also cookies, the user-agent string and basically
-*all data that is not created directly by your own code*.
-
-
-Escape all data before database insertion
-=========================================
-
-Never insert information into your database without escaping it.
-Please see the section that discusses :doc:`database queries
-<../database/queries>` for more information.
-
-Hide your files
-===============
-
-Another good security practice is to only leave your *index.php*
-and "assets" (e.g. .js, css and image files) under your server's
-*webroot* directory (most commonly named "htdocs/"). These are
-the only files that you would need to be accessible from the web.
-
-Allowing your visitors to see anything else would potentially
-allow them to access sensitive data, execute scripts, etc.
-
-If you're not allowed to do that, you can try using a .htaccess
-file to restrict access to those resources.
-
-CodeIgniter will have an index.html file in all of its
-directories in an attempt to hide some of this data, but have
-it in mind that this is not enough to prevent a serious
-attacker.