| 1 | Security vulnerability details for passport-azure-ad <1.4.6, 2.0.0
|
| 2 | ===================
|
| 3 |
|
| 4 | Our team discovered a vulnerability in the Passport-Azure-AD for NodeJS library affecting versions <1.4.6 and 2.0.0. This vulnerability can allow a user to bypass certain authentication mechanisms. Developers using the Passport-Azure-AD for NodeJS library need to download the latest version of the Passport-Azure-AD for NodeJS library.
|
| 5 |
|
| 6 | > - **if you are currently on 1.x below 1.4.6, please update to 1.4.6 or
|
| 7 | > greater**
|
| 8 | > - **if you are currently on 2.0.0, please update to 2.0.1 or
|
| 9 | > greater**
|
| 10 |
|
| 11 | Updated packages are available on npm. To ensure you get additional bug fixes going forward, please ensure your package.json file is updated to take PATCH and MINOR level updates of our libraries.
|
| 12 |
|
| 13 | #### Example for 2.0 release:
|
| 14 | ```sh
|
| 15 | {
|
| 16 | "dependencies": {
|
| 17 | "passport-azure-ad": "^2.0.1"
|
| 18 | }
|
| 19 | }
|
| 20 | ```
|
| 21 | #### Example for 1.4 release:
|
| 22 | ```sh
|
| 23 | {
|
| 24 | "dependencies": {
|
| 25 | "passport-azure-ad": "^1.4.6"
|
| 26 | }
|
| 27 | }
|
| 28 | ```
|
| 29 | ### Upgrade Notes
|
| 30 |
|
| 31 | 1. This patch updates the library that your application runs, but does not change the current state of your users, including any sessions they had open. This applies to malicious users who could have exploited this vulnerability to gain access to your system. If your application has users with existing sessions open, after applying the patch, ensure all these sessions are terminated and users are required to sign in again.
|
| 32 |
|
| 33 |
|
| 34 | 2. In previous versions of the Passport-Azure-AD for NodeJS library, the issuer wasn't validated, even if you had set validateIssuer to true in your configuration. This is fixed in versions 1.4.6 and 2.0.1. However, this may mean you get 401s if you are using the common endpoint in the identityMetadata config setting and have validateIssuer to true. If you are using the "common" endpoint (which looks like "https://login.microsoftonline.com/common/.well-known/openid-configuration"), issuers cannot be validated. You can fix this in two ways:
|
| 35 |
|
| 36 | - If you are a single-tenant app, you can replace 'common' with your tenantId in the endpoint address. The issuer will be validated. IdentityMetadata set to support a single tenant should look like "https://login.microsoftonline.com/72f988bf-86f1-41af-91ab-2d7cd011dddd/.well-known/openid-configuration" with your tenant GUID replaced in the path or "https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/.well-known/openid-configuration" with your tenant name replaced in the path.
|
| 37 |
|
| 38 | - If you are a multi-tenant app and need to go against the common endpoint, you must set validateIssuer to false. Be aware that the issuer field of the token will not be validated and all issuers will be accepted.
|
| 39 |
|
| 40 | You can read more about the [issue here].
|
| 41 |
|
| 42 | [//]: # (These are reference links used in the body of this note.)
|
| 43 | [issue here]: http://support.microsoft.com/kb/3187742
|