sqli.py test fails on non-3.6 versions of python

[KevinHock]

So I tried to add a tox.ini with all the versions of py3 + pypy3, due to the results file I realized with 3.6 you get:

2 vulnerabilities found:
Vulnerability 1:
File: example/vulnerable_code/sql/sqli.py
 > User input at line 26, trigger word "get(": 
	param = request.args.get('param', 'not set')
File: example/vulnerable_code/sql/sqli.py
 > reaches line 27, trigger word "execute(": 
	result = db.engine.execute(param)

Vulnerability 2:
File: example/vulnerable_code/sql/sqli.py
 > User input at line 33, trigger word "get(": 
	param = request.args.get('param', 'not set')
File: example/vulnerable_code/sql/sqli.py
 > reaches line 36, trigger word "filter(": 
	result = session.query(User).filter('username={}'.format(param))

whereas below 3.6 you get

2 vulnerabilities found:
Vulnerability 1:
File: example/vulnerable_code/sql/sqli.py
 > User input at line 33, trigger word "get(": 
	param = request.args.get('param', 'not set')
File: example/vulnerable_code/sql/sqli.py
 > reaches line 36, trigger word "filter(": 
	result = session.query(User).filter('username={}'.format(param))

Vulnerability 2:
File: example/vulnerable_code/sql/sqli.py
 > User input at line 26, trigger word "get(": 
	param = request.args.get('param', 'not set')
File: example/vulnerable_code/sql/sqli.py
 > reaches line 27, trigger word "execute(": 
	result = db.engine.execute(param)

notice the difference? It's just an order problem

This would explain why I had to change the results file to get Travis CI to pass in #23

[KevinHock]

I'm just gonna punt this off until later and add a tox file with just py36.

[Thalmann]

First of the order differs: Because the vulnerabilities are stored in a dictionary.

The problem you describe above has always been a problem.
I see two solutions:

1. We just order the dict with vulnerabilities.
2. Solution 1 could make pyt slower so we could add it as an argument.

More on dicts in python:
A dict in python is a hash table. The hash function was rewritten to counter a security problem(DoS attack if i remember correct.. google it :b). This means that it is more random which results in that the order may differ from python process to python process.

In python 3.6 the dict was re-implemented by Raymond Hettinger. Which actually means that dicts are ordered now by CPython. But it is recommended not to rely on this.

This is why we see a different in the ordering.

[KevinHock]

I initially just thought changing the way we're testing it was what we should do, to make order not matter. From a UI point of view ordering the vulns by line number seems kind of desirable though, we'll eventually give the option to sort by severity so writing the option to sort by line number seems good to me 👍

[Thalmann]

The sanitisers are stored in a dict. So i expect this is the one that is causing it. It can be found in the vulnerabilities.py module.

[KevinHock]

I think this isn't much of an issue :p