-1

I have a problem. I need to pass variables from one site to another site. I don't want to use GET method as I need to pass some secure variables.

How would I do it?

Oldskool
  • 34,211
  • 7
  • 53
  • 66
  • In terms of security, POST and GET are equally insecure; an alternative approach is to encrypt the variables, provided that the domain you're redirecting to can decrypt it again. There are more elaborate ways, such as a token based mechanism (whereby the actual data is transferred by the server but the client only uses an opaque identifier). – Ja͢ck Jun 09 '15 at 02:45

2 Answers2

3

Your best (and most simple) bet if you're concerned about security would be to:

  1. Using cURL over SSL, create a new POST to server 2
  2. After the POST is complete, server 2 will respond with a TOKEN
  3. Use this token in your GET request / browser redirect from server 1
  4. On server 2, check the token and find the data

This is a simple way of doing a secure "pass" of data... albeit, there are more elegant solutions.

See example of flow:

Example of flow

Rob W
  • 9,134
  • 1
  • 30
  • 50
0

Did you consider http POST? It works just like GET, as far as its PHP/HTML implementation: <form action="inputUrl.php" method="post"> for sending and $_POST["var"] for receiving.

As far as security goes, POST is much better than GET, as the data is sent behind-the-scenes, rather than embedded in the URL, making it the typical protocol for login info. It also works well for one-time actions, like purchases. However, it still sends data in plain-text by default, so you should definitely enable encryption/decryption on the two respective servers to enforce data security. You can do this easily enough with PHP; look into the crypt() function.

Community
  • 1
  • 1
BradzTech
  • 2,755
  • 1
  • 16
  • 21
  • I cannot tell a browser to make a post request through an HTTP header. The location header will redirect, but only for GET or HEAD requests. – user4988384 Jun 09 '15 at 02:38
  • I wouldn't say POST is much better; while it's (marginally) more obfuscated, the client can still inspect the payload. – Ja͢ck Jun 09 '15 at 02:52
  • 1
    When I wrote this, I assumed your server does not have SSL. Otherwise, @Half Crazed is definitely the better solution (but it still technically uses POST!) – BradzTech Jun 09 '15 at 10:09
  • 1
    Correct - it does post, but the user is completely unaware of the payload. Though an attacker could be a "man in the middle" or even attack server 2 and cross reference the token to find the data. There's a ton of ways to prevent this, but I felt like my solution was one of the easier ones heh – Rob W Jun 09 '15 at 19:35