Handling forms in Emails

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

Handling forms in Emails

Mark Banner-4
Since Thunderbird 2, we've had a bug on file [1] where forms in email
can't be submitted. This was due to how we changed our content handling
to allow tabs that can view web pages.

Whilst I think we could fix this, the more I think about it, the more I
am concerned about the security implications of forms in emails.

I think the biggest concern is from phishing attacks - e.g. a user
receives an email with form elements due to their bank having issues and
needing to log in.

With no indication of where the submission is going to, the user could
be at serious risk.

I should note, this is only a problem where the user selects to view
"Original HTML". Viewing plain text or "Simple HTML" isn't an issue.

So I don't think it is right to "fix" form handling to just work as it
used to, but I'm not sure about the way forward.

I can see a couple of options:

- Don't allow the display of the form at all, even in original html mode.
- Somehow hook into the form submission, or the email display and
indicate where the form will be submitted to.

I'm not sure if the latter is possible, or sensible from a security
perspective.

Does anyone else have any ideas, suggestions, comments?

Mark.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=533545
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Handling forms in Emails

Syd-3
On Feb 24, 9:09 pm, Mark Banner <[hidden email]> wrote:

> Since Thunderbird 2, we've had a bug on file [1] where forms in email
> can't be submitted. This was due to how we changed our content handling
> to allow tabs that can view web pages.
>
> Whilst I think we could fix this, the more I think about it, the more I
> am concerned about the security implications of forms in emails.
>
> I think the biggest concern is from phishing attacks - e.g. a user
> receives an email with form elements due to their bank having issues and
> needing to log in.
>
> With no indication of where the submission is going to, the user could
> be at serious risk.
>
> I should note, this is only a problem where the user selects to view
> "Original HTML". Viewing plain text or "Simple HTML" isn't an issue.
>
> So I don't think it is right to "fix" form handling to just work as it
> used to, but I'm not sure about the way forward.
>
> I can see a couple of options:
>
> - Don't allow the display of the form at all, even in original html mode.
> - Somehow hook into the form submission, or the email display and
> indicate where the form will be submitted to.
>
> I'm not sure if the latter is possible, or sensible from a security
> perspective.
>
> Does anyone else have any ideas, suggestions, comments?
>
> Mark.
>
> [1]https://bugzilla.mozilla.org/show_bug.cgi?id=533545

Mail.app allows form submissions and users switching from Mail expect
similar behaviour with TB.
I understand the phishing risks but for enterprise apps, its critical
to have form submissions in mail clients.
Simple option is to have form submissions enabled via a preference,
and set it to disabled by default.
Syd
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Handling forms in Emails

Lucas Adamski-2
In reply to this post by Mark Banner-4
Hi Mark,

Email phishing via HTML forms is not uncommon now but usually done via attachments.  Being able to do it inline within
the email probably would not help the situation any. :)
  Lucas.

On 2/24/2012 2:09 AM, Mark Banner wrote:

> Since Thunderbird 2, we've had a bug on file [1] where forms in email can't be submitted. This was due to how we
> changed our content handling to allow tabs that can view web pages.
>
> Whilst I think we could fix this, the more I think about it, the more I am concerned about the security implications
> of forms in emails.
>
> I think the biggest concern is from phishing attacks - e.g. a user receives an email with form elements due to their
> bank having issues and needing to log in.
>
> With no indication of where the submission is going to, the user could be at serious risk.
>
> I should note, this is only a problem where the user selects to view "Original HTML". Viewing plain text or "Simple
> HTML" isn't an issue.
>
> So I don't think it is right to "fix" form handling to just work as it used to, but I'm not sure about the way forward.
>
> I can see a couple of options:
>
> - Don't allow the display of the form at all, even in original html mode.
> - Somehow hook into the form submission, or the email display and indicate where the form will be submitted to.
>
> I'm not sure if the latter is possible, or sensible from a security perspective.
>
> Does anyone else have any ideas, suggestions, comments?
>
> Mark.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=533545
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Handling forms in Emails

Florian Weimer
In reply to this post by Mark Banner-4
* Mark Banner:

> With no indication of where the submission is going to, the user could
> be at serious risk.

It's also difficult to demonstrate that the action URL is malicious
because it can just quietly store the information, without actually
displaying any brand-related material.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Handling forms in Emails

Brian Smith-31
In reply to this post by Syd-3
Syd wrote:
> Mail.app allows form submissions and users switching from Mail expect
> similar behaviour with TB.
> I understand the phishing risks but for enterprise apps, its critical
> to have form submissions in mail clients.
> Simple option is to have form submissions enabled via a preference,
> and set it to disabled by default.

If it were up to me, I would avoid rendering <form> and related elements at all, similar to Outlook. This would be a much better UX than displaying the user non-functional forms.

"Mail.app does it" isn't a very convincing argument, IMO. "Outlook does it" would be more convincing when considering enterprise use cases. From what I can tell from Googling around, at least Outlook 2007 and Outlook 2010 do not support HTML forms [1].

IMO, it is not reasonable to expect/require email applications--especially webmail applications--to safely and correctly support HTML forms. There are many potential security problems. For example, how would HTML forms with input type=password be correctly supported by webmail applications, given that web browsers would likely auto-fill said password fields with the user's email username/password? Right now they can handle this in a very safe way--simply add <form>, <input>, and related elements to their blacklists. In a world where email clients are expected to support HTML forms, they must implement much more subtle logic.

Further, the user should be aware of what credentials will be in use in the submission of the form. This would require Thunderbird to determine which HTTP cookies and/or HTTP auth credentials and/or TLS client auth credentials would be used in the form submission, and it would require Thunderbird to somehow coherently display those credentials to the user before passing the request to the web browser. That is basically impossible to do. It is much safer to have the email contain a link to an HTML document that contains the form, so that the HTML application with the form can display the credentials that will be used.

Also, webmail applications wouldn't be able to submit such forms if they use methods other than GET unless the target site supported CORS. And, also, there's no way to pass a non-GET request to an external web browser on the command line. This means that such forms would be limited to GET. But, this limitation would encourage developers that rely on HTML forms in email to mis-use GET to implement forms that have side-effects, which is bad.

- Brian

[1] http://msdn.microsoft.com/en-us/library/aa338201%28v=office.12%29.aspx
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Handling forms in Emails

Michael Ströder
In reply to this post by Mark Banner-4
Syd wrote:
> Mail.app allows form submissions and users switching from Mail expect
> similar behaviour with TB.
> I understand the phishing risks but for enterprise apps, its critical
> to have form submissions in mail clients.

The enterprise apps I know don't use HTML forms in e-mails at all. They just
send links which lead to input forms generated by web applications (e.g.
workflow-based application).

Ciao, Michael.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security