Note: You are welcome to write more research questions in the comments.
- For older browsers it was possible using style attribute, however it doesn’t work on new browsers.
- If the injected vector (value attribute) comes before the input type attribute then its possible to inject a type=text attribute which will turn the input tag into text instead of hidden. However the first type attribute is the one which decides the tag type so if the injector vector comes after the type attribute then this trick will not work and we are stuck again.
- This post: http://blog.innerht.ml/cascading-style-scripting/ shows how to do xss in hidden input tags using css. The technique it uses on modern browsers only works on internet explorer and it uses UA-Compatible to turn into old IE compatability mode (EmulateIE7) which allows to execute stuff as though the browser is IE7. However this requires to injection the compatability mode tag into the page and if you are stuck inside a tag then its not possible. He presents a way to overcome this problem: he says that if you have a page which appears in microsoft cv list in compatability mode IE7 and you open an iframe in that page then the content in iframe automatically gets the IE7 compatability mode. The lists of such pages are whitelisted here: https://msdn.microsoft.com/en-us/library/gg622935(v=vs.85).aspx , for example the list for IE11: https://iecvlist.microsoft.com/IE11/1387494476607/iecompatviewlist.xml so you need to find a vulnerability in one of the whitelisted pages and inject there an iframe that opens the page you want to exploit the xss at. This is hard and unlikely way to exploit the xss. It does allow the whitelisted pages to exploit the xss though.
- It’s possible on firefox to execute script in input hidden when user presses a combination of keys, by using accesskey attribute and onclick. The accesskey attribute helps trigger onclick when the combination is pressed: http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.html
- In windows before the introduction of zero session isolation in windows vista, there used to be a shatter attack which was based on the idea of sending windows messages from a low priveleged process to a high priveleged window. https://en.wikipedia.org/wiki/Shatter_attack
- Html5 introduced a new api of sending messages to other windows and frame even across domain. The api is postMessage: https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
- See discussion of the possible csrf vulnerability of implementations using postMessage: https://secinfodb.wordpress.com/2016/06/11/postmessage-sophisticated-csrf/
- So the open question is: can there be a way to utilize the postMessage mechanism like the windows messages mechanism, in order to produce some kind of attack? Since the other window\iframe is on the same browser, overloading its client side resources will not produce the desired result in contrast to the shatter attack. However maybe still there might be some innovative idea utilizing postMessage for an attack?