Azure-functions-host: New Feature: Force HTTPS

[securityvoid]

Currently I don't see a way to force an Azure Function with an HTTP binding to only respond to HTTPS.

This request is for a new feature to support HTTPS only. With the security audits our applications go through, HTTPS is a requirement and we need to be sure that HTTP will not be used.

[davidebbo]

Instead of supporting a way to disable http, I think we should generally only support https across the board. The hard part is that it’s a breaking change if someone is relying on http today (which they shouldn't, but still).

[Shrulik]

Is there a way for me to programmtically tell if the function was accessed via HTTP rather than HTTPS ? So I could thorw an error at least.

[Blackbaud-MitchellThomas]

The request itself should have a "Scheme" property that you can use. HttpRequestMessage.RequestUri.Scheme. I'd be interested if this is a valid approach or if it leaves gaps.

I would still like for this to be handled at a global level. I'm in the same boat with security audits. Generic WebHooks already reject non-HTTPS traffic.

[Shrulik]

That is what I ended up doing, also curious if this is "safe enough".

[Blackbaud-MitchellThomas]

We've experienced similar behavior from the GenericWebhook function trigger:

https://github.com/aspnet/WebHooks/blob/4bfeb36657f4f52459d4006c390a8d45375a6731/src/Microsoft.AspNet.WebHooks.Receivers/WebHooks/WebHookReceiver.cs#L174

[Blackbaud-IanThomas]

It seems like that section @Blackbaud-MitchellThomas referenced is as good as any protection I could layer on top aside from blocking things at the network layer.

[securityvoid]

Blocking at the network layer is definitely be much better, since there would never be a connection to the HTTP listener in the first place.

Theoretically if there are cookies without the "secure" flag set, if an attacker was able to make a user make a request to the HTTP Listener and it was listening at all; the cookies would be sent in the clear. If the attacker was on a network in between the user and the application he or she may be able to get that value.

There are a lot of "If's" in there, which should be sufficient to drop anything on a security audit to a low or informational if you in fact make it so the application does not interact on HTTP. However, being able to block it and the network layer is a lot better, since at a minimum; there won't be any explaining to do.

More importantly, this is the type of stupid thing that old-school ops people grab onto to make an argument on why we shouldn't move to the cloud because its "less secure", and we "don't have enough control to make sure we're secure". Which is usually just a smoke screen for, "I don't want to learn something new". You can usually overcome it with logical arguments, but again; its even better to not have to explain it in the first place.

[Blackbaud-MitchellThomas]

You hit the nail on the head. For some applications, this in-code level of protection can be seen as enough of a mitigation of risk, but for more sensitive applications, especially those that fall under HIPAA and PCI scope, we don't want any gaps if we can help it.

[1N50MN14]

+1

[AranVinkItility]

+1

[rhythmnewt]

+1

[pekastel]

+1

[panovic]

+1

[richgo]

+1

[michaelj-smith]

+1

[intransit]

+1

[rhythmnewt]

For now I'm using this utility method in my functions to reject any non-https requests.

        internal static void EnsureSecureConnection(HttpRequestMessage request)
        {
            if (!request.IsLocal() && !request.RequestUri.IsHttps())
            {
                var noHttps = request.CreateErrorResponse(HttpStatusCode.BadRequest, "Only HTTPS traffic is supported on this endpoint.");
                throw new HttpResponseException(noHttps);
            }
        }

[codyfyi]

This works for me (November 2017):

In the Azure portal, go to your function app.

Platform features > Custom Domains > toggle HTTPS Only to 'On'.

Anyone using HTTP will receive a 301 Moved Permanently and be redirected to the HTTPS endpoint. You do not need to actually add a new hostname/domain to toggle this feature. This appears to work with both consumption and app service plans.

[rhythmnewt]

Looks like it was added recently to app services. Seen plenty of articles with that screenshots from that screen and that option was not there! Thanks for the information.

[davidebbo]

Yep, it's brand new indeed. Let's call this one done.

[michaelj-smith]

Is there any way to specify this option in an ARM template that creates the function app?

[davidebbo]

Yes, just set "httpsOnly": true on the site object (i.e. as a sibling to clientAffinityEnabled).

[Blackbaud-IanThomas]

@davidebbo is the update to app service documented anywhere?

[davidebbo]

Not sure. I'd expect it to be mentioned on some post to https://blogs.msdn.microsoft.com/appserviceteam/, but not seeing one now.

[OGalaev-Quest]

By some reason "httpsOnly": true takes no effect during fresh new deployment. It only applies with redeployment to existing app. Is there any explanation for such behaviour?

[davidebbo]

@OGalaev-Quest that looks very much like a bug (I verified it). I will contact the code owners about it.

[ChrisOwczarek]

I cannot get it to work even after the app service has been created.

One approach is to use rewrite rule in web config (https://blogs.msdn.microsoft.com/benjaminperkins/2014/01/07/https-only-on-windows-azure-web-sites/) but I really don’t want go through all my services and do this. It would be good to know if this is accepted as a bug and some time scale for a fix?

[davidebbo]

Saying it doesn't work even after creation is basically equivalent to saying that the feature is generally broken and can't be used at all, and we know that's not the case. So I think something else is at play for you here. Try manually setting it post-creation via https://resources.azure.com/, and verify that the setting sticks.

[ChrisOwczarek]

Thanks David. It's actually the portal not refreshing and causing confusion. Resource explorer showed the updated status correctly. However the blade does not reflect the status, either after clicking the refresh button (in blade) or moving to another blade and back again. Only a browser CTRL+F5 refreshes the status.

[davidebbo]

@ChrisOwczarek yes, the Portal does some caching so it's common for recently updated settings to not be reflected right away.

so to summarize, the only known issue here is that it doesn't work on creation.

[ChrisOwczarek]

Thanks David. But I would say the refresh button (on the blade), when clicked, should result in the latest setting being shown and it does not. Cheers.

[davidebbo]

@ChrisOwczarek yes, I was focused on the backend side. There is definitely a Portal refresh issue, and it is more general (not specific to this setting).

[jeanpaulsmit]

I'm facing the same issue that the httpsOnly field in the ARM template is not acknowledged. When can we expect this to be fixed?
I created an issue on the Azure-Functions repo before I knew about this one.
https://github.com/Azure/Azure-Functions/issues/647

[davidebbo]

@jeanpaulsmit the fix should be live everywhere by the end of the month.

For now, note that if you run your template a second time, it should work.

/cc @jennylaw

[Vossekop]

I'd like to know by the end of which month it should be live? Because it is certainly not working for us at the moment.

[securityvoid]

@davidebbo I don't know if this goes here or in another feature request, but it probably makes sense for the HTTP Header Strict-Transport-Security to be set when this is enabled:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

This will help keep the browser from ever sending anything over HTTP, even if the developer makes a mistake and has a reference to an unsecure resource.

I know the way the setting is working any call to HTTP will redirect to HTTPS, but cookies could still potentially be sent on the HTTP call if not configured properly.

[securityvoid]

@Vossekop This is definitely in place. I am using it.

Check Platform Features -> Custom Domains

[Vossekop]

@securityvoid Sorry, I was refering to @jeanpaulsmit 's issue of using the httpsOnly field in ARM templates. Which is what I am trying to use and isn't working as far as I can see.

[davidebbo]

The ARM issue is supposed to be fixed, but I'll let @jennylaw confirm.

@securityvoid for the Strict-Transport-Security, I think it's best to open a separate feedback item on https://feedback.azure.com/forums/169385-web-sites/ (there may already be one).

[securityvoid]

@davidebbo Okay, its posted here:
https://feedback.azure.com/forums/169385-web-apps/suggestions/33509452-strict-transport-security

Hopefully this can be implemented, as it will knock one more finding off of the Security Reports.

Since with regular websites you can set headers with a web.config, I'm not sure if they will view this as that high of a priority. Primarily it impacts functions where you can't use a web.config (At least that's been my understanding).

Here are instructions on how to do it with a web.config, that should work with the normal Azure Apps.
https://www.hanselman.com/blog/HowToEnableHTTPStrictTransportSecurityHSTSInIIS7.aspx

More details on what this feature does, if you're interesting in reading more:
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet

Setting this header when a website is only available over HTTPS is considered industry best practices and it is a logical setting to correspond with that toggle which was implemented.

[davidebbo]

@securityvoid correct, you can't provide your own web.config. Furthermore, with Consumption functions, you can't use site extensions, so this (3rd party extension) won't work: https://www.siteextensions.net/packages/HstsSettings/