I'm doing a personal number-crunching project, and I'd like to launch multiple programs on multiple computers (maybe even on Amazon's servers someday), and have them all storing and sharing data in a common SQL database, located on my web hosting account.
The hosting company won't allow foreign connections directly to the SQL server, but I was thinking about writing a thin PHP script that would reside on the server and receive SQL commands from the remote programs using HTML POST commands, and pass back results as html. Then I could just use an HTTP library to pass the SQL commands straight into the remote server and get back results.
Obviously its a security issue to send naked SQL commands to a server. I was thinking about using some kind of shared-key encryption to send the post commands, and the results would be fine coming back unencrypted.
So, my question is, what am I not thinking about? I'm not an expert on web security, and I'm obviously missing something. Is there some major security hole here that's impossible to fill? Or is there some other method or library to do this that I haven't found?
It might be better storing the SQL as stored procedures on the database and call these SP from your script. This way you don't have to send any plain SQL (just parameters) and it will be easier to maintain.
What you mean with client? As client from a web application (JavaScript), you may perform it by making an Ajax call and return the data as Json.
If you mean a windows client, it's more interesting to create a WebService instead of just a php page and use that in your application.
As for encryption, I think going over an SSL is more or less the best/only way to ensure full security.
If your hosting company allows SSH, tunnel through an SSH session to your MySQL server with your mysql client.
To reduce the volume of what you send for each query, as the previous answer suggests, create stored procedures for those queries and invoke only them with appropriate parameters.
Related
I have a windows form written in vb.net and I want to encrypt the connection string in app.config and distribute it to other machines. I can encrypt it fine on the machine its compiled on but it does not work on other machines because the encryption is tied to that machine. How can I make it so other machines within my domain can use it ? I am connecting to a database that people would not have access to without the app so I cannot use domain credentials.
It's "simple" really; you just distribute a connectionstring that cites a uer with the minimum permissions required to let the application work or, if your appetite for hacking doesn't extend that far, you create a webservice that does all the grunt work and you never release the connection string at all. If you don't want a web service, you might be able to achieve the same end result by using stored procedures and restricting access to tables directly
Thinking that you can encrypt a connection string in a config, and then bundle with it an application that has to decrypt it to make use of it, is something of a fool's errand. If you don't want someone to know something, you don't give it to them in the first place!
One of the products I am maintaining has FTP uploads as part of its core functionality. We are encountering problems in production where the FTP server times out and the system doesn't react too well to that.
Is there an FTP server that I can use for testing scenarios like that? I want to be able to deliberately fail in different ways such as:
refuse connection (that one's easy)
stall until sockets time out
close connections in the middle of transmissions
Ideally it would let us configure behavior such as "drop the connection on every third upload, 300 bytes in".
I can see how to write this based e.g. on the Apache FTP server code, but I wonder if I am re-inventing a wheel. Is there an FTP server already that I can make fail in a controlled fashion?
My previous question was closed so I will be more specific.
I need to create an application, desktop one written in C#, that will ask for user credentials and after verification opens the GUI allowing to work with DB (black box for users).
It should be used from everywhere, not LAN or SQL domain. I assume I would need to do the following:
Create a client and a server applications that will deal with authentification. That would mean a lot of socketing stuff..
Once the user is verified, the client queries would be sent to database (client->server->DB).
The server would need to send the DB data sets back to the client.
As you can see, this is just my guess but I have no idea whether its too complicated or completely wrong. The main thing is that it must be desktop app (not web based one) and accessible from everywhere.
I am interested in main points how to design the system and will be extremely grateful for that.
You can use a certificate server for authentication..like Apache's mod_ssl
My OSCommerce site includes a separately programmed feature for which I use SQL tables. I've decided to host its tables on a remote site offering free SQL accounts. I'd like to know if there could be any disadvantages to this approach.
Thanks
Syd
Disadvantages might include the longer time it will take to run the script since it has to make a connection over the network and the need to make sure that the database connection is made securely -- that the password for the database login isn't passed in clear text & that the permissions on the receiving end of the connection are set to allow connections from only that IP. Of course you'll also want to make sure that the free hosting company provides adequate security for the database itself -- "free" doesn't alway pay for the best set up or the most knowledgeable technicians...
You should connect to your MySQL database using MySQL's built-in SSL ability. This insures that all data transfered is highly protected. You should create self-signed x509 certificates and hard code them. This is free, and you don't need a CA like Verisign for this. If there is a certificate exception then there is a MITM and thus this stops you from spilling the password.
Another option is a VPN, and this is better suited if you have multiple daemons that require secure point to point connections.
I am assuming you are hosting the OSCommerce database on the same server as the webserver and your solution only allocates one database per customer. You can use the add-on tables in the same database as the regular OSCommerce tables as long as you prefix them with some prefix so that they won't have a namespace conflicts. If the code to the third party solution is any good, it won't be too hard to configure a table prefix so that the code will know what the new names for the tables are. This solves any potential latency problem and keeps the control in your hands. I use this trick to host multiple wordpress blogs in the same database.
For those in the know, what recommendations do you have for storing passwords in Windows Azure configuration file (which is accessed via RoleManager)? It's important that:
1) Developers should be able to connect to all production databases while testing on their own local box, which means using the same configuration file,
2) Being Developers need the same configuration file (or very similar) as what is deployed, passwords should not be legible.
I understand that even if passwords in the configuration were not legible Developers can still debug/watch to grab the connection strings, and while this is not desirable it is at least acceptable. What is not acceptable is people being able to read these files and grab connection strings (or other locations that require passwords).
Best recommendations?
Thanks,
Aaron
Hum, devs are not supposed to have access to production databases in the first place. That's inherently non-secure, no matter if it's on Azure or somewhere else. Performing live debugging against a production database is a risky business, as a simple mistake is likely to trash your whole production. Instead I would suggest to duplicate the production data (eventually as an overnight process), and let the devs work against a non-prod copy.
I think it may be solved partially by a kind of credentials storage service.
I mean a kind of service that do not need a passwords, but allows access only for machines and SSPI-authenticated users which are white-listed.
This service can be a simple WebAPI hosted under SSLed server, with simple principles like so:
0) secured pieces have a kind of ACL with IP whitelist, or machine name-based, or certificate-based whitelist per named resource, or mixed.
1) all changes to stored data are made only via RDP access or SSH to the server hosting the service.
2) the secured pieces of information are accessed only via SSL and this API is read-only.
3) client must pre-confirm own permissons and obtain a temporary token with a call to api like
https://s.product.com/
3) client must provide a certificate and machine identity must match with the logical whitelist data for resource on each call.
4) requesting of data looks like so:
Url: https://s.product.com/resource-name
Header: X-Ticket: value obtained at step 3, until it expire,
Certificate: same certificate as it used for step 3.
So, instead of username and password, it is possible it store alias for such secured resource in connection string, and in code this alias is replaced by real username-password, obtained from step 4, in a Sql connection factory. Alias can be specified as username in special format like obscured#s.product.com/product1/dev/resource-name
Dev and prod instances can have different credentials aliases, like product1.dev/resource1 and product1/staging/resource1 and so on.
So, only by debugging prod server, sniffing its traffic, or by embedding a logging - emailing code at compilation time it is possible to know production credentials for actual secured resource.