警惕！Python中少为人知的10个安全陷阱

　　作者：DennisBrinkrolf
　　译者：豌豆花下猫Python猫
　　原题：10UnknownSecurityPitfallsforPython
　　英文：https：blog。sonarsource。com10unknownsecuritypitfallsforpython
　　声明：本翻译是出于交流学习的目的，基于CCBYNCSA4。0授权协议。为便于阅读，内容略有改动。
　　Python开发者们在使用标准库和通用框架时，都以为自己的程序具有可靠的安全性。然而，在Python中，就像在任何其它编程语言中一样，有一些特性可能会被开发者们误解或误用。通常而言，只有极少的微妙之处或细节会使开发者们疏忽大意，从而在代码中引入严重的安全漏洞。
　　在这篇博文中，我们将分享在实际Python项目中遇到的10个安全陷阱。我们选择了一些在技术圈中不太为人所知的陷阱。通过介绍每个问题及其造成的影响，我们希望提高人们对这些问题的感知，并提高大家的安全意识。如果你正在使用这些特性，请一定要排查你的Python代码！1。被优化掉的断言
　　Python支持以优化的方式执行代码。这使代码运行得更快，内存用得更少。当程序被大规模使用，或者可用的资源很少时，这种方法尤其有效。一些预打包的Python程序提供了优化的字节码。
　　然而，当代码被优化时，所有的assert语句都会被忽略。开发者有时会使用它们来判断代码中的某些条件。例如，如果使用断言来作身份验证检查，则可能导致安全绕过。defsuperuseraction（request，user）：assertuser。issuperuserexecuteactionassuperuser
　　在这个例子中，第2行中的assert语句将被忽略，导致非超级用户也可以运行到下一行代码。不推荐使用assert语句进行安全相关的检查，但我们确实在实际的项目中看到过它们。2。MakeDirs权限
　　os。makdirs函数可以在操作系统中创建一个或多个文件夹。它的第二个参数mode用于指定创建的文件夹的默认权限。在下面代码的第2行中，文件夹ABC是用rwx（0o700）权限创建的。这意味着只有当前用户（所有者）拥有这些文件夹的读、写和执行权限。definitdirectories（request）：os。makedirs（ABC，mode0o700）returnHttpResponse（Done！）
　　在Python3。6版本中，创建出的文件夹A、B和C的权限都是700。但是，在Python3。6版本中，只有最后一个文件夹C的权限为700，其它文件夹A和B的权限为默认的755。
　　因此，在Python3。6中，os。makdirs函数等价于Linux的这条命令：mkdirm700pABC。有些开发者没有意识到版本之间的差异，这已经在Django中造成了一个权限越级漏洞（cve202224583），无独有偶，这在WordPress中也造成了一个加固绕过问题。3。绝对路径拼接
　　os。path。join（path，paths）函数用于将多个文件路径连接成一个组合的路径。第一个参数通常包含了基础路径，而之后的每个参数都被当做组件拼接到基础路径后。
　　然而，这个函数有一个少有人知的特性。如果拼接的某个路径以开头，那么包括基础路径在内的所有前缀路径都将被删除，该路径将被视为绝对路径。下面的示例揭示了开发者可能遇到的这个陷阱。defreadfile（request）：filenamerequest。POST〔filename〕filepathos。path。join（var，lib，filename）iffilepath。find（。）！1：returnHttpResponse（Failed！）withopen（filepath）asf：returnHttpResponse（f。read（），contenttypetextplain）
　　在第3行中，我们使用os。path。join函数将用户输入的文件名构造出目标路径。在第4行中，检查生成的路径是否包含。，防止出现路径遍历漏洞。
　　但是，如果攻击者传入的文件名参数为abc。txt，那么第3行得到的变量filepath会是一个绝对路径（abc。txt）。即os。path。join会忽略掉varlib部分，攻击者可以不使用。字符就读取到任何文件。尽管os。path。join的文档中描述了这种行为，但这还是导致了许多漏洞（CuckooSandboxEvasion，CVE202035736）。4。任意的临时文件
　　tempfile。NamedTemporaryFile函数用于创建具有特定名称的临时文件。但是，prefix（前缀）和suffix（后缀）参数很容易受到路径遍历攻击（Issue35278）。如果攻击者控制了这些参数之一，他就可以在文件系统中的任意位置创建出一个临时文件。下面的示例揭示了开发者可能遇到的一个陷阱。deftouchtmpfile（request）：idrequest。GET〔id〕tmpfiletempfile。NamedTemporaryFile（prefixid）returnHttpResponse（ftmpfile：｛tmpfile｝created！，contenttypetextplain）
　　在第3行中，用户输入的id被当作临时文件的前缀。如果攻击者传入的id参数是。。varwwwtest，则会创建出这样的临时文件：varwwwtestzdllj17。粗看起来，这可能是无害的，但它会为攻击者创造出挖掘更复杂的漏洞的基础。5。扩展的ZipSlip
　　在Web应用中，通常需要解压上传后的压缩文件。在Python中，很多人都知道TarFile。extractall与TarFile。extract函数容易受到ZipSlip攻击。攻击者通过篡改压缩包中的文件名，使其包含路径遍历（。。）字符，从而发起攻击。
　　这就是为什么压缩文件应该始终被视为不受信来源的原因。zipfile。extractall与zipfile。extract函数可以对zip内容进行清洗，从而防止这类路径遍历漏洞。
　　但是，这并不意味着在ZipFile库中不会出现路径遍历漏洞。下面是一段解压缩文件的代码。defextracthtml（request）：filenamerequest。FILES〔filename〕zfzipfile。ZipFile（filename。temporaryfilepath（），r）forentryinzf。namelist（）：ifentry。endswith（。html）：filecontentzf。read（entry）withopen（entry，wb）asfp：fp。write（filecontent）zf。close（）returnHttpResponse（HTMLfilesextracted！）
　　第3行代码根据用户上传文件的临时路径，创建出一个ZipFile处理器。第48行代码将所有以。html结尾的压缩项提取出来。第4行中的zf。namelist函数会取到zip内压缩项的名称。注意，只有zipfile。extract与zipfile。extractall函数会对压缩项进行清洗，其它任何函数都不会。
　　在这种情况下，攻击者可以创建一个文件名，例如。。。。。。varwwwhtml，内容随意填。该恶意文件的内容会在第6行被读取，并在第78行写入被攻击者控制的路径。因此，攻击者可以在整个服务器上创建任意的HTML文件。
　　如上所述，压缩包中的文件应该被看作是不受信任的。如果你不使用zipfile。extractall或者zipfile。extract，你就必须对zip内文件的名称进行消毒，例如使用os。path。basename。否则，它可能导致严重的安全漏洞，就像在NLTKDownloader（CVE201914751）中发现的那样。6。不完整的正则表达式匹配
　　正则表达式（regex）是大多数Web程序不可或缺的一部分。我们经常能看到它被自定义的Web应用防火墙（WAF，WebApplicationFirewalls）用来作输入验证，例如检测恶意字符串。在Python中，re。match和re。search之间有着细微的区别，我们将在下面的代码片段中演示。defissqlinjection（request）：patternre。compile（r。（union）（select）。）nametotestrequest。GET〔name〕ifre。search（pattern，nametotest）：returnTruereturnFalse
　　在第2行中，我们定义了一个匹配union或者select的模式，以检测可能的SQL注入。这是一个糟糕的写法，因为你可以轻易地绕过这些黑名单，但我们已经在线上的程序中见过它。在第4行中，函数re。match使用前面定义好的模式，检查第3行中的用户输入内容是否包含这些恶意的值。
　　然而，与re。search函数不同的是，re。match函数不匹配新行。例如，如果攻击者提交了值aaaaaaunionselect，这个输入就匹配不上正则表达式。因此，检查可以被绕过，失去保护作用。
　　总而言之，我们不建议使用正则表达式黑名单进行任何安全检查。7。Unicode清洗器绕过
　　Unicode支持用多种形式来表示字符，并将这些字符映射到码点。在Unicode标准中，不同的Unicode字符有四种归一化方案。程序可以使用这些归一化方法，以独立于人类语言的标准方式来存储数据，例如用户名。
　　然而，攻击者可以利用这些归一化，这已经导致了Python的urllib出现漏洞（CVE20199636）。下面的代码片段演示了一个基于NFKC归一化的跨站点脚本漏洞（XSS，CrossSiteScripting）。importunicodedatafromdjango。shortcutsimportrenderfromdjango。utils。htmlimportescapedefrenderinput（request）：userinputescape（request。GET〔p〕）normalizeduserinputunicodedata。normalize（NFKC，userinput）context｛myinput：normalizeduserinput｝returnrender（request，test。html，context）
　　在第6行中，用户输入的内容被Django的escape函数处理了，以防止XSS漏洞。在第7行中，经过清洗的输入被NFKC算法归一化，以便在第89行中通过test。html模板正确地渲染。
　　templatestest。html！DOCTYPEhtmlhtmllangenbody｛｛myinputsafe｝｝bodyhtml
　　在模板test。html中，第4行的变量myinput被标记为安全的，因为开发人员预期有特殊字符，并且认为该变量已经被escape函数清洗了。通过标记关键字safe，Django不会再次对变量进行清洗。
　　但是，由于第7行（view。py）的归一化，字符EFB9A4会被转换为，EFB9A5被转换为。这导致攻击者可以注入任意的HTML标记，进而触发XSS漏洞。为了防止这个漏洞，就应该在把用户输入做完归一化之后，再进行清洗。8。Unicode编码碰撞
　　前文说过，Unicode字符会被映射成码点。然而，有许多不同的人类语言，Unicode试图将它们统一起来。这就意味着不同的字符很有可能拥有相同的layout。例如，小写的土耳其语（没有点）的字符是英语中大写的I。在拉丁字母中，字符i也是用大写的I表示。在Unicode标准中，这两个不同的字符都以大写形式映射到同一个码点。
　　这种行为是可以被利用的，实际上已经在Django中导致了一个严重的漏洞（CVE201919844）。下面的代码是一个重置密码的示例。fromdjango。core。mailimportsendmailfromdjango。httpimportHttpResponsefromvuln。modelsimportUserdefresetpw（request）：emailrequest。GET〔email〕resultUser。objects。filter（emailexactemail。upper（））。first（）ifnotresult：returnHttpResponse（Usernotfound！）sendmail（ResetPassword，Yournewpw：123456。，fromexample。com，〔email〕，failsilentlyFalse）returnHttpResponse（Passwordresetemailsend！）
　　第6行代码获取了用户输入的email，第79行代码检查这个email值，查找是否存在具有该email的用户。如果用户存在，则第10行代码依据第6行中输入的email地址，给用户发送邮件。需要指出的是，第79行中对邮件地址的检查是不区分大小写的，使用了upper函数。
　　至于攻击，我们假设数据库中存在一个邮箱地址为foomix。com的用户。那么，攻击者可以简单地传入foomx。com作为第6行中的email，其中i被替换为土耳其语。第7行代码将邮箱转换成大写，结果是FOOMIX。COM。这意味着找到了一个用户，因此会发送一封重置密码的邮件。
　　然而，邮件被发送到第6行未转换的邮件地址，也就是包含了土耳其语的。换句话说，其他用户的密码被发送到了攻击者控制的邮件地址。为了防止这个漏洞，可以将第10行替换成使用数据库中的用户邮箱。即使发生编码冲突，攻击者在这种情况下也得不到任何好处。9。IP地址归一化
　　在Python3。8中，IP地址会被ipaddress库归一化，因此前缀的零会被删除。这种行为乍一看可能是无害的，但它已经在Django中导致了一个高严重性的漏洞（CVE202133571）。攻击者可以利用归一化绕过校验程序，发起服务端请求伪造攻击（SSRF，ServerSideRequestForgery）。
　　下面的代码展示了如何绕过这样的校验器。importrequestsimportipaddressdefsendrequest（request）：iprequest。GET〔ip〕try：ifipin〔127。0。0。1，0。0。0。0〕：returnHttpResponse（Notallowed！）ipstr（ipaddress。IPv4Address（ip））exceptipaddress。AddressValueError：returnHttpResponse（Erroratvalidation！）requests。get（https：ip）returnHttpResponse（Requestsend！）
　　第5行代码获取用户传入的一个IP地址，第7行代码使用一个黑名单来检查该IP是否为本地地址，以防止可能的SSRF漏洞。这份黑名单并不完整，仅作为示例。
　　第9行代码检查该IP是否为IPv4地址，同时将IP归一化。在完成验证后，第12行代码会对该IP发起实际的请求。
　　但是，攻击者可以传入127。0。001这样的IP地址，在第7行的黑名单列表中找不到。然后，第9行代码使用ipaddress。IPv4Address将IP归一化为127。0。0。1。因此，攻击者就能够绕过SSRF校验器，并向本地网络地址发送请求。10。URL查询参数解析
　　在Python3。7中，urllib。parse。parseqsl函数允许使用；和字符作为URL的查询变量的分隔符。有趣的是；字符不能被其它语言识别为分隔符。
　　在下面的例子中，我们将展示为什么这种行为会导致漏洞。假设我们正在运行一个基础设施，其中前端是一个PHP程序，后端则是一个Python程序。
　　攻击者向PHP前端发送以下的GET请求：GEThttps：victim。com？a1；b2
　　PHP前端只识别出一个查询参数a，其内容为1；b2。PHP不把；字符作为查询参数的分隔符。现在，前端会将攻击者的请求直接转发给内部的Python程序：GEThttps：internal。backend？a1；b2
　　如果使用了urllib。parse。parseqsl，Python程序会处理成两个查询参数，即a1和b2。这种查询参数解析的差异可能会导致致命的安全漏洞，比如Django中的Web缓存投毒漏洞（CVE202123336）。总结
　　在这篇博文中，我们介绍了10个Python安全陷阱，我们认为开发者不太了解它们。每个细微的陷阱都很容易被忽视，并在过去导致了线上程序的安全漏洞。
　　正如前文所述，安全陷阱可能出现在各种操作中，从处理文件、目录、压缩文件、URL、IP到简单的字符串。一种常见的情况是库函数的使用，这些函数可能有意想不到的行为。这提醒我们一定要升级到最新版本，并仔细阅读文档。在SonarSource中，我们正在研究这些缺陷，以便将来不断改进我们的代码分析器。