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.

• If you are running applications in other container supporting services than App Service, then you might want to check out my earlier articles section ’Container Security enhancements in Azure Security Center’

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

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

*The container option of App Service deployment supports terminating TLS in the container

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 & Rationale	ControlSeverity	Automated	Fix 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.	Medium	Yes	No
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.	Medium	Yes	No
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.	High	Yes	No
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.	High	No	No
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.	High	No	No
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.	High	No	No
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.	Medium	No	No
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).	Medium	No	No
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.	High	Yes	No
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.	Medium	Yes	Yes
’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.	Medium	Yes	No
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.	Low	Yes	Yes
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.	Medium	No	No
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.	Medium	Yes	Yes
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.	Medium	Yes	No
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.	Medium	Yes	Yes
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	Medium	No	No
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.	High	Yes	Yes
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.	High	Yes	No
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.	Medium	No	No
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	Medium	No	No
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.	Medium	Yes	No
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.	Medium	Yes	No
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.	Medium	No	No
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.	Medium	Yes	No
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.	Medium	No	No
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.	Medium	Yes	No
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.	High	Yes	No
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.	Medium	Yes	No
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.	Medium	Yes	No
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.	Medium	Yes	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.	Medium	Yes	No

Till next time!