SQLMAP - Post JSON data as body - sql

Hi I'm trying to do a SQL injection in a login form.
With BurpSuite I intercept the request:
POST /xxxx/web/Login HTTP/1.1
Host: 10.0.0.70:42020
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: application/json, text/plain, */*
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/json
Referer: http://xxxxxx.com/xxxxxx/
Content-Length: 44
origin: http://xxxxx.com
Connection: close
{"username”:"user",”password”:"pass"}
using:
sqlmap -u requestFile
(where requestFile is the content of the request intercepted with Burp)
sqlmap can't find the injectable field that is password.
I'm sure that's it's injectable cause if as password I input:
' OR 1=1; -- -
I can login with every username I insert
Tried also with:
{"username”:*,”password”:*}
but no luck.
What I'm doing wrong?

Example:
POST / HTTP/1.1
Host: www.example.com
{"username":"*", "password":"*"}
Saved as sqlrequest.txt
Can then initiate a test using this command:
py sqlmap.py -r sqlrequest.txt --level=5 risk=3 --force-ssl
You should then receive a prompt that a custom injection marker is found and that JSON data found in POST body. Process both and then you are good to go.
Sources:
https://security.stackexchange.com/a/150506/67046
https://security.stackexchange.com/a/51862/67046

sqlmap -u URL
sqlmap -r requestFile
Tutorial on how to use request
check this video

Related

Unable to successfully use hydra, http-post-form with Cookie value

I am doing some CTF and stumbled upon a problem with Hydra when trying to use it towards a post request.
I allready know how to solve this, but I am having truble with Hydra.
Intecepted from burp
POST /administrator/index.php HTTP/1.1
Host: 10.10.10.126
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.10.10.126/administrator/index.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 109
Connection: close
Cookie: eaa83fe8b963ab08ce9ab7d4a798de05=0mvnlo2q2792fi1rortceo4or3; 2b01af51830ca9615359108de04d9ca1=bpsnvqrm2mf6hc5akvnr8ftdu1
Upgrade-Insecure-Requests: 1
username=admin&passwd=test&option=com_login&task=login&return=aW5kZXgucGhw&71800a4b802098aac7f3bbd7e49a8665=1
I've been googling a lot and tried several different things without success.
What I did was the following:
hydra -l jonah -P test.txt 10.10.10.126 http-post-form "/administrator/index.php:username=^USER^&passwd=^PASS^&option=com_login&task=login&return=aW5kZXgucGhw&97f7e29809c1606df34ec3df81b10860=1:S=Warning:H=Cookie: eaa83fe8b963ab08ce9ab7d4a798de05=0mvnlo2q2792fi1rortceo4or3; 2b01af51830ca9615359108de04d9ca1=bpsnvqrm2mf6hc5akvnr8ftdu1"
-j is the correct username and
-P test.txt contains the correct password
Could someone tell me what is wrong with my request, and why it doesnt succeed?
There is a bug with version 9.1 of hydra and it won't send a request if you give it a cookie. 9.1 is the version that is packaged with kali still, so you need to upgrade your hydra and it should fix the issue.
Try using like this and replace <IncoorectVerbiage> with something like "invalid password".
hydra -l jonah -P test.txt 10.10.10.126 http-post-form "/administrator/index.php:username=^USER^&passwd=^PASS^&option=com_login&task=login&return=aW5kZXgucGhw&97f7e29809c1606df34ec3df81b10860=1:<IncorrectVerbiage>"

How Shockwave player generates HTTP POST request?

I am intercepting HTTP request/response from an Adobe Shockwave-based web music player application using Chrome Dev tools. When I click the Play button on music player, HTTP request headers like following are raised:
POST /some_url HTTP/1.1
Host: something.com
Connection: keep-alive
Content-Length: 103
Origin: http://something.com
X-Requested-With: ShockwaveFlash/22
User-Agent: Mozilla
Content-Type: application/x-www-form-urlencoded
Accept: */*
Referer: http://something.com/player.swf
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
And Form data looks like following:
param1=561a0d9452069h76fhg46h67a599e8gy34nlj=
param2=something
Now, is there any way to know from where this param1=561a0d9452069h76fhg46h67a599e8gy34nlj= form data came from and how it is generated? If it's some kind of encrypted string or a token, how this is done?
Thank you for your answers
The HTTP request would have come from a URLRequest in ActionScript, which passes the data in key/value pairs. You could have a look at using SWFWire Inspector to decompile the code.

POST data not sent in IE 11 using the WebBrowser control

