WebAPI Security Discussion: Web SMS API

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

WebAPI Security Discussion: Web SMS API

Lucas Adamski-2
Please reply-to [hidden email]

Name of API: Web SMS API
References: https://bugzilla.mozilla.org/show_bug.cgi?id=674725

Brief purpose of API: Send and recieve SMS messages
General Use Cases: None

Inherent threats:
* Sending an SMS costs user money, premium SMS services, SMS payments etc
* Receiving SMS has privacy implications, SMS also used for 2-factor authentication

Threat severity: critical per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: App prompts user to send SMS
Authorization model for uninstalled web content: Explicit (OS Mediated)
Authorization model for installed web content: Explicit (OS Mediated)
Potential mitigations: Prompt user to send SMS. User reviews SMS in trusted UI prior to sending.

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: As per regular web content?
Authorization model: Explicit (OS Mediated)
Potential mitigations: Same as above

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Replacement SMS app
Authorization model: implicit
Potential mitigations: None beyond certification

Notes: Can only certified apps have access to read SMS messages?

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Web SMS API

Adrienne Porter Felt
I like this proposal.

For some apps (like the Yahoo Messenger app), it might be annoying to see a
full-screen preview of the text message every time.  For this, I'd propose
a magic button for sending SMS messages.  In this proposal, the OS takes
the target number as input and includes either the target number or the
contact name in the text of the button, so the button says something like
"Text 555-555-555" or "Text Mom."  The OS could show a greyed-out button
until the number is supplied so that there isn't an empty UI element.  The
OS sends the text message when the user presses the button.  Here, the user
does not verify the content but he/she does verify the target.

Could B2G implement a heuristic for guessing whether the number is a
premium number?  I don't know much about premium numbers, but some effort
could probably be put in to compile a list of shortcodes that are
affiliated with premium charges.  If so, the user could be shown an extra
confirmation/warning (in addition to the magic button) at least the first
time an app tries to text a premium number.

As far as reading SMS goes, there definitely are apps that read SMS.
 There's a bunch of backup apps and privacy apps that selectively backup
texts that you want to keep but don't want to be visible in your standard
SMS app.  Here's a bunch of Android apps that use it:
http://www.google.com/search?client=safari&rls=en&q=site:play.google.com+%22read+SMS+or+MMS%22&ie=UTF-8&oe=UTF-8
.

On Sun, Apr 15, 2012 at 11:10 PM, Lucas Adamski <[hidden email]>wrote:

> Please reply-to [hidden email]
>
> Name of API: Web SMS API
> References: https://bugzilla.mozilla.org/show_bug.cgi?id=674725
>
> Brief purpose of API: Send and recieve SMS messages
> General Use Cases: None
>
> Inherent threats:
> * Sending an SMS costs user money, premium SMS services, SMS payments etc
> * Receiving SMS has privacy implications, SMS also used for 2-factor
> authentication
>
> Threat severity: critical per
> https://wiki.mozilla.org/Security_Severity_Ratings
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: App prompts user to send SMS
> Authorization model for uninstalled web content: Explicit (OS Mediated)
> Authorization model for installed web content: Explicit (OS Mediated)
> Potential mitigations: Prompt user to send SMS. User reviews SMS in
> trusted UI prior to sending.
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: As per regular web content?
> Authorization model: Explicit (OS Mediated)
> Potential mitigations: Same as above
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Replacement SMS app
> Authorization model: implicit
> Potential mitigations: None beyond certification
>
> Notes: Can only certified apps have access to read SMS messages?
>
> _______________________________________________
> dev-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Web SMS API

Lucas Adamski-2
In reply to this post by Lucas Adamski-2
Updated proposal.  Please reply-to [hidden email]

Name of API: Web SMS API
References: https://bugzilla.mozilla.org/show_bug.cgi?id=674725

Brief purpose of API: Send and recieve SMS messages
General Use Cases: None

Inherent threats:
* Sending an SMS costs user money, premium SMS services, SMS payments etc
* Receiving SMS has privacy implications, SMS also used for 2-factor authentication

Threat severity: critical per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: App prompts user to send SMS
Authorization model for uninstalled web content: Explicit (via web activities)
Authorization model for installed web content: Explicit (via web activities)
Potential mitigations:

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Full-featured SMS app.  Read & send SMS.
Authorization model: Explicit
Potential mitigations: Check your phone bill?

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code:  SMS app
Authorization model: Implicit
Potential mitigations: None beyond certification

Note: Should trusted apps be able to register as handlers for SMS web activities/intents, or only certified apps?
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security