I am currently doing a blackbox test on a web application for training purposes. It's a personal project.

In addition to my manual testing process, I used an automated scanner for detecting obvious vulnerabilities. While this tool only found some basic issues, it also detected a potential SQLi vulnerability which I did not notice before. I am able to reproduce the error using Burp, but I am still not able to extract database data manually. Because of that, I gave sqlmap a shot.

Before I come to my actual question, let me give you some details:

The vulnerability seems to exist in a login form. When the following sequence is POSTed to the form


a mysql error is returned:

Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given

I have narrowed the sequence down to the byte %c0. This urlencoded value leads to the warning. So far, I am not sure why exactly this value leads to the warning.

The sqlmap setup looks like this:

 sqlmap -u http://thehost/include/login.php --method POST --data "password=letmein&username=1%c0%00xa7%c0%a2" -p "username" --dbms=mysql

Which generates requests/payloads in the following form:

 [PAYLOAD] 1%c0%00xa7%c0%a2)).("(,)'(
 [TRAFFIC OUT] HTTP request [#3]:
 POST /include/login.php HTTP/1.1
 Host: thehost
 Content-type: application/x-www-form-urlencoded; charset=utf-8
 Accept: */*
 Content-length: 70
 Connection: close

What I would like to do/try is change the injection point within the POST data. Is this possible? I know it is possible to specify an injection point within a GET request. Additionally, does anybody have an idea why the injected %c0 byte messes up the query?


  • Do you mind sharing the relevant parts of the source code?
    – Arminius
    Commented Jan 2, 2017 at 12:57
  • Unfortunately I do not have access to the source code/mysql query (blackbox test). It's a training environment.
    – DucatiNerd
    Commented Jan 2, 2017 at 13:01
  • From some reading it seems '%c0%a2' is decoded into a bad sequence, I've not yet worked out exactly what it decodes to though. Commented Jan 2, 2017 at 14:56
  • So I think I worked it out to decode as \* but I might be completely wrong. Commented Jan 2, 2017 at 15:04
  • @djsmiley2k thanks for your input! I haven't figured it out either. The only idea I had so far was to check i18nqa.com/debug/utf8-debug.html which pointed me to the following codepoint/character combinations: U+00C0, 0xC0, %C3 %80
    – DucatiNerd
    Commented Jan 2, 2017 at 15:17

4 Answers 4


I don't know about the injection point, but 0xc0a2 is a another way to encode the " character using the UTF-8 character encoding. What happens here is that the page script incorrectly strips "dangerous" characters before converting the encoding. You can actually insert all restricted characters this way. Just split the 7-bit binary value of the ascii code in two and encode it like this: 1100000x 10xxxxxx


SQLmap works in a heuristic way, firstly it learns about difference about good and bad response from the application, then you have to introduce a real value for username parameter to get a good response, SQLmap will analyze the responses after that it will inject sql commands to detect a possible SQL Injection. Your SQLmap command must be something like this:

sqlmap -u http://thehost/include/login.php --data "password=letmein&username=this_is_a_real_username" -p "username" --dbms=mysql

The option --method POST is not neccesary, SQLmap knows it's a request POST when you use the option --data.

I hope this information helps you.

Good Luck.

  • Thanks for your suggestion. I have tried your approach before - the problem is that sqlmap does not detect an injectionpoint/does not detect an injection vulnerability. I am only able to trigger the mysql error using a sequence that contains %c0 (or maybe another encoded character that generates a conflict when used with the existing database query). I am still trying to figure out why/how the warning is returned to the user.
    – DucatiNerd
    Commented Jan 2, 2017 at 15:56
  • You could use the options --risk and --level, also you can use the option --tamper and specify different injection techniques for MySQL, for example: --tamper tamper/space2mysqldash.py,tamper/space2mysqlblank.py
    – hmrojas.p
    Commented Jan 2, 2017 at 17:15

Referring this post: https://stackoverflow.com/questions/2973202/mysqli-fetch-array-mysqli-fetch-assoc-mysqli-fetch-row-expects-parameter-1

I believe it's not problem with the injection, rather the passed parameters might not be giving out any result and the application is trying to read the false value returned due to empty results.

Hope this helps!


I run into this one quite often. I am not sure if it is exploitable.

It so happens that when you use mysql_real_escape_string() in your code (AND YOU SHOULD!) before passing the input to a database query, a certain encoding is used.

I believe in this case the %c0 is not escaped, causes the execute_query() to trow an error (returning false, instead of the expected row)

%c0 in UTF-8 (which the program uses) is "À" and that breaks the query as it has no value in UTF-8 and as a result a "\x00" is injected. Everything breaks then.. I have been trying to figure out a way to make this work to my advantage but so far, I have had no luck!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .