From nobody Sun Apr 8 18:26:42 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C79128896 for ; Sun, 8 Apr 2018 18:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=isvTWjhD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bZYWnQGm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb1UzLyj-set for ; Sun, 8 Apr 2018 18:26:38 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B4F126C83 for ; Sun, 8 Apr 2018 18:26:38 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id C2B2720FED for ; Sun, 8 Apr 2018 21:26:37 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 08 Apr 2018 21:26:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=EDayyesoiQHKxNGDaLo2ogVVQekd0cIOxO3310duN x4=; b=isvTWjhD/bm4W9qx6MuvF60pnlu7sZzBGfbqwHIGeCNpaCRYyB4sMKai3 rwADVN3u6v0A+J1Zm9G4KEKNZrL1ZReirG1zJkqjbBtKBII8yJwoybd5aSeg68qQ 3eaU404nwQM9kNA2MJIfdBNSvwkZMjMuex5kNm2HFYQgaYJOJtBhdcTyL5RBJGyz P919h2CYGs9WQ4T37EAUZUdRyBAtMfPvT47emg0c3T8pQJ9vHgIn8saDdo2enUBs djepY/zg20XcPVGpzTtXjp2P/Z/akJ4A9ZKyyDxI3eZMqTNB2q/e8QyRagCN91HG GQafPWTC6Iu5PFom53hVQmi1X2xPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=EDayyesoiQHKxNGDaLo2ogVVQekd0 cIOxO3310duNx4=; b=bZYWnQGmKUVL1CXG8INgokYemLlsU7+e8zEqaaYvSq11Q rihnu7XX0SXddKEB1I18Uqi5WesVyaOB4qHorVyPCyollRUvrhxrdh2NKLtk1OcI nYURAoxLr5nxGR4qRH2YXNm+lvRGc/vooKY5gXrr9rkh7QbmdpMd8xi6Iz5uTIzC igzv1d3ajFNgbNPHDaciLsXF4t3YYQFwSJ6Fnn2KU+pI4gsLNTpMA/UvrBGJ++UD dhXIA3e3FqkeY/yO9zJMNDM8xqPhrSCPb9mX8hQyzlzfmpVqoWNhmtdKHRKlncgb PYjiUNh14yZMC0VQueq17PJ1FeI/u/j50KwG+ui6A== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 71FE9E2146; Sun, 8 Apr 2018 21:26:37 -0400 (EDT) Message-Id: <1523237197.698706.1330964576.6728B2BC@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15232371976987062" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e3b95fa8 Date: Mon, 09 Apr 2018 11:26:37 +1000 Archived-At: Subject: [Jmap] HTML email security considerations X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 01:26:41 -0000 This is a multi-part message in MIME format. --_----------=_15232371976987062 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" This is an important security consideration for client vendors, and getting this right may help vendors avoid various security pitfalls in the future, so it would be good to have a few eyeballs to check I've covered the essential points in sufficient detail. I've created a pull request[1] for review, content copied below for convenience. ------ HTML message bodies provide richer formatting for emails but present a number of security challenges especially when embedded in a webmail context in combination with interface HTML. Clients that render HTML email should make careful consideration of the potential risks, including: * If JavaScript is allowed to execute it can rewrite email to change its content on subsequent opening, allowing users to be mislead. In webmail systems it can access and exfiltrate all user content accessible via the browser, including all other emails and potentially contacts, calendar events, settings, and login credentials. It can also rewrite the interface to undetectably phish passwords. * HTML documents may load content directly from the internet, rather than just referencing attached resources. For example you may have an tag with an external src attribute. This may leak to the sender when a message is opened, as well as the IP address of the recipient. Cookies may also be sent and set by the server, allowing tracking between different emails and even website visits and advertising profiles. * In webmail systems, CSS can break the layout or create phishing vulnerabilities. For example, the use of position:fixed can allow an email to draw content outside of its normal bounds, potentially clickjacking a real interface element. * If not inside a separate frame in a webmail context, any styles defined in CSS rules will apply to interface elements as well if the selector matches, allowing the interace to be modified. Similarly, any interface styles that match elements in the email will alter their appearance, potentially breaking the layout of the email. * The link text in HTML has no neccessary correlation with the actual target of the link, which can be used to make phishing attacks more convincing. * Links opened from an email may leak private info in the Referer header sent by default in most systems.Sanitizing HTML to mitigate these issues is tricky. Using a well-tested library with a carefully vetted whitelist-only approach is the safest way to avoid vulnerabilities. New features with unexpected security characteristics may be added to HTML rendering engines in the future; a blacklist approach is likely to result in security issues.A defence in depth approach can help to mitigate the risks of HTML email. Webmail systems are strongly encouraged to use a strong Content Security Policy[2] as a second line of defence to block malicious content should it manage to evade the filter.Subtle differences in parsing of HTML can introduce security flaws: to filter with 100% accurately you need to use the same parser when sanitizing that the HTML rendering engine will use.As highly complex software components, HTML rendering engines increase the attack surface of a client considerably, especially when being used to process untrusted, potentially malicious content. Serious bugs have been found in image decoders, JavaScript engines and HTML parsers in the past, which could lead to full system compromise. Clients using an engine should ensure they get the latest version and continue to incorporate any security patches released by the vendor. Links: 1. https://github.com/jmapio/jmap/pull/197 2. https://www.w3.org/TR/CSP3/ --_----------=_15232371976987062 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
This is an important security consideration for client vendors, = and getting this right may help vendors avoid various security pitfalls in = the future, so it would be good to have a few eyeballs to check I've covere= d the essential points in sufficient detail. I've created a pull request for review, content c= opied below for convenience.

------

