WebAPI Security Discussion: Web SMS API

[Lucas Adamski]

Please reply-to dev-w...@lists.mozilla.org

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?

[Justin Lebar]

> Potential mitigations: Prompt user to send SMS. User reviews SMS in trusted UI prior to sending.

I do not think untrusted pages will be able to send SMS, with or
without a prompt.

Instead, untrusted pages will use web intents to launch the SMS app.

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

[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
.

> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Mounir Lamouri]

On 04/16/2012 08:10 AM, Lucas Adamski wrote:
> 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.

As Justin said, maybe unauthenticated web content could use Web
Activities (or Web Intents) to send SMS' instead.

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

Why trusted app can't be an full-featured SMS app?

> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Replacement SMS app

"Replacement" isn't a good wording here. You should be able to install
more than one SMS app on your phone if you want to.

> Authorization model: implicit
> Potential mitigations: None beyond certification

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

I believe we could allow trusted app to read SMS messages too.

--
Mounir

[Lucas Adamski]

On Apr 16, 2012, at 2:32 PM, Mounir Lamouri wrote:

> On 04/16/2012 08:10 AM, Lucas Adamski wrote:
>> 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.
>
> As Justin said, maybe unauthenticated web content could use Web
> Activities (or Web Intents) to send SMS' instead.

Makes sense, I'll update that.

>> == Trusted (authenticated by publisher) ==
>> Use cases for authenticated code: As per regular web content?
>> Authorization model: Explicit (OS Mediated)
>> Potential mitigations: Same as above
>
> Why trusted app can't be an full-featured SMS app?

No reason outside of concerns that this would exposure users to direct financial risk (a bar we have been trying to maintain as a difference between Trusted and Certified apps). Incidentally, while I've seen a number of "SMS" apps its not clear to me that they actually replace the stock SMS app on the device so much as they implement a parallel SMS stack through a 3rd party service and SMS gateways. Does anyone know for sure?

>> == Certified (vouched for by trusted 3rd party) ==
>> Use cases for certified code: Replacement SMS app
>
> "Replacement" isn't a good wording here. You should be able to install
> more than one SMS app on your phone if you want to.

Sure.

>> Authorization model: implicit
>> Potential mitigations: None beyond certification
>
>> Notes: Can only certified apps have access to read SMS messages?
>
> I believe we could allow trusted app to read SMS messages too.

Reading is less (financially) risky than writing in theory.
Lucas.

[Lucas Adamski]

Updated proposal per comments. Looking to close this out unless there are further concerns or discussions in the next 48 hours or so.

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: Full-featured SMS app, integrated messaging apps. Read received SMSes, send MMS/SMS.
Authorization model: Explicit
Potential mitigations: Can we filter/warn on premium numbers? Note that premium SMS trojans are currently plaguing the Android platform.

== Certified (vouched for by trusted 3rd party) ==

Use cases for certified code: SMS app

[Chris Lee]

Hi all,

Here are the use cases defined by the feature today:
Tom wants send a text message and selects the SMS app
Tom can send a new message by:
Selecting an existing contact from the Contacts app list
Entering a phone number
Tom is notified of all incoming messages whether he's in the SMS app, on the Home Screen, or in a 3rd party app
Tom also has the ability to send an MMS (deciding if this is in for v1)
MMS supports photos and short videos
Tom has the ability to search through his history of SMS sent/received
Tom has the ability to delete specific SMS threads
The cases above look to be addressed by the categories below, but wanted to confirm with the audience here.

Thanks,
Chris

[Mounir Lamouri]

On 04/19/2012 03:20 AM, Lucas Adamski wrote:
> == 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.

Your wording isn't making clear that this isn't using the API at all but
Web Intents/Activities instead.

> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Full-featured SMS app, integrated messaging apps. Read received SMSes, send MMS/SMS.
> Authorization model: Explicit
> Potential mitigations: Can we filter/warn on premium numbers? Note that premium SMS trojans are currently plaguing the Android platform.
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: SMS app
> Authorization model: implicit
> Potential mitigations: None beyond certification

