1 前言
现在一般的web开发框架安全已经做的挺好的了,比如大家常用的django,但是一些不规范的开发方式还是会导致一些常用的安全问题,下面就针对这些常用问题做一些总结。代码审计准备部分见《php代码审计》,这篇文档主要讲述各种常用错误场景,基本上都是咱们自己的开发人员犯的错误,敏感信息已经去除。
2 XSS
未对输入和输出做过滤,场景:
defxss_test(request): name=request.GET['name'] returnHttpResponse('hello%s'%(name))在代码中一搜,发现有大量地方使用,比较正确的使用方式如下:
defxss_test(request): name=request.GET['name'] #returnHttpResponse('hello%s'%(name))return render_to_response('hello.html', {'name':name})
更好的就是对输入做限制,比如说一个正则范围,输出使用正确的api或者做好过滤。
3 CSRF
对系统中一些重要的操作要做CSRF防护,比如登录,关机,扫描等。django 提供CSRF中间件django.middleware.csrf.CsrfViewMiddleware,写入到settings.py的中间件即可。另外再在函数前加上@csrf_exempt修饰器。
4 命令注入
审计代码过程中发现了一些编写代码的不好的习惯,体现最严重的就是在命令注入方面,本来python自身的一些函数库就能完成的功能,偏偏要调用os.system来通过shell 命令执行来完成,老实说最烦这种写代码的啦。下面举个简单的例子:
defmyserve(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('sudorm-f%s'%fullname) returnre很显然这段代码是存在问题的,因为fullname是用户可控的。正确的做法是不使用os.system接口,改成python自有的库函数,这样就能避免命令注入。python的三种删除文件方式:
(1)shutil.rmtree 删除一个文件夹及所有文件
(2)os.rmdir 删除一个空目录
(3)os.remove,unlink 删除一个文件
使用了上述接口之后还得注意不能穿越目录,不然整个系统都有可能被删除了。常见的存在命令执行风险的函数如下:
os.system,os.popen,os.spaw*,os.exec*,os.open,os.popen*,commands.call,commands.getoutput,Popen*
推荐使用subprocess模块,同时确保shell=True未设置,否则也是存在注入风险的。#p#
5 sql注入
如果是使用django的api去操作数据库就应该不会有sql注入了,但是因为一些其他原因使用了拼接sql,就会有sql注入风险。下面贴一个有注入风险的例子:
defgetUsers(user_id=None): conn=psycopg2.connect("dbname='××'user='××'host=''password=''") cur=conn.cursor(cursor_factory=psycopg2.extras.DictCursor) ifuser_id==None: str='selectdistinct*fromauth_user' else: str='selectdistinct*fromauth_userwhereid=%d'%user_id res=cur.execute(str) res=cur.fetchall() conn.close() returnres像这种sql拼接就有sql注入问题,正常情况下应该使用django的数据库api,如果实在有这方面的需求,可以按照如下方式写:
defuser_contacts(request): user=request.GET['username'] sql="SELECT*FROMuser_contactsWHEREusername=%s" cursor=connection.cursor() cursor.execute(sql,[user]) #dosomethingwiththeresults results=cursor.fetchone()#orresults=cursor.fetchall() cursor.close()直接拼接的是万万不可的,如果采用ModelInstance.objects.raw(sql,[]),或者connection.objects.execute(sql,[]) ,通过列表传进去的参数是没有注入风险的,因为django会有处理。
6 代码执行
一般是由于eval和pickle.loads的滥用造成的,特别是eval,大家都没有意识到这方面的问题。下面举个代码中的例子:
@login_required@permission_required("accounts.newTask_assess")deftargetLogin(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的例子:
>>>importcPickle >>>cPickle.loads("cos\nsystem\n(S'uname-a'\ntR.")LinuxRCM-RSAS-V6-Dev3.9.0-aurora#4 *** PPREEMPTFriJun714:50:52CST2013i686Intel(R)Core(TM)i7-2600CPU@3.40GHzGenuineIntelGNU/Linux07 文件操作
文件操作主要包含任意文件下载,删除,写入,覆盖等,如果能达到写入的目的时基本上就能写一个webshell了。下面举个任意文件下载的例子:
@login_required@permission_required("accounts.newTask_assess")defexportLoginCheck(request,filename): ifre.match(r“*.lic”,filename): fullname=filename else: fullname="/tmp/test.lic" printfullname returnHttpResponse(fullname)这段代码就存在着任意.lic文件下载的问题,没有做好限制目录穿越,同理#p#
8 文件上传
8.1 任意文件上传
这里主要是未限制文件大小,可能导致ddos,未限制文件后缀,导致任意文件上传,未给文件重命名,可能导致目录穿越,文件覆盖等问题。
8.2 xml,excel等上传
在我们的产品中经常用到xml来保存一些配置文件,同时也支持xml文件的导出导入,这样在libxml2.9以下就可能导致xxe漏洞。就拿lxml来说吧:
root@kali:~/python#cattest.xml <?xmlversion="1.0"encoding="utf-8"?><!DOCTYPExdsec[<!ENTITYxxeSYSTEM"file:///etc/passwd"> ]> <root><nodeid="11"name="bb"net="192.168.0.2-192.168.0.37"ltd=""gid=""/>test&xxe;</root> >>>fromlxmlimportetree >>>tree1=etree.parse('test.xml') >>>printetree.tostring(tree1.getroot()) <root><nodeid="11"name="bb"net="192.168.0.2-192.168.0.37"ltd=""gid=""/>testroot:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/ *** in:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh这是因为在lxml中默认采用的XMLParser导致的:
classXMLParser(_FeedParser) |XMLParser(self,encoding=None,attribute_defaults=False,dtd_validation=False,load_dtd=False,no_network=True,ns_clean=False,recover=False,XMLSchemaschema=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不受影响
9 不安全的封装
9.1 eval 封装不彻底
仅仅是将__builtings__置为空,如下方式即可绕过,可参见bug84179
>>>s2=""" ...[xforxin().__class__.__bases__[0].__subclasses__() ...ifx.__name__=="zipimporter"][0]( ..."/home/liaoxinxi/eval_test/configobj-4.4.0-py2.5.egg").load_module( ..."configobj").os.system("uname") ...""" >>>eval(s2,{'__builtins__':{}}) Linux 09.2 执行命令接口封装不彻底
在底层封装函数没有过滤shell元字符,仅仅是限定一些命令,但是其参数未做控制,可参见bug86011
10 总结
1、一切输入都是不可靠的,做好严格过滤。
2、验证输入,避免注入,危险函数列表:evec(),eval(),os.system(),os.popen(),execfile(),input(),compile()
3、访问控制
4、认证管理和session管理,url中不要带认证信息或者用户信息,给敏感信息加密,python的random和whrandom不是足够强大,要获取强大的密码,得使用n=open('/dev/urandom') data = n.read(128)
5、xss
6、错误处理
7、不安全的存储,如base64编码密码
8、ddos
9、配置管理,session过期时间
10、缓冲区溢出
版权声明
本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。