HTML message bodies provide richer formatting for emails but present a n= umber of security challenges especially when embedded in a webmail context = in combination with interface HTML. Clients that render HTML email should m= ake careful consideration of the potential risks, including:

    If JavaScript is allowed to execute it can rewrite email to change its content on subsequent opening, allowing users to be mislead. In webmail sys= tems it can access and exfiltrate all user content accessible via the brows= er, including all other emails and potentially contacts, calendar events, s= ettings, and login credentials. It can also rewrite the interface to undete= ctably phish passwords.
  • HTML documents may load content directl= y from the internet, rather than just referencing attached resources. For example you may have an <img&g= t; tag with an external src attribute. This may leak to= the sender when a message is opened, as well as the IP address of the reci= pient. Cookies may also be sent and set by the server, allowing tracking be= tween different emails and even website visits and advertising profiles.
  • In webmail systems, CSS can break the layout or create phishing vulnerabilities. For example, the use of position:fixed can al= low an email to draw content outside of its normal bounds, potentially clic= kjacking a real interface element.
  • If not inside a separate fra= me in a webmail context, any styles defined in CSS rules will apply to interface elements as well if the selector matches,= allowing the interace to be modified. Similarly, any interface styles that= match elements in the email will alter their appearance, potentially break= ing the layout of the email.
  • The link text in HTML has no necce= ssary correlation with the actual target of the link, which can be used to make phishing attacks more convincing.
  • Links opened from an email may leak private info in the Refere= r header sent by default in most systems.

Sanitizing HTML to mitigate the= se issues is tricky. Using a well-tested library with a carefully vetted wh= itelist-only approach is the safest way to avoid vulnerabilities. New featu= res with unexpected security characteristics may be added to HTML rendering= engines in the future; a blacklist approach is likely to result in securit= y issues.

A defence in depth approach can help to mitigate the ri= sks of HTML email. Webmail systems are strongly encouraged to use a strong = Content Security Policy as a se= cond line of defence to block malicious content should it manage to evade t= he filter.

Subtle differences in parsing of HTML can introduce se= curity flaws: to filter with 100% accurately you need to use the same parse= r when sanitizing that the HTML rendering engine will use.

As hig= hly complex software components, HTML rendering engines increase the attack= surface of a client considerably, especially when being used to process un= trusted, potentially malicious content. Serious bugs have been found in ima= ge decoders, JavaScript engines and HTML parsers in the past, which could l= ead to full system compromise. Clients using an engine should ensure they g= et the latest version and continue to incorporate any security patches rele= ased by the vendor.


