We Keep Coding

burpsuite intruder and hashed passwords

In order to learn how to use Burpsuite, I am trying to use it to hack into the management gui on an IP camera of mine. Access credentials are currently admin/admin. From Burpsuite's proxy I select the following POST command for an intruder attack:
POST /login/ HTTP/1.1
Host: 10.XXX.XXX.173
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.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.XXX.XXX.173/
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
username=admin&password=admin
When I run a sniper attack using a list of passwords, including admin, all the tries come back with the exact same 200 success response/message. Investigating further, I see that after each attack and response message, there is a subsequent GET message from the browser that looks like this:
GET /login/?_=1551456400210&_username=admin&_login=true&_signature=§de6af126fa27f887c20ca2de02411aa913815d9b§ HTTP/1.1
Host: 10.XXX.XXX.173
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.XXX.XXX.173/
X-Requested-With: XMLHttpRequest
DNT: 1
Connection: close
And this generates a success response in the case of admin/admin and a failure response in other cases. So, it appears the camera is hashing the password and passing on the hash in the "signature" element of the GET command. If I use the GET command for the sniper attack and include the hashed value in the password list, the attack sees the hash of "admin" as being successful.
At this point, it appears that I need a two-part attack. Part one gets the hashes of the password list from the gui and part two tells me when a hash/password works to unlock the gui. Am I right? How do I do this in Burpsuite?

Can a browser make an HTTP request to itself?

It's easy enough to use AJAX from a browser to an external address, (i.e. external to the browser, even if it's localhost) but I have a different question.
Is there some kind of object or service that would allow a browser to make (or mock) an HTTP request to itself, e.g. from JavaScript?
E.g. from Firefox I can see the following raw request:
GET /headers.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
And by using a PHP script (the aforementioned headers.php in the GET request):
<pre>
<?php
print_r(apache_request_headers ());
I can see the following on the page:
[Content-Type] =>
[Content-Length] => 0
[Upgrade-Insecure-Requests] => 1
[User-Agent] => Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
[Host] => localhost
[Accept-Language] => en-GB,en;q=0.5
[Accept-Encoding] => gzip, deflate
[Accept] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
[Connection] => keep-alive
[Cache-Control] => max-age=0
Can I get the same information via JavaScript, without making a call to a server script?

You can request either a Blob URL or a data URI see Does Stack Overflow have an "echo page" to test AJAX requests, inside a code snippet?, or use ServiceWorker to serve a specific Response Chrome extension: Block page items before access. An empty string passed to either XMLHttpRequest.open() or fetch() requests the current URL.

Post request looks like 2 different requests on ESP8266. Is this a Chrome bug?

I am setting up a server on ESP8266 WiFi module. Basic operation is, you request a URL. ESP serves that page. It has a form. You fill it in and click submit, and the browser sends POST request by AJAX. I am not using jQuery, just js. From Chrome dev-tools, it looks like all is well.
But on the ESP Server side, I noticed I am missing post data once in a while. After digging deep, I found this issue.
Ideal result from Chrome on my windows: And this works correctly. Post data comes in as expected.
+IPD,0,507:POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 63
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=tgfgfdgfdtrd&auth=4
But on my Mac Chrome, I see the following result.
+IPD,0,472:POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 63
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
DNT: 1
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,ml;q=0.6
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
+IPD,0,63:ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=asdfasdfasdf&auth=4
And I can repeat this. The only different in each case is I am using Chrome on Windows as opposed to Chrome on Mac. To double check, I downloaded Chrome canary version and tried. The first request worked fine. From second request onwards, it shows this problem. Why is this happening? Any ideas? May be my laptop has issues? :)
Here are Chrome dev-tools info from Chrome on Mac (the one with the problem)
**Request Headers:**
POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 61
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
DNT: 1
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,ml;q=0.6
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
**Request Payload**
ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=asdfasdfoi&auth=4

+IPD is the AT command that says data was received from the network. +IPD,0,63: is saying to receive 63 bytes from connection 0. That matches with your Content-Length header. Notice that it also appears at the beginning of the header portion of the request.
Your WiFi library on the ESP side is throwing that in. Here and on line 281 is the source code where it might be happening. There are a couple variables that affect whether or not the +IPD is added, maybe you have set or inadvertently changed one.

Satellizer not pass Authenication header to my API

So I am currently working locally, I have an API (Laravel). Everything is working great, I can login using Facebook, I get a JWT from my API and that is saved in local storage, however, after being logged and API calls do contain the 'Authorization: Bearer + token' header.
From what I understand in the docs, this should be all set up and ready to go without and config in the app side of things?
Here is my code:
app.js
$authProvider.tokenPrefix = '';
// Facebook
$authProvider.facebook({
clientId: '219883618025157',
url: APICONFIG.url + APICONFIG.version + 'auth/facebook/callback'
});
Example API Call:
$http.get(APICONFIG.url + APICONFIG.version + 'auth/logout').then(function(response) {}, function(error) {});
The request headers in the above request:
GET /v1/auth/logout HTTP/1.1
Host: api.myapp.app
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json, text/plain, */*
Origin: http://myapp.app
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36
Referer: http://myapp.app/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Any ideas what is going on here?

Ok so this was my silly mistake, I was essentially logging the user out of my AngularJS application (removing the token) and then POSTing to my API which off course wouldn't contain the token as it was being unset before my call.

IE 9 Ajax Request posts null values to MVC App

I have an application posting to an asp.net MVC webservice via Ajax.
This seems to work like a champ in all browsers except IE 9. What could be causing this?
The javascript
console.log(data);
$.ajax
({
type: 'POST',
url: '//localhost:65201/User/CreateAsynch',
data: data,
cache: false,
success: function (response) {
// Do stuff
},
error: function (xhr, msg) {
// Do stuff
}});
The Controller
This is what happens when I post in IE vs other browsers (Chrome, in this example)
See how some of the values are populating?
Then there's IE9
Here's what the requests look like (from fiddler)
Chrome
POST http://localhost:65201/User/CreateAsynch HTTP/1.1
Host: localhost:65201
Connection: keep-alive
Content-Length: 184
Accept: */*
Origin: http://localhost:56076
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://localhost:56076/retail/registrationform/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Username=drew.j.wyatt%40gmail.com&FirstName=Drew&LastName=Wyatt&Email=drew.j.wyatt%40gmail.com&RawPassword=boom&RawConfirmPassword=boom&CountryCode=USA&UserTypeID=2&RegisterForStore=31
IE9
POST http://localhost:65201/User/CreateAsynch HTTP/1.1
Accept: */*
Origin: http://localhost:56076
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost:65201
Content-Length: 184
DNT: 1
Connection: Keep-Alive
Pragma: no-cache
Username=drew.j.wyatt%40gmail.com&FirstName=Drew&LastName=Wyatt&Email=drew.j.wyatt%40gmail.com&RawPassword=boom&RawConfirmPassword=boom&CountryCode=USA&UserTypeID=2&RegisterForStore=31
What am I missing?