0x00 前语

from:http://sector.ca/Portals/17/Presentations15/SecTor_Branca.pdf

这个pdf中深化Python的中心库进行剖析，而且探讨了在两年的安全代码检查过程中，一些被认为是最要害的问题，最终也提出了一些解决方案和缓解的办法。我自己也在验证探求过程中添枝加叶了一点，如有过错还请指出哈。

下面一张图表明他们的办法论：

探求的场景为：

输入的数据是"不知道"的类型和巨细 运用RFC标准构建Libraries 数据在没有通过恰当的验证就被处理了 逻辑被更改为是独立于操作系统的

0x01 Date and time —> time, datetime, os

time

asctime

这里边asctime()函数是将一个tuple或许是struct_time表明的时刻方式转换成类似于Sun Jun 20 23:21:05 1993的方式，能够time.asctime(time.localtime())验证一下。对time.struct_time(tm_year=2019, tm_mon=11, tm_mday=7, tm_hour=20, tm_min=58, tm_sec=57, tm_wday=5, tm_yday=311, tm_isdst=0)中每一个键值设置invalid_time可形成溢出过错。

在Python 2.6.x中报错为OverflowError: long int too large to convert to int

在Python 2.7.x中报错为

OverflowError: Python int too large to convert to C long OverflowError: signed integer is greater than maximum

自己在64位Ubuntu Python2.7.6也测验了一下，输出成果为：

[-] hour: [+] OverflowError begins at 31: signed integer is greater than maximum [+] OverflowError begins at 63: Python int too large to convert to C long ...

gmtime

time.gmtime()为将秒数转化为struct_time格局，它会根据time_t渠道进行查验，如上代码中将秒数扩展进行测验时会发生报错ValueError: timestamp out of range for platform time_t。假如数值在-2^63到-2^56之间或许2^55到2^62之间又会引发另一种报错ValueError: (84, 'Value too large to be stored in data type')。我自己的测验成果输出如下：

[-] 2 power: [+] ValueError begins at 56: (75, 'Value too large for defined data type') [+] ValueError begins at 63: timestamp out of range for platform time_t [-] -2 power: [+] ValueError begins at 56: (75, 'Value too large for defined data type') [+] ValueError begins at 64: timestamp out of range for platform time_t

os

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]  黑客接单网