--_----------=_15232371976987062-- From nobody Sun Apr 8 18:30:44 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B846A127137 for ; Sun, 8 Apr 2018 18:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=IU4lwG8C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cylLvnMp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eItGRs-hFCYf for ; Sun, 8 Apr 2018 18:30:40 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23628126C83 for ; Sun, 8 Apr 2018 18:30:40 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8B6EC2082D; Sun, 8 Apr 2018 21:30:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 08 Apr 2018 21:30:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=n37F4fzJqfgloqfUlZhpcQP8EP0o6 sRoo3FA+8osAxk=; b=IU4lwG8CRS+i9uJ8fRNJv73pB7Mc9NF+VrCMlHXHSTMMs 5/paw6BId74YpQ8vEaty2iKzxr3FVdLmY9H7qSPyX5Sa37uVw+OXW3uxNJU9POwG hGmy02p5F2G2dDXJpTcHoDEL20l99n40D6QFn2UdQPScpj/hUb5r52NxroaUyOc6 oNyXRTMn31kwHs0py1Fvw8db3miZ+kM0yWgzMgxcLYnV/5n5arX5b/QHKnGWJDfO Hka9LAqqjTQ3CmTPM6QtWR6FhNVk3GhSa4fhMwtTyLjf1dmaD+GNDzUD5Q71LJrp OVVIGyADPlVtZD3heNejOG7wGviCVkGsbbF/YjPRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=n37F4f zJqfgloqfUlZhpcQP8EP0o6sRoo3FA+8osAxk=; b=cylLvnMpXXWoSC6TWuC2rb PVW81Ewp1QbFownhRNFP18+N70iXinl7R0lf8urjLJ+/FA3feUwftCQ2LOfkUHCe 6WjpppluxM/rHUFLKVu5LChh12UPn43ZnNsJOYwVRA0t+i0JL4eOYc1eP3Hyjwzl OQBFHidYYZ99w9iqT5a67/ZNIypA75zVrXQOpLCzzv5X11XJIrfGfurlTgY3Y9u+ pAO/3ykTfsOIMdcIMiz3IHAiUgTjGqFPSkZ+XgyrJQpwYTwcj1spcslne3J8ZILh 8rxu+5CeHhdV69HNsT2Aj2b6f1xNjVzyhSxu210v7C000+zkPQtpRL9NWj5fXIDg == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 2E0691027D; Sun, 8 Apr 2018 21:30:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mark Nottingham In-Reply-To: <1523237197.698706.1330964576.6728B2BC@webmail.messagingengine.com> Date: Mon, 9 Apr 2018 11:30:35 +1000 Cc: IETF JMAP Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <43207A19-6ADB-4E06-9965-7052DC0E3732@mnot.net> References: <1523237197.698706.1330964576.6728B2BC@webmail.messagingengine.com> To: Neil Jenkins X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Jmap] HTML email security considerations X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 01:30:43 -0000 > On 9 Apr 2018, at 11:26 am, Neil Jenkins = wrote: >=20 > This is an important security consideration for client vendors, and = getting this right may help vendors avoid various security pitfalls in = the future, so it would be good to have a few eyeballs to check I've = covered the essential points in sufficient detail. I've created a pull = request for review, content copied below for convenience. >=20 > ------ > HTML message bodies provide richer formatting for emails but present a = number of security challenges especially when embedded in a webmail = context in combination with interface HTML. Clients that render HTML = email should make careful consideration of the potential risks, = including: >=20 > =E2=80=A2 If JavaScript is allowed to execute it can rewrite = email to change its content on subsequent opening, allowing users to be = mislead. In webmail systems it can access and exfiltrate all user = content accessible via the browser, including all other emails and = potentially contacts, calendar events, settings, and login credentials. = It can also rewrite the interface to undetectably phish passwords. > =E2=80=A2 HTML documents may load content directly from the = internet, rather than just referencing attached resources. For example = you may have an tag with an external srcattribute. This may leak = to the sender when a message is opened, as well as the IP address of the = recipient. Cookies may also be sent and set by the server, allowing = tracking between different emails and even website visits and = advertising profiles. > =E2=80=A2 In webmail systems, CSS can break the layout or create = phishing vulnerabilities. For example, the use of position:fixed can = allow an email to draw content outside of its normal bounds, potentially = clickjacking a real interface element. > =E2=80=A2 If not inside a separate frame in a webmail context, = any styles defined in CSS rules will apply to interface elements as well = if the selector matches, allowing the interace to be modified. = Similarly, any interface styles that match elements in the email will = alter their appearance, potentially breaking the layout of the email. > =E2=80=A2 The link text in HTML has no neccessary correlation = with the actual target of the link, which can be used to make phishing = attacks more convincing. > =E2=80=A2 Links opened from an email may leak private info in = the Referer header sent by default in most systems. > Sanitizing HTML to mitigate these issues is tricky. Using a = well-tested library with a carefully vetted whitelist-only approach is = the safest way to avoid vulnerabilities. New features with unexpected = security characteristics may be added to HTML rendering engines in the = future; a blacklist approach is likely to result in security issues. >=20 You might want to refer to=20 https://www.w3.org/TR/referrer-policy/ > A defence in depth approach can help to mitigate the risks of HTML = email. Webmail systems are strongly encouraged to use a strong Content = Security Policy as a second line of defence to block malicious content = should it manage to evade the filter. >=20 > Subtle differences in parsing of HTML can introduce security flaws: to = filter with 100% accurately you need to use the same parser when = sanitizing that the HTML rendering engine will use. >=20 > As highly complex software components, HTML rendering engines increase = the attack surface of a client considerably, especially when being used = to process untrusted, potentially malicious content. Serious bugs have = been found in image decoders, JavaScript engines and HTML parsers in the = past, which could lead to full system compromise. Clients using an = engine should ensure they get the latest version and continue to = incorporate any security patches released by the vendor. It might also be worthwhile to ping the W3C WebAppSec WG for a review: https://www.w3.org/2011/webappsec/ Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Apr 8 18:53:36 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24712711A for ; Sun, 8 Apr 2018 18:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Qh+dwYc6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NBnVAaHp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJu5y75rTA5Y for ; Sun, 8 Apr 2018 18:53:33 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99546124D68 for ; Sun, 8 Apr 2018 18:53:33 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id C831620CE9; Sun, 8 Apr 2018 21:53:32 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 08 Apr 2018 21:53:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=NE8+ud ic1JAcWlqrPUj2J4PXjJFCcNW6tvgotX3SUS8=; b=Qh+dwYc6UGdaJ26GkhRjny wOfKeTfFjE54gHdpOEXOQlp3fRuxQKaLTT99m3D/faBMPm0e/jtNktY1BI/o/lzK 5COG1x+gDP6a39cAo6yu5X+CGc5vA+KMmgQx5eQSgrmmLRcU7fRTGI9GCyPTu6gB 950cr3PXMvBCzmH+ZZoNCvAzX4nFiH7Fm3SFN6rxXKFhPpfiKfJeUyFEq/7IaXoh rXGthQaxoMABKssG06wxyJiZnLbZHwRwN1P15FZTaDkbMcRx/4ihOQACJIz+FkdU EFXLCwILszLRALav1XFds29P8dZa/zBNPnEqZOWdWez6q8avOg8ubaFzLGt+Dctw == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=NE8+ud ic1JAcWlqrPUj2J4PXjJFCcNW6tvgotX3SUS8=; b=NBnVAaHp+AlK8KvuDVuu7n CKRD1f3Rdrc9J0ByqoknS9GrSC+1VyOW8nSDDcQy8dLA0cMU/fCJ6oy5I+Yve3aY 7hHO/VR99vZQW2xkBmcnO6v4DBXqbD7+wwByiRwjXRs4FdX6P9lrnL3JwnJzN/up u6hLKwTYTe//QVdkvKViKHhIqcS9EmmyWUUE6b3b4+9Rhj7xwuFaR0T4adOo9DVY p9xa23wFL59gSRbqUEcz9uPE8OdBqQeMLDJsTiBOonyOy7DGkX8VuxKUdRXcINzM rMLo1jdtgANtNaz+ks6KPuovevHzLBUIa7ytQNq3LotEtYzaWHuSKOfqTYGwNEbQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 845C4E2146; Sun, 8 Apr 2018 21:53:32 -0400 (EDT) Message-Id: <1523238812.730320.1330981840.7417D782@webmail.messagingengine.com> From: Neil Jenkins To: Mark Nottingham Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15232388127303200" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e3b95fa8 Date: Mon, 09 Apr 2018 11:53:32 +1000 References: <1523237197.698706.1330964576.6728B2BC@webmail.messagingengine.com> <43207A19-6ADB-4E06-9965-7052DC0E3732@mnot.net> In-Reply-To: <43207A19-6ADB-4E06-9965-7052DC0E3732@mnot.net> Archived-At: Subject: Re: [Jmap] HTML email security considerations X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 01:53:35 -0000 This is a multi-part message in MIME format. --_----------=_15232388127303200 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 9 Apr 2018, at 11:30 AM, Mark Nottingham wrote: > You might want to refer to https://www.w3.org/TR/referrer-policy/ Yes, good idea. I've now added this as a mitigation for referrer leakage. > It might also be worthwhile to ping the W3C WebAppSec WG for a review:> https://www.w3.org/2011/webappsec/ Thanks, have done. Cheers, Neil. --_----------=_15232388127303200 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 9 Apr 2018, at 11:30 AM, Mark Nottingham wrote:
You might want to refer to https://www.w3.org/TR/referrer-policy/

