User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151029151421 Steps to reproduce: Please access the following page. https://mallory.csrf.jp/ios/hsts.html Click the 'Set HSTS' button. At this time, the response header has 'Strict-Transport-Security'. Go back to previous page. Click the 'HSTS Not Applied' button. This button link to 'http://cs%5crf.jp'. (%5c is the most important.) Actual results: HSTS does not work. HSTS bypass was successful. Expected results: If %5c included, access should not be successful.
Not sure if the iOS version is part of the bounty program but nominating all the same
Does this also affect Safari? If so, have you filed a WebKit bug and/or a rdar?
Yes. This bug also affect Safari, and I already reported this to Apple as a WebKit bug.
Please include a pointer to the WebKit bug here, if you can.
I received email about 'Wall of Fame' from Apple yesterday. So I think this WebKit bug be fixed in the next iOS/OS X update. However, I don't know the exact dates for that.
Minusing for bounty as this is a webkit issue that clearly reproduces in Safari. Apple is now aware of it and is working on it (or has fixed it).
I can think of at least two possible fixes: 1) Load https://csrf.jp (i.e., load csrf.jp like we do now, but with HSTS enabled). 2) Show an error page for http://cs%5crf.jp because it's an invalid URL (Firefox desktop does this). I think we'd probably want to go with #2. That said, I'm trying to figure out how this can be exploited to decide if this is worth an attempted fix before v1.3. Could you describe a scenario where an attacker could use this?
Sorry for my late reply... This webkit bug fixed in iOS/OSX update today. CVE-2015-7094 https://support.apple.com/en-us/HT205635
Thank you for the update!