Considerations for php (codeigniter) Security

Considerations for php (codeigniter) Security

1. httponly

The session must use httponly. Otherwise, it may be attacked by xxs. Use js to obtain the cookie session_id.

Use the ci_session of the framework, the longer digits, and httponly. These are all configured by default.

Instead of using native phpsession, use ci_session. Ci_session has a longer number of digits.

If you want to use a native session, set it as follows (php. ini ):

Session. sid_length // The length of sid, which needs to be extended here. The default value is too short.

Session. cookie_httponly = 1The native session will become httponly.

2. phpinfo

Be sure to close the phpinfo page. The dump Request information may be exploited by attackers. For example, cookie information.

3. Force full-site https

The local development environment must also be configured with https. If you cannot use https in some links, such as message push, you can create a new site.

4. Strict mode

Session. use_strict_mode = 1

Only the session id generated by the server is used, and the session id generated by the user client is not used.

5. CSRF Cross-Site Request Forgery

A's cookie contains the session id of the site example.com, which has not expired. B tries to put an image on the Forum and seduce A to click on the image. This image will initiate A request, the request is disguised as example.com. A's browser believes it is true that the cookie of example.com is appended to this request. The request information is intercepted by B's code and sent to B through asynchronous requests, B has logged on to A's account at example.com through this cookie.

CI has the anti-CSRF mechanism, that is, it will automatically insert a hidden CSRF field in the form. The following settings are required:

Application/config. php:

$config['csrf_protection'] = TRUE;

Note that after this is enabled, all requests made to the external site are blocked. If our website obtains data from other websites, such as calling an api, this function cannot be enabled.

6. xss attacks

CI performs xss filtering on post data, as long as the call is as follows:

$this->input->post('a',true);

If the parameter is set to true, xss can be used to filter post data.

7. Replay

You have encrypted the user name and password and uploaded them to the server for login verification. The attacker does not need to decrypt these user names and passwords. He only needs to re-operate the intercepted data packets to achieve login, this is replay.

Defense measures 5 and 6: Each form contains a hidden random token that can only be used once.

Only one token is used: redis is deleted after expiration

8. Conclusion: Secure user login process

<1> basic session policy:

(1) The session is only used as a session. If the browser is closed, the session becomes invalid;

(2) The shorter the session validity period, the safer it is, for example, 60 seconds;

(3) modify the session refresh time, for example, 30 seconds;

(4) set to store session with redis.

The configuration is as follows:

In php. ini:

session.gc_maxlifetime = 60

This is the validity period of the session. The default value is 1440 seconds, that is, 24 minutes. For example, 60 seconds. If the sid is correct between the client and the server after 60 seconds, it is also invalid. You should refresh the page to update the sid before 60 seconds;

In application/config. php:

$ Config ['sess _ driver '] = 'redis'; // set to use redis to store session $ config ['sess _ cookie_name'] = 'Ci _ session '; $ config ['sess _ expiration '] = 0; // set it to session, close the browser, and the client cookie becomes invalid. $ config ['sess _ save_path'] = 'tcp: // 127.0.0.1: Port Number '; // redis address $ config ['sess _ match_ip'] = FALSE; // do you want to verify that the ip address is consistent? $ config ['sess _ time_to_update '] = 30; // refresh sid $ config ['sess _ regenerate_destroy'] = TRUE after 30 seconds; // Delete the old sid when the sid is regenerated

<2> session id refresh and session expiration time are distinguished:

Note:These settings have a lot to do with security. You should differentiate and use them.

As mentioned aboveSession. gc_maxlifetimeWhat does that mean? That is, the time from which a session is generated to when it expires. In fact, if you use redis, it is clear that this value is a set duration when you use redis to save the sid, when a sid is generated, the key-value is deleted.

So thisSess_time_to_updateAs the name implies, This is the refresh time. This time is a threshold value, that is, the refresh when it exceeds this time.It is not an automatic refresh, but a refresh when accessing the session!When we use the session, we will judge the interval between the last session and the current session. If the interval is greater than this value, we will refresh the sid. This usually happens when we refresh the page and need to read the session for authentication. That is, when we refresh the page, the interval between the two times exceeds this time, that is, refresh the sid, in combination with the above maxlifetime, the session is restarted after the refresh, a new session is written in, and a start time is associated.

That is to say, if we click the page and click the page, we will inevitably trigger our refresh mechanism when necessary, so our session will not expire and will never, if you click here frequently. If the interval between two refreshes exceeds maxlifetime, the logon timeout is displayed and the session is no longer displayed, because the update fails when the session expires.

In summary, this maxlifetime determines the maximum length of time between the two refreshes. Otherwise, the logon times out. However, the update MUST be smaller than maxlifetime, which is inevitable, it is invalid if the value is greater than the value, because it is useless to refresh the expired value. And I 'd better think that this update should be less than half of maxlifetime. If maxlifetime is very long (it is not good to improve the user experience and make the user always log on timeout), it does not matter if the update settings are short, if this session is stolen, it is very likely that the thief has expired and the security will be high.

<2> one-times-tokens:

One-time token

Refer to this article:

Measure the test taker's knowledge about CSRF attack methods.

The concept of replay attacks (this article is required)

The above discussion about php (codeigniter) security considerations is all the content shared by the editor. I hope to give you a reference, and hope you can provide more support for the customer's house.