I've noticed in the AWS console that our website got a lot of more requests than normally. Especially in the night hours (Europe time).
Then I've checked the nginx logs and now I know that a lot of devices with different IP addresses request the root of the website, most of them with the user agent swcd (unknown version) CFNetwork/978.0.7 Darwin/18.7.0. Sometimes one of the versions is different.
I have absolutely no idea what is going on so I hope that someone can help.
swcd runs on iOS and macOS devices and will periodically attempt to access /apple-app-site-association and /.well-known/apple-app-site-association. This is used for several features which mediate between an Apple native app and the web, including Shared Web Credentials, Handoff, and Universal Links.
This process will typically run overnight in the user's local time zone, but specific timing is not guaranteed.
See also Setting Up an App’s Associated Domains for more information on associated domains.
Hard to guess the cause of the spike without knowing more about your product - but some possible causes:
you recently released an update to your iOS or macOS app
a larger customer just signed up for your service or rolled out your product to more employees
a larger customer just deployed an iOS or macOS operating system update to their managed devices
Anyway, I would ignore the spike. If it's causing you trouble, ensure your load balancer is configured correctly.
Recently this same behavior was detected by our CDN and our WAF's, and what we detected here in some clients, was a botnet doing enumeration of users in a distributed way, there is even a name for it, user enumeration spraying.
Anyone who doesn't know how web attacks work would say this is normal.
Looks to me like someone with a botnet is trying to take advantage of the shared web credentials to compromise your site, doing it at night to try to avoid detection. Other evidence is the "a lot of devices with different IP addresses request the root of the website". If it was just a "viral" event, just certain classes of devices would show, rather than a wide diversity of devices. Accessing the root of the web-site -- these are devices that have never been to your site before. It's not a denial of service attack because they are doing it at night, therefore not denying anybody their service, and night is the natural time for break-ins.
I'm not a cracker myself, just an old-school developer, and I'm not even terribly familiar with ios, but I could not remain silent while there was a possibility that your web site was attacked without you at least suspecting and investigating. HTH.
Related
We looking to develop an "App" which would have the ability to record the details of a damaged car for assessors. The idea is that a small number of assessors would have company iPads. Then when car is damaged and returned to the car yard they can visit take photos, enter some details and then upload them into the main system later. Some of the car yards may be in areas that do not have internet coverage, so offline capability is required.
Our initial thoughts were to develop an IOS App for installation on a small number of company iPads. The App could access the camera to take photos and then when the device has internet access upload the photos to the main system. However this solution could prove too costly (regarding development costs) for the customer.
I have read about PWAs and caching data, but the caching seems to be for offline read access.
If we installed chrome on an iPad and then installed a PWA then presumably
The PWA could store pictures up to 128GB * 6% = 7.68GB?
If stored using the File System API then (as long as there is plenty
of space on the system) the data will be persisted (my understanding is there is no time limit)? Or would a different type of storage be more suitable.
The offline data is obviously important (may be required in court) so are there any other concerns around persistence & stability before the images are uploaded to the main system?
Note we would prefer to use iPads (as the customer would prefer these) but we could consider other platforms.
At this stage I am really trying to find out if a PWA accessing the offline storage is likely to be feasible, practical and stable on the platform?
Firstly, iOS restricts third party web browsers (or any app that displays web pages) to using its own engine - installing Chrome on an iPad will not enable access to any web APIs that iOS/Safari doesn't already support.
So in particular:
File System API is not available on iOS, even if you're using Chrome
Cache API has a storage limitation per website of 50MB
IndexedDB has a storage limitation per website of 500MB or half the device's free space (whichever is smaller)
PWAs and their cached data are automatically wiped from devices if not used for a few weeks
the "navigator.storage" API for requiring durable data is not support on iOS, even if you're using Chrome or Firefox.
My first thought would be that if you are only going to support iPads and indefinite offline storage is a requirement, you are probably best of with a native application. Keep in mind that for this kind of application you would need the Apple Enterprise Program, which is more expensive than the regular Developer Program.
However, if you do want to use a PWA, your best bet for local storage would be the IndexedDB. As per the comment by skybondsor, browsers do indeed limit and possibly evict data after a while, according to ADM webdocs.
But reading your question, I get the sense that you do not really need persistent local storage, but rather a method ensuring that your data will eventually end up on the server. You can accomplish this by exploiting the Background Sync methodology. This allows your application to delay the upload to when a stable internet connection is available.
Hello all I am developing a extension app which will fetch-
The people you contact the most.
Most frequently used apps.
Any body have idea, How can I get these things.
Thanks in advance.
This is not possible. Your app runs in a sandbox, which means that it is very limited in how it can interact with the rest of the operating system. This is to prevent security vulnerabilities from apps snooping on a user's behavior. For more information on this, and to see what you can and can't do in the sandbox, see https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html.
I work with web analytics and have somewhat of a web developer background, BUT I am not a programmer. I need a way to debug the tracking code I request our mobile app team to implement. They are also not Web Analysts so they struggle to be able to verify if it works too.
I need a way to take one of their builds, run it on a desktop environment, and monitor it with a network monitoring tool like Charles Proxy or the network monitoring tools in the developer tools of most browsers.
I want to at least be able to see the information being passed back to our analytics tracking tool via the network connection. That will tell me if what I requested works or not. If there are other tools that a non-programmer can use to achieve this and more I would be grateful to hear about them. The few tools I have seen seem to be more about testing web pages via a mobile device. I need to test apps that you will eventually download from the an app store.
Thanks!
In our company, we found that Charles is perfect for testing all that concerns tracking.
Charles will record all your requests and responses from your computer, SSL traffic included.
(You can also let physical Android/iOS devices use your desktop as a proxy to catch all traffic there, which is even more impressive and useful, but I understand that this is not what you want.)
You can even do fancy stuff like throttling your connection and adding breakpoints, to see what would happen in "real" situations with bad connection...
Hope this helps.
I recently came across an app in the app store called Dataman Pro. It has a feature that lets you see the data usage per app basis (see the attached screenshot). I have been wondering what is it doing to get this sort of information.
See this post about getting the list of installed apps, and this git project.
Then about usage tracking:
If you wondered about any public APIs that give you network statistics out of the box - there's nothing there.
DataMan it self is an app that used to work in the background all the time, and bind to the network interfaces to track network usage. Which is one of the reasons that its data is never 100% accurate as it is not guaranteed to always work in the background. This is also the reason Apple kicked it from the AppStore after a few versions...
Now that app has returned, if I understand correctly, after making a few changes: Mainly avoiding "hacks" to stay in background, and using Location Services to get back online when the user moves around. I guess this is another hack but one that Apple did not oppose to, yet.
Edit:
After looking around the web for a bit, it seems that Apple found that trick also, and removed many apps from the AppStore due to staying in the background by using location. I guess right now it's not working more than 10 minutes in the background, so you open it when you want to measure current Activity, and it stops measuring after 10 minutes.
About the tracking code itself, its mainly C code, using CFNetwork framework, and you can find some answers on stackoverflow on this subject.
More, in response to comment:
Well, the part about seeing the installed apps list, and foreground app, is not exactly private APIs, but private plist, as you mentioned.
Apps which access private files do get through from time to time. When Apple finds that some "private" files are accessed and need to be kept safer - they change it in an iOS update, like they did with the call history file, which is sensitive. Old apps tended to use (around iOS <= 3.3) the call history db to do some stats, and on iOS4 they were obsolete by the file moving to a secure location.
Reading "private" files which are unprotected is pretty easy to do without getting caught by automatic analyzers.
When you know which is the foreground app, and you can count current network usage, you can associate it with the app... And get an estimation. So this is how they do it, most likely.
However, The techniques change from time to time, due to Apple re-reviewing apps and their own policies, and due to API changes, and if you track the history of such apps and even this specific app - you will see that from time to time they get kicked off of the AppStore and return with a twist. They adjust... So no technique is reliable and this is a major headache to maintain, which is probably why the developer charges 9.99$ for it. I would.
I need to do a study of what apps are actually used among a group of test users taking part of an experiment. I would like to know the time each of the random 3rd party apps have been used to do statistics on it. If possible, I plan on distributing an iOS app through TestFlight. My app will gather the app usage statistics and send it to my server.
The overall goal is to get total usage time for each installed app on a daily base from each of the users taking part of the experiment.
What I have:
One of my ideas are to develop an app that will use the VoIP backgrounding profile (or similar) to run in the background and periodically (like every 10 secs) log the name or bundle identifier of the current foreground app (if any).
I have found a method to get the current running processes: Can we retrieve the applications currently running in iPhone and iPad
The method described in the above post gives a struct kinfo_proc that includes other structs with information such the process name, priority and running time (including time spent in the background). I have not been able to identify a flag revealing what process is in the foreground. Also the priority does not seem to be a reliable indictor. Something I'm missing here?
The above method can be used to get the current running time for a process, but as each app can be sleeping in the background for days (or weeks) this is a poor indicator for how much the app has actually been used. If I could kill all the running user installed apps every hour or so I could get an indicator of how often apps are used. The most used apps would be cold-started by the user more often. But that would give an unpleasant experience for the testers as apps are killed randomly. But anyway, is there a way I can kill another process?
Another idea is to traverse through the view hierarchy to probe the label of the leftmost app in the task bar. Any ideas of how this might be possible to hack?
I had another idea of analyzing device logs and gathering app usage statistics that way. However it seems that app background-foreground switching activity is not logged to the system console. Is there some other logs containing this information or can I get it somehow by enabling energy diagnostics logging?
If I had my test users set up to use Apple Mobile Device Management (MDM) would I then be able to collect the information I am interested in?
Any ideas are very much appreciated.
A few notes:
My test users does not have jailbroken devices, but I can use private APIs as I am not distributing through the App Store.
I would use an analytics tool like Flurry Analytics to get the data concerning usage statistics, which you could then download into your app using their API. They can get you very details stats on how your users are using your app, how frequently, etc. It's a great tool, plus it's free!