3

The security team of my company is stating that content spoofing occurs when they send a different "content-type" for an HTTP request that only accepts JSON content type, and the server response is an error HTML page, naturally with content type "text/html". They are complaining only about the content type of the response, not what is retrieved on the error HTML page, which contains only some generic text like "An error occurred". They say the content-type of the response should be always the same as the one you send in the request because it can propitiate security exploitations such as XSS. Personally, this does not make any sense to me, and I really dont understand how can this be a security flaw.

Can this be considered content spoofing and, also, can this propitiate security exploitations?

  • 1
    Hi and welcome to Security.SE! I edited your title, hopefully that still matches the spirit of your question. If not, feel free to edit it again. – Mike Ounsworth Jan 29 '19 at 16:59
2

It seems like your security team has an overly-strict idea of what Content Spoofing is. For a background, I'm looking at the OWASP page on Content Spoofing, main point:

When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.

As usual, ask your security team for a demo of the vulnerability that they believe they have found! If they believe there is a Content Spoofing / Cross-Site Scripting (XSS) vuln here, then they should be able to demonstrate it (ie craft a request to your server that results in a <script>alert()</script> popup in your browser.


Content Spoofing attacks (and XSS more generally) are all about sending malicious input in the request that is reflected in the response.

The point of the Content-Type: header is to tell the browser how to interpret the response. This can help reduce the attack surface because you only need to worry about user input that is malicious within the specified content type. For example, if it's Content-Type: text/html then you need to HTML-escape any user-supplied text that has been embedded in the response. If it's Content-Type: text/javascript, then I really hope you're serving a static .js file and not reflecting any user input into it. On the flip side, if its Content-Type: text/text or Content-Type: application/json than you don't need additional output escaping because the browser won't try to run this as code anyway.


Your situation

It sounds like you have an API endpoint that accepts POSTs with a JSON body, and on errors it returns an HTML error page. I agree that it's more common for JSON APIs to return JSON error messages, but returning static HTML error pages is perfectly fine from a security perspective. Of course, if you're taking parts of the request and embedding them un-escaped in the HTML response, then you'll have XSS, but that's almost a separate issue.

From reading your question, it seems like your security team wants the attacker to be able to control the Content-Type of the response? That seems absurd to me. The Content-Type header should match the content; if the error response contains an HTML page, then the server should indicate so with Content-Type: text/html.

As stated above, if your security team believes there is a security issue here, then ask them to demo it!

| improve this answer | |
1

The content-type response depends on the server implementation basically. So if you make an HTTP POST with some json on it and you need an Authorization header, probably the server will respond with a content-type plain/text that basically means that you don't need a special software to process the response. On the other hand, if the HTTP service is based on JSON all the services it would desirable that all the requests and responses will have the content-type as json, but this depends on the implementation of the service.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.