Python format string vulnerabilities in Django, for example-the vulnerability of early warning-the black bar safety net

ID MYHACK58:62201782745
Type myhack58
Reporter 佚名
Modified 2017-01-10T00:00:00


! Author: phithon In the C language, there is a class of particularly interesting vulnerability, format string vulnerability. The light then destroy the memory, read and write any address of the content, binary content, I will not say, say to also do not understand, share the link Python formatted string Python also has a formatted string methods, in Python 2 The old version use the following method to format the string: "My name is %s" % ('phithon', ) "My name is %(name)%" % {'name':'phithon'} Behind the To String object to increase the format method, the improved format string usage is: "My name is {}". format('phithon') "My name is {name}". format(name='phithon') A lot of people have been considered both before and after the difference is just a change of wording only, but in fact the format method has been all-encompassing. Document here: Give some examples of it: "{username}". format(username='phithon') # normal usage "{username! r}". format(username='phithon') # equivalent to repr(username) "{number:0.2 f}". format(number=0.5678) # equivalent to "%0.2 f" % 0.5678, to retain two decimal places "int: {0:d}; hex: {0:#x}; oct: {0:#o}; bin: {0:#b}". format(42) # convert binary "{user. username}". format(user=request. username) # get the object properties "{arr[2]}". format(arr=[0,1,2,3,4]) # get array key value The above usage in Python2. 7 and Python 3 are feasible, it can be said to be a common usage. The formatting string resulting in sensitive information disclosure vulnerability Then, if the formatted string is controlled, it will send? My idea is thus, first of all, we are temporarily unable to pass the formatted string to execute code, but we can use the formatted string in the“Get object properties”,“get array value”, etc. methods to find, access to some sensitive information. In Django, for example, the following view: def view(request, args, kwargs): template = 'Hello {user}, This is your email:' + request. GET. get('email') return HttpResponse(template. format(user=request. user)) The intent is to display the login user of the incoming email address: ! But because we control the formatting part of the string that will cause some unexpected problems. The most simple, such as: ! The output of the current logged user hash password. Look at why will appear such problem: user is the current context of only one variable, that is, the format function to the incoming user=request. user, Django in the request. the user is the current user object, this object contains one attribute of the password, i.e. the user's password. So, {the user. password}is actually the output of the request. user. password. If the changes about the view: def view(request, args, kwargs): user = get_object_or_404(User, pk=request. GET. get('uid')) template = 'This is {user}\'s email:' + request. GET. get('email') return HttpResponse(template. format(user=user)) Will lead to an arbitrary user password disclosure vulnerability: ! Use the format string vulnerability leaked Django configuration information Any of the above passwords leaked cases may be too ideal, we still use most of that case: def view(request, *args, kwargs): template = 'Hello {user}, This is your email:' + request. GET. get('email') return HttpResponse(template. format(user=request. user)) I can get to a variable only the request. the user, in this case how to use? Django is a huge framework, which database, complex relationships, we can through the relationship between attributes to go a little mining of sensitive information. But Django is just a framework, in the absence of target source in the case quite hard to dig up information, so my idea is: go to the mining Django comes with the application of some path, eventually reading the Django configuration items. After a rummage, I found that Django comes with an application“admin” - that is, Django comes with a background of models. py to import the current site configuration file: ! So, the idea is very clear: we just need to somehow find the Django default app for admin model, then by this model acquires the settings object, and then get the database account password, Web, encryption key and other information. I just listed two, there are a few of the more interesting I temporarily do not say: http://localhost:8000/?email={user. groups. model. _meta. app_config. module. admin. settings. SECRET_KEY} http://localhost:8000/?email={user. user_permissions. model. _meta. app_config. module. admin. settings. SECRET_KEY} ! Jinja 2.8.1 template sandbox bypass String formatting vulnerability caused by an actual case-the Jinja template sandbox bypass(

[1] [2] next