Don't redirect to HTTPS for API

[Sjord]

Your API Shouldn't Redirect HTTP to HTTPS

The argument is that when a client uses 'http://api.example.org', it should fail instead of silently be insecure.

I propose to add a requirement that specifies what behavior a site should have when the HTTP version is accessed, whether it should redirect or return an error.

[elarlang]

Situation at the moment:

#	Description	L1	L2	L3	CWE
9.1.1	[MODIFIED] Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications.	✓	✓	✓	319
9.2.2	[MODIFIED] Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols.		✓	✓	319
9.3.1	[ADDED] Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application, and does not fall back to insecure or unencrypted communications.		✓	✓	319

Section titles to better understand the context of the requirements above:

• V9.1 HTTPS Communication with External Facing Services
• V9.2 General Service to Service Communication Security
• V9.3 HTTPS Communication between Internal Services

---

I find it quite complicated to write a requirement "If you use http: for an API, then don't auto-redirect to https:" as we disallow use http: in any situation.

If we find it worth to be mentioned, I think it should be done in 9.2.2.

[randomstuff]

I find it quite complicated to write a requirement "If you use http: for an API, then don't auto-redirect to https:" as we disallow use http: in any situation.

I don't think that 9.1.1, 9.2.2 or 9.3.1 intends to disallow listening on http: for redirecting browsers to HTTPS.

Even if you are certain that all your software is properly communicating using https:, third party applications communicating with your application might use http: by mistake. This makes sure that this problematic configuration does not go unnoticed.

[elarlang]

This makes sure that this problematic configuration does not go unnoticed.

I agree it decreases the likelihood, but at the same time it must be clear, that it does not fix the issue.

If a third party app communicates over http: and there is already man-in-the-middle (MiTM) in place, MiTM participant can do the redirect itself - it works "correctly" for the third party client and it works "correctly" for the service provider.

[elarlang]

The points to achieve:

• redirect to https only navigation requests
• do not redirect if the request contains sensitive data
  • give an error as a response
  • do not listen on http: (port 80) at all (for API)

[tghosth]

Ok, I think we need to focus this on API calls specifically here.

It seems unlikely but not impossible that you would use Cookies with an API so I don't think we can limit to just tokens in headers.

Since this would apply for non-browser clients which would not necessarily comply with Secure flag and HSTS.

Overall, I would propose:

13.1.8 - Verify that API endpoints will not respond to a non-HTTPS request, even with with a redirect to the HTTPS endpoint. This is to avoid API clients accidentally sending data over plaintext HTTP but this not being discovered due to an automatic redirect.

(Level 3)

Thoughts @Sjord @elarlang @randomstuff

[elarlang]

It is a wider topic than API. For example, redirects using OAuth or some SSO and containing secrets or sensitive information.

[randomstuff]

It seems unlikely but not impossible that you would use Cookies with an API

For what it's worth, I have seen that :)

[tghosth]

It is a wider topic than API. For example, redirects using OAuth or some SSO and containing secrets or sensitive information.

How would you expand the proposal then?

[elarlang]

It is a wider topic than API. For example, redirects using OAuth or some SSO and containing secrets or sensitive information.

How would you expand the proposal then?

Got stuck with providing alternative proposal. We can say, that the service getting the request from SSO or whatever other request is an API and the proposed request is valid.

The requirement is also negative requirement, but when I tried to make it positive, it's hard to keep the main problem in the focus, say probably we can leave it like that.

[tghosth]

Any better?

13.1.8 - Verify that API endpoints, including those used in SSO processes, will only respond to HTTPS requests and that an HTTP endpoint is not available, even for redirection. This is to avoid API clients accidentally sending data over plaintext HTTP but this not being discovered due to an automatic redirect.

[randomstuff]

Is is clear enough that we are talking about HTTP-based APIs (in contrast to some other RPC mechanism)?

Would we need something like:

13.1.8 - Verify that HTTPS API endpoints, including those used in SSO processes, will only respond to HTTPS requests and that an HTTP endpoint is not available, even for redirection. This is to avoid API clients accidentally sending data over plaintext HTTP but this not being discovered due to an automatic redirect.

or

