Add several minor changes in. prep for run 7 (#10)

Add minor update/fixes to most exercices as part of preparations for inagural CS workshop --------- Co-authored-by: Stein A Sivertsen <[email protected]>
equinor · Jan 16, 2024 · 7931468 · 7931468
1 parent 0ee8d77
commit 7931468
Show file tree

Hide file tree

Showing 29 changed files with 69 additions and 57 deletions.
diff --git a/README.md b/README.md
@@ -49,7 +49,7 @@ In the workshop participant will get to know key technologies such as OAuth2, Op
 
 ## Documentation and Slide deck
 
-Most of the topics and exercises have documentation as part of the exercise. We use a slide deck for some parts. The [docs/readme](doc/readme.md) shows you how to load the docs in your local environment. Slides are also served using Github Pages at [https://equinor.github.io/appsec-fundamentals-authn-authz-cs](https://equinor.github.io/appsec-fundamentals-authn-authz-cs)
+Most of the topics and exercises have documentation as part of the exercise. We use a slide deck for some parts. The [docs/readme](docs/readme.md) shows you how to load the docs in your local environment. Slides are also served using Github Pages at [https://equinor.github.io/appsec-fundamentals-authn-authz-cs](https://equinor.github.io/appsec-fundamentals-authn-authz-cs)
 
 ## Support documents
 

diff --git a/docs/content/ex-10.md b/docs/content/ex-10.md
@@ -28,8 +28,8 @@ Open the file ex-10/readme.md for the exercise. ([official repo](https://github.
 ## Questions
 
 * What are typical security challenges when creating API'S in your team?
-* What kind of security test do you use for your API's?
-* Any other subject, like Codespaces
+* How do you do security in depth?
+* Do you have any specific tests for security for your API's?
 
 Note and share a few key points for each question.
 

diff --git a/docs/content/ex-2.md b/docs/content/ex-2.md
@@ -6,7 +6,7 @@
 
 >The purpose of this exercise is get an access token using code. We are moving from the raw style using bare http requests to start exploring what's needed to get this done in code.
 
-Open the file `ex-02/readme.md` for the exercise. ([official repo](https://github.com/equinor/appsec-fundamentals-authn-authz/blob/main/ex-02/readme.md))
+Open the file `ex-02/readme.md` for the exercise. ([official repo](https://github.com/equinor/appsec-fundamentals-authn-authz-cs/blob/main/ex-02/readme.md))
 
 👷‍♀️👷‍♂️👇
 ---

diff --git a/docs/content/retrospective.md b/docs/content/retrospective.md
@@ -5,7 +5,7 @@ A tiny  <!-- .element style="font-size: 0.40em"-->
 
 ## Setting the stage
 
-We have been together 4 days exploring protecting api's and web apps. Along the road we have discussed good practices, security and testing.
+We have been together 2 days exploring protecting api's and web apps. Along the road we have discussed good practices, security and testing.
 
 Our objective was to "de-mystify, build confidence and prepare for further exploration of A&A"
 

diff --git a/ex-01/doc/exploring_tokens.md b/ex-01/doc/exploring_tokens.md
@@ -10,6 +10,7 @@ Steps:
   * Format (header, payload, signature)
   * Decoded
   * Claims (aud, iss, nbf, exp, appid, scp)
+* Explore the ID Token
 * Remember the _token config_ in the AD App Object? This can be used to include additional claims
   * Standard claims in a JWT token - [RFC 7519](https://tools.ietf.org/html/rfc7519#section-4)
   * Registry for public claims to avoid naming conflicts - [IANA](https://www.iana.org/assignments/jwt/jwt.xhtml)
@@ -18,6 +19,7 @@ Steps:
 
 ## --Now You--
 
+* Do the steps, explore tokens
 * Experiment with scope, add _offline_access_ to the scope and explore the "refresh_token"
 
 ## --Discuss security issues and good practices--

diff --git a/ex-01/doc/requesting_an_access_token.md b/ex-01/doc/requesting_an_access_token.md
@@ -17,7 +17,8 @@ Steps:
 
 ## --Discuss security issues and good practices--
 
-* This part of the communication happens in the "back-channel" <br/> (will be more obvious later on)
+* This part of the communication happens in the "back-channel"  
+(will be more obvious later on)
 * Public vs. Confidential Client (Trust level)
 * The importance of proper SSL, exception of localhost
-* The importance of handling client_secret as a secret
+* The importance of handling `client_secret` as a secret
diff --git a/ex-02/doc/environment_variables.md b/ex-02/doc/environment_variables.md
@@ -15,13 +15,9 @@ Steps:
   ```
 * The `aa-get-redirect-uri.sh` scripts helps to extract and generate a redirect uri for your workspace</br>Examine the script at `../src/aa-get-redirect-uri.sh` (It's automatically added to the path)
 * You can extract the value from the CLIENT_SECRET from the environment using the following command
-  ```shell
-  echo $APPSEC_AA_CLIENT_SECRET 
-  ```
-  alternatively this command to set value directly into CLIENT_SECRET
 
   ```shell
-   export CLIENT_SECRET=$(echo $APPSEC_AA_CLIENT_SECRET) 
+  echo $APPSEC_AA_CLIENT_SECRET 
   ```
 * If you have create a new code space since you configured the Entra ID Application Object for the client app, you may need to update the app registration with the proper redirect uri.
 

diff --git a/ex-02/doc/exploring_the_code.md b/ex-02/doc/exploring_the_code.md
@@ -4,7 +4,7 @@ In this part we will explore the app and the code to get an idea of the moving p
 
 Steps:
 
-* Explore the [Microsoft Entra ID end-points](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview) once again
+* Explore the [Microsoft Entra ID end-points](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps) once again
 * Explore the app config (./lib/app-config.js)
 * Explore the server & web app end-points (./src/server.js, ./src/app.js)
 * Explore html templating (./public, ./view)

diff --git a/ex-02/doc/running_the_app.md b/ex-02/doc/running_the_app.md
@@ -33,8 +33,9 @@ Steps:
   ```shell
   export NODE_ENV=development
   ```
+* Start the back-end (`npm start`)
 * Observe that the "automatic port forwarding" is adding the forward for port 3000
-* Run the application again and observer the logging
+* Use the application again and observer the logging
 * Observe that the port forwarding is public so it remembered your decision
 
 ## --Now You--
@@ -45,7 +46,7 @@ Steps:
   * First leg: redirect to login.microsoftonline.com (the 302) with params and redirect_uri
   * Second leg: receive code on redirect_uri endpoint, use code to request access token 
 * Extract the access token and inspect at [jwt.ms](https://jwt.ms)
-* Experiment with changing a few parameters of the authorization request
+* Experiment with changing a few parameters of the authorization request (auth-utils.js)
   * (npm will use the NODE_ENV to determine which dependencies to install)
   * Using "dev" mode with auto restart on changes is nice when experimenting
     ```shell
@@ -55,7 +56,7 @@ Steps:
   * response_mode
   * scope
 * Explore what consent you have given to apps on Microsoft Entra ID on [myapps.microsoft.com](https://myapps.microsoft.com/)
- * Test revoking for your app (if available in the list)
+ * Test revoking for your app (if available in the list, if not can you find how to add it to the list? :) )
 
 ## --Discuss security issues and good practices--
 

diff --git a/ex-02/doc/secrets.md b/ex-02/doc/secrets.md
@@ -77,6 +77,6 @@ Steps:
   * Observe: This is NOT a 100% secure solution. It still requires high confidence/trust into client environment
 * Good Practice - Rotate secrets often - preferably automated
 * Good Practice - MS Recommend using Certificates (non self signed for production) rather than client secret "strings"
-  * Anyone have experience with this pattern? What's the root CA that's used?
+  * Anyone have experience with this pattern? Any takes on Pros and Cons?
 * Storing secrets as part of ordinary config may make sense in some scenarios (like we have done 👆)
 * Good Practice - Scan for Secrets in your dev environment. The AppSec Team has workshops on this as well, the [AppSec Fundamentals Secret Scanning](https://github.com/equinor/appsec-fundamentals-secret-scanning) workshop.⚡️
diff --git a/ex-02/doc/the_scenario.md b/ex-02/doc/the_scenario.md
@@ -8,12 +8,20 @@ The purpose of this part is to explain the basic CLIENT scenario we are using in
 
 ## Components
 
-This scenario has 1+1 key components. 
+This scenario has 4 key components. 
 
-* The Client
+* The Web browser (Used as the intermediate for the **oAuth2: Resource owner**)
+  * The front-end part of the app
+* The Client (**oAuth2: Client**)
   * Serving the Web front end
-  * Handling /showinbox - triggering the OAuth2 code grant redirect and showing content of inbox using the O365 API
-* Microsoft Entra ID
+  * Hosting the back-end api
+    * Login
+    * Logout
+    * Show Inbox
+* Microsoft Entra ID (Trusted 3rd party. **oAuth2: Authorization Server**)
   * The Authorization Server
   * The Identity provider (Authorization Service)
+* Office 365 (**oAuth2: Resource server**)
+  * Serving, and protecting the InBox
+
 
diff --git a/ex-03/doc/ms_graph_explorer.md b/ex-03/doc/ms_graph_explorer.md
@@ -8,16 +8,16 @@ Steps:
 * Sign in using your Equinor account
 * Query `/v1.0/me`
 * Explore
-  * Permissions tab
+  * Modify Permissions tab
   * Access token (extract access token and explore in [jwt.ms](https://jwt.ms))
   * Response preview
 * Query `/v1.0/me/memberOf`
 * Explore
-  * Permissions tab
+  * Modify Permissions tab
   * Response preview
 * Query `v1.0/me/mailFolders('Inbox')/messages?$select=sender,subject`
 * Explore
-  * Permissions tab
+  * Modify Permissions tab
   * Response preview
 * Take a look at the [Graph Api Documentation](https://docs.microsoft.com/nb-no/graph/api/overview?view=graph-rest-1.0)
 * Explore other parts of the Graph API, explore response and permissions

diff --git a/ex-04/doc/running_the_application.md b/ex-04/doc/running_the_application.md
@@ -10,16 +10,14 @@ Steps:
 
     ```shell
     source ~/path-to-env-file/appsec-course-client-eq.env
-    npm start
     ```
 
 * Run the application 
-    * If problems; remember that the forwarded port needs to be PUBLIC and that the redirect uri is dynamic.
-
+
     ```shell
     npm start
     ```
-
+  * If problems; remember that the forwarded port needs to be PUBLIC and that the redirect uri is dynamic.
 * Use the application and test the "get Inbox" feature
 * Stop the application and set the NODE_ENV to "development"
 

diff --git a/ex-05/doc/sessions_caches_patterns.md b/ex-05/doc/sessions_caches_patterns.md
@@ -88,4 +88,4 @@ This would be the full blown architecture shown in the drawing above.
 
 This option will solve all issues in section #1 and is the most flexible, scalable and performant solution. **It's obviously also the most complex!**
 
-As mentioned earlier - we transport and storage should be encrypted!
+As mentioned earlier - the transport and storage should be encrypted!
diff --git a/ex-05/lib/app-config.js b/ex-05/lib/app-config.js
@@ -22,14 +22,14 @@ const msalConfig = {
     request: {
         authCodeUrlParameters: {
             scopes: ['user.read mail.read'],
-            redirectUri: process.env.REDIRECT_URI,
             responseMode: 'query',
+            redirectUri: process.env.REDIRECT_URI
             // responseMode: 'form_post',
             // prompt: 'none',
         },
         tokenRequest: {
-            redirectUri: process.env.REDIRECT_URI,
             scopes: ['user.read mail.read'],
+            redirectUri: process.env.REDIRECT_URI,            
         },
         silentRequest: {
             scopes: ['user.read mail.read'],
@@ -40,7 +40,6 @@ const msalConfig = {
     },
 };
 
-
 function isConfigOk() {
 
     if (__.isUndefined(tenantId)) {
@@ -63,6 +62,7 @@ function isConfigOk() {
         return false; 
     }
 
+
     return true;
 }
 

diff --git a/ex-06/doc/scenario_1.md b/ex-06/doc/scenario_1.md
@@ -14,7 +14,7 @@ One analogy that could make sense to understand these two are; app registrations
 
 Steps:
 
-* From Microsoft Entra ID, select Enterprise Applications
+* From [Microsoft Entra ID](https://portal.azure.com), select Enterprise Applications
 * Search for your client application (INTIAL-appsec-course-client)
 * Select **Properties** on the left side menu
 * Observe
@@ -40,10 +40,11 @@ Steps:
 * Configure the Enterprise Application object for your client and observe changes
   * Disable sign-in
     * Test => Not able to sign-in
+    * Revert the change
   * Enable "user assignment required"
     * Remove yourself from assigned users
-    * Test => Not able to get access token, not able to sign-in
-  * Add yourself to assigned users
+    * Test => Not able to sign-in
+  * Add a group you belong to, to assigned users/group
     * Test => Able to sign in
   * "Sign-in" should be enabled, "Assignment required" should be disabled.
     * Test => Able to sign in.
@@ -52,3 +53,4 @@ Steps:
 
 * Valid account means all accounts in the Microsoft Entra ID tenant, not only "employees". It could be externals, guests accounts or similar.
 * Be aware of security considerations for multi tenant applications ([MS Guidance](https://msrc.microsoft.com/blog/2023/03/guidance-on-potential-misconfiguration-of-authorization-of-multi-tenant-applications-that-use-azure-ad/))
+
diff --git a/ex-06/doc/scenario_2.md b/ex-06/doc/scenario_2.md
@@ -44,10 +44,11 @@ Steps:
 
 ### --Further experiments--
 
-* Do the following experiments (remember to save in AAD and to restart the client back-end between changes)
+* Do the following experiments (remember to save in AAD and to restart the client back-end between changes. Changes can take "some time" to be reflected)
   * Experiment-1
-    * Uncheck "Security Groups" and Check "Groups Assigned to Application"
+    * Uncheck "Security Groups" and Check "Groups Assigned to Application" (Use "+ Add Groups Claim")
     * (This will reduce the number of groups included to only be those a user is assigned too - direct or via a AD group)
+    * (You will have to assign a group to the Enterprise app to populate the claim)
   * Experiment-2
     * "Emit groups as role claims" for "ID" token
     * (The groups will be in the role claim rather than the group claim)
@@ -89,12 +90,13 @@ Steps:
   * Display name "Writers"
   * Allow "Users, Groups and Applications"
   * Value "app.write"
-  * Description "Writer than can write"
+  * Description "Writers than can write"
   * Enable the app role
 * Identify the new role in the App Manifest (the "appRoles" key)
 * Assign yourself this role in the Enterprise Applications for your client
   * "Users and groups"
   * (Some time it may take a minute until the app role is available)
+  * (Using user-defined-approles together with token configuration which has selected "Emit groups as role claims" will give precedence to token config, hence your user-defined-approles will not show if this features is turned on. These features are competing)
 * Login to your application
 
 ### --Now You--
@@ -103,6 +105,7 @@ Steps:
 
 * Do the steps above
 * Identify the roles claim in the proper token (this step may involve altering the backend app code)
+* Identify the change to the application gui?
 * Explore the possible payload claims for [access tokens](https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens#payload-claims) and [id tokens](https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens#payload-claims)
 
 ## --Discuss security issues and good practices--

diff --git a/ex-06/readme.md b/ex-06/readme.md
@@ -2,7 +2,7 @@
 
 In this section we will explore a few common authorization (and authentication) scenarios and how to configure these in Microsoft Entra ID.
 
-A typical way of implementing authorization in Equinor is to use AD (Active Directory) groups. Users apply for access to "something" in Access@IT. If approved, the user is added to a AD group. AD groups and members are synced to AAD (Azure Active Directory / MS Entra ID). Applications use the group membership to implement access control.
+⚡️A typical way of implementing authorization in Equinor is to use AD (Active Directory) groups. Users apply for access to "something" in Access@IT. If approved, the user is added to a AD group. AD groups and members are synced to AAD (Azure Active Directory / MS Entra ID). Applications use the group membership to implement access control. 
 
 ## Scenarios
 

diff --git a/ex-10/client/lib/auth-utils.js b/ex-10/client/lib/auth-utils.js
@@ -7,10 +7,8 @@ var __ = require('underscore');
 const msal = require('@azure/msal-node');
 const Crypto = require('crypto');
 
-
 async function requestAccessTokenUsingAuthCode(request, reply, authCode) {
 
-
     var accessToken;
     const requestConfig = appConfig.msalConfig.request;
 
@@ -160,7 +158,6 @@ async function readInbox(accessToken) {
     }
 }
 
-
 //Generate useragent header (used by webserver and got)
 
 function clientUserAgent()  {

diff --git a/ex-10/doc/configure_client_anda_api.md b/ex-10/doc/configure_client_anda_api.md
@@ -59,7 +59,6 @@ Steps:
   * Update the value of apiAudience (the Application ID URI for your api)
     * Hint: App Registrations -> (initials)-appsec-course-episodes-api -> Expose and Api -> Application ID URI
     * Remember to save the change
-* Run `aa-save-env-files-to-github-user-secret.sh` to persist the new environment files
 
 
 ### Microsoft Entra ID

diff --git a/ex-10/doc/execute_client_and_api.md b/ex-10/doc/execute_client_and_api.md
@@ -28,7 +28,7 @@ Steps:
 ### --Now You--
 
 * Do the steps above
-* Play around with the Swagger interface
+* Play around with the Swagger interface, it may not work 100% 😀
 
 
 ## The Client
@@ -50,6 +50,7 @@ Steps:
     NODE_ENV=development npm start 
     ```
 
+* You may have to fix an error before the application will start
 * Use the application from your browser
 
 ### --Now You--

diff --git a/ex-10/doc/exploring_the_api_code.md b/ex-10/doc/exploring_the_api_code.md
@@ -56,10 +56,12 @@ Steps:
   * "Trust but verify"?
 * Good practice: Use frameworks to do token validation, especially the crypto part
 * Good practice: [OWASP Top 10 for api security](https://owasp.org/www-project-api-security/) is a good resource for securing your api's
-  * #1 - Broken Object Level Authorization (handled with fastify schemas)
-  * #2 - Broken User Authentication (the basic validation is in place (jwt))
-  * #3 - Excessive Data Exposure (not a problem for this api)
-  * #4 - Lack of resource and rate limiting (we have implemented rate limiting)
-  * #5 - Broken Function Level Authentication (we have simple func auth with jwt, scope and schemas)
+  * #1 - API1:2023 - Broken Object Level Authorization (handled with fastify schemas)
+  * #2 - API2:2023 - Broken Authentication  (the basic validation is in place (jwt))
+  * #3 - API3:2023 - Broken Object Property Level Authorization (we have simple func auth with jwt, scope and schemas)
+  * #4 - API4:2023 - Unrestricted Resource Consumption (we have implemented rate limiting)
+  * #5 - API5:2023 - Broken Function Level Authorization (we have simple func auth with jwt, scope and schemas)
   * #6 .....
+
+* 4 of the top 5 API security issues has to do with Authentication and Authorization
 * Good practice: Create automated documentation of your api, Swagger or OpenApi are good choices.
diff --git a/ex-10/doc/registering_api_in_azure_ad.md b/ex-10/doc/registering_api_in_azure_ad.md
@@ -18,7 +18,7 @@ Steps:
 * Augment app object to be compliant ⚡️
   * Add an additional owner to AppReg and to the Enterprise App (select course instructor) (Owners) ⚡️
   * Update the "service management reference" to refer to the "AppSec-Training" - 119775 (Branding & Properties)⚡️
-* Select the _Expose an API_ in the left side menu
+* Select the _Expose an API_ in the left side menu of "App Registrations"
 * Add new scope
   * Use the suggested **Application ID URI**, save and continue
   * Scope name: **Episodes.Read**

diff --git a/ex-10/doc/the_scenario.md b/ex-10/doc/the_scenario.md
@@ -8,7 +8,7 @@ The purpose of this part is to explain the API scenario we are using in the exer
 
 ## Components
 
-This scenario has 2+1 key components. The 2 key components are independent of each-other and can be seen as microservices.
+This scenario has 2+2 key components. The 2 key components are independent of each-other and can be seen as microservices.
 
 * The Client
   * Serving the Web front end
@@ -22,6 +22,7 @@ This scenario has 2+1 key components. The 2 key components are independent of ea
   * Requests needs to be validated, tokens needs to be issued by Microsoft Entra ID
 * Microsoft Entra ID
   * The identity provider and the Authority Server
+* Microsoft Office 365 (Resource Server)
 
 Steps:
Original file line number	Diff line number	Diff line change
Expand Up		@@ -88,4 +88,4 @@ This would be the full blown architecture shown in the drawing above.

		This option will solve all issues in section #1 and is the most flexible, scalable and performant solution. It's obviously also the most complex!

		As mentioned earlier - we transport and storage should be encrypted!
		As mentioned earlier - the transport and storage should be encrypted!