Ok, so I have setup a Docusign Connect to a 3rd party application (Infusionsoft) and have it working great.
They don't natively work together, so I created a php script that reads the tabs in the docusign envelope, and passes it to Infusionsoft, along with a copy of the completed envelope itself.
Now I would like to pass payment info through this as well, as one of the document templates I have in Docusign is a billing agreement. I have done a test run of this with dummy info and I am able to do this well, BUT, I now have to be concerned with PCI compliance on this, right?
I have a dedicated server with a domain that has an SSL certificate which is hosting the php script, which does not store any information. It just passes the docusign info (gathered by using the docusign connect) and then formats it so it can be accepted by Infusionsoft.
I am a novice programmer, and pretty ignorant regarding knowledge behind encrypting data or securing a connection. The fact that Docusign passes the info through an XML file seems to be not ideal for handling sensitive data (at least I would imagine), and that is something that is out of my control.
So what I am asking is would it be possible to securely transmit payment info (credit card or bank account) through a Docusign connect connection in the type of setup I have? If so, how would I approach it? I am open to hiring a programmer if needed or getting a different server setup if it was necessary.
I can do this without adding the payment info to the template, and just adding it afterwards directly into Infusionsoft to limit my liability, but it would be so much easier if I could do it directly through Docusign Connect as it would automate the entire sign up process.
Well Comodo's test turned up a bunch of holes and warnings, with a detailed report of what to fix. I took that in turn to Hostgator support, who went ahead and made the appropriate changes to fix the holes. The also reported that their were a bunch of false positives with supporting documentation.
So I have to do another test to verify that everything was closed up and report the false positives. But other than that it seems like it should all be cleared up.
I also spoke with Docusign Support over the phone about this, and they confirmed other companies are doing what I am doing as well, which was reassuring.
So in short, use Comodos online scan tool to see what holes you have. Then contact your hosting company to fix the holes. Not a great answer, but I suppose better than nothing.
Related
We don't store any credit card information. It is gathered via an HTML form, then processed by a PHP script which uses the API from Intuit to charge the credit card. After calling the API to charge the card, all credit card information is disposed of.
Here are my questions regarding the security of the credit card information:
I assume SSL is a must. Is this correct?
Should I switch from shared hosting to a dedicated server?
I assume there is no encryption that isn't easily un-reversible that can take
place between the HTML form and the PHP script, does any encryption
need to be used for what I'm trying to do?
If there is anything else you can think please share it. Thanks for your time everyone.
I assume SSL is a must. Is this correct?
Yes, correct.
Should I switch from shared
hosting to a dedicated server?
A VPS at minimum is a very good idea. You can probably not be PCI compliant successfully on a shared host, you just don't have enough control to lock your server down as required by PCI.
I assume there is no encryption that
isn't easily un-reversible that can take place between the HTML form
and the PHP script, does any encryption need to be used for what I'm
trying to do?
Your API should take care of that. Be sure the API is over an SSL/Secure connection as well.
Please read up on PCI requirements. You are transmitting cardholder data so you DO NEED TO BE PCI COMPLIANT. You will be at the "lowest level" of compliance (I think it's C or D). You will need to run quarterly scans on your server IP to prove compliance as well. As an FYI, I use McAffee Secure for this.
The only way you won't be subject to PCI rules is if the cardholder's data is entered on somebody else's server (think: paypal). Whenever you pay by paypal, you are transferred to PayPal's server, then transferred back. In that scheme, you would not need to be compliant.
Now a lot of the PCI requirements talk about some stuff that don't apply in the questionaire (i.e. is your server stored in a safe place, how physically secure is your building, etc....) - the good news is that your server/hosting company should handle that.
After your network scan, it'll come up with a list of things that make you non-compliant. They are almost always server related issues. You can either fix them yourself, or ask your host to help you - most hosts will do it if you send them the list. You will NOT be able to fix a lot of them on shared hosting.
Your points addressed in order
Yes, even when connecting to the API, which should be the only option
Its a good idea, less security exposure. You will have lower probability that a compromised tenant will compromise your site.
As long as you are not storing or caching the data in any form and using SSL for transit, you wont have to implement encryption on your application.
PCI requirements may be applicable.
1) I would serve the entire page through HTTPS to avoid users from getting the alarming message of "some resources are not protected"
2) Depends on the integration, if Intuit has provided you with an iframe or form action to use, then sensitive data never reaches your server. user either type and/or submit it directly to intuit with your page merely as a container.
If the above is true:
3) You don't have to pass PCI compliance. Intuit already did. Sensitive data never reaches your server, thus there's nothing to dispose.
4) Shared or dedicated host doesn't really matter since you are not transiting or storing any sensitive information.
SSL: Yes, of course. Between your server and the client, as well as between you and the API.
Dedicated Hosting: Ideally, yes. There are two problems with using shared hosting:
Anything stored in a session can potentially be retrieved by others on the server.
A security breach in a site that is not even yours could lead to a breach in yours.
These are primarily the domain of your host's security policies, and are not easily identified by PCI scans.
I am trying to get a full Kerberized domain environment configured, and one of the obstacles is webmail. I have scoured the Internet for information about how to do single sign on with Kerberos through webmail, but without definitive results. So now I am going to try and do it on my own.
The point is, while it is easy to authenticate against one service (the webmail frontend in this case) using mod_auth_kerb for Apache, forwarding a ticket to the IMAP/SMTP servers is proving more tricky. From the documentation about Kerberos that I have read it seems to be possible to accomplish this - The client would send a forwardable ticket to the webmail application, and then that server would use delegation to authenticate (as the user) to IMAP/SMTP. However, finding any actual information on existing implementations seems to be fruitless.
In attempting to make my own implementation, one of the first problems that I will face will be getting the ticket for use against the IMAP/SMTP servers. I can think of doing this one of two ways - either a forwardable ticket is stored at the point of authentication to the webmail, or whenever the user tries to send an email/refresh their mailboxes authentication occurs again, but this time no data is stored since it all occurs in one request (and mod_auth_kerb supports saving credentials for the duration of the request).
In going down the storing of credentials route, there are security concerns, scalability concerns and implementation concerns. However, authentication only happens once (whatever benefit that would give).
The reauthentication on refresh/send would be much more secure, since the credentials are only stored for the duration of the request due to mod_auth_kerb, and there should be fewer scalability issues since there will not be many credential caches floating around the place when many people are logged on. However, authentication would happen much more frequently, perhaps causing problems due to higher network load, or the chance that something bad would happen on the client between authenticating and attempting to send an email.
I am leaning towards the second method, simply because the security issues seem quite drastic, however I would like some more opinions - perhaps there is a better way of doing it?
EDIT: Another challenge which I will face is getting GSSAPI working with the PHP IMAP extension. From the material I have read it seems possible to do this one of two ways - either using Cyrus IMAP or using the built in GSSAPI mechanism in PHP IMAP. There is next to no documentation on how to do either method though, so help would be appreciated.
I am trying to integrate PHP-PayPal-IPN (great library btw, you can see the blog post on usage here).
Since security is essential here, I have checked the source code. I found no apparent problems with it, but I would also like to check the PayPal certificate chain that is bundled with the library: https://github.com/Quixotix/PHP-PayPal-IPN/tree/master/cert
How can I check that the certificate chain is correct? (correct == "it allows only connections from PayPal and from nowhere else")
I don't think that's the point of it. That SSL just allows you to setup your IPN script on a secure server so that the data is encrypted. To my knowledge it's not going to block hits to the script that don't come from PayPal's server.
That's where the verified/unverified check comes into play. If the data comes from anywhere other than PayPal it will fall into the unverified portion of code. You can choose to handle these however you want. Completely ignore them, log them as invalid but keep them for your records, send yourself email notifications, etc.
I'm tasked with coming up with an e-commerce solution for a small, local business. My client uses Intuit/Quickbooks point of sale software. I've just discovered that Intuit has a series of PHP 5+ classes that allow interoperability (link for anyone else that may stumble on this: https://code.intuit.com/sf/sfmain/do/viewProject/projects.php_devkit).
The website will be hosted on shared hosting, so the two systems are split quite literally. Her desktop does have internet access.
So, my questions:
Is there a way for me to connect to her desktop via curl?
If so, is there a way for me to do it securely if I can't create a VPN on my host?
Now that I think about it, is there a VPN service I could use?
Any other security things I should be aware of?
Payment processing will be handled through Stripe (http://www.stripe.com). This is really just for inventory/order synching.
Your best bet is the QuickBooks Web Connector, along with that set of PHP classes you mentioned. See my specific comments below:
I've just discovered that Intuit has a series of PHP 5+ classes that allow interoperability (link for anyone else that may stumble on this: https://code.intuit.com/sf/sfmain/do/viewProject/projects.php_devkit).
It's worth noting that that library is NOT developed by Intuit (disclaimer - I'm the developer of that library). Intuit hosts our Subversion repository, but we're a separate company, and Intuit does not contribute to the actual PHP code. Intuit provides a Windows COM-based API only, we provide the actual PHP components so you can talk to QuickBooks from a remote server via the Web Connector, without the need to muck with COM.
We have a ton of information on our QuickBooks integration wiki which might be helpful - specifically the QuickBooks integration with PHP section and this overview of the QuickBooks Web Connector.
Consider grabbing the latest nightly build from the link you posted, and taking a look at this file:
* docs/example_web_connector_point_of_sale.php
It illustrates exchanging data between PHP and QuickBooks Point of Sale.
The website will be hosted on shared hosting, so the two systems are
split quite literally. Her desktop does have internet access.
This ^^^ is just fine, and a typical scenario. It's exactly what the Web Connector was designed for. The Web Connector essentially acts as a "dumb proxy" between a PHP SOAP service, and QuickBooks itself - it relays messages from your PHP app, over HTTP(S), to QuickBooks.
Is there a way for me to connect to her desktop via curl?
Not with Curl, no (though you could build one... but why reinvent the wheel?). The Web Connector is SOAP based, but your PHP components will be the SOAP server half, not the SOAP client half.
If so, is there a way for me to do it securely if I can't create a VPN on my host?
The Web Connector can use SSL via HTTPS to keep the data secure while in transit across the net.
Now that I think about it, is there a VPN service I could use?
Just buy an SSL certificate, it's easier. :-)
Any other security things I should be aware of?
Not beyond the typical web application security guidelines that you could find elsewhere on Stackoverflow.
If you're going to sync to a system like Quickbooks, don't do it real-time, do it in a batch process that is resilient to things like her desktop being turned off, the crappy office internet (compared to a datacenter) being slow or down, etc.
This ^^^ is great advice, and is exactly how the Web Connector works.
If you need real-time, Quickbooks running on a desktop is NOT the way to go.
In fact, if you need real-time, QuickBooks period is not the way to go. QuickBooks is a great small to medium business accounting software... but is slow and not reliable enough for consistent real-time communication. With that said... what you're talking about does not require real-time communication, so this shouldn't bother you.
Batching the orders isn't a problem, but how would I make even a batch process resilient?
The PHP code uses a queue with a status, so you can track what got processed, what didn't, what you got back from QuickBooks as a response ("Added a customer successfully!" vs. "Ooops, failed to add a customer because ..."), what error messages QuickBooks threw, etc. and then react appropriately with your code, or manually.
You won't need cron - the Web Connector can be scheduled to run, and it'll relay all errors and a ton of other information back to you so that you can handle errors, send out warnings, build reports to show to people about what failed/succeeded, etc.
There is a company that uses salesforce software to keep track of all customers and the performance of the employees. I am building a points website, which is about the manager rewarding points to employees for a job well done. I want to integrate the info from salesforce software database about the employees and present it on my website so that the manager can see the number of deals closed by each employee and accordingly allocate points to that person. is there any kind of a plug-in or something like that? if not, how can i achieve this? My website is a cms, built on php.
Thanks.
The best way to handle this situation is to import the enterprise or partner WSDL into your PHP CMS. This will enable you to make webservice calls to Salesforce.com and access almost all of the data sitting on the Salesforce.com server.
It'll also enable you to write back to Salesforce.com servers. There is very good documentation and code samples out there try this link first:
http://wiki.developerforce.com/index.php/Web_Services_API#PHP
Hope this helps!
Check out the PHP Toolkit, which is a PHP wrapper around the salesforce API.
Be aware, there are some quirks and it's some bulky functionality. Salesforce limits the amount of hits you can have on the webservice, so you may need to do a cron-based "grab" of info and store to your site at various intervals. You'll get a rude awakening when you're testing and run out of connections for the day (not applicable to people who pay the premium level of Salesforce) It's also rather slow and has a propensity to timeout often....so be prepared to write code to handle the exceptions that will be caused.
Your server will need to have CURL installed and properly functioning.
Good luck!