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.");
}
Related
For some business we have to check the request headers if is's Referer is original of some domain.
But we found there is no Referer in headers from video request by Android browser.
GET foo/bar/biz.mp4
HTTP/1.0
MAX-UDP-PORT: 65535
MTK-RTSP-CACHE-SIZE: 4
User-Agent: stagefright/1.2 (Linux;Android 5.1)
MTK-HTTP-CACHE-SIZE: 10
allow-cross-domain-redirect: false
MIN-UDP-PORT: 1024
Host: example.com
Connection: Keep-Alive
Accept-Encoding: gzip
How can I do to make headers contain Referer?
add to <head> of your page
<meta name="referrer" content="always">
http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html
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 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.
This is my fiddler report of a post request from my browser ! I can see the post data ! The question is how to add this data if i make the post request from java e.g say using httpPost method. My question is what to write at httpPost.addheader("","");
POST http://reactomews.oicr.on.ca:8080/ReactomeRESTfulAPI/RESTfulWS/queryHitPathways HTTP/1.1
Host: reactomews.oicr.on.ca:8080
Connection: keep-alive
Content-Length: 41
Accept: application/json
Origin: http://reactomews.oicr.on.ca:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Content-type: text/plain
Referer:http://reactomews.oicr.on.ca:8080/ReactomeRESTfulAPI/ReactomeRESTFulAPI.html
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
PPP2R1A,CEP192,AKAP9,CENPJ,CEP290,DYNC1H1 // this sequence of data I have to add in my post request from java
For android I use Loopj - Android-asyc-http for REST requests and it's POST is EXTREMELY easy to use! Give it a try and let me know if it worked for you!
Hope it helped! :)
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>