I just purchased an SSL certificate from my hosting provider, at the request of a bank I'll be doing Credit Card transactions with. As of yet, I'm not sure if I'll be sending my users to their site to do the transactions or if I'll just be sending CC information to their site to do the transactions. My confusion is in regards to coding a developing my system. I'm building a very simple photo purchasing website, so I've opted to design my own shopping cart system. At what point do I need to utilize the SSL? Is there some sort of PHP code I'll have to use to decrypt the data sent to me via POST? Do I need to utilize it at all, or is the work already done for me by simply having a certificate (as verified by the little lock that appears in Safari)?
Thanks!
You typically don't need to deal with the server certificate in the application logic. Just configure it into the web server; configure the application in the web server to use https.
How to do that is off-topic for StackOverflow (I'm still responding to confirm that you don't need to deal with it in PHP).
Related
First, I need to tell that I'm pretty new about Bitcoin.
I'm asked to build a Bitcoin Exchange website. I'll have a server which I plan to build with Linux and PHP.
-All the transfers will be issued manually
So we will have an online wallet and we will manually transfer Bitcoins to given addresses also receive Bitcoins to this wallet.
The problem is I'm not allowed to use any 3rd party API.
So how can I create an online wallet without any 3rd party API on my PHP server?
Should I install bitcoind to my server or is there any other way?
Is it a good idea to install bitcoind to a remote server?
Thanks.
The problem is I'm not allowed to use any 3rd party API.
It is good decision to make your system safe, but it is not enough.
Should I install bitcoind to my server or is there any other way? Is it a good idea to install bitcoind to a remote server?
With any approach, you need a bitcoin node (which bitcoind is most reliable one) which be accessible with you PHP code, so it should be remote!
I don't think it would be a security problem to install bitcoind on your PHP server, as long as it would be configured to just listen to localhost and not visible publicly, and just respond to your server PHP requests.
But don't forget that there are still many other security risks here.
For example if someone be able to hack your server and access it, he can easily use your funds. It is best practice to implement a Cold Storage solution to transfer most part of funds in your hot online exchange wallet to it, and bring it back to hot wallet manually whenever it is needed.
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.
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'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.
I'm doing a website with Realex as the payment gateway. I want to integrate remote realex payment method in my website.
I know when we go live we need SSL enabled on our website to do remote method payments. But my question is, Is SSL required when we are doing testing?
Every time I test, it results in error (remote method), but when I do Real Auth method there is no problem.
I don't know what the exact problem is. Am i missing something?
No. We use Realex, and don't use SSL on our test sites.
In fact, if we don't use SSL on our live sites, it still generates no error. Realex doesn't actually have any way to know whether or not you're using SSL.
As TRiG has already said, Realex have no way of telling whether or not you have SSL on your website. However, your customers will not feel safe entering card details if they don't see the little padlock, and this will affect your sales conversion.
Communications between your server and Realex are https/SSL, so this is secure, but the card data must first get from the browser to your server securely. You may prefer to use the Realex Redirect integration if you do not want to buy an SSL cert.
Owen
at merchant site in live / testing ssl is not required
it results in error . may be due to
your response URL is not set
or you are trying to get the response from local host
to set response URL have to contact Realex support ...
it is the same as we do in papal notify
what response URL we send that is to compare not to set