PHP, mySQL, client/server-SSL - php

I'm doing a website project in PHP, front/back-end from scratch, which will require secure database connections. I've set up my MySQL database with XAMPP, and have gotten an understanding on how to avoid SQL injections. As of now, when a user signs up to my website, I send them an auto-generated email with a link containing a GET request. This GET request contains non-sensitive information to validate the user to the database which I have managed successfully.
Now, I've learned that to increase security, I should use SSL/TLS encryption on all communications between server/client and this is where I'm confused. AFAIK PHP offers mysqli_ssl_set to establish an encrypted connection to MySQL. And MySQL can be configured to force only SSL/TLS connections (Please alert me if I'm wrong).
How do I make sure that my information sent to the client is SSL encrypted? I'm planning on moving my project to a hosting service. Will they provide the correct certificates needed to encrypt my information to the world wide web? On which subject do I need to further develop my understanding of these concepts?

Related

Is Encrypted Sql Data secured when being transmitted from Server to Server

If run a Web application on a web server in one location and inside my php code I use OpenSSL to encrypt data, will the data be secured when transmitted to my SQL Server on my Server.
I am working on a Web application but it is being hosted on 3rd Party Web hosting Service but User Data is being Stored in SQL On my Personal Server. All Data will be encrypted Using OpenSSL on the web Server where web Server ask for the Users personal encryption key stored SQL One Time Per Session. I plan on Using a Second OpenSSL Encyption to Encrypt the User Encryption Keys. Users will also only be able to use the app via a Secured HTTPS Connection to Web Server.
I Just want to find out What I need to do to ensure User Data will be Secured to the Best of My Ablilities form mainly Man In Middle Attacks.
The Web Hosting Service is a Well Know Service with Secured Connections, I Will Have an upgraded SSL Certificate.
My SQL Server Will Only Except Connection from Web Server IP on a Non Standard SQL Port.
It sounds like you have the front-end encryption taken care of, but what you are asking about is the connection to the back-end, or your SQL server. You need to make sure that you are properly defining a secure connection as that is the default, BUT MySQL will drop down to an unsecured connection if there are any issues in that config (past auth, of course).
Here is a link to the MySQL doc page, https://dev.mysql.com/doc/refman/5.7/en/encrypted-connections.html
You should be able to get some info there more specific to how you are trying to configure your connection string and user account.
-Tango

How to secure a MySQL server running on Linux?

I have a MySQL server installed on an Nginx server on Debian 8.
The production page on the server, say example.com has SSL installed in it.
This MySQL server will be used along with PHP to set and retrive data.
Now I am confused whether to add SSL for the connection between client and MySQL server? What is the best practice?
If the traffic runs through app to MySQL locally, your traffic is secure (as long as your linux server is secure).
You don't need ssl for MySQL to app if the app only accesses MySQL locally.
You need ssl if anyone will be accessing MySQL remotely or if your app server is remote.
You will need to worry about those two things the most.
Transport Security. Does MySQL traffic ever leave your local network? If so, is it encrypted during transmission? If you are doing everything locally, then you have nothing to worry about. If your database connection goes across internet, make sure to use SSL.
System Security. Is your MySQL server accessible from internet? Does it need to be? If not, just add rule into iptables to block all incoming traffic to 3306 that's not from localhost. Also make sure that you are using strong SSH passwords and implement fail2ban, or allow key based authentication only.
SSL is good to help protect your clients. Sniffing packets may be thwarted by SSL. For example, if someone does a credit transaction, the credit card data would not be in plain view, as the data moved between the client to the server. However, SSL is not a way to protected your SQL resources, which is backend between the web serer and SQL database server. You need to run "mysql_secure_installation" for a mysql database, and design you PHP code to prevent SQL injection issues, for example. So, yes, SSL is very important to protect your clients, but other design factors are needed to protect your backend server assets.

By default, is the connection from PHP to SQLAnywhere secure or encrypted?

There is a requirement to connect to a remote server, over the internet, to a SQL Anywhere database.
SQL Anywhere has a number of PHP extensions, which allow for PHP to connect to the server via IP and a specific port - however, is the connection secure?
Is there an option that needs to be set on either the SQL Anywhere server or PHP web server to enable some sort of encryption? Or do we need to create a VPN tunnel between the two servers to make sure it is safe to send data over the internet?
No, connections are unencrypted by default though passwords are never sent in the clear. You can use the ENCRYPTION connection parameter to indicate the type of encryption you want to use. TLS encryption is supported.
You don't say what version of SQL Anywhere you are using, but here are the v17 docs for the ENCRYPTION connection parameter. The usage of this parameter is pretty much the same going back to v10.
Disclaimer: I work for SAP in SQL Anywhere engineering.

securing connection to php server

I have following scenario:
The Android clients communicate with a PHP server via HTTP Post. The PHP server is communicating with mySQL database and sends the output as JSON to the Android client.
Now I am concerned that people sniffing the traffic, find out the URL and will post a lot of grap in my database.
I have no concern of sniffing the payload. So it does not necessarily be encrypted.
I was thinking of TLS/SSL which comes in mind because of the HTTP connection. But I am not sure what is the prefered way to go in this scenario.
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. You can use the keytool included with the Android SDK for this purpose. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android, both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.
SSL won't help you, as the traffic can be sniffed before the data hits the wire, and people will STILL be able to figure out your API calls and fill the DB with crap.
You can "secure" the service with access tokens and username/password requirements. But again, they won't prevent a malicious user from flooding your system with bad data. However, it would let you track down WHICH user was doing so, as they'd have to be using a unique access token of some sort to get at your system.

PHP Socket Server (for Android Push Notifications) - Security / Authentication Issue

I have recently written a socket server in PHP that will be handling communication between an Android phone application and my PHP webserver. Due to the fact that Android doesn't natively support push style notifications we are going to be using our webserver as the middleware layer to handle our 'pushes'.
The socket server is stable, runs well, and seems to scale nicely. While I would eventually like to re-write this in C I don't have the skill necessary to do that right now so I am going to be staying in PHP for at least a short while. As of this moment our Android emulator is able to communicate through the server, get pushes, etc. so that part is all covered.
My concern is that, right now, anyone can open a socket to my server and will be given a client connection. While we won't be passing sensitive data back and forth I don't want to allow just anyone to connect over and receive broadcast information, eat up my resources, and clog my server in general.
The question is, how do I secure a server like this? Let's assume that I am running on port 25,000--can I set up some sort of SSL layer on that port and expect devices like the Android to be able to communicate over that port without any special protocols or jumping through hoops?
I have considered asking the connecting clients to authenticate their user against our user database before being given a client connection, but that would require the passing of credentials in plain text over the network which I am NOT about to do.
Any suggestions on this would be very helpful--I am rather new to straight TCP communication from PHP and feel like I might just be missing something simple that allows for authentication on this level.
Additional information: If I am able to get a valid username and password securely I would be using MySQL to validate the user and then accept/reject their connection based on the results of the query.
Thanks in advance..
First, I hope you've implemented your PHP socket server in a fashion that allows more than one client to be connected at the same time. This is not as trivial as it should be given the absence of threads in PHP, but it's certainly.
Now, if you already have a socket server implemented, adding TLS support is easy. Just run stunnel and have your PHP socket server only accept requests on the local interface.
I don't think SSL is really going to solve your problem. At best with SSL you can provide each client with a client certificate and do client certificate validation on the server. But you'll need to manage tons of certificates then. Or give everyone the same client certificate (not a good idea).
You'll have to authenticate the client using his credentials. You are right that you don't want to send the credentials in plain text over the network, but there are simple alternatives. Take a look at e.g. HTTP Digest Authentication (http://en.wikipedia.org/wiki/Digest_access_authentication) or xAuth (http://dev.twitter.com/pages/xauth). You don't have to implement these techniques over HTTP; you can just as well send a challenge (a realm) over a simple tcp socket after you have accepted the connection. The client should then send a valid response within a short timeframe or the server aborts the connection.
By the way, did you consider HTTP streaming? See http://ajaxpatterns.org/HTTP_Streaming
It would probably make your life a lot easier as you can rely upon some other service (e.g. Apache) doing the hard work for you, and you can focus on the business value of your application.
you might want to consider:
Cloud to Device Messaging : http://code.google.com/android/c2dm/index.html
The only drawback is that it is only supported by android >=2.2
Not sure why you guys didn't use some off the shelf messaging library/server for java, then create an android service that connects to the message broker and handles all initial authentication.
The service would simply sit there and wait for any incoming messages.
(I'm pretty sure that listening for network data doesn't power up the radio, only when the data is actually there that the radio powers up. I suspect this is how C2DM works.)
This is better then polling because you're only waiting for data. You're not constantly sending packets requesting data. But you knew that already.
I did this, (I used the rabbitmq-java library and the rabbitmq message queue server) and had push style notification for my app in no-time. Even with Android 1.5 devices.
About security:
You could also implement your own security but without having to send plain-text passwords. Simply encrypt the passwords using something like MD5 before passing it through the network.
Then compare the encrypted password with the encrypted password you have on file.
This way, only encrypted passwords will go through the network.

Categories