I'm currently running a windows azure web app behind an application gateway v2.
I would like to use header information for x-forwarded-host or x-original-host - but it does not work.
Now I'd like to trace what request headers are actually received by the web app. I'm trying network-capturing. But as the whole traffic is HTTPs - I guess I'm not seeing all the fields.
Any Idea?
You can configure application gateway to modify request and response headers and URL by using Rewrite HTTP headers and URL or to modify the URI path by using a path-override setting. However, unless configured to do so, all incoming requests are proxied to the backend.
For more details, you can read the offical document.
Related
I am trying to call the Azure-hosted API endpoint using a 3rd party application. Application sends the HTTP request with the header values ContentType = "*/*";
Azure Application Gateway WAF blocks the request showing the below diagnostics logs.
I am aware that, I can add an exclusion in the Web Application Firewall settings, however, I am not able to extract the Request Header Name since the logs do not show the value due to the wildcard(ContentType = "*/*";) content type sent by the 3rd party app.
I added the below rule, but it is still blocking the request.
How can I allow the request via the AGW?
Please find the logs below.
Thanks in advance.
Hello I am trying to deploy my Azure Machine Learning pipeline with a REST endpoint. My problem is that I was able to generate an endpoint but has some sensitive information in it (ex: subscription id, resource group, etc). How can I generate a URL that forwards the request body to my Azure ML REST endpoint?
also, here is an approach I've done:
Used Application Gateway Redirect (this approach didn't forward the request body. It instead turned my POST request into a GET request when it redirected to the correct URL.)
The issue is raised because of some of the default security headers dependent on REST API and web based. Need to set the REST API CSP HEADER. Check the request and response headers in config file of the web application.
I have a problem configuring my Open Auth ID .net Core 2 application as an App Service behind a Web Application Firewall using a Path based routing.
My application is myapp.azurewebsites.net with a network restriction making it inaccessible from the public internet. I have deployed a WAF in the same VNET and allowed traffic between the WAF and App Service using a Path based route "/Admin*".
The effect is that https://myapp.azurewebsites.net is not internet accessible but https://myWAF/Admin is accessible and maps to the app service.
This setup works fine, but when I introduce Open ID auth to my .net core application the outgoing Location header includes its myapp.azurewebsites.net/signin-oidc as the reply URI.
This doesn't work because the host is not accessible from the internet. I have attempted several approaches;
I have added the WAF URL (https://myWAF/Admin/signin-oidc) in the application registration URL in Azure App Registrations to allow AAD to accept the modified URL (as legitimate
I have coded app.UseForwardedHeaders (forcing reuse of all X-Forwarded headers) in my startup.cs. This doesn't seem to have any affect on the Location header being sent by my App Service.I presume the WAF is sending X-Forwarded headers, but if it is, the Open Auth ID stack isn't using them.
I have coded a header rewrite in the WAF to replace the myapp.azurewebsites.net with the WAF URL. This does replace the URL correctly and allows the callback, but then fails with a Correllation Error (which seems to be a generic Open ID stack error meaning "the nonce does not match". Its possible that the nonce is predicated on the URL being called back to - which in my case changes due to the WAF redirection, but that's a guess).
It seems to me like I should be able to use the X-Forwarded headers in my app to get around the need to code up header re-writes in the WAF, but I can't find an example where this is used successfully to alter the Reply URI being sent out by Open ID.
My question it; is using the X-Forwarded header the correct approach to handling proxies in an OAuth context, or is header-rewriting in the WAF the correct approach ?
I have set
After much investigation I found the following;
WAF does not send the standard X-Forwarded-Host to App Services but sends X-Original-Host instead. Documented here https://feedback.azure.com/forums/217313-networking/suggestions/33657763-add-the-x-forwarded-host-header-to-application-gat
The ForwardedHeaderOptions that ASP.net Core 2 uses in its ForwardedHeaders middleware have an option to replace the expected and supported "X-Forwarded-Host" with an arbitrary other host header name. This behaviour can be triggered as follows to replace the use of the x-Forwarded-Host with the WAF specific X-Original-Host.
options.ForwardedHostHeaderName = "X-ORIGINAL-HOST";
WAF does not pass the Path of the Path Based Route down the Http Header stack as expected in the PathBase header. This must be added to the Request Headers either in the WAF via a Header Rewrite, or inside the app as follows (in this case the apps Path Route is /Admin);
app.Use((context, next) =>
{
context.Request.PathBase = new PathString("/Admin");
return next();
});
For my Web Java application, Which is deployed on Azure VM I have done the http to https redirection on azure waf listener. which looks working fine on web but not for rest webservices.
For example: When I access the http url like http: //www.abc.com it will automatically redirect to https: //www.abc.com.
But when I am trying to access the rest post webservice with http for example: http: //www.abc.com/rs/savedata it gives error with status code -301 and status message "Moved Permanently".
However when we access rest post api with https it works fine.
I am not sure what configuration is required on Azure, so that it can automatically redirect to https for http rest request.
This is the normal behavior that is described in here: you will have to manage it from the client to call the new redirect to URL as described in here:
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-redirect-overview
if you want transparent redirect you will need to look at putting in place a Reverse Proxy Like Nginx which will handle the redirect and make a pass through.
Hi I have a question about azure mobile apps.
Can I confirm HTTP request including header, body and url parameter in azure mobile apps when troubleshooting?
If yes, how can I confirm that?
For example, let me assume that client send a HTTP request to azure mobile apps, and a the response is bad request(status code 400).
Then I would like to figure out the cause.
First of all I set [Diagnostics log] - [Web server logging] as Storage in portal.azure.com,and confirmed the IIS log.
But there is no header, body info in the HTTP request.
So I did not find out the cause by that log.
Finally problem is solved by client logs by taking fiddler and cause is wrong info in body of the http request.
Above all, by taking fiddler log in client side, I was able to solve the problem but I would like to know if there is a way to confirm http request's header, body and url parameter in azure mobile apps side.
You can log the inbound query on the client or server side, or use something like Fiddler. For the server side, just use regular methods for Node.js or ASP.NET - nothing special is needed. For the client side, I documented the process for all platforms on my blog. Although the documentation is for adjusting the HTTP request, it's the same recipe for logging.