Change:
What happened: The name of an arbitrarily supplied URL parameter is copied into the HTML document as plain text between tags. The payload cfk88<scriptalert(1)</scripty9rri was submitted in the name of an arbitrarily supplied URL parameter. This input was echoed unmodified in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the response. The response does not state that the content type is HTML. The issue is only directly exploitable if a browser can be made to interpret the response as HTML. What you expected to happen: the response should not contain any valid HTML content. Avoid to nject arbitrary JavaScript. How to reproduce it (as minimally and precisely as possible): Just make the backend service unreachable. For example, https backend service is only supported. Anything else we need to know?: Environment: Kubernetes version (use ): v1.14.2 Cloud provider or hardware configuration: None OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery /priority important-soon
Similar issue kube-apiserver did not know how the response will be handled. But if it was interpreted by browser it's a security issue. Not sure we can transform the error message to something which cannot be interpreted by browser before return the response. cc
responses from kube-apiserver seems correctly setting header, either json or protobuf.
the json encoding explicitly escapes to to avoid the browser interpreting it as HTML /close
Closing this issue. <detailsIn response to : the json encoding explicitly escapes to to avoid the browser interpreting it as HTML Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Can you check the origin issue Sorry to bring issue and get you confused. As you see the html element , was not encoded.
ah, you're right, I thought was the issue description /reopen
Reopened this issue. <detailsIn response to : ah, you're right, I thought was the issue description Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
Is there a PR/work associated with this issue yet?
there is not. a PR would be welcome
Hi, is there a PR to fix this issue?
opened to resolve this
Is this fix mapped with the latest versions? Looking to the v0.19.3 code I don't see these changes and scanning my docker image (XRAY scanning) that is integrating the version v0.19.3 I can see this vulnerability that seems fixed in a version older than the one I am using. Am I wrong?
Yes, it is present. The issue was fixed in That commit () is present in the repo in v0.16.4+ as

Discussion:
resp, err := rt.RoundTrip(req) if err != nil { <del> message := fmt.Sprintf("Error: '%s'nTrying to reach: '%v'", err.Error(), req.URL.String()) </del> <ins> message := fmt.Sprintf("Error trying to reach service: '%v'", err.Error()) </ins> resp = &http.Response{ <ins> Header:     http.Header{}, </ins> StatusCode: http.StatusServiceUnavailable, Body:       ioutil.NopCloser(strings.NewReader(message)), } <ins> resp.Header.Set("Content-Type", "text/plain; charset=utf-8") resp.Header.Set("X-Content-Type-Options", "nosniff") </ins> return resp, nil }