You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(a)
Vulnerability #1 should not be in the output, or at least, if you would argue it should be, you'd concede it's a good idea to give an option for vulnerabilities like it to not be in the output. When I say 'vulnerabilities like it' I mean, we ran it on a controller file, upload_controller.py which calls into misc.py, then we reported vulnerabilities as though we ran it on misc.py, resulting in a duplicate (vulnerabilities 1 and 2).
To solve this, maybe we should do something with self.filenames[-1] inside of interprocedural.py or just, at a higher level, grab the file from the -f output and skip any vulnerabilities that don't match it (note the File: example/django.nV/taskManager/misc.py in the output). The latter idea sounds cleaner and smoother.
(b) Vulnerability #3 is not unknown, although we know uploaded_file is tainted we don't have any idea if uploaded_file.temporary_file_path() is something that leads to a vulnerability.
To solve this, we somehow add the return value of uploaded_file.temporary_file_path() to blackbox_assignments. The .args list of the sink might include uploaded_file, so we'll need to change this as well when we're visiting BBorBInode arguments.
(c) Vulnerabilities #4 and #5 are the same vulnerability, stemming from the same line.
(d) In the Vulnerability #5 output, it doesn't show the actual request.whatever line that led to the vulnerability.
Perhaps these can be solved with the same code, not sure.
(e) If you run it without -trim, and search through the output you'll see ret_render_to_response('taskManager/upload.html', 'form'form, ¤call_13) (from the original line render_to_response('taskManager/upload.html', {'form': form}, RequestContext(request))), so I take it I don't handle visual_args very well when they're dictionaries. A low-priority issue from where I stand though.
Another thing that I noticed, but I'm not going to implement, is #71
The text was updated successfully, but these errors were encountered:
KevinHock
changed the title
2 Duplication problems and a false-positive in a portion of django.nV output
2 Duplication problems and a false-positive in a portion of django.nV output, among other things.
Nov 12, 2017
@KevinHock defining non-propagating attributes is one idea, another unrelated one is refining sinks by specifying which specific arguments are sinks. Would these be desirable features?
So I run
python -m pyt -a E -f example/django.nV/taskManager/upload_controller.py -trim
and out I get:There are many issues with this output.
(a)
Vulnerability
#1
should not be in the output, or at least, if you would argue it should be, you'd concede it's a good idea to give an option for vulnerabilities like it to not be in the output. When I say 'vulnerabilities like it' I mean, we ran it on a controller file,upload_controller.py
which calls intomisc.py
, then we reported vulnerabilities as though we ran it onmisc.py
, resulting in a duplicate (vulnerabilities 1 and 2).To solve this, maybe we should do something with
self.filenames[-1]
inside ofinterprocedural.py
or just, at a higher level, grab the file from the -f output and skip any vulnerabilities that don't match it (note theFile: example/django.nV/taskManager/misc.py
in the output). The latter idea sounds cleaner and smoother.(b) Vulnerability
#3
is not unknown, although we knowuploaded_file
is tainted we don't have any idea ifuploaded_file.temporary_file_path()
is something that leads to a vulnerability.To solve this, we somehow add the return value of
uploaded_file.temporary_file_path()
to blackbox_assignments. The .args list of the sink might includeuploaded_file
, so we'll need to change this as well when we're visiting BBorBInode arguments.(c) Vulnerabilities
#4
and#5
are the same vulnerability, stemming from the same line.(d) In the Vulnerability
#5
output, it doesn't show the actualrequest.whatever
line that led to the vulnerability.Perhaps these can be solved with the same code, not sure.
(e) If you run it without -trim, and search through the output you'll see
ret_render_to_response('taskManager/upload.html', 'form'form, ¤call_13)
(from the original linerender_to_response('taskManager/upload.html', {'form': form}, RequestContext(request))
), so I take it I don't handle visual_args very well when they're dictionaries. A low-priority issue from where I stand though.Another thing that I noticed, but I'm not going to implement, is #71
The text was updated successfully, but these errors were encountered: