Re: [OAUTH-WG] Same Origin Method Execution (SOME)

Antonio Sanso <> Thu, 25 June 2015 10:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 66EAC1B352A for <>; Thu, 25 Jun 2015 03:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.254
X-Spam-Level: ***
X-Spam-Status: No, score=3.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vTthABxIa3uO for <>; Thu, 25 Jun 2015 03:48:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45A6B1B352B for <>; Thu, 25 Jun 2015 03:48:30 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 25 Jun 2015 10:48:27 +0000
Received: from ([]) by ([]) with mapi id 15.01.0201.000; Thu, 25 Jun 2015 10:48:27 +0000
From: Antonio Sanso <>
To: John Bradley <>
Thread-Topic: [OAUTH-WG] Same Origin Method Execution (SOME)
Thread-Index: AQHQrtd3Tpnpu59uf06O0m3GZFMlH529D7iA
Date: Thu, 25 Jun 2015 10:48:27 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1032; 5:VQoNtcmtk9JPCQC9+lJY61oKmS237i3m5ELEsL6aSHcF55tQU7R1bIepsrx2IvgGAcxSiZvTObpP97ijNAiNmeRm9zZEsH+QuKHWtA0pvLddKMKIKf2LgKzvqYpHuz1/G3CaFPLiCmYht934HEIWlw==; 24:lkcRZo/VHQmcmn507hTrAAsqmvAaL3WgeTh0CllG2GiJIxUusO8izIBjk6h+sSUGky6+9fNf6wtWgTfHPWnO+0AeT4Cvj4SVBmNo9fkiDq8=; 20:4A5SW50ho7O7DNNhq2JawWdUPE/Lo39FSIy7+UskhjYw2c7A+UTusX9GrVvoVj/F/P6GMMypmUbJtNZnBQz97g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1032;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0201MB1032; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1032;
x-forefront-prvs: 0618E4E7E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(243025005)(377454003)(24454002)(51914003)(46102003)(19617315012)(99286002)(106116001)(16236675004)(50986999)(5001920100001)(76176999)(54356999)(77096005)(1600100001)(102836002)(15975445007)(66066001)(83716003)(189998001)(92566002)(36756003)(87936001)(5001960100002)(2950100001)(2900100001)(62966003)(77156002)(2656002)(5002640100001)(122556002)(40100003)(82746002)(33656002)(19580395003)(19580405001)(110136002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1032;; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_51B1A21C4893403EAE0033F4B7827346adobecom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2015 10:48:27.0767 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1032
Archived-At: <>
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jun 2015 10:48:32 -0000

hi John

On Jun 25, 2015, at 1:42 AM, John Bradley <<>> wrote:

Thanks for the info,

As I read it, this is an attack on Java Script callbacks.

The information tying it to OAuth is not clear.

Is the issue relating to JS people using the implicit flow and the JS loaded from the client somehow being vulnerable?

Or is this happening in the JS after authorization in calls to other resources from the same origin, and it is just coincidence that people are using OAuth.

is more the second one :) Extrapolating from the white paper [0]

"The most common technique tasked with fullling
the above described need is OAuth. In order to gain access to third-party resources
using OAuth, the service shall utilize a third-party endpoint (OAuth dialog) that will
ask for the resource owner's approval. The problem with this process is that redirecting
the service to an OAuth dialog means losing the content of the currently open service
document. For overcoming this problem, developers open a pop-up window to display
the dialog in a singular browsing context. Once the user permits or denies access to
the service, the OAuth dialog pop-up will be redirected to render a callback endpoint
hosted on the service domain. This document should eventually notify the service that
the process has been completed.
For the new pop-up window to notify the service window upon approval, denial or for
it to transfer access tokens or similar data, developers may implement callback endpoints
that use a script referencing the "opener" window for executing a callback method of the
service. When developers also opted for providing the service with the decision on how
to "call it back" through a callback parameter, the entire domain becomes vulnerable to




Understanding if there is any Oauth specific advice to give would be helpful.   I see there are ways to prevent the SOME exploit.

John B.

On Jun 24, 2015, at 4:18 PM, Antonio Sanso <<>> wrote:

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth client endpoints due to some common developers pattern (concrete example in


OAuth mailing list<>