CODEWITHSUNDEEP
phpiframegetembedrestful-authentication
A.O.
A.O.

Reputation: 3763

Embedded iframe - Verify source/origin of GET request

I'm seeking to utilize an iframe to embed some html in customers websites that will list some information from my database using a simple GET request like so:

// customer would copy/paste this code onto their site
// value of key would be unique key for that customer

<iframe src='http://mydomain.php/api?key=1234j1lj1hj124kh' ></iframe>


Now I want to be able to verify that the request is coming from customer that owns the key, and not just anybody who copy/pasted that code onto their page.

I've done some research and found that $_SERVER['HTTP_REFERRER'] can give me this information, but with mostly mixed reviews saying it isn't always reliable (and most of the questions I came across were a couple years old).

QUESTIONS

1.) Is this method of using an iframe/GET request the standard way of achieving this functionality?

2.) Is there a standard, SECURE and RELIABLE way to verify the origin of the GET request?

Upvotes: 2

Views: 2285

Answers (3)

Robbie
Robbie

Reputation: 17720

In summary, use a NONCE (cookied), validate IP and user agent.

Steps:

  1. When you deliver the outer frame, generate a unique identifier (totally random, long string) and return that in a cookie with the HTML content.

  2. At the same time, note the IP and the user agent string you have sent that unique identifier to, and store in a DB with the time.

  3. When requesting the inner frame, assuming the same domain, the cookie will come too. (If a different domain, you'll need to attach the unique identifier as a visible string, but that's not really of concern, just uglier)

  4. If the user agent or IP do not match those you stored against the unique string, or the request is too long (i.e. after an hour, or whatever is reasonable for your application) or the unique string is used more than once (or whatever other restrictions you place on it) then reject the request and invalidate (delete) the unique identifier.

Not 100% foolproof, but just combine more options to make it less and less likely to be abused.

Upvotes: 1

mesutozer
mesutozer

Reputation: 2859

Unfortunately this is not possible in a secure way.

To answer your questions: In fact this is not a standard functionality itself. I mean, there is no standard secure way of allowing content to be loaded only through iframes from allowed websites.

There are three parties in this communication:

1) Your website

2) Customer website that loads your website's data in an iframe

3) End user visiting customer website

When an end user visits customer web site, he will perform a GET request to your website through the iframe. At this connection, 2nd party above (customer website) is not involved. In this case, there is no reliable way for your website to know whether this request is coming through the iframe or not. Only favor that party 2 does here is adding HTTP_REFERER header to end-user's request. But this header cannot be trusted.

For example, if I want to abuse this and show that content on my website, I can create a proxy page on my application, where I perform a back-end call to your app (adding a valid HTTP_REFERER header) and display results back.

Upvotes: 1

Adi Bradfield
Adi Bradfield

Reputation: 2093

Personally I would never use iFrames for this functionality. I am assuming that this has to be reasonably secure, which is why only your specified customer can view it? If for whatever reason you can't use PHP to embed the content you need to display (through the use of an "included" file for example), I would instead use AJAX which would still use any PHP user verification you have in place to dynamically load content into a secure webpage.

This is because your PHP user verification will (should!) use cookie/session information to determine which customer is viewing the page and therefore decide whether the content should be delivered, since Session variables are determined by a single unique code stored client-side, which match up to as much information as you want to collect about a user server-side (Which could include the last page they visited, which is what the "HTTP_REFERRER" variable would give you, if they came from another page on your website).

'$_SERVER' variables aren't reliable because they rely on the information given to them by the web browser when the request is made, and such information can easily be forged, by most people who have a basic understanding about how headers are sent.

Upvotes: 1

Related Questions