Yes, good idea. I've now added this as a mitigation for referrer leakage.

It might also be worthwhile to ping the W3C WebAppSec WG for a review:

Thanks, have done.

Cheers,
Neil.
--_----------=_15232388127303200-- From nobody Sun Apr 8 19:19:06 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23409127337 for ; Sun, 8 Apr 2018 19:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF0SiOjNpMbb for ; Sun, 8 Apr 2018 19:19:03 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23001127136 for ; Sun, 8 Apr 2018 19:19:03 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id y46-v6so6975667otd.4 for ; Sun, 08 Apr 2018 19:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ln6ki63MXGdLsN7pVl3X16s++bqFf09mGsiAJZW/g8E=; b=SLBI++g1ZTYhag42eT9f90aRntOsgdF21NSaI2FScntbwt/NyMGrzY+HAJgGPlmtgg n6vAP2ShiqJgJX20RFk9EYUDQi3pu1/wLrvVjO1tfcTohBN+61cIELH4F29+ZPXOmXf1 Yuae0pXCUHQIg6j7W5f9Hc0Fm0eawYmDEA27mLdm+FpPm3YsAzI9e2Y+gdY3WJDE6zDd mcZhsqhubuF04bq1FS53h9eKdqJ6zC6V8HJsowu4SMiWymXtljq90IKa/Lp28n6Dr/Bm y7Y3kVE5Vk3fA8CUhbT4y+KtBWUQY396oTXptyAkn57+PRsPKkGU77RIaGZsjpqYh8JM rP6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ln6ki63MXGdLsN7pVl3X16s++bqFf09mGsiAJZW/g8E=; b=Q13XRKn/T4cDLS4o+ozBcxU6F+vDIPlAFLjYTyiqxoDn5GO54erKkDHlr+Ua+w+11u o53chve9QpaJpdBBwjvqY684El+niH6LdCQx+2KBI1BaKMuScW1/Fs2QKS0/mdtOQTfn OffVGvs4jB0c1q/hN0v5B655UYUSCWQFKB4RZJkMxChbMdcYCRLaPSsh95+h0VrbHxrp 3HvChO1+MdIr6AqYQXDU4USUqTjgMwwrFwInQ0QNbbGLVfaovT97ng83KdI/soq2Dyv6 EP1xjrsb2NayBxM36Kdh5P7EfkbYHFVjWgF2NEBBBj1hjwjlEUqO/x/K5c9l0EK4voJt J5Cg== X-Gm-Message-State: ALQs6tB8/gUfRI1WTZExE9Bqgm+C195GJROwN3GA0HO1ywm80G9NEQRt gEmH3YL30dmSC+wgekxQQWLFVbtotqZ8bAeIuWtGK8Pw X-Google-Smtp-Source: AIpwx49kTm0VlkfaLOhdZ2+b5chempT0C107pO9afp3QdNcWh0pH+w0gGePrilqaAlZZEYNfQECl68eN7MiKYl135wc= X-Received: by 2002:a9d:6001:: with SMTP id h1-v6mr12507612otj.283.1523240342261; Sun, 08 Apr 2018 19:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Sun, 8 Apr 2018 19:19:01 -0700 (PDT) In-Reply-To: <1523237197.698706.1330964576.6728B2BC@webmail.messagingengine.com> References: <1523237197.698706.1330964576.6728B2BC@webmail.messagingengine.com> From: Martin Thomson Date: Mon, 9 Apr 2018 12:19:01 +1000 Message-ID: To: Neil Jenkins Cc: IETF JMAP Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] HTML email security considerations X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 02:19:05 -0000 > If JavaScript is allowed to execute it can rewrite email to change its co= ntent on subsequent opening, allowing users to be mislead. In webmail syste= ms it can access and exfiltrate all user content accessible via the browser= , including all other emails and potentially contacts, calendar events, set= tings, and login credentials. It can also rewrite the interface to undetect= ably phish passwords. The point here is that a webmail system might render HTML in its own origin, which will mean that JS will run in that origin. As you say, that's a complete compromise of all state available to the webmail system and gives the attacker all capabilities not explicitly disabled by a CSP (which - given typical webmail client capabilities, won't exclude much). You would point out that a compromise like this is likely persistent: get pwned once and that pwnage can be persistent. A webmail system doesn't have to render HTML in its own origin, which is actually a great defense. But that could limit what it can do. It might also have other costs related to the use of other origins. p.s., Old man observation: my spellchecker doesn't object to "pwned" as a word. What a world we live in. On Mon, Apr 9, 2018 at 11:26 AM, Neil Jenkins wrot= e: > This is an important security consideration for client vendors, and getti= ng > this right may help vendors avoid various security pitfalls in the future= , > so it would be good to have a few eyeballs to check I've covered the > essential points in sufficient detail. I've created a pull request for > review, content copied below for convenience. > > ------ > > HTML message bodies provide richer formatting for emails but present a > number of security challenges especially when embedded in a webmail conte= xt > in combination with interface HTML. Clients that render HTML email should > make careful consideration of the potential risks, including: > > If JavaScript is allowed to execute it can rewrite email to change its > content on subsequent opening, allowing users to be mislead. In webmail > systems it can access and exfiltrate all user content accessible via the > browser, including all other emails and potentially contacts, calendar > events, settings, and login credentials. It can also rewrite the interfac= e > to undetectably phish passwords. > HTML documents may load content directly from the internet, rather than j= ust > referencing attached resources. For example you may have an tag wit= h > an external src attribute. This may leak to the sender when a message is > opened, as well as the IP address of the recipient. Cookies may also be s= ent > and set by the server, allowing tracking between different emails and eve= n > website visits and advertising profiles. > In webmail systems, CSS can break the layout or create phishing > vulnerabilities. For example, the use of position:fixed can allow an emai= l > to draw content outside of its normal bounds, potentially clickjacking a > real interface element. > If not inside a separate frame in a webmail context, any styles defined i= n > CSS rules will apply to interface elements as well if the selector matche= s, > allowing the interace to be modified. Similarly, any interface styles tha= t > match elements in the email will alter their appearance, potentially > breaking the layout of the email. > The link text in HTML has no neccessary correlation with the actual targe= t > of the link, which can be used to make phishing attacks more convincing. > Links opened from an email may leak private info in the Referer header se= nt > by default in most systems. > > Sanitizing HTML to mitigate these issues is tricky. Using a well-tested > library with a carefully vetted whitelist-only approach is the safest way= to > avoid vulnerabilities. New features with unexpected security characterist= ics > may be added to HTML rendering engines in the future; a blacklist approac= h > is likely to result in security issues. > > A defence in depth approach can help to mitigate the risks of HTML email. > Webmail systems are strongly encouraged to use a strong Content Security > Policy as a second line of defence to block malicious content should it > manage to evade the filter. > > Subtle differences in parsing of HTML can introduce security flaws: to > filter with 100% accurately you need to use the same parser when sanitizi= ng > that the HTML rendering engine will use. > > As highly complex software components, HTML rendering engines increase th= e > attack surface of a client considerably, especially when being used to > process untrusted, potentially malicious content. Serious bugs have been > found in image decoders, JavaScript engines and HTML parsers in the past, > which could lead to full system compromise. Clients using an engine shoul= d > ensure they get the latest version and continue to incorporate any securi= ty > patches released by the vendor. > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > From nobody Sun Apr 8 21:38:35 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE112751F for ; Sun, 8 Apr 2018 21:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=VtQoPRtg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NKG5PSFn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB_7jPI4XNdY for ; Sun, 8 Apr 2018 21:38:30 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE601252BA for ; Sun, 8 Apr 2018 21:38:29 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 1E9E521003 for ; Mon, 9 Apr 2018 00:38:29 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 09 Apr 2018 00:38:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=pRfZr6cuwXhVppJhVNlreWdCsUJ6bQcwiGNFGYHNI N8=; b=VtQoPRtg5LMxnqsprSqf76S73NjRbHPAOuLjGHIrriv7zi9kJTL2iAuYr WWEPb8Bg3Pa5HmN2CZYSr7lf5w1ROq0NG7hnfBoUa3rk2RuECoxtinkTFPoI2JJv 3lMv519rZdSLv91J+ybzDM3smLuK8NJsnqjiYZuehlWVCYAnVbu+vj2kFk76O8J4 ZwcG68acYfwLTx4CNdk480wNFKaJeHcaTNnGzCzR8u5lHBPHPPQx7BpG3pWpZnxg 4On52aVhNPzjAMrjgNJd1/bTee0udKucy9n9ufX2XLD1zFoTFJ66WQifRQnPCDV0 FFouKbQlVnEZmtmVchb4WAKjGGv8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=pRfZr6cuwXhVppJhVNlreWdCsUJ6b QcwiGNFGYHNIN8=; b=NKG5PSFndAraarqw0Gyj9W+r1JsUIvI74m7C8O1ObuY/I 8A5RzAL0e2hqR7MpyR2MGPSleXwTZ5VVHDx0jRrUrlmtw1EQ/n+SMXYHgdHlrSdv iWSwrTqCM55cVS84ag9GyXdRnQZ/SXvd/+6MYcWiRhJEs1nK5tyruL+AglWb6xli XspxlaosajqFZq7D73lFvsBQ7XcOpWsI4OdmhoclzYyMB673eIX+gs0IgBL/Vim/ L3t3c7/ltGoA93udbC2f/JBNCq9x/tTsYM7ojDQy7B85Mjk7cEaNcJenI5EdC4m1 7gZ5eeXz2wx28bAqPPN1PVury8Ote1rTvOTKBeFnQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B669AE20CD; Mon, 9 Apr 2018 00:38:28 -0400 (EDT) Message-Id: <1523248708.888256.1331080240.4B9BDEE7@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15232487088882560" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e3b95fa8 Date: Mon, 09 Apr 2018 14:38:28 +1000 Archived-At: Subject: [Jmap] Adding optional createdId property to Request/Response object X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 04:38:33 -0000 This is a multi-part message in MIME format. --_----------=_15232487088882560 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I presented this briefly in London, but before merging the pull request[1] I just wanted to post this to the list to check it's clear and people agree this is valuable. You can check the diff in the pull request, but essentially this change adds an optional extra property you can send with a request which contains an initial map of creation id => server-assigned "real" id for records. This is primarily to allow for easier proxying of JMAP requests. For example, suppose you had this request, presuming a Foo object with a name property, and a Bar object with a name property, and a fooId property that references a Foo: { "using": [ ... ], "methodCalls": [ ["Foo/set", { "accountId": "1", "create": { "k31": { "name": "1st object" } } }, "1"], ["Foo/set", { "accountId": "2", "create": { "k32": { "name": "2nd object" } } }, "2"], ["Bar/set", { "accountId": "1", "create": { "k31": { "name": "3rd object", "fooId": "#k31" } } }, "3"], ] }A proxy server may wish to proxy the method calls to different backends depending on the accountId. In order to do so it needs to split this into 3 JMAP requests, each with a single method call, make the requests in order, then combine the results. However, to do this without the proposed createdId change, the proxy would have to resolve the "fooId" reference itself. This requires understanding the structure of the Bar object (knowing that the fooId property is a reference to a Foo object), making the proxy much harder to write, when it shouldn't need to know this information. With the proposed change, the proxy can do this. To server 1: { "using": [ ... ], "methodCalls": [ ["Foo/set", { "accountId": "1", "create": { "k31": { "name": "1st object" } } }, "1"], ], "createdIds": {} }Response from server 1: { "methodResponses": [ ["Foo/set", { "accountId": "1", "created": { "k31": { "id": "84291" } } ... }, "1"], ], "createdIds": { "k31": "84291" } }Then request to server 2 just passes the received createdId object on: { "using": [ ... ], "methodCalls": [ ["Foo/set", { "accountId": "2", "create": { "k32": { "name": "2nd object" } } }, "2"], ], "createdIds": { "k31": "84291" } }and similarly the object returned from this call is passed on to the final request to server 1 again: { "using": [ ... ], "methodCalls": [ ["Bar/set", { "accountId": "1", "create": { "k31": { "name": "3rd object", "fooId": "#k31" } } }, "3"], ], "createdIds": { "k31": "84291", "k32": "7333adf1" } }The proxy then just has to concatenate the methodResponses arrays from the different calls to return to the client. Importantly, you can now write a very light-weight JMAP proxy that does useful things without having to understand anything specific about the methods it is proxying. Any comments/objections/clarifications please let me know, otherwise I'll merge this next week. Cheers, Neil. Links: 1. https://github.com/jmapio/jmap/pull/198 --_----------=_15232487088882560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I presented this briefly in London, but before merging the pull request I just want= ed to post this to the list to check it's clear and people agree this is va= luable. You can check the diff in the pull request, but essentially this ch= ange adds an optional extra property you can send with a request which cont= ains an initial map of creation id =3D> server-assigned "real" id for re= cords. This is primarily to allow for easier proxying of JMAP requests.
=

