Re: [OAUTH-WG] Endpoint Misconfiguration / Social Engineering Attack

Dave Tonge <> Thu, 08 October 2020 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 990D63A0DA6 for <>; Thu, 8 Oct 2020 05:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dLHQjeAPGNDr for <>; Thu, 8 Oct 2020 05:31:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D3553A0DAA for <>; Thu, 8 Oct 2020 05:31:08 -0700 (PDT)
Received: by with SMTP id cq12so5658160edb.2 for <>; Thu, 08 Oct 2020 05:31:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BNl++8G3agUWrybMppXr2hIEBeOQB4vSCXQr7g2N0j0=; b=BqH3vF4AWY4q9/F7NBk3oqyoLjSdTe9wzaHRZel5rRRHby8rZ+QJVv7px+S37LqErK W6/hHhF3jf/TfSOXRFlHhQaePdhCPTwuZTRVBoLNlQj+NgpIuNi0DYCe8hRishMcS7TU tgCYUoASS2pZP2qKGm9I1qfF56kPoJ/ZEcLkE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BNl++8G3agUWrybMppXr2hIEBeOQB4vSCXQr7g2N0j0=; b=A/YKyuiJ9JJX9IolNQgxuvI929JoVF2bPD55SPRQ9fE34LvL+hGjtGMGPc1TRGN2MS RBY5viXpDHFyaWFCNEF/Nl8TleiGhHY/pNtaYPbBLyMHE+eef1GhbQgEGh/Qhf0am5Ks AOUg0FebgBUqtz2GpDsdENMOqDWp6ym+KLQGpolPTx6y9yOTrF++M4ic4lRm2Gk7XqxN Oj8tzdidDFgWRig8X7SMVnko3fX5dehCGvOSeFTGyeSRoV+SQOhF0J4D/YjICoVczrTp Oeur9GzM/aE42d8zpTrvjLcef+t5XI4SkKvFfxArybsfAbat+d3FgS0m5Xa7kIeDShIF cOnA==
X-Gm-Message-State: AOAM531umwecODzGhtwfUntktlgbNSmDciAhUgjmBlteSqMbEbsXU1/B FdNJRayvQQ4O9oIT3+zLNSLJ/ex6Yo9aUw4eJYrIQ6ViYfShDgGAWtoeghjU06cIiigusnc0zwF AlLEISCJnFVyiy0s66jr2hw4y
X-Google-Smtp-Source: ABdhPJyj3vHrRXa2Q1adVHywJ+eAi5xENA0LyZl08R7kOMzo6ogcyIiKoLRy4Xe1rtqBsVGvEE6WWXezoykxTpdre5w=
X-Received: by 2002:a05:6402:744:: with SMTP id p4mr8505111edy.190.1602160266717; Thu, 08 Oct 2020 05:31:06 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dave Tonge <>
Date: Thu, 08 Oct 2020 14:30:55 +0200
Message-ID: <>
To: Guido Schmitz <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000009247e405b128012d"
Archived-At: <>
Subject: Re: [OAUTH-WG] Endpoint Misconfiguration / Social Engineering Attack
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, 08 Oct 2020 12:31:11 -0000

Hi Guido

We've also discussed this issue in the FAPI Working Group at the OpenID
We came to the conclusion that we should require the use of either RFC8414
or OpenID Connect Discovery.

I'd be in favour of adding the recommendation to the BCP.

I'm not aware of an attack in the wild in this area, but I'm definitely
aware of quite a bit of misconfiguration of clients. We've had a problem in
the UK OpenBanking space where alternative authorization endpoints were
communicated via email or hosted PDFs. In my mind this opens up social
engineering attacks that are much less likely when RFC8414 is used.


On Thu, 8 Oct 2020 at 14:18, Guido Schmitz <> wrote:

> Hi,
> We just had a discussion in Stuttgart on the possibility of
> misconfigured endpoints, i.e., an honest client uses the wrong endpoints
> for interacting with some honest AS. Such a setting might be the outcome
> of a social engineering attack against the administrators of a client
> (e.g., the attacker disguises as an AS support agent and convinces the
> client admin that some endpoint needs to be changed). If some endpoint
> is configured to a URL controlled by some adversary, critical data can
> leak and the attacker can even tamper with the requests to this endpoint.
> Is this a realistic attack scenario? Does anybody have more insight or
> data on this problem? (I think that such a scenario had been mentioned
> at some OSW discussion.)
> A potential mitigation against this problem could be the usage of AS
> metadata discovery (RFC8414). In this case, the client only needs to set
> the "issuer" to configure the endpoint URLs. A social engineering attack
> to change the issuer might be less likely as a social engineering attack
> to change some endpoint URLs (which a client admin might have less
> understanding of). Further, using AS metadata discovery also reduces the
> risk of misconfiguration at the client in general. Maybe it is a good
> idea to add a recommendation for the usage of RFC8414 in the security
> BCP. What do you think?
> Regards,
> Guido
> _______________________________________________
> OAuth mailing list



Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at 
<>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.