app service AZSK Azure NodeJS

Unobvious stuff about Azure services – App Service TLS termination

If you’ve worked with Azure for the last few years, you might’ve came across things that exist in documentation, but are not highlighted in the basic overview and can cause confusion after a late discovery ( I am not arguing that these things should be highlighted in the overview) – So I decided I should flag few occasions like this here;

Starting with subject of ’App Service TLS termination’ as there might be some compliance driven edge cases, where you might need to evaluate the other Azure Services. If you don’t have such edge cases, then App Service in terms of security is a excellent choice. Much better than for example than plain (read:unsecured) docker host in its default configuration running your application.

Background: Encryption in Azure (TL DR)

Due to my work being on the security side of things, I receive frequently questions about encryption. Sometimes these questions are driven more about compliance than actual technical security, which is one the aspects of security work. (Note this is not negative comment, compliance is another domain, with its own required domain knowledge)

  • My short take is that Azure goes beyond normal expectations in terms of encryption in transit and in rest. By going beyond, I mean, that you can audit/alert/getRecommendations/ and to some extent ’auto-fix’ these

App Service TLS termination

The In-transit traffic towards App Service Web app is not e2e (’end-to-end encrypted’). TLS terminates in another part of the service architecture, and requests to actual application runtime arrive as unencrypted. Even knowing this I prefer app service 99% of the time for deploying workloads in Azure.

  • My reasoning: Though this is not technically correct, I consider TLS Termination design of Azure App Service to be part of my application runtime, not an external service in terms evaluation of ’how well the application is secured’. In my thinking its similar to having NGINX container terminating traffic before reaching the application runtime with HTTP
  • Its also good to understand, that you can have multiple TLS terminating services before reaching appliction runtime: waf-HTTPS->apim-HTTPS->AppService->HTTP->ApplicationRuntime
  • If your app requires E2E encryption right until the application runtime due to compliance reasons, you might be better running your service in version that support the application runtime TLS termination
    • AKS
    • Docker Host in Azure (lot other things to secure here…)
    • ACI
https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-bindings#handle-tls-termination

Example: Node.JS application running in docker host vs app service web app

Below are code snippets of the relevant parts (not complete code)

  • With containerized version of the application which runs on a docker host (not as container in app service) – The spawned express object is added as ’requestListener’ argument into node HTTPS server initialization function. In app service this wouldn’t work, even if it we’re running in custom port
  • With App service I’ve taken in consideration, that App service adds another TLS terminating layer into the service, so my application runtime is internally exposed by the app service

Extra:

If the TLS terminating design of app service is ok for you, and you want to increase security of the app service you should look the controls available in AZSK.

AZSK Table for App Service

Source: https://azsk.azurewebsites.net/02-Secure-Development/ControlCoverage/Feature/AppService.html#appservice