For example, suppose you had this request, presuming a Foo object with= a name property, and a Bar object with a name property, and a fooId proper= ty that references a Foo:

{
    "using": [ ... ],
    "methodCalls": [
        ["Foo/set", {
            "accountId": "1",
            "create": {
                "k31": {
                    "name": "1st object"
                }
            }
        }, "1"],
        ["Foo/set", {
            "accountId": "2",
            "create": {
                "k32": {
                    "name": "2nd object"
                }
            }
        }, "2"],
        ["Bar/set", {
            "accountId": "1",
            "create": {
                "k31": {
                    "name": "3rd object",
                    "fooId": "#k31"
                }
            }
        }, "3"],
    ]
}
A proxy server may wish to proxy the method calls to = different backends depending on the accountId. In order to do so it needs t= o split this into 3 JMAP requests, each with a single method call, make the= requests in order, then combine the results.

However, to do this without the proposed createdId change, t= he proxy would have to resolve the "fooId" reference itself. This requires = understanding the structure of the Bar object (knowing that the fooId prope= rty is a reference to a Foo object), making the proxy much harder to write,= when it shouldn't need to know this information.

With the proposed change, the proxy can do this. To server 1:

{
    "using": [ ... ],
    "methodCalls": [
        ["Foo/set", {
            "accountId": "1",
            "create": {
                "k31": {
                    "name": "1st object"
                }
            }
        }, "1"],
    ],
    "createdIds": {}
}

