Browser sending "Dalvik" as user agent

Question

Android Browsers is sending Dalvik as the user agents in the request headers.

I am currently working on a mobile site having a simple login page that validates username and password then authorizes users profile.

But when i checked the request headers i saw something unusual, there were two user agents from the same device.

Following are the user-agents from the same device:

"Mozilla/5.0 (Linux; Android 4.1.2; C5303 Build/12.0.A.1.257) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.114 Mobile Safari/537.36"

"Dalvik/1.6.0 (Linux; U; Android 4.2.2; C2004 Build/15.2.A.2.5)"

Even something strange the cookies that were initialed we either reset or dropped.

Is there any way i can debug this further for more information and get a better view on this issue??

This issue is not seen in old android phones or ios or windows phones.

**Issue noticed in high end android mobile handsets having KitKat/JellyBean OS

Elledge

Sounds like something is pulling the VM version info out of System.getProperty(). No idea why it would send it to a web server, or would claim to have Android 4.2.2 if it's running KitKat. – Dolly

Yes its strange and we are still not found any solution to this???? – Elledge

I also noticed one strange behavior when i enable McAfee antivirus on it send this header but when i disable it it ,doesn't this is just an assumption but not entirely true...!!! @Dolly – Elledge

Very strange but when we disable McAfee it works, i am not sure how does this happen.....! – Elledge

Are you sure both are normal web requests? If some are calls invoked from javascript they might use a different http engine (version) than the browser itself. – Moscow

I see these ID's on multiple (~80) simultaneous gets to streaming (8000) servers, mostly from Phillipines and China eyeball networks, so IPs change. They seem to be a lightweight DDoS attack, and the client runs out of bandwidth long before the server does. They're only annoying for now, but I've seen them with rapidly increasing frequency in the last six months. – Decoct

Answer 1

I just noticed a similar pattern of User-agents for back to back requests. In my case, the first request (with the Mozilla User agent) was from an embedded webview. The requested URL was to download a PDF file. What I've found is that the Android webview cannot handle the PDF content type, so it launches a PDF viewer through an intent. However, before this viewer is launched Android makes a second request for the same URL. In the second request, the Dalvik user agent is presented.

The two request strangeness has been discuss before, see Is setDownloadListener onDownloadStart called after the webview already Gets the file? and WebView - can't download file without requesting it twice?.

In my first request, from the webview, I see the user agent:

Mozilla/5.0 (Linux; U; Android 4.2.2; en-us; Galaxy Nexus Build/JDQ39) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

The second request (which I assume is from the Android OS, and not the webview) shows the user agent:

Dalvik/1.6.0 (Linux; U; Android 4.2.2; Galaxy Nexus Build/JDQ39)

Alverson

Answer 2

• Dalvik is the Android VM in which individual apps run.
• What you're seeing is the request header from a browser running in Android (which runs within Dalvik).
• Hence the two UA (User Agent) strings, one for the browser, one for the VM in which it's running.

Optimal

Michael Levy, above, explains correctly that when an application passes an intent to another and a file needs downloaded, this UA is triggered. One browser request does not equal two HTTP requests on Android. – Frontage

Answer 3

I've been seeing a rapidly increasing incidence of simultaneous GET requests with this profile on streaming servers in the past 6 months, but going back a few years with much lesser volume. It was easy to ignore them at first. The client pumps many simultaneous requests (I see 60-80 typically), and then it appears the client runs out of bandwidth; requests stall, subside, and then re-emerge. This goes on for several minutes. If multiple attacks of this sort were launched from different IPs on different Eyeball networks, it would start to qualify as a DDoS attack in my book.

Because the sources are on eyeball networks with ever changing IP's (over time, but not during an attack), using IP blocking is of limited effectiveness, and blocks need to be aged-out so they don't affect legitimate users.

Your observation that cookies are not observed in any way would seem to lend weight to the possibility that these are malicious requests.

In conclusion, to answer your question simply, yes, you can block these requests, especially since you have evidence that these may be malicious requests (that have been rising steadily since your post in my experience). You may, of course, be blocking legitimate requests. That's your call. You'll also have to deal with how to block them, since in my experience they originate mostly from DHCP leased addresses on eyeball networks.

See also: Can I safely block Dalvik browser agent requests?

Decoct