Description & RationaleControlSeverityAutomatedFix Script
All users/identities must be granted minimum required permissions using Role Based Access Control (RBAC)
Granting minimum access by leveraging RBAC feature ensures that users are granted just enough permissions to perform their tasks. This minimizes exposure of the resources in case of user/service account compromise.
MediumYesNo
Custom domain with SSL binding must be configured for App Service
Use of custom domain protects a web application from common attacks such as phishing, session hijacking and other DNS-related attacks.
MediumYesNo
App Service must authenticate users using Azure Active Directory backed credentials
Using the native enterprise directory for authentication ensures that there is a built-in high level of assurance in the user identity established for subsequent access control.All Enterprise subscriptions are automatically associated with their enterprise directory (xxx.onmicrosoft.com) and users in the native directory are trusted for authentication to enterprise subscriptions.
HighYesNo
Publish profile credentials must not be used for App Service deployment
Publish profile of App Services contains deployment and FTP credentials. There are 2 risks with this. First, the credentials can get easily leaked during the various workflows involving the publish profile. Secondly, use of public profiles weakens auditability of deployment actions.
HighNoNo
Trigger URL for the App Service Web Job must require authentication
Scheduled WebJobs can be triggered by specific scheduled time or by triggered URL. WebJob triggered URL can be authenticated by AAD authentication (bearer token) or by App Services deployment credentials. Since its not recommended to use publish profiles, WebJob triggered URL must be authenticated by AAD authentication.
HighNoNo
The webhook used for a Web Job must encrypt sensitive data in transit
Use of HTTPS ensures server/service authentication and protects data in transit from network layer man-in-the-middle, eavesdropping, session-hijacking attacks.
HighNoNo
All App Service secrets should be stored in Key Vault
Keeping secrets such as DB connection strings, passwords, keys, etc. in clear text can lead to easy compromise at various avenues during an application’s lifecycle. Storing them in a key vault ensures that they are protected at rest.
MediumNoNo
App Service should use Notification Hub for push notification (instead of directly using Push Notification Service)
Notification Hub provides a better mechanism to manage the keys related Push Notification Systems (PNS).
MediumNoNo
Remote debugging must be turned off for App Service
Remote debugging requires inbound ports to be opened on App Service. These ports become easy targets for compromise from various internet based attacks.
HighYesNo
Web Sockets should be disabled for App Service
WebSockets protocol (WS) is vulnerable to different types of security attacks. Usage of Web Sockets with in web applications has to be carefully reviewed.
MediumYesYes
’Always On’ should be configured for App Service
By default, websites are unloaded if they have been idle for some period of time. However, this may not be ideal for ’high availability’ requirements. Configuring ’Always On’ can help prevent app services from getting timed out.
MediumYesNo
The latest version of .NET framework version should be used for App Service
Running on older .Net versions could mean you are not using latest security classes. Usage of such old classes and types can make your application vulnerable.
LowYesYes
Deployment of App Service should be done using ARM template
Deployment using ARM template is more secure than using publish profiles. This is because the former uses user/SPN credentials which can be protected better than publish profiles and provide a better audit trail of deployment activity.
MediumNoNo
App Service must be deployed on a minimum of two instances to ensure availability
App Service deployed on multiple instances ensures that the App Service remains available even if an instance is down.
MediumYesYes
Backup feature must be configured to backup data for App Service
Enabling backup on App Service ensures that there is always a previous snapshot of App Service data that can be leveraged towards recovery scenarios.
MediumYesNo
Auditing and Monitoring must be enabled for App Service
Auditing enables log collection of important system events pertinent to security. Regular monitoring of audit logs can help to detect any suspicious and malicious activity early and respond in a timely manner.
MediumYesYes
Auto healing should be configured for App Service
With the use of Auto-Healing, a website can automatically recover from long running/blocked states. Auto-Healing enables automatic recycling of the worker process hosting your web application based on certain events. E.g. 1. When request count breaches a certain limit 2. When requests are running slower that expected 3. When an unexpected http status code is received X number of times 4. When the process consumes more than expected memory
MediumNoNo
App Service must only be accessible over HTTPS
Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks.
HighYesYes
WEBSITE_LOAD_CERTIFICATES parameter must not be set to ’’ (i.e. all) for App Service
Using ” for this parameter means that all certificates will get uploaded to the VM running the website. This will most likely lead to abuse of the principle of least privilege as it is unlikely that the site needs access to all certificates at runtime.
HighYesNo
Keys should be renewed after a regular interval
Periodic key/password rotation is a good security hygiene practice as, over time, it minimizes the likelihood of data loss/compromise which can arise from key theft/brute forcing/recovery attacks.
MediumNoNo
Host key access should not be shared with individual clients
Host Keys grant full access to all the functions within a function app. Not sharing this key with individual clients ensures that clients are granted just enough permissions to invoke a particular function
MediumNoNo
Authorization level for HTTP Trigger function in a function app should be set to ’Function’
Use ’Function’ authorization level to ensure that users with minimum of function keys should only be able to invoke the function. This is in accordance with the principle of least privilege.
MediumYesNo
Functions app edit mode should be set to Read Only
Using ’Read Only’ mode ensures that source code is changes come in via a CICD pipeline and not directly through portal. This ensures that code changes are properly audited.
MediumYesNo
Different functions keys must be generated and shared with individual clients.
Different function keys for individual clients promotes separation of concerns. It also makes revocation easier to manage in the event of a compromise of one client.
MediumNoNo
Ensure that CORS access is granted to a limited set of trusted origins.
CORS enables applications running under one domain to access a resource under another domain. Using ’*’ (allow all) for CORS setting means that an application running under any domain can have access to your application’s resources and data. Restricting allowed origins to the specific set that needs access aligns with the principle of least privilege.
MediumYesNo
Alerts should be configured to track unauthorized access attempts for the AppService.
Alert rules for unauthorized requests enable you to detect any suspicious and malicious activity early enough.
MediumNoNo
Use Managed Service Identity (MSI) for accessing other AAD-protected resources from the app service.
Managed Service Identity (MSI) allows your app to easily access other AAD-protected resources such as Azure Key Vault. The identity is managed by the Azure platform and eliminates the need to provision/manage/rotate any secrets thus reducing the overall risk.
MediumYesNo
Function App must only be accessible over HTTPS
Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks.
HighYesNo
Use approved version of TLS for the App Service
TLS provides privacy and data integrity between client and server. Using approved TLS version significantly reduces risks from security design issues and security bugs that may be present in older versions.
MediumYesNo
Extensions installed on a App Service should be carefully reviewed
Each extension is something like a plugin that adds functionality to your App Service. Installing unknown/unverified extensions can be dangerous as some third party extensions may have vulnerabilities which introduce unnecessary avenues for attack.
MediumYesNo
Setup IP-based access restrictions for App Service if feasible
Using the IP/VNet subnet rules based access restriction ensures that access to the data or the service is restricted to a specific set of IPs. NOTE: While this control does provide an extra layer of access control protection, it may not always be feasible to implement in all scenarios.
MediumYes No
Review use of credentials in CORS request for App Service
CORS enables applications running under one domain to access a resource under another domain. Allowing cross-origin credentials is a security risk. A website at another domain can send a signed-in user’s credentials to the app on the user’s behalf without the user’s knowledge.
MediumYesNo

Till next time!

0 comments on “Unobvious stuff about Azure services – App Service TLS termination

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Google photo

Olet kommentoimassa Google -tilin nimissä. Log Out /  Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s

%d bloggaajaa tykkää tästä: