[OAUTH-WG] OAuth leakage via third-party content, 'Referer' header and Referrer-Policy (draft-ietf-oauth-security-topics)
Rodrigo Speller <rspeller@primosti.com.br> Tue, 14 February 2023 23:57 UTC
Return-Path: <rspeller@primosti.com.br>
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 E47B7C18798B for <oauth@ietfa.amsl.com>; Tue, 14 Feb 2023 15:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=primosti.com.br
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMQazfvBztKS for <oauth@ietfa.amsl.com>; Tue, 14 Feb 2023 15:57:28 -0800 (PST)
Received: from mail.primosti.com.br (eagle.primosti.com.br [69.64.62.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD65C187986 for <oauth@ietf.org>; Tue, 14 Feb 2023 15:57:28 -0800 (PST)
Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by mail.primosti.com.br (PrimosTI-Mail) with ESMTPSA id A3D6D73C for <oauth@ietf.org>; Tue, 14 Feb 2023 23:57:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primosti.com.br; s=v1; t=1676419046; bh=3kt+hqpN2M3kfZy5Q2V5pyz/ICLGJVQAHYkEdb7oUUY=; h=From:Date:Subject:To:Cc; b=N87qFDpqhTpXarOKNsbL+0fz3KZkuWygSLPunvQH9tG7NteELhWMMAbXeblSWq1XO J2Qzqzyv5SlnFEdM/eI5kCfOg4aA288TnVyCubOQ7GhmykZnjcLCuMU38vxoQK4Vg+ MePjqFP3vfozH1/MGV5I1lSu1CaOcaYbFRDp+ohdAPs152YdP+3bwDTyVD/RvksaLi UCgy4emEcSGlUWdo5V89FC3WE74yKr2XqmZdo7TrirR7Mthzt9r1ISx6mpH3mtWnxe 4n9bxusyMNYqw8WyaOOcAEnyrUoPcMKDcARR4QVm7pM1eRfuNwkQqFJDptRwYQ7qnA PULEbVRX7Ay+g==
Received: by mail-pg1-f178.google.com with SMTP id 7so11386103pga.1 for <oauth@ietf.org>; Tue, 14 Feb 2023 15:57:26 -0800 (PST)
X-Gm-Message-State: AO0yUKUhuX+ijWMbo4OwspAftfbN7wFLf7hYuZ7ETulOu/FOO/aei7qj I0lF0AvUDyGJPGoefsbBoMjy8TcXnWcV6xyAmms=
X-Google-Smtp-Source: AK7set8+uW1jt9j4N7fLV5lC8WwzTUFdeZcj4DNyuw2m2o201I20Wlzn0utnfkNpX+WG0DkOc5wFWYyzrY2H+OJS/9c=
X-Received: by 2002:a63:7881:0:b0:4fb:7b94:46e0 with SMTP id t123-20020a637881000000b004fb7b9446e0mr24917pgc.129.1676419045626; Tue, 14 Feb 2023 15:57:25 -0800 (PST)
MIME-Version: 1.0
From: Rodrigo Speller <rspeller@primosti.com.br>
Date: Tue, 14 Feb 2023 20:57:07 -0300
X-Gmail-Original-Message-ID: <CADom2f0VcVtQLE3UYf4_4Ht=5Neizc_-fWKzkLud5CmAJp+XCg@mail.gmail.com>
Message-ID: <CADom2f0VcVtQLE3UYf4_4Ht=5Neizc_-fWKzkLud5CmAJp+XCg@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b59c2805f4b1b958"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/UfqwifRskqn_zaKkQ-r1ajiVZEA>
Subject: [OAUTH-WG] OAuth leakage via third-party content, 'Referer' header and Referrer-Policy (draft-ietf-oauth-security-topics)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2023 23:57:33 -0000
Hi, I have few comments about leakage via third-party content, 'Referer' header, Referrer-Policy and the underlying assumptions: In the OAuth and OpenID good practices and specifications, I miss the use of the 'Referer' header as a way to validate the origin of the calling page. It seems to me that the current document ('oauth-security-topics') is a great point to open this discussion. The 'Referer' header value can be obtained by the client application from the request in the backend and even in the frontend (through javascript - `document.referrer`), since the first versions of the browsers. We know that the concern is not about how the client application can get the value of the referrer, but how to protect against leaking the authorization parameters through this header. So, we have available the "Referrer-Policy" specification. Referrer-Policy is already widely implemented, including in not-so-modern browsers. The draft-ietf-oauth-security-topics-21, Section 4.2 ("Credential Leakage via Referer Headers"), discusses part of this issue. However, in Section 4.2.4 ("Countermeasures"), in the first measure, an example is cited, indicating the use of "Referrer-Policy: no-referrer". I understand that this is just an example about how to apply Referrer-Policy, but I suggest encouraging the use of "Referrer-Policy: origin" instead of "Referrer-Policy: no-referrer". The use of "Referrer-Policy: origin" should not bring any security breaches, as only the "schema://host:port" part of the referrer is passed on, opening up another possibility of protection against CSRF when validating this value (origin or site validations), mainly when using the GET method. ======================================================================== Therefore, I suggest that in the first measure of Section 4.2.4, the text be changed from: 4.2.4. Countermeasures The page rendered as a result of the OAuth authorization response and the authorization endpoint SHOULD NOT include third-party resources or links to external sites. The following measures further reduce the chances of a successful attack: * Suppress the Referer header by applying an appropriate Referrer Policy [webappsec-referrer-policy] to the document (either as part of the "referrer" meta attribute or by setting a Referrer-Policy header). For example, the header Referrer-Policy: no-referrer in the response completely suppresses the Referer header in all requests originating from the resulting document. To: 4.2.4. Countermeasures The page rendered as a result of the OAuth authorization response and the authorization endpoint SHOULD NOT include third-party resources or links to external sites. The following measures further reduce the chances of a successful attack: * Reduce the Referer header by applying an appropriate Referrer Policy [webappsec-referrer-policy] to the document (either as part of the "referrer" meta attribute or by setting a Referrer-Policy header). For example, the header "Referrer-Policy: origin" in the response will only inform the values of the scheme, host and port on Referer header in all requests originating from the resulting document. ======================================================================== Configuring the client application and the AS to inform the origin in the Referer header should be considered a good practice, bearing in mind that this could be very useful for applications to have one more validation criterion to prevent the attacks described in: - 4.1. Insufficient Redirect URI Validation - 4.2. Credential Leakage via Referer Headers - 4.4. Mix-Up Attacks - 4.5. Authorization Code Injection - 4.6. Access Token Injection - 4.7. Cross Site Request Forgery - 4.8. PKCE Downgrade Attack - 4.10. Open Redirection However, I am not aware of any reference to these practices in any OAuth standard (RFC or OpenId). Perhaps it makes some sense, in addition to commenting about these aspects in this document, to also start a new document to specify the origin trust mechanisms, because, I believe , that we will need to configure the usage of these policies through the Discovery Endpoint metadata. Best regards, - Rodrigo Speller
- [OAUTH-WG] OAuth leakage via third-party content,… Rodrigo Speller