most appropriate approach to linking two sites

You're on the right track with querystrings, and you're right they can be unsecure.  By and large, you only have to worry if someone can see an example of the querystrings being passed back and forth.  Otherwise, it's unlikely anyone will know these pages even exist.

To sidestep anyone trying to manipulate the querystrings, you could encrypt the data being passed.  ROT13, or some other simple mechanism such as just swapping characters around would probably work fine.

Using a VPN would be another alternative, but would be overkill, IMO.

Thanks Scott this looks like a good approach

To clarify, by posting a password, I mean your own passcode or "salt" that you add to the concatenated data.  

I am doing this very thing myself so wordpress php can talk to a web app I have in asp.

is this salt something that both sides agree upon first, and then hide?

Yes, both sides use the same password or salt.

The full password of course is the hashed concatenated field.  You don't have to use all fields, but at least 3 or 4 are good. Throwing in the current date or day is good too. Anything that helps avoid a pattern.

I agree with Scott. That's probably the easiest way to do things. Just to clarify one thing that he said, though:

Even if you don't have a certificate, you can use https.   

Select allOpen in new window

HTTPS does require a certificate, but I think what Scott was trying to say is that you can use a self-signed, free certificate. You don't need to buy a commercial certificate from a place like VeriSign just for this.

>HTTPS does require a certificate,

Actually, it does not.  You just have to have https turned on.  The only thing a certificate does is let the browser know it is trusted and the url in the browser is in fact the right server.   A self signed certificate will throw an warning to the browser as well.  Since we are talking about making a direct post, you can do this without a certificate.

When you use https, your data is still encrypted.

both sides are already HTTPs with signed certificates.
Scott I'm not fully understanding the salt/password mechanism.  does each side have to first agree upon some hidden key and hash mechanism so that the request and some other password are hashed together, and then the other side uses the same salt to pull it back apart?

Exactly.  Assume you use sha256 as your hash.  Assume your salt is the current date and the password, "eXpert"  To encode a first_name and last_name you would concatenate the two fields along with the date and password.    

myHash=sha256(first_name&last_name&formatdatetime(date,2)&"eXpert").

Notice I formatted the date to m/d/yyyy.  Since PHP and ASP may treat dates differently,  make sure the end result is m/d/yyyy or mm/dd/yyyy if you use the full date.  

Now myHash gets submitted to the php page with the rest of the data.  So you will want to grab each field posted individually on the php side (first_name and last_name), add the date and password in the same order and apply sha256.    Next, compare the myHash that was posted from the other server to the myHash you created on the receiving server.   If they match, you are good.  

When you process credit card transactions, you will see this same method used by some gateways.

Actually, it does not.  You just have to have https turned on.  The only thing a certificate does is let the browser know it is trusted and the url in the browser is in fact the right server.   A self signed certificate will throw an warning to the browser as well.  Since we are talking about making a direct post, you can do this without a certificate.

Just a final note for anyone else that comes across this thread - some servers will come with a default certificate installed. Turning on HTTPS without any changes may have it fall back to this default certificate, but a certificate is always required for HTTPS.

very interesting.

still confused though - if both sides are HTTPS, is plain text fine?  If not, if VPN between servers, is plain text fine? Or, is asking if plain text is fine just being lazy?

Yes it is.  Based on what I have worked on it always just worked.  It's a good day when you get to learn one new good thing!

gr8gonzo can probably answer the question about clear text vs vpn better than I can.  However, if you have ever worked with 3rd party api's or send credit card data to a gateway, the method I gave you is typical.  

The other benefit of setting up your own api like this is you can easily reuse it for something else.

I see, understood now. I like it!

I'd almost always tell people to treat server VPNs as a last resort. VPNs are great for temporary access to a network, but keeping them active all the time is a pain. Most need to refresh at points and that can interrupt things, so a VPN is not usually a good thing to rely on to be active all the time.

Clear text is probably fine if you're using SSL. There's no harm in encrypting things further so if one security layer is breached, you have a fallback. It's just up to you and what data you're trying to secure. The more sensitive the data, the more you'll want to protect it.

Most security standards like PCI DSS don't require more than one layer of encryption on the data, but it's not a bad idea if you can afford to implement it.