I'm not sure what's the difference between Trusted and Certified app
(bad memory FTW). Depending on that, we could allow or not sending for
trusted apps.

--
Mounir

[Mounir Lamouri]

On 04/19/2012 06:27 AM, Chris Lee wrote:
> Here are the use cases defined by the feature today:
> Tom wants send a text message and selects the SMS app
> Tom can send a new message by:
> Selecting an existing contact from the Contacts app list
> Entering a phone number
> Tom is notified of all incoming messages whether he's in the SMS app, on the Home Screen, or in a 3rd party app
> Tom also has the ability to send an MMS (deciding if this is in for v1)
> MMS supports photos and short videos
> Tom has the ability to search through his history of SMS sent/received
> Tom has the ability to delete specific SMS threads
> The cases above look to be addressed by the categories below, but wanted to confirm with the audience here.

Those are not the use cases of the WebSMS API but of the SMS application.

--
Mounir

[Lucas Adamski]

Updated proposal. Please reply-to dev-w...@lists.mozilla.org

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?

[Mounir Lamouri]

On 04/29/2012 10:04 PM, Lucas Adamski wrote:
> Note: Should trusted apps be able to register as handlers for SMS web activities/intents, or only certified apps?

I don't see why not.

--
Mounir

[Lucas Adamski]

There have been some concerns raised recently from Jonas and Doug Turner regarding the WebSMS model, regarding the ability for Privileged apps (The App Type Formerly Known As Trusted, ie. TATFKAT) to send SMS/MMS at all.

Per our current schedule, realistically we can't implement the suggested mitigations such as warning on premium numbers for 1.0. Instead, we could disallow access to SMS/MMS for Privileged apps entirely.

Keep in mind that per the model Privileged apps require review and approval, plus the user is prompted before the app has any access to the SMS API (additionally, we expect that any app requesting this API would also provide an "intended usage", which would in turn be reviewed and approved).

I personally think this risk is reasonable and (unlike other platforms) users who don't think a given app needs SMS access will simply deny the permission prompt.

Thoughts?
Lucas.

On Apr 18, 2012, at 6:20 PM, Lucas Adamski wrote:

> Updated proposal per comments. Looking to close this out unless there are further concerns or discussions in the next 48 hours or so.
>

> 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: Full-featured SMS app, integrated messaging apps. Read received SMSes, send MMS/SMS.

> Authorization model: Explicit

> Potential mitigations: Can we filter/warn on premium numbers? Note that premium SMS trojans are currently plaguing the Android platform.
>

> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: SMS app

> Authorization model: implicit

[Jonas Sicking]

On Fri, Aug 3, 2012 at 10:20 PM, Lucas Adamski <lada...@mozilla.com> wrote:
> There have been some concerns raised recently from Jonas and Doug Turner regarding the WebSMS model, regarding the ability for Privileged apps (The App Type Formerly Known As Trusted, ie. TATFKAT) to send SMS/MMS at all.
>
> Per our current schedule, realistically we can't implement the suggested mitigations such as warning on premium numbers for 1.0. Instead, we could disallow access to SMS/MMS for Privileged apps entirely.
>
> Keep in mind that per the model Privileged apps require review and approval, plus the user is prompted before the app has any access to the SMS API (additionally, we expect that any app requesting this API would also provide an "intended usage", which would in turn be reviewed and approved).
>
> I personally think this risk is reasonable and (unlike other platforms) users who don't think a given app needs SMS access will simply deny the permission prompt.
>
> Thoughts?

What concerns me here is the very high incentives people have for
abusing the SMS API. Setting up a pay-for SMS number and then tricking
users into sending that number lots of messages can make you lots of
money in relatively small amounts of time.

The value is also *relatively* low. I definitely agree it would be
cool if people could write apps to replace the SMS app and create
things like integrated communication centers. But I don't think that
we'll make it that much of a less attractive platform for users if we
don't have those types of apps in the initial version.

I also believe Adrienne had done some analysis of Apps in the Android
app store which use SMS and found that a scarily large percentage used
it for non-great purposes.

So I'd prefer to keep things simple in the initial release and simply
not expose SMS, and instead focus finding secure ways of exposing it
in a later release.

