Trusting Third Party Code ⇥ krausefx.com
Third-party SDKs can often easily be modified while you download them! Using a simple person-in-the-middle attack, anyone in the same network can insert malicious code into the library, and with that into your application, as a result running in your user’s pockets.
31% of the most popular closed-source iOS SDKs are vulnerable to this attack, as well as a total of 623 libraries on CocoaPods. As part of this research I notified the affected parties, and submitted patches to CocoaPods to warn developers and SDK providers.
Last week, news broke that a third-party screen reading script often used by government and public websites was surreptitiously mining a cryptocurrency. A couple of years ago, a programmer pulled several of his scripts from a JavaScript registry; several applications that were dependent on one of these packages, in particular, subsequently failed to compile.
Even this very website has been susceptible to failures in third-party code, albeit on a minor scale: most ads are loaded from Carbon’s CDN; but, occasionally, they have served ad images from those advertisers’ servers. You may have seen the result of this when the ad image is blank, owing to the content security policy I’ve implemented here.
In response to the cryptocurrency mining screen reading script revealed last week, I wrote that we ought to treat third-party code as though it will, at some point, be carrying malware. I feel like that might be too generous. It is not realistic to tell developers to stop using third-party code, but they should not trust it.