I launched burp as an emulator's proxy for debugging of http requests from my application with intercepting option switched on and at the startup I found that emulator sends a GET request to google:
GET /generate_204 HTTP/1.1
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.3; sdk Build/JWR66V)
Host: 173.194.32.129
Connection: Keep-Alive
Accept-Encoding: gzip
And gets a response like:
HTTP/1.1 204 No Content
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Thu, 05 Sep 2013 06:56:51 GMT
Server: GFE/2.0
So I would like to know if there is some purpose for making this request to google at the startup?
It's most likely for counting things:
active developers
emulator use
framework use
generating statistics how developers are spread over the world
...
It's Android trying to tell if the Wifi (or other network connection) connection has internet. I'm testing on real devices and it does the same thing. If you don't forward the message the connection status in Android Wifi Setting will say "Connected. No internet" until you forward and it gets a success back.
Related
I am trying to connect to a WebSocket server that my Android device connects to from an app. I captured the packets on my Android device, and the initial request headers look like this:
GET / HTTP/1.1
Pragma: no-cache
Cache-Control: no-cache
Host: example.com:80
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ysWaBflPV9EmRaB1JpPMOQ==
Origin: http://example.com:80
Sec-WebSocket-Protocol: default-protocol
Sec-WebSocket-Extensions:
Sec-WebSocket-Version: 13
The response from the server looks like this:
HTTP/1.1 101 Switching Protocols
Date: Wed, 31 Jan 2018 02:37:20 GMT
Connection: upgrade
Set-Cookie: AWSALB=0yaRd5HOPlZSITp+bcXoZoIn/7YOOqE9o4/t/8b3kw2PTxooflm/85w+1JfudEE0Cwb1BUkWPV+t4kOnEm4FbLSWwMMFp8URbblZKj0a0kd0xB+glbLBHWxc/TPW; Expires=Wed, 07 Feb 2018 02:37:20 GMT; Path=/
Server: nginx/1.12.1
Upgrade: websocket
Sec-WebSocket-Accept: bj5wLF8vmyDrA7pqEgbHKbxqQSU=
Then, some communication begins, with lots of unrecognizable characters and some clear words in the messages. I don't have much experience with WebSockets, but I assume it is some form of compression.
I was able to send an identical request to this server using the ws module in Node.js, and I got an identical response to the one above. One notable difference was that when I set the protocol header to default-protocol, I received an error saying "Server sent no subprotocol". Without using this header, I still got the same response.
After the initial response, however, I did not receive any more messages, even though I did on my Android device. After about 30 seconds, the connection closes with code 1006 and no further information.
I tested the same request with curl and received the same headers back, but it also closed after about 30 seconds saying:
"Empty reply from server"
So my main question is obviously: What is going wrong, and how can I fix it?
More specifically, I am wondering if anyone with WebSocket experience knows if it is a problem with my client, or with the server itself.
It is possible that the server is authenticating me in some way on my Android device, but the headers that I captured are not revealing anything about that. Is it ever customary to authenticate a connection with a later message in the client-server communications? Is it possible that a separate HTTP request is authenticating me for this WebSocket server? All of these things seem unlikely to me since I found no other packets with anything related to auth requests. It seems much more likely that there is something wrong with the messages being sent.
Background:
I am experiencing a very confusing behaviour with android Webviews in API 21 and up when testing in real devices.
I have a local HTML5 application (inside assets folder) with the following functionality
Login (2 steps authentication).
Show a list of items depending on the authentication.
The problem:
After doing the login requests, the server returns a cookie with the session. This cookie is not stored in the Webview when using real devices with API 21 or up. If I use emulators (Genymotion in this case), the cookies are properly stored.
More information:
The request to do the auth has the following headers:
POST http://myServer/j_spring_security_check HTTP/1.1
Proxy-Connection: keep-alive
Content-Length: 101
access-control-allow-origin: *
accept: application/json
access-control-allow-credentials: true
User-Agent: Framework/1.5.0 (Linux; U; Android 6.0.1; Nexus 5X Build/MMB29Q) App/0.1.1
Origin: file://
content-type: application/x-www-form-urlencoded
Accept-Language: en-US
X-Requested-With: app.package
Host: myServer
With the following response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=4D169E8656DBEDFFA4D17FE8D436A5BA; Expires=Fri, 19-Feb-2016 14:27:55 GMT; Path=/; HttpOnly
Content-Type: application/json;charset=UTF-8
Content-Length: 43
Date: Fri, 19 Feb 2016 14:17:55 GMT
The cookie is not stored in devices with API 21 or more. Same request/response works fine in the rest of devices + all the emulators
Clarification:
This flags are enabled inside the app:
android.webkit.CookieManager.setAcceptFileSchemeCookies(true);
(Before CookieManager or webview is instantiated, as documentation says)
if(VERSION.SDK_INT >= 21) {
CookieManager.getInstance().setAcceptThirdPartyCookies(this.nativeWebView, true);
}
If after doing the authentication, I access the cookies datastore and
check the "hasCookies" method, I get false.
The two step auth service actually calls 3 different paths from the same endpoints. None of the cookies that the response that generate this services are stored. I don't know if this is relevant or not.
When doing simple authentication (to a different server), cookies are stored properly in all the devices emulators.
I am using Angular 1.5
I am aware that the service is using http instead of https. That will be solved in the future.
I get no error message in the consoles.
Questions:
Is there any internal security measure in the webviews that blocks the storage of the cookies? Why does it work on emulators (that are rooted devices) and not in real devices? This really bugs me.
If the network request is done using window.fetch you may need to add:
fetch('/something', { credentials: 'same-origin' }) // or 'include'
On chromium, window.fetch has the credentials flag set by default to 'omit' and no cookies are stored into the cookie storage. More details of this bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=477523
I have a project where I'm controlling an Arduino at my house using an Android app through WAN. I'm using MIT's App Inventor to design the app and with that I'm using a HTTP PUT/POST (I've tried both) to send the string of information "helloThere" to the Arduino. Everything has been fine while broadcasting directly to my IP address and port number. This is the Arduino output (I've obfusticated my IP and port):
PUT / HTTP/1.1
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.4.4; GT-I9305 Build/KTU84P)
Host: xx.xx.xx.xx:xxxx
Connection: Keep-Alive
Accept-Encoding: gzip
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
helloThere
The problem arises when I use a DDNS (no-ip) to refer to my IP address (As it is dynamic). For some reason the PUT/POST request does not get carried out when getting relayed through this. The output from the Arduino is shown below when using the DDNS:
GET / HTTP/1.1
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.4.4; GT-I9305 Build/KTU84P)
Host: xx.xxx.xx.xx:xxxx
Connection: Keep-Alive
Accept-Encoding: gzip
Somehow it is changing to a GET request instead of a PUT/POST, but it is still contacting the device. I'll be honest, I'm not a web guy so I'm pretty confused by this, is a DDNS not supposed to relay whatever you send to it? I've had a look around and can't find anything on this, any help or explanation would be appreciated.
EDIT: After doing a lot of further research I have figured out that a DDNS server actually returns the IP address of the desired hostname when queried. Does anyone have any idea what address and port that no ip use to do this? I am aware that windows uses an "NSLOOKUP" to perform this, but I have no idea how this is achieved on an arduino. It could be over UDP or HTTP. Again, any help from someone who has experience in this area would be appreciated.
Alright, finally solved the issue for those of you that are interested. Here's the Arduino code to retrieve the ip:
char server1[] = "xxxxxxxxxxxx.ddns.net"; //server to ping to get external
ip address
if (currentMillis - previousMillis >= interval) {
previousMillis = currentMillis;
if (client1.connect(server1, 80)) { // if you get a connection output to
serial:
Serial.println("connected");
client1.println("GET / HTTP/1.0"); //Make a HTTP request:
client1.println("Host: xxxxxxxxxxxx.ddns.net");
client1.println("Connection: close");
client1.println();
delay(1200);
}
while (client1.available()) { //loop to read html from external server and
take ip from it
char c = client1.read();
HTTPArray [counter] = c; // copy all the data from the buffer into an
array
counter++;
}
This is driving me nuts. I want to offer an .apk file for download. All browsers I've tested will download my file without any problem. Except for the built-in browser in android. For some strange reason it will repeat the request for the resource. Using BurpSuite I've discovered that the apk file is transferred flawlessly. I proxy the file, but I send the headers right away, using curl I could confirm the headers are sent and the content starts being transmitted in the following. I've compared my headers with the headers sent by threema.ch which works flawlessly.
These headers are sent by my application:
HTTP/1.1 200 OK
Date: Sat, 16 Aug 2014 16:41:01 GMT
Server: Apache/2.4.7
Content-Disposition: attachment; filename="test.apk"
Content-Type: application/vnd.android.package-archive
Transfer-Encoding: Chunked
These headers are sent by Threema:
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 16 Aug 2014 17:49:10 GMT
Content-Type: application/vnd.android.package-archive
Content-Length: 14146751
Connection: keep-alive
Content-Disposition: attachment; filename="Threema-1.63.apk"
Strict-Transport-Security: max-age=31536000; includeSubdomains
I've first loaded the file through an iframe. Currently I'm redirecting the browser to the download using HTTP redirect. I offer the file from a different subdomain. But I also tried delivering the file from the same domain and using a html link.
These are the headers sent by the client. First:
GET /download/download/NlnMhaeXmcjSosfqRTcG8YdxQgQGSxTWQeE10-GrH4U HTTP/1.1
Host: l.dl.test
Proxy-Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Linux; Android 4.4.4; Nexus 7 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Safari/537.36
Referer: http://l.google/device/deviceid/351cd7c24f637eb5?token=6Xf3nJIIMIa4toKrpTqgDGFjAKzeBBoaeduMmcIMeGY
Accept-Encoding: gzip,deflate
Accept-Language: de-DE,en-US;q=0.8
X-Requested-With: com.android.browser
And then (around 20s later):
GET /download/download/NlnMhaeXmcjSosfqRTcG8YdxQgQGSxTWQeE10-GrH4U HTTP/1.1
User-Agent: Mozilla/5.0 (Linux; Android 4.4.4; Nexus 7 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Safari/537.36
Referer:
cookie:
Accept-Encoding: identity
Host: l.dl.test
Connection: Keep-Alive
I'm generating a download id for one time use. The second Request will fail, because the id becomes invalid after the first request. The download works if I permit the second attempt to download the file.
Might it be that the android browser wants compressed content in the first attempt and if it gets identity content it will make a second attempt using Accept-Encoding identity? I also tried setting Content-Encoding: identity without luck.
Workaround:
The only way I've got this working without sending the .apk twice is using this very stupid (and properly error-prone) workaround:
header("Content-Disposition: attachment; filename=\"test.apk\"");
header('Content-Type: application/vnd.android.package-archive');
// Ugly workaround for bug in built-in android browser.
if (
isset($_SERVER['HTTP_X_REQUESTED_WITH'])
&& ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'com.android.browser')
&& isset($_SERVER['HTTP_ACCEPT_ENCODING'])
&& (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'identity') === FALSE)
) {
// The built-in android browser will make two requests for the apk
// file, one with Accept-Encoding gzip and deflate and one with
// Accept-Encoding identity. But it will only serve the second request
// with Accept encoding identity. So stop the first request.
// If the first request is shown, the workaround didn't work.
die ("Oh no! I'm sorry. The built-in android browser has a nasty bug."
. " It's hard to work around. If you see this the workaround failed."
. " Please try downloading with a different browser.");
}
We have a website that makes use of OAM for single sign on (form-based authentication). When we submit credentials to WebGate / Access Server the authorization succeeds, however after the authentication is performed, the form action (as configured in the Authentication Scheme - with passthrough:no) returns a server error instead of redirecting to the originally requested URL.
If we use Mini Opera, we are able to get authenticated and forwarded properly.
This problem happens on numerous Android phones (versions ranging from 1.5-2.2), as well as the Emulator provided with the SDK.
This is proving to be a real problem as the default browser on Android phones is not able to get access to our sites(and this is the only browser that is having this problem).
I have created a WebView-based custom browser with the hope of seeing a client-side error and tried trapping every possible error....none show up....
I have tried to trace all of the http requests and found only a single difference in the requests... the http header for Connection:keep-alive is not sent by the Android WebView.
I have provided some tracing info below...
Has anyone run into this problem? Has anyone solved this?
Any insight to this issue would be greatly appreciated.
Thanks,
Tim
Request RAW Data-
POST
http: // MYSERVER/security/ATLAFunction HTTP/1.1 Host: MYSERVER:7777
Accept-Encoding: gzip
Accept-Language: en-US
Cookie:ObSSOCookie=loggedoutcontinue
Accept-Charset: utf-8, iso-8859-1,utf-16, ;q=0.7
Referer:http://10.84.32.71:7777/tpf/login.html
User-Agent: Mozilla/5.0 (Linux; U; Android 2.2; en-us; sdk Build/FRF42) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Origin: http: // MYSERVER
Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/*;q=0.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
uname=auser&pwd=appas
Raw Response Data -
HTTP/1.1 503 Service Temporarily
Unavailable Date: Tue, 05 Oct
2010 14:26:12 GMT Set-Cookie:
ObSSOCookie=II%2F4n5pFreT6B6hOAumv6pI6CZh6l04VhyXHrCzuRUT5hDEHMK%2FJCX659uyCkxgIyJ8ywB3BKrHxorsCwZwivpn91t9Mu%2FCKT7PrY23S518xoBeOam26tr%2B0pSfCbo%2FZXLmFIxjHFOPHPGxi5tHrOlUroXXA9Fe0GZz3SbJLMgAkCw0euuAVewOHKIjoDh8MwAdGtL4lo%2BmHhk5kB316iFJ4Aljr7cQYpAp1r%2BVGD9FbLkYl4ekY5hrlNfwYS%2BVjnR0uSIFjc0toiKkGN33z7%2FiElh2Ue2iWQrpCRcgFpxE%3D;
httponly; path=/; Cache-Control:
no-cache Pragma: no-cache
Content-Length: 312 Connection:
close Content-Type: text/html;
charset=iso-8859-1
<!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>503 Service Temporarily
Unavailable</title>
</head><body>
<h1>Service Temporarily
Unavailable</h1>
<p>Sorry!The server is
currently unable to handle the
request due to a temporary
overloading or maintenance of the
server.</p>
</body></html>