I have questions about our application's security architecture:
A critical piece that cannot save state but collects and displays sensitive information is served up in an IFRAME inside a more modern web framework that would control login, session, etc.
IFRAME app and parent are on same domain. Both IFRAME and parent will use https.
When user logs in to the outer web application, an iframe-ed form containing sensitive information is generated and then made available inside and IFRAME via a unique URL (e.g. hxxps://example.com/myapp/form/a8ba8b8dsf8sdfasfsd0sfd/) and immediately expired so that a subsequent request with the same url token cannot access the sensitive data. Contained in the form is a one-time, time sensitive submit token (like a csrf token) that protects against unauthorized form submission.
I am thinking that the risk of a malicious user playing around with the iframe url is nearly non-existent due to the one-time tokens.
What security risks are there to this architecture?
Is there a better way for a wrapper app to communiate with the IFRAME app?
I suppose the wrapper app could make requests directly to the child app and write the response straight out to its own page instead of using an IFRAME. We would still need to generate temporary tokens because the resulting form would still need to submit to the "child" app that cannot maintain state. The advantage to this is that now the wrapper application is the only host allowed to make GET requests to the "child" application (the client must be allowed to make POST requests but those won't be able to get sensitive information).
This advice from OWASP seems to warn against this kind of thinking but the immediate expiration of each token seems to mitigate their concerns.
Highly protected applications should not use URL rewriting to maintain state when cookies are turned off on the client.
the wrapper app making direct requests to "child" app solution will not work for us and we are going the path of the IFRAME. Are my conclusions about the IFRAME valid?