Ghostly AJAX Requests
Sam Goldstein, a member of the New Relic Browser team, runs Earthquake Track. You can see all of the AJAX requests made by browsers while visiting his site in this section of the New Relic Browser AJAX dashboard:
When Sam saw these requests he was very perplexed, because his app doesn’t make any AJAX requests. Where are these requests coming from? If you search for some of the listed domains, you’ll find that many of them are, or are suspected of, being malware-related. Our best guess is that these AJAX requests are made by malware extensions in the visiting users’ browsers.
You may notice as well that the throughput in requests per minute (rpm) is very small — much smaller than the number of pages served per minute for the site. This tells us that it affects a small percentage of the site’s end users, which also fits our malware browser extension theory.
To be clear, our suspicion of browser extension malware AJAX requests does not mean that the site is hosting malware; instead, this only means that some browsers that visited the site had malware installed.
AJAX request to http://localhost:0
AJAX requests work over TCP at the networking level: TCP sends data to IP addresses and then to specific ports. For example, HTTP traffic usually goes to port 80, and HTTPS traffic usually goes to port 443. While developing the AJAX requests feature, we found some requests were sent to localhost port 0. That’s a rather odd place to send a request to, because not only is the browser sending a request to the computer it is running on, it is sending it to port 0, which is a reserved TCP port. However, at the time we didn’t have a way to figure out what was causing the traffic.
During our closed beta period, a customer reported that when some users visited their site using Chrome for iPhone or Chrome for iPad, they were getting the following screen:
We were able to reproduce the issue by clearing all cached data and visiting a page instrumented with New Relic Browser as though we were visiting for the first time. From there we were able to narrow down to the root cause: Chrome was making AJAX requests to http://localhost:0/chromecheckurl, and this request was failing somehow. It also means we found the source of those AJAX requests to localhost port 0!
It turns out that as part of a workaround for having to build Chrome for iOS on top of the built-in iOS WebKit engine, the browser needs to use some tricks, such as using AJAX to hit a local HTTP endpoint, to do things like URL verification. Our instrumentation was somehow triggering a bug that caused Chrome for iOS to believe that valid URLs were bad. For now, we have disabled AJAX timing for Chrome for iOS, but we plan to bring it back soon with workarounds for this issue.
‘a.highchartsObject’ é nulo ou não é um objeto
To infinity, and beyond!
These are just a few of the interesting things we have found through the development of New Relic Browser. Inserting ourselves into the inner-workings of the browser environment has yielded many unintended insights, and we expect to find even more with the features we plan to add soon. Stay tuned!