--randomize switch affects vector check

[SebaNuss]

What's the problem (or question)?

When using the --randomize switch, SQLMap will also randomize the "IF" string statement when testing for false positives against Microsoft SQL/Sybase stacked queries.
This breaks the checking of false positives, as it will not execute the IF statement, but instead two random characters.

Do you have an idea for a solution?

Make it so the --randomize switch only affects the user's supplied parameter, not any of the actual vector code.

How can we reproduce the issue?

1. Run SQLMap with the --randomize parameter on the actual vulnerable parameter, the issue occured on a Microsoft SQL Server/Sybase stacked queries (comment) vulnerable injection point
2. When SQLMap finds the injection point, it will test for false positives, and in doing so it will randomize the "IF" string from the vector. This causes the test to automatically fail

What are the running context details?

• Installation method (e.g. pip, apt-get, git clone or zip/tar.gz): apt-get kali
• Client OS (e.g. Microsoft Windows 10): Kali
• Program version (python sqlmap.py --version or sqlmap --version depending on installation): 1.3#stable
• Target DBMS (e.g. Microsoft SQL Server): Microsoft SQL Server
• Detected WAF/IPS protection (e.g. ModSecurity or unknown): Unknown
• SQLi techniques found by sqlmap (e.g. error-based and boolean-based blind): Stacked Queries (comment)
• Results of manual target assessment (e.g. found that the payload query=test' AND 4113 IN ((SELECT 'foobar'))-- qKLV works): Not relevant
• Relevant console output (if any):

sqlmap -r operator.req --level=5 --risk=3 -p Operator --randomize=Operator --dbms=mssql --os=windows --force-ssl --technique=s --test-filter comment -v 6
...
[11:23:11] [INFO] POST parameter 'Operator' appears to be 'Microsoft SQL Server/Sybase stacked queries (comment)' injectable
[11:23:11] [INFO] checking if the injection point on POST parameter 'Operator' is a false positive
[11:23:11] [PAYLOAD] 9999-0013';IF(30=30) WAITFOR DELAY '0:0:5'-- 2554
[11:23:11] [TRAFFIC OUT] HTTP request [#37]:
POST <snipped> HTTP/1.1
Accept-language: nl,en-US;q=0.7,en;q=0.3
Accept-encoding: gzip, deflate
Accept: */*
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Host: <snipped>
X-Requested-With: XMLHttpRequest
Cookie: <snipped>
Referer: <snipped>
Content-type: application/x-www-form-urlencoded; charset=UTF-8
Authorization: <snipped>
Content-length: 147
Connection: close

<snipped>&Operator=8982-4038%27%3BPY%2830%3D30%29%20WAITFOR%20DELAY%20%270%3A0%3A5%27--%203944&<snipped>

[11:23:12] [TRAFFIC IN] HTTP response [#37] (200 OK):
Content-length: 272
Set-cookie: ASP.NET_SessionId=<snipped>; path=/; HttpOnly
Expires: Tue, 05 Feb 2019 10:23:11 GMT
Vary: *
Uri: <snipped>
Server: Microsoft-IIS/7.0
Last-modified: Tue, 05 Feb 2019 10:23:11 GMT
Connection: close
Cache-control: public, max-age=0
Date: Tue, 05 Feb 2019 10:23:11 GMT
X-frame-options: SAMEORIGIN, SAMEORIGIN
X-powered-by: ASP.NET
Content-type: application/json; charset=utf-8

<snipped>
[11:23:12] [WARNING] false positive or unexploitable injection point detected
[11:23:12] [WARNING] POST parameter 'Operator' does not seem to be injectable
[11:23:12] [CRITICAL] all tested parameters do not appear to be injectable. Rerun without providing the option '--technique'. If you suspect that there is some kind of protection mechanism involved (e.g. WAF) maybe you could try to use option '--tamper' (e.g. '--tamper=space2comment') and/or switch '--random-agent'

• Exception traceback (if any):

[stamparm]

--randomize should not be used/available against a parameter for which the test is being run. I'll make a quick check for this kind of cases