Response from serve= r 1:

{
    "methodResponses": [
        ["Foo/set", {
            "accountId": "1",
            "created": {
                "k31": {
                    "id": "84291"
                }
            }
            ...
        }, "1"],
    ],
    "createdIds": {
        "k31": "84291"
    }
}

Then request to ser= ver 2 just passes the received createdId object o= n:

{
    "using": [ ... ],
    "methodCalls": [
        ["Foo/set", {
            "accountId": "2",
            "create": {
                "k32": {
                    "name": "2nd object"
                }
            }
        }, "2"],
    ],
    "createdIds": {
        "k31": "84291"
    }
}

and similarly the o= bject returned from this call is passed on to the final request to server 1= again:

=
{
    "using": [ ... ],
    "methodCalls": [
        ["Bar/set", {
            "accountId": "1",
            "create": {
                "k31": {
                    "name": "3rd object",
                    "fooId": "#k31"
                }
            }
        }, "3"],
    ],
    "createdIds": {
        "k31": "84291",
        "k32": "7333adf1"
    }
}

The proxy= then just has to concatenate the methodResponses arrays from the different= calls to return to the client. Importantly, you can now write a very light= -weight JMAP proxy that does useful things without having to understand any= thing specific about the methods it is proxying.


Any comments/objections/clarifications please let me know, otherwise I= 'll merge this next week.

