0

I am creating a web application that is sending sensitive data between servers. I need to take user inputted web form data from website 1 (abc.com) and post the data to website 2 (xyz.com/api). Website 2 will capture the data from website 1 and score it and then return a json response that will be published in the user's browser on website 1.

Both websites will have https.

An Asymmetric-Key using Open SSL will be used.

  • Website 1 will use open ssl to encrypt all data with a generated public key before sending and website 2 will unlock data with private key known by website 1 and 2.

  • With the transmission of the data, Website 1 will also send a signature with openssl_sign signed with the private key and that will be checked with a public key on website 2.

  • Response from website 2's api will be sent back to Website 1 in json.

  • Before website 2 processes the posted request, it will verify the domain is authorized, it will verify the signature with openssl_verify and will verify the timestamp is within limits. It will sanitize data before processing it into a database.

In my application I have used php curl on website 1 to post to the api on website 2.

In my below questions, assume the web form on Website 1 is using best practices for validation and to sanitize the inputted data.

Here are my questions:

  1. Is this a secure model for a sever to server communication? Should I be considering other items?

  2. Do I need to be worried about the security of accepting post data from php curl?

  3. Instead of php curl what other methods can be used to post data to the api that may be more secure?

  4. Is it necessary to use open_ssl to encrypt the Json response from website 2 back to website 1?

  5. Is there a better model to accomplish the above?

3
  • 3
    "SHA512 private key" - there is no such thing. There are ECC or RSA public and private keys and there is a SHA-512 hash algorithm, but there is no SHA512 private key. Based on this it is unclear to me what you are doing. Why not just use HTTPS ? What are you trying to achieve with the added complexity? What risks you are trying to address which are not already addressed by simple HTTPS? Commented Sep 12, 2021 at 20:39
  • @SteffenUllrich sorry I did not communicate that well. Basically I was saying the key was generated with this open ssl like this: $config = array("digest_alg" => "sha512", "private_key_bits" => 2048, "private_key_type" => OPENSSL_KEYTYPE_RSA, ); $resource = openssl_pkey_new($config); // Extract private key from the pair openssl_pkey_export($resource, $private_key, NULL); I edited to prevent confusion. Commented Sep 12, 2021 at 20:57
  • @SteffenUllrich basically if I understand your questions, you are indicating that HTTPS is sufficient security for this type of application. I don't need to worry about any type of private and public key structure? Commented Sep 12, 2021 at 21:03

1 Answer 1

1

Is this a secure model for a sever to server communication? Should I be considering other items?

It's not. You are inventing a very complicated wheel after someone invented a better and simpler one decades ago. You must just use HTTPS as it is, nothing else is needed.

Do I need to be worried about the security of accepting post data from php curl?

For your application, there's no difference between a browser, curl, a python script or someone doing the TLS handshake by hand. So if your application is secure, the client does not matter. And you cannot build a secure application that depends on the client to be secure.

Instead of php curl what other methods can be used to post data to the api that may be more secure?

If it's secure to send data using curl, it's secure to use anything else on your toolkit.

Is it necessary to use open_ssl to encrypt the Json response from website 2 back to website 1?

No, it's not. Just access anything over TLS and you are good.

Is there a better model to accomplish the above?

TLS on everything. And only TLS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .