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.
Related
I have a WCF service which I make API requests to.
This API call returns a JSON response object and also is able to return it in GZIP compression as well when "gzip" value is used in "Accept-Encoding" header.
The problem is when I try to get the response in GZIP, Postman shows "Could not get any response" although I see response and response's content are OK (200 status code) in Fiddler and can easily decompress the response content in my C# client.
I took a look in Postman Console but all I see is "Error: incorrect header check".
I hardly tried to find any documentation regarding this header check but couldn't find any.
These are the request headers:
POST /correction/v1/document?lang=US HTTP/1.1
Content-Type: text/plain
Accept-Encoding: gzip
User-Agent: PostmanRuntime/7.6.0
Accept: */*
content-length: 630
Connection: close
These are the response headers:
HTTP/1.1 200 OK
Content-Length: 512
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Server: Microsoft-HTTPAPI/2.0
Date: Sun, 24 Feb 2019 14:05:50 GMT
Connection: close
The only thing I suspect is wrong is this message from Fiddler:
I integrated this code into mine in order to use GZIP in WCF.
https://github.com/carlosfigueira/WCFSamples/tree/master/MessageEncoder/GZipEncoderAndAutoFormatSelection
Basically, it captures the response before returning to client and use GZipStream for compression.
I got the same issue, I added the following header to fix this issue.
Accept-Encoding : *
I was able to solve a similar issue by using the header Accept-Encoding: */* or if you want to be specific do Accept-Encoding: */* that way the HTTP client will be able to process the response based on the type of encoding received, in the case of a gzip, it will decode the response and show it as normal text.
For me, I removed 'Accept-Encoding' in the request header.
I got this issue when the REST service was returning a zip content (aka. WinZip format). I solved the error by compressing the data using 7zip to produce true gzip format.
What is a common approach in authenticating of user session for websocket connection?
As I understand websocket message contains data only with no headers. Thus authorization cookie is not available to server backend. How should application distinguish messages from different clients?
Which websocket server are you using?
if your webserver and websocketserver are the same, you could send the sessionid via websocket and force-disconnect any client that does not send a valid sessionid in his first message.
if your websocketserver parses the HTTP headers sent in the HTTP upgrade request properly, it may also save any cookie. this is what a request of my firefox (version 35) looks like:
GET /whiteboard HTTP/1.1
Host: *:*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Sec-WebSocket-Version: 13
Origin: *
Sec-WebSocket-Protocol: whiteboard
Sec-WebSocket-Key: iGPS0jjbNiGAYrIyC/YCzw==
Cookie: PHPSESSID=9fli75enklqmv1a30hbdmg1461
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
as you see, the phpsessionid is transmitted fine. check the documentation of your websocketserver if it parses the HTTP headers. remember that cookies will not be sent if the websocket's domain differs from the webserver's domain.
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?
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 ...
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');