Cheers,
Neil.
--_----------=_15232487088882560-- From nobody Sun Apr 8 22:35:58 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC16120454 for ; Sun, 8 Apr 2018 22:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=qnpNhoR/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nL0qG70W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WD9kYERSRC4 for ; Sun, 8 Apr 2018 22:35:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330D21205F0 for ; Sun, 8 Apr 2018 22:35:56 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id F314D20F50; Mon, 9 Apr 2018 01:35:54 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 09 Apr 2018 01:35:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=L0bLv5 W1U31SgAUgRLaborJuuc0cqmlsyKnJMTh7dVU=; b=qnpNhoR/zB0QTxFTSJ8yrW /EtUWJiCBnbEafy4Akl23UHhC8hK+0WlYRZ8tCWAIzSpAdZwFYZwezR5gDacnLtb eK4EnMkMrIA9e8O2Hva5tu8ZP1fLsaxKqb1udD8QL5Mm5BGd1VEwneLxHl3WhXtf iSXdciZZHKE/9Za6zvrk1NPYVjbg9VISR8m57rNLAxp6wdal6zbaXuTVNm9sqs1e 0AiFb15vxyoKcN+xzc4F15BHJZJ605LIclz/shYI7Ak+CMdLINsA448M2dU87EL6 TTLX5HKzmM5bqlEXN8fR6SR/PBo6liimm6edN6yWq7RjO/gbsLZyQv0UzmewkeUA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=L0bLv5 W1U31SgAUgRLaborJuuc0cqmlsyKnJMTh7dVU=; b=nL0qG70WBogWeBzTV//lEo LK7RpyOcGIDHZO/ZukN7bwDvdUE5u6FClFYvUDJW9v8jfL0msEU/7F3iOosT1bnS g3HoAmMu61IoVd4A/vfb8TdqM7ZDm/r4wfEUN+uodA2ZCo4HgSi34E+RQeE8WM2a bT06MIjMR7u0Vek8EBDIy54RvkdKbop5u3oHCXXHKLln0lmrs7aRJ0d26+D8VD1J tnRzeT+2pRBM2JtPsq1NfeWA136YxuOtUA/6ik/5fhBMNxUywppPQyZq8PIpptTj erfScfzi9lZXVO+yDhOPR5STP+hEyq9pYq6e97WfvWztz/sAvAwgXmbQ8koTRnBg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A6FA3E20CD; Mon, 9 Apr 2018 01:35:54 -0400 (EDT) Message-Id: <1523252154.942536.1331113624.2228D43B@webmail.messagingengine.com> From: Neil Jenkins To: Martin Thomson Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15232521549425360" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e3b95fa8 Date: Mon, 09 Apr 2018 15:35:54 +1000 In-Reply-To: References: <1523237197.698706.1330964576.6728B2BC@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] HTML email security considerations X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 05:35:58 -0000 This is a multi-part message in MIME format. --_----------=_15232521549425360 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Mon, 9 Apr 2018, at 12:19 PM, Martin Thomson wrote: > The point here is that a webmail system might render HTML in its own > origin, which will mean that JS will run in that origin. > =E2=80=A6=20 > You would point out that a compromise like this is likely persistent Good points. I've updated this paragraph to the following: *If JavaScript is allowed to execute it can rewrite email to change its content on subsequent opening, allowing users to be mislead. In webmail systems, if run in the same origin as the interface it can access and exfiltrate all user content accessible via the browser, including all other emails and potentially contacts, calendar events, settings, and credentials. It can also rewrite the interface to undetectably phish passwords. A compromise is likely to be persistent, not just for the duration of page load, due to exfiltration of session credentials or installation of a service worker that can intercept all subsequent network requests (this however would only be possible if blob downloads are also available on the same origin, and the service worker script is attached to the message).* Neil. --_----------=_15232521549425360 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Mon, 9 Apr 2018, at 12:19 PM, Martin Thomson wrote:
The point here is that a webmail system might render HTML = in its own
origin, which will mean that JS will run in that origin.
=E2=80=A6
You would point out that a compromise like this is likely persistent

Good points. I've updated this paragraph to the following:

If JavaScript is allowed to execute it can rewrite email to change = its content on subsequent opening, allowing users to be mislead. In webmail= systems, if run in the same origin as the interface it can access and exfi= ltrate all user content accessible via the browser, including all other ema= ils and potentially contacts, calendar events, settings, and credentials. I= t can also rewrite the interface to undetectably phish passwords. A comprom= ise is likely to be persistent, not just for the duration of page load, due= to exfiltration of session credentials or installation of a service worker= that can intercept all subsequent network requests (this however would onl= y be possible if blob downloads are also available on the same origin, and = the service worker script is attached to the message).

Neil.
--_----------=_15232521549425360-- From nobody Mon Apr 9 17:10:01 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B350D120713 for ; Mon, 9 Apr 2018 17:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=WgaR23vW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e4h3J7jQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM776_nOSFHt for ; Mon, 9 Apr 2018 17:09:59 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27082120227 for ; Mon, 9 Apr 2018 17:09:59 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8D4EE212FC for ; Mon, 9 Apr 2018 20:09:58 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 09 Apr 2018 20:09:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=HLeKG7TcW9cG24njq0F06C1+f4m4AtCHndz2e16Ej60=; b=WgaR23vW ENSRAMetDMwT2YB1qxAE4puwdZZTluMx0hSvaj1xIofSd7HzJc6nLHT9yA1HL/96 bh4BuGn6j9HzBvCHeiFpPo2ySC6bDSYvzcjVQquCJjya3c6m6/gvfT+fGRzeI0zg gxkxc1MZLTXXU1OI89ukgZOJb2JlX9TEz4u7nlyO77trk+p2YR9CniRoc9ULZ/Az kYPsrGN+8ioASN7YY7mFTzvismYT1N+T/lOB/bGIyIYyfm0c3eqf6IPgHA1qHa8M qzdCHrBvh/5QcuXzwcLHSAuoL6PcwO8bL7N3GbrUPZuKKF+fYXtDbTUjcx6t3KKr kPktgVxPjCZTBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=HLeKG7TcW9cG24njq0F06C1+f4m4A tCHndz2e16Ej60=; b=e4h3J7jQYqVVosSt+5GH0zMWLuhNELKKmDffybyBsILF5 6LbV/YrgpGYPNBZy3E6+t5WpvbpgSb8+LKdGjtZI1PMLUloAIDPkSloruXTymcrA HnmJLFJh1s1qP8o0OG38J/cRUwii60E5J8aV4EBEhf0hEsT7y82q16We8p4ojZ9o vklskDJknnkwoh9/U57wN2IamkfK62w6eJs2Oj1wuhGvp8jKciKc26P/YRrmCIeH OFwK0Xt2yyz44zdTd7PDXwzbS1nCScuo0OZoXXxKJxfusnLcKJbG7GxwaY/ZyP7W lmU45PjNJe+LnOqNAKba374F2EfCTykOOw++VmEjQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5BC259E09F; Mon, 9 Apr 2018 20:09:58 -0400 (EDT) Message-Id: <1523318998.3479527.1332298776.3ABB64D1@webmail.messagingengine.com> From: Robert Mueller To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152331899834795270" X-Mailer: MessagingEngine.com Webmail Interface - ajax-61ab7380 Date: Tue, 10 Apr 2018 10:09:58 +1000 Archived-At: Subject: Re: [Jmap] Adding optional createdId property to Request/Response object X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 00:10:00 -0000 This is a multi-part message in MIME format. --_----------=_152331899834795270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" > The proxy then just has to concatenate the methodResponses arrays from > the different calls to return to the client. Importantly, you can now > write a very light-weight JMAP proxy that does useful things without > having to understand anything specific about the methods it is > proxying.> > Any comments/objections/clarifications please let me know, otherwise > I'll merge this next week. Shouldn't the creation id's be separate for each type, since the spec already mentions that "Creation ids are scoped by type; a separate creation id -> id map MUST be kept for each type for the duration of the request". So I think it should be: "createdIds": { "Foo": { "k31":"84291", ... } } Rob Mueller robm@fastmailteam.com --_----------=_152331899834795270 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

