From nobody Thu Dec 3 02:13:31 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7A93A0E26 for ; Thu, 3 Dec 2020 02:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qed3m4Mz0b92 for ; Thu, 3 Dec 2020 02:13:28 -0800 (PST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 117AD3A0E21 for ; Thu, 3 Dec 2020 02:13:28 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id x17so1511875ybr.8 for ; Thu, 03 Dec 2020 02:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oVEyQYAp0CV3vCKEfDluEdP9nlQtmcwBgiZ4GYM/IHs=; b=nP6SR2DNjgtjE/kx7r3oxQY45i1tY08fWDOvlRXg0gYHJnlaTDdXX/vRumsM3zAduO iJ5qHtPk84zP3bkMrIcp7JyR/D+2EUf73d+EFFfumHPOayORumyTsIfMuFNh850o93V2 qQD/DM5LGdnEAZpYqJuom4KGiluWKeyyzzfqwwMzT14CUsz2aYgHCC/Cczeh8edH3ll1 4gST1Molmf1boZX+fM77AwrzUikSu1k9lwh+3a+NwDlbSyLAQhkOvPHfXXmtddvbmNR0 vR0UnnfTMzYh9Ujlp+9NrlUHr3jck3hSqxJpYfSDDFaBlbDmAy5gZyY/kX6w1CVtJ4bH z7zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oVEyQYAp0CV3vCKEfDluEdP9nlQtmcwBgiZ4GYM/IHs=; b=WvcWd8+OBlpxA+fWBirGTOAp6s/OesIzCdM1ZD7ps0IZFLDa8tTDCvfohiJ60CI3fH oOgIddSr+Fk0jrADW6pVRBbE4jRhpYlAGwky3ugpP1qAP8Tljn9vKmz9wT5YDEWuZQPX /ZrkCmnCLAwM+hA4A60Iszqv0XlPGkLenen3Ep5P3YxitPxY/ft3nkB/eCHPJlaNZAu/ r1KGl+qv0Rd8nhbz72oU/tTTIRt7MKdXCLmMAqCWvKYVk/XVM6GP4+STbGWM4uw+WZPg muCCI4y6gnDgtZyVQlx1kyPTUmkDlVNs1pnS59EKwyygRJMxlKHSNkA0x+1axq9OlSoL X+Hg== X-Gm-Message-State: AOAM531Oiw/u1XZXP6jSF1iSYZeoNE+EM46qzGVeN9OCtuBpXS7Hzg1e OhpYR6lm5uJD94RzQ91YNVTVa1rMfCSy8g30vAWCP5/hvw== X-Google-Smtp-Source: ABdhPJyQaH+gCO/WM8rtUmzcGcG/Q9kQuuMH0axKLPC2dMVt/wgfMYdcxQZ0XLVwitPIFMNU003E9k5W7OxA/eAFkJo= X-Received: by 2002:a25:209:: with SMTP id 9mr3644730ybc.127.1606990406991; Thu, 03 Dec 2020 02:13:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Thu, 3 Dec 2020 11:12:50 +0100 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000005dc38805b58c9cdf" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:13:30 -0000 --0000000000005dc38805b58c9cdf Content-Type: text/plain; charset="UTF-8" Please note that this simple validation (in combination with web application enforcing http(s) schemes) removes the need to implement and maintain a blocklist of potentially malicious schemes such as `javascript:/`, `vbscript:/`, and `data:/`. More details: https://security.lauritz-holtmann.de/post/sso-security-redirect-uri/ Best, *Filip* On Thu, 3 Dec 2020 at 10:59, Filip Skokan wrote: > Hello everyone, > > Both RFC 8252 and OAuth > 2.1 draft > > state that (paraphrasing) > > Apps MUST use a URI scheme based on a domain name under their control, >> expressed in reverse order, as recommended by Section 3.8 of [RFC7595] for >> private-use URI schemes. e.g. com.example.app:/ > > > My question is, is the AS right to reject client registrations that do not > follow this specific requirement, to e.g. reject myapp:/oauth2/example-issuer > on the account of it not being neither claimed https scheme, an http: + > loopback interface, nor having a "." (dot) character suggesting it is a > reverse domain scheme? > > Best, > *Filip* > --0000000000005dc38805b58c9cdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please note that this simple validation (in combination wi= th web application enforcing http(s) schemes) removes the need to implement= and maintain a blocklist of potentially malicious schemes such as `javascr= ipt:/`, `vbscript:/`, and `data:/`.

More details:=C2=A0<= a href=3D"https://security.lauritz-holtmann.de/post/sso-security-redirect-u= ri/" target=3D"_blank">https://security.lauritz-holtmann.de/post/sso-securi= ty-redirect-uri/

Best,
Filip


On = Thu, 3 Dec 2020 at 10:59, Filip Skokan <panva.ip@gmail.com> wrote:
Hello every= one,

Both RFC 8252 and OAuth 2.1 draft state that (paraphrasing)

Apps MUST use a URI scheme = based on a domain name under their control, expressed in reverse order, as = recommended by Section 3.8 of [RFC7595] for private-use URI schemes. e.g.= =C2=A0com.example.app:= /

My question is, is the AS right to reject client registrations t= hat do not follow this specific requirement, to e.g. reject=C2=A0myapp:/oauth2/example-issuer on the account=C2=A0of it not being neithe= r claimed https scheme, an http:=C2=A0+ loopback interface, nor having a &q= uot;." (dot) character suggesting it is a reverse domain scheme?
=
Best,
Filip
--0000000000005dc38805b58c9cdf--