Open Redirect on Azure

Open Redirect vulnerabilities in Azure environments typically arise from improper validation of redirect URLs in authentication flows, portal navigation, and custom applications. Azure's identity services and portal framework provide multiple attack vectors that attackers can exploit.

The most common Azure-specific pattern involves the post_logout_redirect_uri parameter in Azure AD logout flows. When a user logs out of an Azure AD-integrated application, the logout endpoint accepts a redirect URI parameter that can be manipulated:

GET /connect/endsession?id_token_hint=...&post_logout_redirect_uri=https://malicious-site.com HTTP/1.1

If the application doesn't validate this parameter against a whitelist, attackers can craft logout URLs that redirect users to phishing sites, appearing legitimate because they originate from trusted Azure domains.

Another Azure-specific manifestation occurs in Azure App Service and Azure Functions. These services often use query parameters for navigation or error handling. For example:

GET /api/redirect?returnUrl=/admin/dashboard HTTP/1.1

Without proper validation, attackers can modify returnUrl to point to external domains, creating phishing opportunities that appear to come from your azurewebsites.net or azurewebsites.io domain.

Azure B2C custom policies also introduce open redirect risks. The redirect_uri parameter in OAuth flows must be validated against registered redirect URIs. An attacker can exploit misconfigurations where the policy accepts any subdomain or path variation:

GET /oauth2/v2.0/authorize?client_id=...&redirect_uri=https://login.contoso.com.attacker.com/oauth2/nativeclient HTTP/1.1

Azure API Management gateways can also be vulnerable when they proxy external services without validating redirect URLs in responses. If an API returns a Location header pointing to an external site, and the gateway blindly forwards it, users can be redirected to malicious destinations.

Azure Storage accounts with static website hosting present another vector. If your application constructs URLs using user input for blob paths or container references without validation, attackers can manipulate these to redirect users to external sites.

Detecting open redirects in Azure environments requires both manual testing and automated scanning. For Azure AD applications, test the logout endpoint with various post_logout_redirect_uri values:

curl -v "https://login.microsoftonline.com/your-tenant-id/oauth2/v2.0/logout?id_token_hint=...&post_logout_redirect_uri=https://test-malicious.com"

Look for successful redirects to external domains. A secure implementation should reject any redirect URI not in the application's configured whitelist.

For Azure App Service applications, use parameterized testing to identify vulnerable redirect logic:

import requests

def test_redirect_vulnerability(base_url):
    test_urls = [
        f"{base_url}/api/redirect?returnUrl=https://evil.com",
        f"{base_url}/login?next=https://malicious.net",
        f"{base_url}/auth/callback?redirect=https://phishing.site"
    ]
    
    for url in test_urls:
        response = requests.get(url, allow_redirects=True)
        if response.url.startswith('https://evil.com'):
            print(f"Vulnerable: {url} redirects to external site")
        else:
            print(f"Safe: {url} does not redirect externally")

middleBrick's Azure-specific scanning identifies open redirect vulnerabilities by testing common Azure authentication and navigation patterns. The scanner automatically tests:

• Azure AD logout redirect parameters
• App Service return URL parameters
• Azure Functions HTTP trigger redirect logic
• API Management gateway response headers
• B2C custom policy redirect URIs

The scanner checks for both the presence of redirect functionality and whether it properly validates against allowed domains. It reports findings with severity levels based on the potential impact and provides the exact parameter names and vulnerable endpoints.

For Azure Storage accounts, use the Azure CLI to enumerate static websites and test for path traversal that could lead to open redirects:

az storage blob list --container-name $web --account-name yourstorageaccount

Then test URL construction in your application code to ensure user input cannot manipulate the final URL destination.

Remediating open redirects in Azure environments requires implementing strict URL validation and leveraging Azure's built-in security features. For Azure AD applications, always validate post_logout_redirect_uri against a whitelist of approved domains:

using Microsoft.Identity.Web;

public class LogoutController : Controller
{
    private readonly string[] allowedRedirectDomains = new[]
    {
        "https://yourapp.azurewebsites.net",
        "https://yourapp.com"
    };
    
    public IActionResult Logout(string post_logout_redirect_uri)
    {
        if (!string.IsNullOrEmpty(post_logout_redirect_uri))
        {
            var uri = new Uri(post_logout_redirect_uri);
            if (!allowedRedirectDomains.Any(domain => uri.Host.EndsWith(domain)))
            {
                return BadRequest("Invalid redirect URI");
            }
        }
        
        return SignOut(new AzureADOpenIDConnectOptions() { PostLogoutRedirectUri = post_logout_redirect_uri });
    }
}

For Azure App Service and Functions, implement a URL validation helper that checks both domain and path:

using System.Web;

public static class UrlValidator
{
    private static readonly HashSet allowedDomains = new()
    {
        "yourapp.azurewebsites.net",
        "yourapp.com",
        "api.yourapp.com"
    };
    
    public static bool IsValidRedirectUrl(string url)
    {
        if (string.IsNullOrEmpty(url))
            return false;
            
        try
        {
            var uri = new Uri(url);
            
            // Check domain against whitelist
            if (!allowedDomains.Contains(uri.Host))
                return false;
                
            // Check for dangerous schemes (javascript:, data:, vbscript:)
            if (uri.Scheme != Uri.UriSchemeHttp && uri.Scheme != Uri.UriSchemeHttps)
                return false;
                
            return true;
        }
        catch
        {
            return false;
        }
    }
}

In Azure API Management policies, add URL validation to outbound policies:

<outbound>
    <set-header name="Location" exists-action="override">
        <value>@{
            var location = (string)context.Variables["originalLocation"];
            if (IsSafeRedirect(location)) {
                return location;
            } else {
                return "https://yourapp.com/error";
            }
        }</value>
    </set-header>
</outbound>

For Azure B2C custom policies, restrict redirect URIs in the client_id registration and validate in your policy XML:

<ClientDefinition>
    <ClientUri>https://yourapp.com</ClientUri>
    <LogoUri>https://yourapp.com/logo.png</LogoUri>
</ClientDefinition>

<ClientMetadata>
    <Item Key="redirect_uris">
        https://yourapp.com/callback,
        https://yourapp.azurewebsites.net/callback
    </Item>
</ClientMetadata>

Implement Content Security Policy (CSP) headers in your Azure applications to mitigate open redirect impact:

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("Content-Security-Policy", 
        "default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self';");
    await next();
});

For Azure Storage static websites, validate blob paths before constructing URLs:

private string GetSafeBlobUrl(string containerName, string blobPath)
{
    if (!blobPath.StartsWith('/') || blobPath.Contains(".."))
        throw new ArgumentException("Invalid blob path");
        
    return $