Can the Origin header have alphabetical port or parameters in a real-life scenario?

Question

I'm testing this application which is properly validating origin header on the sever side. However, if I add any domain and the expect domain as port, application still consider this valid.

Origin: https://random-domain.com:expected-domain.com

This is also valid.

Origin: https://random-domain.com?expected.domain.com

I'm doing all this from my intercepting proxy but in real world origin header can't have parameters, fragments or alphabetical ports (numeric ports are possible though)

Is there a solution for this? I'm looking for a solution to bypass this and send an arbitrary origin header value and still get successful response.

Answer 1

If you're wondering whether the behaviour you described can be abused, I can think of at least one exploit (described by James Kettle, from PortSwigger) that can lead to the equivalent of stored XSS, but only under certain conditions:

1. The value of the Origin request header gets reflected verbatim in the Access-Control-Allow-Origin response header can have security implications.
2. There is some Web caching but no Vary: Origin in responses.

You could then craft a request with a malicious Access-Control-Allow-Origin value containing a carriage return,

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

which would result in a header injection in some browsers (IE),

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

That malicious response would get cached on the server side and delivered to subsequent visitors.