177
edits
| Line 72: | Line 72: | ||
====Potential Countermeasures==== | ====Potential Countermeasures==== | ||
* Controls are largely the same as for vulnerable web applications - see above. | * Controls are largely the same as for vulnerable web applications - see above. | ||
* Code Signing is an effective control here (assuming static web apps). Signing with a key not stored on the hosting server so that compromise of the server doesn’t directly result compromised phones. For best results, this means adopting the full debian-like (or redhat-like) application distribution model, as documented and described in [[Apps/Security#Debian_Keyring_.28Package_Management.29_for_distribution_of_apps]] | * Code Signing is an effective control here (assuming static web apps). Signing with a key not stored on the hosting server so that compromise of the server doesn’t directly result compromised phones. However, signing is effectively introducing people-based security and is recognition of the fact that host-based security is ineffective. For best results, this means adopting the full debian-like (or redhat-like) application distribution model, as documented and described in [[Apps/Security#Debian_Keyring_.28Package_Management.29_for_distribution_of_apps]] | ||
* Under people-based (GPG/PGP) PKI security, a compromised host is completely irrelevant, as the mere hosting of pre-signed, pre-vetted and pre-validated packages has ''nothing'' to do with the actual signing, vetting or validating | * Under people-based (GPG/PGP) PKI security, a compromised host is completely irrelevant, as the mere hosting of pre-signed, pre-vetted and pre-validated packages has ''nothing'' to do with the actual signing, vetting or validating (being best carried out on a completely separate network or better on a completely network-isolated system) | ||
=== App Store Compromise=== | === App Store Compromise=== | ||
edits