0

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.

  1. What security risks are there to this architecture?

  2. 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.

UPDATE::::::

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?

  • How does the inner frame know what is and isn't a valid token? Are the backend servers communicating in some way so they can exchange tokens? – u2702 Jan 16 '15 at 0:49
  • thanks for responding. The inner frame creates a document (HTML or PDF) with a URL containing the valid token and then lets the wrapper app know that URL and then expires it (the document is destroyed). – mcgyver5 Jan 20 '15 at 19:56
1

You can make the requests to the child app directly from the wrapper's server code and drop the use of the iframe. The child app should only allow access from the main application server.

This would also result in a better user experience, because you would have a better, uniform design.

  • I like it Dino. Unfortunately I have since learned that the "direct requests to child app" won't work and I have updated the question. – mcgyver5 Jan 15 '15 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.