1

Hi Everyone,

I'm not sure if I may be in the wrong venue to post as this would have to do with PHP, CURL and SSL, so I've decided to place the question here. Please feel free to let me know if the question should be dropped in some other location…

My company has been using a ticketing system that is hosted on another server being cloud based which uses a RESTful style API over HTTP using XML. They also use HTTP Basic Authentication over SSL to secure data.

For any options worth knowing, the cloud based ticketing system cannot host any of the custom forms that we've designed. They will not allow any custom additions to their tables either. So, utilizing the API is out of the question because of the custom form data requirements which demand more columns than that are currently provided by the ticketing systems API.

Logically, the solution is now deduced to one alternative; to submit and email data from a custom form from another server - securely if possible.

The server hosting the custom forms would have no issue of SSL being implemented – which would at least to provide security for the front end, however, it is the backend in were my question is; how is it that this data can be secured and/or is there a secure way of providing a secure tunnel through PHP and/or CURL by the ticketing systems server authentication?

The information too that is being submitted is not a high security risk such as HIPPA, Social Security Cards, Credit cards or even purchase related. Basically, the submitted information would only contain names, phone numbers and messages regarding product information.

Is it possible that one could use a client URL (CURL) with PHP to authenticate then email the data to the ticketing system and view this as secure way of submitting the data? Should specific headers be used to indicate authentication, etc.? How would IT regard this as being secure? What would be the best way to write this code? What could be regarded as the best way to secure data when emailing?

Basically, the cloud hosted ticketing system provides a unique email address in which the data will be submitted to. My assumption is that one could utilize the cloud hosted HTTP Basic Authentication over SSL in which they would provide a unique username and an authentication token as a password. Would this be regarded as securing submitted data? The only thing I really see is that this would simply verify that the ticketing system server to be true before the data has been submitted. If not, no data is therefore submitted which can provide some measure of security.

I’ve used curl plenty of times in the past to update, delete, put, post and get, but never emailed, so I’m not sure if this would really be a secure way to go? Documentation is a bit fragmented as I’ve pulled fruitless searches on this subject, but I’ve provided a theoretical and very simple script below (which I have not tested) in order to invite any feedback. If any of you have had more experience in this area, please feel free to expand.

Thank you and keep up the great coding that all of you do!

<?php ob_start();

$Name       = $_POST['name'];
$from_email = $_POST['email'];
$phone      = $_POST['phone'];
$message    = $_POST['message'];

if( !empty($Name)) {
$sender     = $from_email;
$receiver   = '129zop78as7q0c7b28f3728soq1b45m31@somedomain.com'; //
$email_body = "Name: $Name \nEmail: $from_email \nPhone No: $phone \nMessage: $message \n";  
$extra      = "Reply-To: $sender \r\n" . "X-Mailer: PHP/" . phpversion();

// URL FOR AUTHENTICATION =============
$url        = 'https://ticketingsystem.com/';

// INITIALIZE CURL ====================
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_HEADER,  0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

// USERNAME AND TOKEN ID ===============
curl_setopt($ch, CURLOPT_USERPWD, sprintf('%s:%s', '123456', '3ecb5f17-e219-6801-64d8-cb3027def0e8'));


curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC | CURLAUTH_ANY);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, 15);

curl_close($ch);

// SEND MAIL ==========================
if( mail( $receiver, $email_body, $extra ) ) {

// IF SUCCESSFUL, REDIRECT ============
header("Location: https://ticketingsystem.com/thankyou.php");
} 
else 
{
header("Location: https://ticketingsystem.com/nogo.php");
}
}

ob_flush();
2
Contributors
3
Replies
36
Views
3 Years
Discussion Span
Last Post by Lsmjudoka
1

To my knowledge CURL and mail() operate independently of each other as mail() uses whatever SMTP server is defined in your php.ini. The only way to really go about securing an email is to encrypt the contents - I haven't done this personally but it looks like the popular solution is to use PEAR::Mail to connect to Gmail's servers via SSL and send it that way, letting them handle the encryption.

Edited by Lsmjudoka

Votes + Comments
Great suggestion
0

Hi lsm and thanks for the response! You know, I've thought about that so many times, but I keep going back to other recipients that may be using something other than Gmail. My only thought was if I could not provide an encrypted connection how could I at least verify an SSL connection to "Server B" when submitting from "Server A". I've never really used PEAR before, but I didn't know if there was another way to verify this and what IT would really need to see in order to call it a "secure" SSL connection. However, you've given me an idea that having a drop box for Server A (which could be hosted by Gmail's servers) could provide the encryption tunnelling to "Server B" just might do the trick. Thanks!

0

Actually the idea seems to be to piggyback on Gmail's servers to send your mail (apparently they allow this) which should allow it to be sent to any address. The reason for using Gmail's servers to send it is that they will encrypt it for you, which is the most secure you can really get on an email. But run a google search and look more in depth on it. Hope it works out for you!

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.