Experimental testing: Azure AD Application Proxy With Azure Application Gateway WAF

Disclaimer: This configuration example is only for experimental testing. I’d advise against using it in any kind of serious scenario as the configuration has no official support …and is based on-whim testing 🙂

Update: I’ve added more configuration screenshots to additional post, since this post is focusing on key configuration options. If you find any setting missing, or feel that its missing linked relevant setting. check it out here

Background

I was recently browsing Feedback for Azure AD Application Proxy, and noticed that I am not the only one who would like to see WAF functionality enabled for AAD App Proxy.

While its fairly easy to retrofit WAF API -scenario with Azure AD App Proxy and API management, it’s another thing to also make it render web pages in a browser without a custom front end. https://securecloud.blog/2019/06/01/concept-publish-on-prem-api-using-aad-app-proxy-and-api-management-with-azure-ad-jwt-bearer-grant/

Test configuration

Application Proxy Configuration

Application Gateway Configuration

1. Create Listener binding the cert for App Proxy Apps FQDN

2. Add the hostname of Azure AD App Proxy application as back-end target

• The logic: Point the DNS to Application Gateway instead to App Proxy Application, and point the application gateway to that CNAME, and override the naming bind in the listener of Application Gateway

3. Override the host name to the same name that is in the DNS (Why we do this here is to ensure that connection is using matching binding to that what is configured in Azure AD Application Proxy application)

Now watch the back end for traffic originating through WAF + AppProxy

• Obvious problem is that the attacker can bypass WAF by ”gatewaying” itself with custom DNS directly to the AppProxy.
  • Obviously there is no public reference anywhere, what is the IP for Azure AD App Proxy app, or whats the name of the app, as the communication goes through App GW, and DNS points to App GW. Depending on the back-end app, the attacker might figure out a simple way, to get the app ”echoing” back the route (For example headers…)
• Sub optimal mitigations would be (if back-end app is configurable, and you want to check in back end that did the request come from WAF)
  • • that the only calls that have last X-Forwarded-For IP as Application Gateway would be authorized.
    • Or to set an ”secret” header in Application Gateway URL rewrite rules, and check the presence of that header in the back-end app for authorization
• If I had to do this in production today, I would place WAF in the internal network before the back-end app

I will stay tuned to see if this feature gets actually implemented!

Br Joosua!