1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
########
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.
|
