Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what php security precautions are there", in daily operation, I believe many people have doubts about what php security precautions are there, Xiaobian consulted all kinds of information, sorted out simple and easy to use operation methods, and hoped to answer "what php security precautions are there" doubts helpful! Next, please follow the small series to learn together!

1、httponly

Session must be httponly otherwise it may be xxs attack, use js to obtain cookie session_id.

To use the framework ci_session, longer digits, httponly, these are configured by default.

Do not use native phpsession, use ci_session instead. ci_session is longer.

If you want to use a native session, you should set it like this (php.ini):

session.sid_length //sid length, here to be longer, the default is too short

session.cookie_httponly = 1 The native session becomes httponly.

2、phpinfo

Be sure to close the phpinfo page, dump requests can be exploited by attackers. For example, cookie information.

3. Mandatory https

Through cdn jump, the local development environment should also be equipped with https. If some links cannot use https, such as message push, then you can create a new site.

4、Strict mode

session.use_strict_mode = 1

Only use the session id generated by the server itself, not the session id generated by the user client.

CSRF Cross-site Request Forgery

A's cookie has the session id of example.com and has not expired. B lures A to click on this image by putting an image on the forum. This image will initiate a request disguised as example.com. A's browser believes it and attaches the cookie of example.com to this request. This request information is intercepted by B's code and sent to B through asynchronous request. B logs in A's account at example.com through this cookie.

CI has a CSRF prevention mechanism, i.e. it automatically inserts a hidden CSRF field into the form. The following settings are required:

application/config/config.php:

$config['csrf_protection'] = TRUE;

Note that when this is enabled, all outgoing requests are blocked. If our site has behavior that fetches data from other sites, such as calling api, then this switch cannot be enabled.

6. XSS attack

CI will xss filter the post data if called:

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

As long as you add a parameter true, you can xss filter the post data.

7. Replay

You encrypt the user name and password, and send it to the server for login verification. The attacker does not need to decrypt your user name and password. He only needs to intercept these data packets and re-operate them once to log in. This is replay.

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

Token implementation only once: redis expires and is deleted directly after use

8. Summary: User Security Login Process

Basic session strategy:

(1)session only session, close the browser is invalid;

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

(3)The corresponding refresh time of the session needs to be modified, for example, 30 seconds;

(4)Settings are stored in redis session.

The configuration is as follows:

In php.ini:

session.gc_maxlifetime = 60

This is the validity period of the session, the default is 1440 seconds, that is, 24 minutes, changed to, for example, 60 seconds. When 60 seconds later, the client and the server this sid match, it is invalid, should refresh the page before 60 seconds to update sid, how to update the following said;

In application/config/config.php:

$config <$'sess_driver'] = 'redis';//Set to redis storage session$config <$'sess_cookie_name'] = 'ci_session';$config <$'sess_expiration'] = 0;//Set to session, close browser, client cookies will expire $config <$'sess_save_path'] = 'tcp://127.0.0.1: port number';//redis address $config <$'sess_match_ip'] = FALSE;//do not verify ip consistency $config <$'sess_time_to_update']= 30;//refresh sid after 30 seconds $config <$'sess_regenerate_destroy'] = TRUE;//delete old sid when sid is regenerated

Distinguish between refresh of session id and expiration time of session:

Note: These settings are very important to security and should be distinguished and used.

What does session.gc_maxlifetime mean? That is, the time from the generation of a session to its expiration. In fact, if you use redis, it is clear that this value is a duration set when using redis to save sid. This is very clear. When a sid is generated, this time will be written in, so at this time, this key-value will be deleted.

So this sess_time_to_update, as its name implies, is the refresh time. This time is a threshold, which means that if this time is exceeded, it will be refreshed. It is not automatically refreshed, but refreshed when visiting the session! When we use session, it will determine the interval between the last session and this session. If the interval is greater than this value, it will refresh sid. This use, the usual performance is that we refresh the page, need to read the session to authenticate, then when refreshing the page, the interval between two times exceeds this time, that is, refresh sid, then combined with the above maxlifetime, that is, after refreshing the session renewed life, a new session is written in, accompanied by a restart of the timing.

That is to say, if we swipe the page for a while, then we will trigger our refresh mechanism when necessary, then our session will not expire, never, if we swipe there frequently. If the time interval between two refreshes exceeds maxlifetime, then it will show that the login timeout, the session has disappeared, because after the expiration, you go to update, obviously it is not good, update failed.

So the summary is that this maxlifetime determines how long we can't exceed between two refreshes, otherwise the login timeout; and update must be less than maxlifetime, which is inevitable, because if it is greater than it is invalid, because it is useless to refresh after expiration. and preferably i think this update should be less than half of maxlifetime. If maxlifetime is very long (hope to improve the user experience, let the user always log in timeout is always not good), then this update set is relatively short also does not matter, because if set relatively short, assuming that this session was stolen then there is a greater possibility that the thief to use the time has expired, security will be relatively high.

one-times-tokens：

One-time token

At this point, the study of "what PHP security precautions" is over, hoping to solve everyone's doubts. Theory and practice can better match to help everyone learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.