I have the following JavaScript code being executed inside of an onclick event handler on my website.
var newRequest = new window.XMLHttpRequest();
newRequest.open('POST', '/index.cfm', true);
newRequest.send('q');
If I use IE 11 and open up my web page that is located on a testing server I can see that the request gets sent as expected using Fiddler with a content length of 1 and 'q' in the post data. However, if I open up my application that hosts the WebBrowser control and navigate to the same website on my test server and have it execute the above code I can always see that the request is being made but that the Content-Length header is 0 and 'q' is not sent along with the request. Here is the failing request as it appears in Fiddler.
POST http://test.mycompany.com/index.cfm HTTP/1.1
Accept: */*
Referer: http://test.mycompany.com/Curtis/BrowserTests/BrowserEventTests.html
Accept-Language: en-US
Content-Type: text/plain;charset=UTF-8
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: test.mycompany.com
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
If I then set the HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION registry value for my executable to 9000 then it works and does send the post data as expected.
Here is the correct request as reported by Fiddler.
POST http://test.mycompany.com/index.cfm HTTP/1.1
Accept: */*
Referer: http://test.mycompany.com/Curtis/BrowserTests/BrowserEventTests.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: test.mycompany.com
Content-Length: 1
Connection: Keep-Alive
Pragma: no-cache
q
If I change that value back to 10000 or 11000 then it does not work. Does anyone have any ideas on why the post data would not be sent properly using the WebBrowser control? I have reset my IE settings back to factory default with no change in behavior.
Update: If I change the JavaScript to look like this instead then it works with the emulation mode set to 10000.
var newRequest = new ActiveXObject("Msxml2.XMLHTTP");
newRequest.open('POST', '/index.cfm', true);
newRequest.send('q');
Is this just a bug that needs to be reported?

Get the actual HTTP request message that NSURLConnection generates?

Is there a way to get the actual HTTP request message NSURLConnection generates? I've used "tcpdump" (Unix util) to figure it out, but was wondering if there is a way to get it programmatically?
For example, the URL string http://www.example.com/somepath/resource?v=99 will apparently produce this if I use it in NSURLConnection:
GET /somepath/resource?v?99 HTTP/1.1
Host: www.example.com
User-Agent: {myprog}/1 CFNetwork/596.2.3 Darwin/12.2.0 (x86_64) (iMac11%2C1)
Accept: */*
Date: Wed, 19 Dec 2012 03:12:12 GMT+01:00
Accept-Language: sv-se
Accept-Encoding: gzip, deflate
Cookie: {long-string}
Connection: keep-alive
Some of these HTTP headers can be set to other values using setValue:forHTTPHeaderField: on the NSURLRequest (e.g. "Host" and "User-Agent") but some can't (like "Connection").
[request allHTTPHeaderFields] sends an dictionary with keys and values only which yo have set ....
If you want to see the entire request , you can use the following tool...
http://blog.jerodsanto.net/2009/06/sniff-your-iphones-network-traffic/
I shows the request and response ...

User authentication with XMLHttpRequest works in IE, not in Chrome?

The following function works in IE but not in Chrome:
function doStuff() {
var request = new XMLHttpRequest();
request.open("POST", "http://twitter.com/statuses/update.json", true, "USERNAME-HERE", "PASSWORD-HERE");
request.send("status=STATUS UPDATE HERE");
}
Chrome generates the following request. Note the Authorization header is missing:
OPTIONS /statuses/update.json HTTP/1.1
Host: twitter.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.78 Safari/532.5
Access-Control-Request-Method: POST
Origin: file://
Access-Control-Request-Headers: Content-Type
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
I get the following response (http 401):
HTTP/1.1 401 Unauthorized
Date: Wed, 03 Feb 2010 00:39:33 GMT
Server: hi
Status: 401 Unauthorized
WWW-Authenticate: Basic realm="Twitter API"
X-Runtime: 0.00107
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache, max-age=300
Set-Cookie: _twitter_sess=BAh7BzoHaWQiJTUxMTc2Nzk4N2U0YzMzZmU0ZTQyNzI4NjQyYjI3ODE2Igpm%250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG%250AOgpAdXNlZHsA--bb61324c3ba12c3cd1794b3895a906a69c154edd; domain=.twitter.com; path=/
Expires: Wed, 03 Feb 2010 00:44:33 GMT
Vary: Accept-Encoding
Content-Length: 73
Connection: close
{"request":"/statuses/update.json","error":"Could not authenticate you."}
So, how am I supposed to pass a username and password to XHR? Webkit/Safari documentation says the open method should take these parameters, so I'm not sure why it is failing.
The solution was that I needed to add
request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
The way I'm doing this is... special... so this may not be of much use to others going forward. But once I added this webkit started adding Authorization.
From the look of it, you're trying to do an X-Domain XMLHTTPRequest, which is why Chrome sends the OPTIONS pre-flight request. Because the Twitter server doesn't respond to the OPTIONS request indicating that X-Domain access is okay, you get a failure here.
Your code would only work in IE in the Local Computer zone, or if you turn off x-domain-checking (very dangerous)
Have you tried:
request.setRequestHeader('Authorization', 'yourvalue');