Php Y2K38 vulnerability solution, phpy2k38

Php Y2K38 vulnerability solution, phpy2k38

Php Y2K38 vulnerability Solution

Y2K38, also known as the Unix Millennium Bug, affects all 32-bit systems that use UNIX timestamp Integers to record time in PHP and other programming languages.

The maximum time that an integer variable can be saved is 03:14:07, January 1, January 19, 2038. After this time is exceeded, the integer value will overflow.

From January 1, January 01, 1970 to 03:14:07 on Tuesday 1, January 19, 2038, the world standard goes beyond 2 ^ 31-1. 2 ^ 31-1 is 0x7FFFFFFF. I believe many programmers have read it. In a 32-bit system, this indicates the largest signed integer. If it is used to represent the number of seconds, it is about 68.1 years. It is exactly the number from 1970 to 2038 years.

In a 32-bit system, it is shown that the date after 03:14:07 January 1, January 19, 2038 will overflow.

<? Php $ date = '2017-01-01 12:00:00 '; echo strtotime ($ date); // empty overflow echo date ('Y-m-d H: I: s ', strtotime ($ date); // 1970-01-01 00:00:00?>

Will the 64-bit system be affected?

Theoretically not. We strongly recommend that you perform a test. In a 64-bit system, the maximum date that can be saved is 21 times the current cosmic age ~ 29.2 billion years.

On 32-bit machines, you can use the DateTime class to solve this problem. (PHP5.2 introduced this class and added some methods in version 5.3)

The Code is as follows:

<?php$date = '2040-01-01 12:00:00';$dt = new DateTime($date);echo $dt->format('U');           // 2209032000echo $dt->format('Y-m-d H:i:s'); // 2040-01-01 12:00:00 ?>

Convert datetime to unixtime

<? Php // convert datetime to unixtime $ dt = new DateTime ('2017-01-01 12:00:00 '); echo $ dt-> format ('U'); // 2040?>

Unixtime to datetime

<? Php // unixtime to datetime $ dt = new DateTime ('@ 2209032000'); echo $ dt-> format ('Y-m-d H: I: s '); // 2040-01-01 12:00:00?>

Php Vulnerability

Session fixation means that someone else uses a known sid to log on to you, and then he can log on and operate on your account.
Several methods to avoid it
1. Do not send sid in post or get methods. Change it to cookie.
2. Confirm the ip address of the access request, and regenerate the sid for different ip addresses.
3. Encrypted SSL transmission is used for important data operations.
4. Change the sid in time after the user's browser or logout and any changes
5. Set the session for inactive operations to time out. After the timeout, the sid is regenerated to reduce the possibility of theft.

What are PHP vulnerabilities?

First, like ASP, lax filtering of sensitive characters will lead to injection ..
PHP is also very characteristic. It is very user-friendly to run the program. If it is not set properly, you can submit a wrong address and the like to tell you sensitive information such as absolute paths.
PHP may read arbitrary files due to lax filtering.
If the variables are not strictly filtered, the counterfeit data will be spoofed to the server.
And so on. I'm talking about this.