/ Jonas

[Brian Smith]

Jonas Sicking wrote:
> So I'd prefer to keep things simple in the initial release and simply
> not expose SMS, and instead focus finding secure ways of exposing it
> in a later release.

Do we support sms:+123456789?body=hello%20there links correctly? (Opening up the SMS application with the message and recipient pre-filled.)

I think that many applications that would need to send SMS would be able to make do with sms: links, so to me seems like a good idea to do as Jonas recommends. I don't see any developer or customer considering the lack of an automatic SMS API to be a deal-breaker.

I think we're being way too reliant on straight-up permission prompts. Doing what the iOS 4+ does [1], providing a way to reasonably integrate the SMS UI into your app, seems way better to me than exposing an API that brings up an annoying prompt. (Perhaps irrationally, permission prompts always seem more annoying to me than "preview" prompts, which I frequently like as a user as they are re-assuring.)

Lucas wrote:
> Keep in mind that per the model Privileged apps require review and
> approval, plus the user is prompted before the app has any access to
> the SMS API (additionally, we expect that any app requesting this
> API would also provide an "intended usage", which would in turn be
> reviewed and approved).

It is too early to say how effective these measures will actually be as a security mechanism as we have no real-world experience with any of these features. Given the privacy and financial risks associated with the feature, I think it is prudent to do iron out the wrinkles in our security mechanisms in a production release first.

Cheers,
Brian

[Jonas Sicking]

On Mon, Aug 6, 2012 at 3:30 PM, Brian Smith <bsm...@mozilla.com> wrote:
> Jonas Sicking wrote:
>> So I'd prefer to keep things simple in the initial release and simply
>> not expose SMS, and instead focus finding secure ways of exposing it
>> in a later release.
>
> Do we support sms:+123456789?body=hello%20there links correctly? (Opening up the SMS application with the message and recipient pre-filled.)

I don't know, but I agree it's something we should support.

> I think that many applications that would need to send SMS would be able to make do with sms: links, so to me seems like a good idea to do as Jonas recommends. I don't see any developer or customer considering the lack of an automatic SMS API to be a deal-breaker.
>
> I think we're being way too reliant on straight-up permission prompts. Doing what the iOS 4+ does [1], providing a way to reasonably integrate the SMS UI into your app, seems way better to me than exposing an API that brings up an annoying prompt. (Perhaps irrationally, permission prompts always seem more annoying to me than "preview" prompts, which I frequently like as a user as they are re-assuring.)

I think you forgot to include the [1] reference.

> Lucas wrote:
>> Keep in mind that per the model Privileged apps require review and
>> approval, plus the user is prompted before the app has any access to
>> the SMS API (additionally, we expect that any app requesting this
>> API would also provide an "intended usage", which would in turn be
>> reviewed and approved).
>
> It is too early to say how effective these measures will actually be as a security mechanism as we have no real-world experience with any of these features. Given the privacy and financial risks associated with the feature, I think it is prudent to do iron out the wrinkles in our security mechanisms in a production release first.

Very good point.

/ Jonas

[Brian Smith]

Jonas Sicking wrote:
> On Mon, Aug 6, 2012 at 3:30 PM, Brian Smith <bsm...@mozilla.com>
> wrote:
> > I think we're being way too reliant on straight-up permission
> > prompts. Doing what the iOS 4+ does [1], providing a way to
> > reasonably integrate the SMS UI into your app, seems way better to
> > me than exposing an API that brings up an annoying prompt.
> > (Perhaps irrationally, permission prompts always seem more
> > annoying to me than "preview" prompts, which I frequently like as
> > a user as they are re-assuring.)
>
> I think you forgot to include the [1] reference.

[1] The first answer in:
http://stackoverflow.com/questions/10848/how-to-programmatically-send-sms-on-the-iphone

- Brian

[Lucas Adamski]

I'm not sure we have any disagreement then. Per https://wiki.mozilla.org/WebAPI/Security/SMS showing a user
confirmation is a recommended mitigation, so *if* we could implement something like:
explicit permission for SMS access + OS confirmation on send
- would that work?
Lucas.

