I currently have a WordPress website hosted on 3 virtual machines behind an application gateway. When users are trying to submit a form via our websites sponsorship pane, after clicking submit users are prompted with:
403 forbidden microsoft-azure-application-gateway/v2
I've done a significant amount of research and viewed the logs and I'm not seeing any red flag that is causing restricted access to the resource. The WAF is set to prevention so maybe it's seeing the form submission as a type of malicious activity and blocking it? Not quite sure at this point though.
I am not a web master, so my scope of service stops after it leaves the Azure portal.
Please advise.
After digging around the WAF logs, the way that the form is being transmitted to the website is being flagged as malicious and classifying the request as an SQL injection attack.
How I mitigated it in two ways:
Navigated to the Web application firewall (WAF) and disabled the rule in question
Add specific custom rules for exclusions for specific URLs
Related
I'm following the guide here to setup Application Insight telemetry on a frontend web form. I wish to use the snippet-based setup. I notice, however, that it requires me to embed the connection url in the html page. Is that a security issue?
There would be nothing to stop a malicious user from using browser dev tools to grab that url and then send any API calls to that url. Should I be concerned about this? If so, what is the recommended approach for securing this connection url.
... what is the recommended approach for securing this connection url.
There is none. For now you have to accept it is visible somehow. See also this open issue regarding the topic
Should I be concerned about this?
Not so much. The instrumentation key cannot be used to read any telemetry. However, it could be used to send bogus telemetry to your application insigths resource. This could lead to higher costs depending on the amount of data ingested and it could clutter your logs, possible masking possibly relevant telemetry.
Unless the application is hosted on a vnet integrated resource you cannot restrict access to application insights resource. If it is, then you can set application insights to deny queries or ingestion from external sources in the network isolation setting.
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-security
So even if someone gets the url they cannot access.
I'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)
I have researched around a bit where all of the captive portals are little bit complicated in terms of configuration.
I dont need AAA , I would just show a webpage where user will be click yes accept terms and then it will redirected.
I am using ignite cloud controller to manage the access points.
Implementing a service where I would like fetch SSID from a repository to match incoming SSID and then redirect based on the SSID.
I am trying to build something externally. My networking skills are pretty new.
I am confused how to get IPAddress and Necessary details from the access point there is an option in ignite cloud controller where I can specify the external settings for captive portal. (Like If my captive portal is running on remote IP, I know I can capture request incoming from access point. How? Can I build a normal web service to do that?)
I think it is straightforward implementation but little guidance is required.
I solved the above by creating a simple web service which filters the request sent from the ACCESS POINT.
There was an option in ignite cloud where I could redirect to my web-service
Once AP redirect I have to set variables in the request forwarding it back to AP with res=success.
Then it will allow me to browse web as expected.
Thanks
Having an issue with users of one domain from viewing a website being hosting on another domain. Both domains are internal, domain1.local & domain2.local.
The website hostname is webapp.domain1.local. It is being hosted on a server webserver.domain2.local. When i view the site off the "Default Web Site" as a sub-webapp, it renders correctly when a user, domain2\user, is accessing the "Default Web Site" it renders correctly. But if the same user were to access the webapp web site, with hostname webapp.domain.local, there is an access denied.
Default Web Site:
Hostname: localhost default for IIS 7.
webapp Web Site:
Hostname: webapp.domain1.local
Both IIS 7 websites having a webapplication named webapp.
According to our Network Administrator, there is an existing passthrough communication handle but seems to be quirky on what gets passed through.
Background
Over the last 5-7 years the company has been absorbing other smaller companies and during this time absorbed a company as big as them and hence the two domains. We are currently in the process of migrating to domain1.local but its taking time cause of the sheer size of domain2.local.
Its hard to say without Event Viewer and/or IIS logs from the troublesome server (in either direction) however it looks to me like passthrough is probably doing what it should and denying access because the users are not allowed to authenticate.
I would say your looking at setting up cross domain authentication in its entity e.g. file shares from one domain to another how does that work? If the problem is more wide spread then really your looking at setting up a domain trust relationship between Domain1 and Domain2 (http://technet.microsoft.com/en-gb/library/cc739693(v=ws.10).aspx) either this or allow anonymous access to the website but its not exactly secure :)
Any questions let me know.
Charles
I currently have a VPS with another provider. On that VPS, I have IIS running with multiple app pools and web sites. I would like to get out of the "server management business", so it would seem that Azure Web Sites (Reserved) would be a great fit. I'm able to get the Azure Web Sites set up, including the custom domain piece. The problem that I can't seem to figure out is how to get the same URLs and behavior that I currently have on my VPS.
For example, I have URLs that look like this right now:
www.foo.com/bar
www.foo.com/baz
wildcard.foo.com/bla
I can't find a way to mimic that in Azure.
Things I've thought of/tried:
Go with one Azure Web Site and have separate virtual directories/app pools in Azure, but googling tells me that isn't supported.
Create 3 Azure Web Sites, one for each of the above. The problem there as I see it is I would need to change to use bar.foo.com, baz.foo.com, and bla.foo.com/wildcard (i.e. lose wildcard subdomain mapping and rework things to have a custom route at the end).
Maybe have one Azure Web Site with a rewrite URL? The problem I think I'd run into there is that it all runs in one app pool, so deploying one piece will affect all 3, and obviously a fault in one app would impact the other 2.
Has anyone else gone down this path and solved it? If the answer is spin up a virtual server, I'll probably just stay where I'm at.
Considering www.foo.com/bar, www.foo.com/baz and wildcard.foo.com/bla are 3 independent web applications that share a domain (foo.com):
Create a Windows Azure Website for each web application. You don't necessarily need to assign custom domain names to them.
Create another, separate website and assign to it the *.foo.com domain using an A record. Refer to Configuring a custom domain name for a Windows Azure web site for instructions. As documented, "With an A record, you map a domain (e.g., contoso.com or www.contoso.com) or a wildcard domain (e.g., *.contoso.com) to the single public IP address of a deployment within a Windows Azure web site. The main benefit of this approach over using CNAMEs is that you can map root domains (e.g., contoso.com) and wildcard domains (e.g., *.contoso.com), in addition to subdomains (e.g., www.contoso.com)."
In this "master" website, set up URL redirection (possibly with status code 307 Temporary Redirect) so that requests go to the appropriate applications.
Alternatively, to avoid the delay of the additional request caused by the redirection, set up the "master" website as a reverse proxy that transparently forwards the request to the "inner" web application and sends the response back to the user.
As yet another alternative, use a custom DNS service to do the routing at the DNS layer.
This way, each web application is independent and you solve the issue of routing requests to the appropriate application.