CODEWITHSUNDEEP
phpiframe
oneiros
oneiros

Reputation: 3568

Security Concern with PHP loading an iframe

I have a PHP page that has an authentication mechanism. Only after a successful login, I want to show a PHP page that resides on a different server. I could do that using an iframe, but my concern of course is that somebody can just get the value of the src attribute in the iframe and go to the page directly - hence bypassing the security mechanisms.

What would be the best way to implement this? How can I block the page in the iframe from being accessed directly by bypassing the initial login?

Upvotes: 2

Views: 1002

Answers (2)

serakfalcon
serakfalcon

Reputation: 3531

If you don't want the external site to be picked up on, I would suggest not using an iframe at all. You can get php to put the contents of the external site directly into the current page, for example, by using file_get_contents() This also allows for a simple form of security, as you can POST authentication details from the existing server to the remote one:

$opts = array('http' =>
  array(
    'method'  => 'POST',
    'header'  => "Content-Type: text/xml\r\n".
      "Authorization: Basic ".base64_encode("$https_user:$https_password")."\r\n",
    'content' => $body,
    'timeout' => 60
  )
);

$context  = stream_context_create($opts);
$url = 'https://'.$https_server;
$result = file_get_contents($url, false, $context, -1, 40000);

(example from the comments section of php curl manual on file_get_contents1)

a more sophisticated way (aka better in the long run if you have the time to figure it out) is to use curl, you can see how to get the result of a POST back using the code from this question: PHP + curl, HTTP POST sample code?

Edit: just saw your comment:

The problem with this approach is that the external site being loaded in the iframe performs numerous ajax requests to pages residing on the same server.

There's nothing to prevent you from performing the ajax requests within the page. Of course, the requests have to come from the same domain by default but there is ways around that:

  1. Have a php script on your own page act as an intermediary: basically it would pass the ajax to the external server, and then send the response back (upside, simple, downside, extra traffic generated due to the request being handled twice)

  2. Cross-Origin Resource Sharing https://developer.mozilla.org/en/docs/HTTP/Access_control_CORS) basically, you tell the client that you will use resources from another site. That way browsers won't block it as a potential hijack.

(see http://css.dzone.com/articles/ajax-requests-other-domains)

The advantage of this is it hides the source of the iframe, and allows you to use authentication between the two domains. In combination with .htaccess it can be quite secure as you can use .htaccess such that only your domain/domains running your code are allowed to access that page.

If you must use an iframe, of course you should have authentication since otherwise it will be open to the world as the client needs to access the site directly. You can POST data to the iframe (see Sending data through post method to an iframe or How do you post to an iframe?) which involves setting up the iframe as a form, and then submitting the form (which you could do automatically through javascript) to get the POST results.

Since this would have to be done client side, it not only exposes what page to go to, but also what sort of requests to send. Whether or not that is an issue is up to you and what sort of users you expect to be using your program.

As for curl, curl won't solve the problem with the iframe and ajax calls per se, but it is a more efficient and flexible url/webpage-getting command/framework than file_get_contents.

Upvotes: 3

Phil
Phil

Reputation: 824

A not so clean but effective way would be to load the remote site via file_get_contents and output it. You might have issues with path names of resources liked images, css, scripts though. You can fix them by using absolute URLs everywhere, if you control the remote site.

You might want to consider caching, if performance is an issue.

Upvotes: 1

Related Questions