[Adrienne Porter Felt]

On Mon, Aug 6, 2012 at 2:58 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> I also believe Adrienne had done some analysis of Apps in the Android
> app store which use SMS and found that a scarily large percentage used
> it for non-great purposes.
>

That's not exactly what our data shows; it's not that most apps that
request SMS are malware, but rather that most apps that are malware request
SMS. However, I would agree that the value added by SMS is low but the
risk is high. Here's the data I've got:

- 2.934% of Android apps request the SEND_SMS permission.
- By our estimation (manual review of apps), only 0.8% of all apps need
the permission; the remainder could use a built-in SMS widget like in iOS
without any loss of functionality.
- 73% of malware requests this permission. I believe this % has
increased since I measured it last year.
- The privilege ranks in the top 5 most concerning to users (because of
its ability to spend their money.

[Brian Smith]

Lucas Adamski wrote:
> I'm not sure we have any disagreement then. Per
> https://wiki.mozilla.org/WebAPI/Security/SMS showing a user
> confirmation is a recommended mitigation, so *if* we could implement
> something like:
> explicit permission for SMS access + OS confirmation on send
> - would that work?

I expect that <a href='sms:+1234567890?body=hello%20there'>Send SMS</a> should open up a pre-filled SMS message, even in untrusted web content. And, I guess that must be what the intent mechanism does.

Would calling send() with "OS confirmation on send" be different, UX-wise? If it would be the same UX, I think it would be better to simply avoid exposing send() to non-certified apps, to encourage developers to use the same mechanisms that are more likely to work cross-browser (sms:) and/or that work without being "privileged" and which we could potentially implement easier in a cross-platform way (intents). This way, send() would not operate differently depending on the privilege level of the app.

Also, I just now understand that there's not a separate permission for reading/deleting existing SMS vs. sending new SMS. While I think there are not many apps that want to read/delete messages but do not want to send them, I think there are quite a few use cases for being able to send an SMS but never needing to read/delete them. And, there are significant risks to allowing an app to read SMS (e.g. the two-factor authentication and password reset cases already mentioned on the wiki, and general privacy risks). So, I recommend separating the permission for sending from the permission from reading/deleting.

Cheers,
Brian

[Jonas Sicking]

On Mon, Aug 6, 2012 at 4:17 PM, Lucas Adamski <lada...@mozilla.com> wrote:
> I'm not sure we have any disagreement then. Per https://wiki.mozilla.org/WebAPI/Security/SMS showing a user
> confirmation is a recommended mitigation, so *if* we could implement something like:
> explicit permission for SMS access + OS confirmation on send
> - would that work?

I'm talking about more than showing a user confirmation. I'm talking
about using the model of WebActivities to switch over to the SMS app
and send the message there. The <a href="sms:..."> syntax is basically
syntax sugar on top of such a WebActiity.

So I think we should label it as "Using web activities" for anything
but certified apps.

/ Jonas

[Jonas Sicking]

On Mon, Aug 6, 2012 at 5:04 PM, Adrienne Porter Felt <a...@berkeley.edu> wrote:
>
> On Mon, Aug 6, 2012 at 2:58 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> I also believe Adrienne had done some analysis of Apps in the Android
>> app store which use SMS and found that a scarily large percentage used
>> it for non-great purposes.
>
>
> That's not exactly what our data shows; it's not that most apps that request
> SMS are malware, but rather that most apps that are malware request SMS.
> However, I would agree that the value added by SMS is low but the risk is
> high. Here's the data I've got:
>

> 2.934% of Android apps request the SEND_SMS permission.

> By our estimation (manual review of apps), only 0.8% of all apps need the
> permission; the remainder could use a built-in SMS widget like in iOS
> without any loss of functionality.

> 73% of malware requests this permission. I believe this % has increased
> since I measured it last year.

> The privilege ranks in the top 5 most concerning to users (because of its
> ability to spend their money.

Ah, thanks. I love data like this!

I'd recommend that we implement the ability to use WebActivities to
bring up the SMS app with a prefilled number and body. Seems like that
will get us in the order of 99% of all apps with very little risk to
the user.

/ Jonas