13.1.8 - Verify that HTTP-based API endpoints, including those used in SSO processes, will only respond to HTTPS requests and that an HTTP endpoint is not available when used over the network, even for redirection. This is to avoid API clients accidentally sending data over plaintext HTTP but this not being discovered due to an automatic redirect.

Is it clear that the "always use HTTPS" requirements do not apply to HTTP-over-IPC (such as HTTP over Unix Domain Socket)?

Is it clear that "HTTP endpoint" is about the actual virtual + port + path (+ HTTP method)? i.e. if my API is https://www.example.com/, it is OK if:

• the server is listening on http://www.example.com/;
• the server is redirecting for example http://www.example.com/ to https://www.example.com/;
• the server must not redirect http://www.example.com/api/ to https://www.example.com/;
• but could instead answer with some 404.

[tghosth]

Ok so how about:

13.1.8 - Verify that HTTPS-based API endpoints, including those used in SSO processes, will only successfully respond to HTTPS requests. The endpoint should respond to plaintext HTTP requests with either an error or no response, and never with a redirect to the HTTPS endpoint. This is to avoid clients accidentally sending data over plaintext HTTP, but this not being discovered due to an automatic redirect.

or even

13.1.8 - Verify that HTTPS-based endpoints will only successfully respond to HTTPS requests. The endpoint should respond to plaintext HTTP requests with either an error or no response, and never with a redirect to the HTTPS endpoint. This is to avoid clients accidentally sending data over plaintext HTTP, but this not being discovered due to an automatic redirect.

[tghosth]

Opened #2432 based on discussion with Elar

[jmanico]

I know this is merged but this text is a little awkward.

non-encrypted HTTP

This is redundant.

requests with an error

This alone can be problematic. The better call it to not respond at all:

So I suggest we just keep this simple, with text like.

Verify that HTTPS-based endpoints do not respond to HTTP requests.

This drops the negative requirement of not redirecting, drops the "error message" part, and simplifies the language.

[elarlang]

Current requirement:

V13.1.8 Verify that HTTPS-based endpoints will only respond to non-encrypted HTTP requests with an error or will not respond at all. Responding with an automatic redirect to the HTTPS endpoint may lead to clients accidentally sending data over non-encrypted HTTP, but this is not being discovered.

@jmanico - Can you clarify, what is the problem to solve or improve from the current requirement? You seem to propose new versions, but without taking into account, why the requirement was created and which messages it must send.

If there no clear mistake in the current one or clear proposal for improvement, I prefer to leave it as it is.

---

If we want to move forward with this one, I would like to get highlighted add-on:

Verify that HTTPS-based endpoints either return an error or do not respond to unencrypted HTTP requests. Automatic redirects from HTTP to HTTPS endpoints can risk exposing data if clients accidentally send information over unencrypted HTTP, potentially resulting in data leakage that may go undiscovered.

[jmanico]

I only want to fix this sentence which has an awkward ending. "Responding with an automatic redirect to the HTTPS endpoint may lead to clients accidentally sending data over non-encrypted HTTP, but this is not being discovered."

Especially, "but this is not being discovered", is a bit strange language. But after hearing you and Josh's comments I do not want to change the details, just wordsmith it so it flows better.

[elarlang]

The initial idea was it was not great for APIs to redirect from HTTP to HTTPS while it might be a good idea for frontend / HTML pages. This has been dropped at some point but I think this was good to have because redirecting from HTTP to HTTPs for HTML pages provides some value (it makes it possible to provide the HSTS info to the browser).

I proposed to widen it to be more general than API, but now it is too wide. So the question is, should we have one requirement to say, in which conditions is allowed to make redirect from http: to https: or we should have the requirement (the current direction) to say, that don't do redirect if the request contains authenticated or sensitive data.

If the request was made over HTTP, the sensitive data was already sent over HTTP and not redirecting or responding does not give away this.

If the browser/client starts talking over HTTP, the fact that the server does not listen on this port does not help so much. It helps against passives attackers but any active attacker could just answer to HTTP in the target server's place.

This is taken out of context. It was written to point out the word "keep".

[randomstuff]

This is taken out of context. It was written to point out the word "keep".

Oh yes OK, I understand. :bow

[tghosth]

