How to secure codeigniter website?

CSRF Protection (Cross-Site Request Forgery)

CSRF 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.

URI Security

CodeIgniter contain following character in URI

·         Alpha-numeric text (Latin characters only)

·         Tilde: ~

·         Per cent sign: %

·         Period: .

·         Colon: :

·         Underscore: _

·         Dash: -

·         Space

Password Handling

·         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 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.

 

Form Validation

Codeigniter has a Form Validation Library which is use for validation, filtration, prepping you data. Be sure to always validate and sanitize all input data.

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 insertion

Never insert information into your database without escaping it. Please see the section that discusses 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.

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.

 

 

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 handling ENVIRONMENT page.

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:

1.    Validate the data to ensure it conforms to the correct type, length, size, etc.

2.    Filter the data as if it were tainted.

3.    Escape the data before submitting it into your database or outputting it to a browser.