The proxy then just has to concatenate the methodRespo= nses arrays from the different calls to return to the client. Importantly, = you can now write a very light-weight JMAP proxy that does useful things wi= thout having to understand anything specific about the methods it is proxyi= ng.


Any comments/objections/clarifications please let me know, otherwise I= 'll merge this next week.

Shouldn't the creation id's be separate f= or each type, since the spec already mentions that "Creation ids are scoped= by type; a separate creation id -> id map MUST be kept for= each type for the duration of the request".

So I think it should be:

  "createdIds": {
<= /div>
    "Foo": {=
      "k3= 1":"84291", ...
}
}

Rob Mueller

--_----------=_152331899834795270-- From nobody Mon Apr 9 18:20:42 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB86C126B72 for ; Mon, 9 Apr 2018 18:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=nhZYb/kj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Su2cWyHD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFBx1H4jbgT6 for ; Mon, 9 Apr 2018 18:20:39 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AD51201F8 for ; Mon, 9 Apr 2018 18:20:39 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id AB92E2196D for ; Mon, 9 Apr 2018 21:20:38 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 09 Apr 2018 21:20:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8MA5SNi5kfenFmVKL 0/r6xnqm9jAf/7vQ99WhA9RjJI=; b=nhZYb/kjfA/kkvWEqhtOMzAMcrPCeYigk aBXoMEBsuKFSLEe4Gkc2Y2nYNgo4iMK6T9AbX0iWj7jXT8en3+rR82GsG3Sw/igX QVuYMy/XyL/Hojqh8qMWPeHnl0gk/GZKIjlWejIBciBq468yyDNiCXxnTTTr/b+x gmp1cbxs9bZiP1sftuSozbrNM/ad8p12kb+Wr4f8SulA1fZEBrxApnUbpuWKx0St nATmcjKZ+SR5GZh1BwfAiJu+rSiLA3zkEdtnKmX5TpofakmpiMGZv0NO3Dl73h6E fxLoBtz0zUq+hKYM1AuQtk4q4OpI9S1KtpxhEb+wm18FZDRG36rrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8MA5SN i5kfenFmVKL0/r6xnqm9jAf/7vQ99WhA9RjJI=; b=Su2cWyHDCSsdl3cLO3W0K/ Al6gF8Yr+q4ekQxKSCQ+OYLr83Pg09TcFiKAi02GH0fLvjKi8s34In9kT6pYkk3p 0bHU/YaidWYKZWdP831h/tEVVO1xf7cwBy0YwNYtzy9/KZx6/faSv5nTKegMLyfm VnVxSy1zUehgekEJN94IRutDadMmSJWlkSUQjUWMt8L02DR1DTEvGvBSvvGYmdat 89iOKf5dHW8VB0xBX4ym3n9itzasDwmnpOlhaL6YXiKindrsTdySJS0Jha8icrAz HtC3B5gTr6Rv46vzfl8WJayGRN7+6LnRfkf3dPiH420ngnzMT9xgXlDafKVmKEOw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 616B4E2148; Mon, 9 Apr 2018 21:20:38 -0400 (EDT) Message-Id: <1523323238.2139225.1332347784.65CC2A14@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152332323821392250" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e3b95fa8 References: <1523318998.3479527.1332298776.3ABB64D1@webmail.messagingengine.com> In-Reply-To: <1523318998.3479527.1332298776.3ABB64D1@webmail.messagingengine.com> Date: Tue, 10 Apr 2018 11:20:38 +1000 Archived-At: Subject: Re: [Jmap] Adding optional createdId property to Request/Response object X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 01:20:41 -0000 This is a multi-part message in MIME format. --_----------=_152332323821392250 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 10 Apr 2018, at 10:09 AM, Robert Mueller wrote: > Shouldn't the creation id's be separate for each type, since the spec > already mentions that "Creation ids are scoped by type; a separate > creation id -> id map MUST be kept for each type for the duration of > the request". This is also changed in the pull request, to make implementation simpler. There's a single map of creation id => real id, and it's up to the client to ensure it doesn't reuse a creation id. Neil. --_----------=_152332323821392250 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 10 Apr 2018, at 10:09 AM, Robert Mueller wrote:
Shouldn't the creation id's be separate for each type, since the spec already mentions that "Creation ids are scoped by type; a separate creation id -> id map MUST be kept for each type for the duration of the request".

This is also changed in the pull request, to make implementation simpler. There's a single map of creation id => real id, and it's up to the client to ensure it doesn't reuse a creation id.

Neil.
--_----------=_152332323821392250--