Incorrect or missing MIME type as both Medium and Low Risk - difference?

[GoogleCodeExporter]

(Note: I've read the FAQ on MIME types :)

I see this classified both as a Medium Risk and as a Low Risk issue. What's the 
difference? In all the cases, the page is a 302 (to a "you need to sign in" 
page - I'm guessing skipfish logged itself out of the app at some point), the 
Content-type says text/html, and skipfish says it should be text/plain - but I 
can't tell what the key difference is. Examples of both follow (top is Medium, 
bottom is Low).

==

HTTP/1.1 302 Found
Server: nginx/0.8.52
Date: Thu, 21 Oct 2010 21:36:57 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Location: skipfish://invalid/;?
Content-Length: 101
Set-Cookie: ...

302 Found

The resource was found at skipfish://invalid/;?; you should be redirected 
automatically.  

==

HTTP/1.1 302 Found
Server: nginx/0.8.52
Date: Thu, 21 Oct 2010 21:34:06 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Location: https://x.x.x.x:4000/xxx
Content-Length: 123
Set-Cookie: ...

302 Found

The resource was found at https://x.x.x.x:4000/xxx; you should be redirected 
automatically.  

Original issue reported on code.google.com by yaa...@gmail.com on 22 Oct 2010 at 11:45

[GoogleCodeExporter]

"Medium" is used for cases where scanner input is directly observed in the 
resulting output, which is a good indicator of immediately exploitable HTML / 
charset sniffing bugs.

"Low" is reserved for cases where input is not directly seen, but that should 
still be inspected for user input. You can also use -J to disable these 
low-risk warnings.

Original comment by lcam...@gmail.com on 22 Oct 2010 at 11:50

• Changed state: Done

[GoogleCodeExporter]

Thank you.

Original comment by yaa...@gmail.com on 22 Oct 2010 at 11:59

[GoogleCodeExporter]

One more follow-up question: in the above Medium Risk example, is there 
actually a vulnerability? The URL is properly escaped/quoted in the 
response.... (It's a redirect/continuation URL.)

Here's another Medium Risk example:

=== REQUEST ===

GET /foo/search?q=1-->">'>'"<sfi000142v524891> HTTP/1.1
Host: x.x.x.x:4000
Accept-Encoding: gzip
Connection: keep-alive
User-Agent: Mozilla/5.0 SF/1.69b
Range: bytes=0-199999
Referer: -->">'>'"<sfi000142v524891>
Cookie: ...

=== RESPONSE ===

HTTP/1.1 302 Found
Server: nginx/0.8.52
Date: Thu, 21 Oct 2010 21:40:14 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Location: 
https://x.x.x.x:4000/auth/signin?cont_url=%2Ffoo%2Fsearch%3Fq%3D1--%3E%22%3E%27%
3E%27%22%3Csfi000142v524891%3E&email=
Content-Length: 216
Set-Cookie: ...

302 Found

The resource was found at 
https://x.x.x.x:4000/auth/signin?cont_url=%2Ffoo%2Fsearch%3Fq%3D1--%3E%22%3E%27%
3E%27%22%3Csfi000142v524891%3E&email=; you should be redirected automatically.

Original comment by yaa...@gmail.com on 23 Oct 2010 at 12:07

[GoogleCodeExporter]

That first example is definitely vulnerable to redirection to arbitrary 
protocols (including vbscript: / javascript: / data:), which can lead to XSS in 
certain browsers.

It is probably not vulnerable to XSS; I should probably tweak the filter if you 
use HTML escaping for that output, the scanner is just not happy that the 
format of the response does not seem to be HTML. In this particular case, this 
is probably harmless, but is a problem when you - for example - return 
text/plain, text/csv, or text/javascript with C-T of text/html.

Original comment by lcam...@gmail.com on 23 Oct 2010 at 12:50