Python security coding and code Auditing

Python security coding and code Auditing

1 Preface

Currently, the general web development framework security has been quite good. For example, django is commonly used, but some nonstandard development methods will still cause some common security problems, the following is a summary of these common problems. For the preparation of code audit, see php code audit. This document mainly describes common error scenarios, which are basically errors made by our own developers and sensitive information has been removed.

2 XSS

Input and output are not filtered. Scenario:

def xss_test(request):    name = request.GET['name']    return HttpResponse('hello %s' %(name))

A search in the code finds that a large number of places are used. The correct method is as follows:

def xss_test(request): name = request.GET['name'] #return HttpResponse('hello %s' %(name))return render_to_response('hello.html', {'name':name})

It is better to restrict the input, such as a regular expression range, and use the correct api or filter the output.

3 CSRF

Perform CSRF protection for important operations in the system, such as logon, shutdown, and scanning. Django provides the CSRF middleware django. middleware. csrf. CsrfViewMiddleware and writes it to the middleware of settings. py. Add the @ csrf_exempt modifier before the function.

4. Command Injection

Some bad habits of writing code are found in the audit code process. The most serious manifestation is the functionality that can be completed by some function libraries of python itself in terms of command injection, however, the OS must be called. to be honest, this is the most annoying way to write code. The following is a simple example:

 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

Obviously, this code is problematic because fullname is controllable. The correct method is to change the OS. system interface to the python library function, so as to avoid command injection. Python deletes files in three ways:

(1) shutil. rmtree delete a folder and all files (2) OS. rmdir delete an empty directory (3) OS. remove, unlink delete a file

After using the above interface, you must note that you cannot traverse the directory. Otherwise, the entire system may be deleted. Common functions with risky command execution are as follows:
OS. system, OS. popen, OS. spaw *, OS .exe c *, OS. open, OS. popen *, commands. call, commands. getoutput, Popen *

We recommend that you use the subprocess module and make sure that shell = True is not set. Otherwise, there is a risk of injection.

5. SQL Injection

If you use django APIs to operate databases, there should be no SQL injection. However, if you use concatenated SQL statements for some other reasons, there is a risk of SQL injection. The following is an example with injection risks:

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=%d'%user_id  res = cur.execute(str)  res = cur.fetchall()  conn.close() return res

For this type of SQL concatenation, there is an SQL injection problem. Normally, you should use the django database api. If you have such requirements, you can write them as follows:

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()

Directly splicing is absolutely impossible. If modelinstance.objects.raw( SQL ,])), on.objects.exe cute (SQL, []), the parameters passed through the list are not risky because django will process them.

6. Code Execution

This problem is generally caused by the misuse of eval and pickle. loads, especially eval. The following is an example in the Code:

@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=[]

This piece of code is because the eval parameters are uncontrollable, resulting in arbitrary code execution. The correct method is the literal. eval interface. Here is an example of 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.40 GHz GenuineIntel GNU/Linux
0

7. File Operations

File Operations include downloading, deleting, writing, and overwriting any file. If the file can be written to the target, a webshell can be written. The following is an example of downloading arbitrary files:

@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)

This code is prone to arbitrary. lic file downloading and does not limit directory traversal.

8. File Upload

8.1 Arbitrary File Upload

There is no limit on the file size, which may lead to ddos attacks, no limit on the file suffix, resulting in arbitrary file upload, not renaming the file, may cause directory traversal, File Overwrite and other problems.

8.2 xml, excel, and other uploads

Xml is often used in our products to save some configuration files, and export and import of xml files is also supported, so that the xxe vulnerability may occur below libxml2.9. Take lxml for example:

root@kali:~/python# cat test.xmlxml version="1.0" encoding="utf-8"?>]> id="11" name="bb" net="192.168.0.2-192.168.0.37" ltd="" gid="" />test&xxe;>>> from lxml import etree>>> tree1 = etree.parse('test.xml')>>> print etree.tostring(tree1.getroot()) id="11" name="bb" net="192.168.0.2-192.168.0.37" ltd="" gid=""/>testroot:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/bin/shbin:x:2:2:bin:/bin:/bin/shsys:x:3:3:sys:/dev:/bin/shsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/bin/shman:x:6:12:man:/var/cache/man:/bin/sh

This is caused by the XMLParser used by default in lxml:

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)

Pay attention to two key parameters. resolve_entities = True and no_network = True. resolve_entities = True will cause the object to be parsed. If no_network is True, this condition is valid, this will cause some ssrf problems, and data cannot be taken out. In python, xml. dom. minidom and xml. etree. ElementTree are not affected.

9 insecure Encapsulation

9.1 incomplete eval Encapsulation

You only need to leave _ builtin _ blank. You can bypass this by using the following method. For more information, see bug83169.

>>> s2="""... [x for x in ().__class__.__bases__[0].__subclasses__()... if x.__name__ == "zipimporter"][0](... "/home/liaoxinxi/eval_test/configobj-4.4.0-py2.5.egg").load_module(... "configobj").os.system("uname")... """>>> eval(s2,{'__builtins__':{}})Linux

0

9.2 command invocation interface encapsulation is incomplete

The underlying encapsulation function does not filter shell metacharacters. It only limits some commands, but its parameters are not controlled.

10 Summary
1. All inputs are unreliable and strictly filtered.
2. Verify input to avoid injection. List of dangerous functions: evec (), eval (), and OS. system (), OS. popen (), execfile (), input (), compile ()
3. Access Control
4. authentication management and session management. do not include authentication information or user information in the url to encrypt sensitive information. The python random and whrandom are not powerful enough to obtain a powerful password, use n = open ('/dev/urandom') data = n. read (1, 128)
5. xss
6. handle errors
7. insecure storage, such as base64-encoded passwords
8. ddos
9. Configuration Management and session expiration time
10. Buffer Overflow