new requirement: end-user should not be able to give and/or manipulate headers which an application expects/uses from load balancers or proxies

[elarlang]

Problem to solve: if an application uses HTTP request headers (like X-Forwarded-* headers) from load balancers, proxies etc, then it should be clear that those headers are not given by end user.

Fits to category: V14.5 HTTP Request Header Validation

[tghosth]

Something like:

Verify that http headers which the application relies upon for business logic or security decisions such as X-Forwarded-* cannot be manipulated/controlled by the end-user.

What do you think @elarlang ?

[elarlang]

Can we use something like...

Verify that HTTP headers, which are set by middleware like proxy of load balancers, and application relies upon ...

End-users can manipulate those headers anyway, the point is, that this middle-layer should clean up headers with the same name.

[tghosth]

Are there any other security sensitive headers that you want to consider here or only those related to the original IP?

If there are other headers then this needs to stay as a separate requirement and we should be more specific maybe.

If the only headers we are talking about are those which provide source IP then I think we can merge with the requirement in #1389.

[jsulinski]

Not just IP, there are:

• X-Forwarded-For
• X-Forwarded-Host
• X-Forwarded-Proto

Rails has historically struggled with these in certain configurations.

Perhaps something like:

Verify that HTTP headers defined by intermediary devices, such as X-Real-IP and X-Forwarded-*, that the application relies upon cannot be overridden by the end-user.

[elarlang]

I was thinking about it more and those (#1389) need to be separate requirements.

and/or to and in @jsulinski proposal and it's good for me.

[elarlang]

Requirement:
Verify that HTTP headers defined by intermediary devices, such as X-Real-IP and X-Forwarded-*, that the application relies upon cannot be overridden by the end-user.

Other pieces/proposals:

• Category V14.5 HTTP Request Header Validation
• Level: 2
• CWE proposal CWE-345

[tghosth]

My modification:

Verify that if the application relies upon HTTP headers such as X-Real-IP and X-Forwarded-*, which are defined by intermediary devices like load balancers or proxies, that these cannot be overridden by the end-user.

[elarlang]

One more thing - "relies upon" ... maybe just "uses"?

[tghosth]

Verify that if the application uses HTTP headers such as X-Real-IP and X-Forwarded-*, which are defined by intermediary devices like load balancers or proxies, that these cannot be overridden by the end-user.

Yeah ok. Any other comments @jsulinski ?

[jsulinski]

Sounds good to me! Here's another version if you prefer, that resolves the awkwardness of 'which/that these':

Verify that any HTTP headers used by the application and defined by intermediary devices like load balancers or proxies, such as X-Real-IP and X-Forwarded-*, cannot be overridden by the end-user.

[elarlang]

I updated PR based on that (097e6fa)

[tghosth]

@elarlang what do you think about CWE-346 instead of CWE-345?

[elarlang]

Both are ok, but what is the key difference?

• CWE-345 - Insufficient Verification of Data Authenticity
  • The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
• CWE-346 - Origin Validation Error
  • The product does not properly verify that the source of data or communication is valid.

346 and Origin in web context associates with the Origin header.

From #1481 point of view, it does not matter too much anyway.

[tghosth]

@elarlang let's make it 346 anyway but I accept that this sort of thing is potentially going to become less important going forward

[elarlang]

(PR is updated, #1720)