Bug in csrf-token option, not replacing

[JavanXD]

Issue while using a non-regex value as Anti-CSRF token

We have problems with --csrf-token which could be caused by a new change in sqlmap which supports regex. We tested on version 1.3.2#stable Kali Linux 2019.1

This problems occurs when the csrf-token includes a char like : (e.g. -p "MyForm:csrftoken" ). We also tried urlencoding it to %3A but that didn't solve the problem.

When we started a scan we were always asked for provided value for option '--csrf-token' is a regular expression? [Y/n]. This became very strange because we didn't know there is support for regex params. After some research we came up to this new pull request in version 1.3.
Because we didn't provide a regular expression we shouldn't be asked.

I think the first bug sits in line option.py#L1692. Because the escaped : differs from the original csrf-token. This could be solved by creating an additional flag like --csrf-regex=1.

Not replacing CSRF token in post param

But no matter whether we answer with 'Y' or 'n' it does not change the outcome. There must be one additional problem:

Sometimes the CSRF-Token was replaced correctly in the request and sometimes not - very strange behaviour. We reviewed/debugged the HTTP History also by using Burp as Proxy and including a delay as option. The most strange thing is that the csrf-token which is provided seems to be received correctly from the --csrf-url option but is not inserted in the requests #3-#45 (note that csrftoken is always equal to 8e8adea846994f37643f702413abc973, which is defined in request_3.txt). Strangely csrftoken is replaced in the first http post request (which does not include a payload, see [13:44:51] [TRAFFIC OUT] HTTP request [#2]). But after that it stops immediately to replace the tokens for each request. After post request #45 the csrftoken replacing begins to work again.

Why is the csrftoken not replaced in the tests between #3 and #45?

sqlmap -r /root/Documents/BlubWeb/request_3.txt --level 1 --risk 1 -v 5 -p "MyForm:name1" --dbms=oracle --csrf-token="MyForm:csrftoken" --csrf-url="https://blablubhost/BlubWeb/pages/blubbiblub/dosth.faces;jsessionid=Thisisasessionid" --force-ssl --skip-waf --not-string="Keine Suchergebnisse" --technique="BUSTQ" --proxy=http://127.0.0.1:8080

request_3_anonymized.txt
sqlmap-log_anonymized.txt

Tested together with @JoalpaLe

[stamparm]

At first glance, problem appears to be in url-encoding of : inside the page response (which is perfectly by the book), while sqlmap expects it in non-encoded form. My fault as I haven't included such scenario in my head. Will patch