How about:

Verify that HTTPS-based endpoints either return an error or do not respond to unencrypted HTTP requests which contain sensitive data in the headers or body. If a client is erroneously sending unencrypted HTTP requests but the requests are being automatically redirected to HTTPS, this leakage of sensitive data may go undiscovered.

Cookies should be irrelevant because they should be marked secure only.

[Sjord]

requests which contain sensitive data in the headers or body

I am not sure this is a criteria. Not only the confidentiality, but also the integrity of the connection should be protected. If a trading bot requests http://publicstockmarket.example/NASDAQ.json the request does not contain any sensitive information, but if the response is manipulated by a MitM attacker that is still a problem.

[elarlang]

We can not fix the MiTM issue with this requirement, see #2416 (comment)

We can only set the condition when redirect from http: to https: should and can happen.

[tghosth]

@elarlang @jmanico are you good with this fix: #2416 (comment) ?

[elarlang]

@elarlang @jmanico are you good with this fix: #2416 (comment) ?

I'm ok with that.

[Sjord]

What I am saying is that in my example, publicstockmarket.example should not transparently redirect to HTTPS, because this allows clients to configure HTTP URLs without noticing, which risks the integrity of the response. How the proposed requirement is currently worded, they could have a HTTPS redirect, since they don't have "sensitive data in the headers or body".

[tghosth]

What I am saying is that in my example, publicstockmarket.example should not transparently redirect to HTTPS, because this allows clients to configure HTTP URLs without noticing, which risks the integrity of the response. How the proposed requirement is currently worded, they could have a HTTPS redirect, since they don't have "sensitive data in the headers or body".

So to my mind this is less risky because the attacker would have to have perpetual AiTM to continually feed incorrect data via HTTP

[jmanico]

@elarlang @jmanico are you good with this fix: #2416 (comment) ?

I'm ok with that.

[tghosth]

Opened #2444

[Sjord]

I feel like we insufficiently explored whether "sensitive data in the headers or body" is required, and whether integrity protection is needed. I made two comments but the proposed requirement was merged without much discussion. I feel left out, like my contributions were ignored.

[elarlang]

I feel left out, like my contributions were ignored.

@Sjord - I think your comments were answered.

Please revisit this comment and give feedback, does it make sense for you? If not, then please explain.

• Don't redirect to HTTPS for API #2416 (comment)
• Don't redirect to HTTPS for API #2416 (comment)

I made two comments but the proposed requirement was merged without much discussion.

It was agreed by 3 persons. In that case, if there is no clear problem statement to discuss, it is expected to merge it.

I feel like we insufficiently explored whether "sensitive data in the headers or body" is required, and whether integrity protection is needed.

As I understood the problem statement: the scope for this issue is only to "give feedback for misconfigured client to stop using application over http: connection". If there is man-in-the-middle scenario in place, we can not fix it with this requirement.

If there is some mistake or error in any requirement, we can always re-open related issue and fix it.

[Sjord]

If there is man-in-the-middle scenario in place, we can not fix it with this requirement.

You mentioned this multiple times, but I don't understand why exactly. You seem to assume some misunderstanding on my part, is that right? Do I have an invalid assumption or something like that?

To make sure API clients configure the correct (secure) URLs, HTTP URLs should not work. So services should not transparently redirect to HTTPS, unless they expect the URL to by typed by humans into a browser. HTTPS encryption is not only needed for confidentiality but also for integrity, so HTTP URLs should give an error whether the data contains sensitive information or not.

So to my mind this is less risky because the attacker would have to have perpetual AiTM to continually feed incorrect data via HTTP

An AiTM that by chance sees some responses by chance and modifies them could already have a large impact, but this depends on the working of the application. In my example, a single modified NASDAQ.json could make the tradebot make incorrect trade decisions. If the tradebot requests this file every minute, it is pretty likely that a AiTM can modify one response.

[tghosth]

@Sjord do you have an alternative wording suggestion?

[Sjord]

Verify that services do not transparently redirect HTTP requests to HTTPS unless the URL is specifically designed to be accessed manually by end-users via a web browser.

[tghosth]

Could you reword it to be worded as a positive requirement and also include the text that explains why?