[Microsoft Login Connector] Security vulnerability in Microsoft Login Connector

[Microsoft Login Connector] Security vulnerability in Microsoft Login Connector

  
Forge Component
(5)
Published on 30 Nov (3 weeks ago) by Paul Davies
5 votes
Published on 30 Nov (3 weeks ago) by Paul Davies

Hi,

When implementing this connector in my companies applications I've noticed a unwanted effect of the way this component works; by passing parameters to the OAuthLogin webscreen, you are exposing your client-secret of your (Azure AD-) app to the client. Since these webrequests are before authentication, your client can be anyone with or without malicious intentions.

In detail the following happens:
From a application's logic flow (in outsystems) you do a navigate to the OAuthLogin webscreen (with filled in screen parameters). This results in a HTTP 302 with redirect to [environment]/MicrosoftLoginConnector/CommonFlow.OAuthLogin.aspx including (including query parameters!) to your client's browser. These calls can be inspected via various http sniffing tools including your browsers developer tools (f12 > network tab). See attached image.


Having your clientid and clientsecret exposed could be a massive breach; for example, I was able to get an Active directory token with my apps permissions via the client credential flow (grant_type = client_credential on the /oauth2/token endpoint).

Are you able to fix this / do you need some help? I think that the most easy solution lies with a server side lookup of the clientsecret in a config tabel based on the client id for example.


Regards, Rob



Hi Andreia Gaspar,

Has this vulnerability been addressed already?
It will be a pity if we start forking this component while the fix seems to be very straightforward. 


Kind regards,

Robin 



Rob Mooijman wrote:

Hi,

When implementing this connector in my companies applications I've noticed a unwanted effect of the way this component works; by passing parameters to the OAuthLogin webscreen, you are exposing your client-secret of your (Azure AD-) app to the client. Since these webrequests are before authentication, your client can be anyone with or without malicious intentions.

In detail the following happens:
From a application's logic flow (in outsystems) you do a navigate to the OAuthLogin webscreen (with filled in screen parameters). This results in a HTTP 302 with redirect to [environment]/MicrosoftLoginConnector/CommonFlow.OAuthLogin.aspx including (including query parameters!) to your client's browser. These calls can be inspected via various http sniffing tools including your browsers developer tools (f12 > network tab). See attached image.


Having your clientid and clientsecret exposed could be a massive breach; for example, I was able to get an Active directory token with my apps permissions via the client credential flow (grant_type = client_credential on the /oauth2/token endpoint).

Are you able to fix this / do you need some help? I think that the most easy solution lies with a server side lookup of the clientsecret in a config tabel based on the client id for example.


Regards, Rob



Hi Rob,


I now have access to publish this component so would be great to get you on the team to work on this fix if you still have time.

Thanks


Paul


Paul Davies wrote:

Rob Mooijman wrote:

Hi,

When implementing this connector in my companies applications I've noticed a unwanted effect of the way this component works; by passing parameters to the OAuthLogin webscreen, you are exposing your client-secret of your (Azure AD-) app to the client. Since these webrequests are before authentication, your client can be anyone with or without malicious intentions.

In detail the following happens:
From a application's logic flow (in outsystems) you do a navigate to the OAuthLogin webscreen (with filled in screen parameters). This results in a HTTP 302 with redirect to [environment]/MicrosoftLoginConnector/CommonFlow.OAuthLogin.aspx including (including query parameters!) to your client's browser. These calls can be inspected via various http sniffing tools including your browsers developer tools (f12 > network tab). See attached image.


Having your clientid and clientsecret exposed could be a massive breach; for example, I was able to get an Active directory token with my apps permissions via the client credential flow (grant_type = client_credential on the /oauth2/token endpoint).

Are you able to fix this / do you need some help? I think that the most easy solution lies with a server side lookup of the clientsecret in a config tabel based on the client id for example.


Regards, Rob



Hi Rob,


I now have access to publish this component so would be great to get you on the team to work on this fix if you still have time.

Thanks


Paul


Good job! Sure, I'll send you a DM.