B2G App Security Model/Threat Model: Difference between revisions

Jump to navigation Jump to search
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===
177

edits

Navigation menu