I am devloping an android application using java.now i want to place db on remote server,and want to access and upgrade the database.
Can anyone help me?
It's at least a challenge to write an android application that would be able to talk with a remote database. AFAIK, there's no jdbc on android.
So your "remote database" needs an additional business layer, some sort of public API that you can use for your CRUD operations. Otherwise you'd have to port jdbc and a jdbc driver for you database for android...
A very simple (and pretty dangerous!) API would simply accept SQL strings (from a trusted source!), forward this SQL to the database and respond with the result set (csv format, for example).
Typically, you won't allow remote connections to your db from an untrusted source.
Instead, think about what operations you want to execute on the database. Then write an interface with all the required methods (addEntry, removeEntry, etc).
On the client side (android), create a class that implements this interface by delegating to the server (HTTP requests or whatsoever).
On the server side, implement the same interface with JDBC access to your db and set up a simple server process that delegates the requests (HTTP or whatever) to this implementation. That's it.
Related
I am creating an application that needs access to a MySQL Database. But I know that people are able to decompile Java code. I am wondering if there is a really secure way for me to connect to my database without it being accessed by decompilers?
In short: no. If you distribute an application which connects to a MySQL server, it will always be possible for users to decompile and/or debug your client application to extract the credentials the application uses to connect.
MySQL is primarily intended for use by a trusted server-side application. If you cannot fully trust your client application (and the users who have access to it!), do not allow the application to connect to your MySQL server. Instead, consider building an HTTP-based API (i.e, a web application) to allow your client software to perform appropriate operations on the database.
In a JavaEE application you can store the data source in the application and configure the connection in your application server.
Is your application a standalone Java application that your users have access to but has access to the Internet? In that case you may consider isolating your data layer to another application stored elsewhere and accessible with a web service, for example.
If a Java-based web application needs to update clients based on a database record update using server sent events, are there ways to getting the database updates via a callback mechanism from a database to a servlet so that a java servlet does not need to continuously poll a database to detect for updates?
There is nothing in the JDBC specification (that I know of) that will allow you to do this. If at all, this is a database-specific functionality. Oracle supports such functionality starting Oracle 11g:
http://docs.oracle.com/cd/E18283_01/java.112/e16548/dbchgnf.htm
Okay, I apologize in advance for this question, as it is quite broad.
Basically, I am developing a system involving:
A website where users can register an account. This process will create a new database on the server for that account.
A client side external application written in Java. This will access the data in the database in order to perform useful operations for the user.
The databases themselves which are created in the first point.
My question is about what security measures should be implemented in order to keep the databases secure and how to transfer data securely.
My concerns are:
How is a MySQL database actually secured? When I create the database at the point of account registration, do I need to set a password for that database? Does this encrypt the database? Is this enough to prevent someone from accessing the data?
Java is pretty easy to decompile. Assuming I am to store the log in data for an account database in a master database, how do I secure that database and connect to it from my application in a way which doesn't require me to hard code the details for connecting to that database in the application. I believe this must be an issue in languages which are compiled to native code too, as someone could just perform a memory dump to get hold of such variables at run time of the application (I think).
When sending and receiving data to the client from the server and vice versa, how do I prevent someone from network eavesdropping and getting hold of the data (whether this be log in credentials or other data from the database). I assume this is what SSL is for, but is that all I need to use?
A possible answer to these questions is to use a middle man service in between the Java client side application and the database, much the same way you would use PHP in between Javascript and a MySQL database (although the PHP is a necessity in this case). I assume this middle man service would contain the log in credentials for the master database etc. and would contain its own methods for preventing unauthorized access. If this is correct, how would I go about setting up such a service? Would it be possible to utilize a PHP script from a Java application to transfer data?
I hope my question makes sense and isn't too ambiguous.
Thanks in advance for your time.
How is a MySQL database actually secured? When I create the database at the point of account registration, do I need to set a password for that database? Does this encrypt the database? Is this enough to prevent someone from accessing the data?
Using an account name and password, together with different access rights for particular databases "granted" to different users.
The password is associated with the user account, not the database.
MySQL databases are not encrypted.
Yes ... though if untrusted people can gain admin control of the database itself, or the system that hosts the database, then all bets are off.
Java is pretty easy to decompile. Assuming I am to store the log in data for an account database in a master database, how do I secure that database and connect to it from my application in a way which doesn't require me to hard code the details for connecting to that database in the application.
A common approach is to put the connection details and/or account credentials into a Properties file that the application loads at startup time. However, I think your real issue is that you want to allow updates to the database by applications running on untrusted machines. A more sensible solution to that is to run a trusted service on a properly secured machine and have the untrusted machines talk to the trusted service and NOT directly to the database.
I believe this must be an issue in languages which are compiled to native code too, as someone could just perform a memory dump to get hold of such variables at run time of the application (I think).
That is correct.
When sending and receiving data to the client from the server and vice versa, how do I prevent someone from network eavesdropping and getting hold of the data (whether this be log in credentials or other data from the database). I assume this is what SSL is for, but is that all I need to use?
SSL is sufficient for securing data (or credentials) that are sent over the network.
The situation with man-in-the-middle attacks is murky, certainly when it comes to web browsers and whether trusted roots should really be trusted. But if I understood what I read correctly, there is a way to use SSL that should be immune to MITM. Basically you need to generate individual SSL certificates for all participants (clients, servers) and distribute them to all using an out-of-band distribution mechanism; i.e. NOT over the internet. Then you only accept SSL connections from parties with a known certificate. And make sure that you use TLS 1.1 or 1.2.
I see some possibilities -
Using jBoss SX framework
Using EJBs is another thing, which provides the requried layers of abstraction.
JCA components can be used on middle-man components
Finally SQL injections can also be accessed through some of the available tools like the sqlMAP.
You are correct in assuming that your client application should never store database authentication information. It is far too easy to decompile a Java application to retrieve those connection strings.
Instead, as I think you understand, you should expose a web service providing the information your app requires. There are a few ways you can go about this. You could, for example, write a REST interface so that your clients make HTTP calls to your server and receive JSON or XML responses back. You could also write a Java RMI server that allows your client to make remote method calls on the server to find the information they need. Without a more specific question or constraints, I can't really advise on which is more appropriate.
I would like to create a touch screen application.It will be a windows application, so using that how can i get data from a web server?
There are several methods.
Your server can create scripts/webpages to return data in XML or JSON format upon request, and your windows application will have to make HTTP requests to your scripts/web server, retrieve and parse to get the data.
Make sure to protect your data which are requested from the web to prevent other unintended use.
You can also directly connect to the database (depending whether your database supports remote connection or not...)
Using a webserver is usually totally independent from the clients operating system. It may be tricky if the webserver provides service and entity beans and you rich client is written in C/C++ language.
But there are several protocols where you do not have to care. If your application is a thin client (browser interface), I suggest having a look at REST. For rich clients you can use SOAP to talk with your server.
Of course, the server has to provide the data for the chosen protocol...
I've got a Java client that needs to access a remote database. It is the goal to hide database credentials from the user and not hardcode any credentials within the code. Therefore, the database access will probably have to be on the server side.
I'm restricted to use Ibatis as a data abstraction framework. Apart from that I have JBoss running on the webserver, allowing me to use data sources.
How would you design the remote database access and data serialization/deserialization. would you prefer web services of some kind of data stream over a socket? How would you realize either of both?
Build a Service Layer and expose it over RMI - possibly as EJB3 stateless session beans as you have JBoss, possibly as pure RMI. I wouldn't bother with web services unless you have a specific need. RMI will take case of serialisation for you.
Your service layer needs to expose a method to authenticate users using their credentials entered on startup of the Swing app. All calls for data go through the service layer. No SQL exists in the Swing app.
There are other benfits of this arrangment other than just hiding the database credentials. Not only do you end up with a layered architecture, but you gain efficiencies from sharing prepared statements amongst all your clients by having a single data source on the server.
So you want users to be able to access the database without knowing the credentials? Your only option is server-side database access. Unfortunately there is no way of hiding the username and password in Java -- if you put it into a properties file and encrypt it, a determined attacker could still attach a debugger and see what values are being held in your code.
Also, unless you're connecting to the DB over a secure connection someone could run a packet sniffer such as tcpdump and get the credentials there.
You say that you're running a JBoss server, what might be best is to set up remote EJBs so that your client application doesn't access the database directly - it has to go via your EJB methods. (It doesn't have to be EJB, by the way, you could do something such as web services if you prefer).
The point is, your server talks to the databas directly, and your client's only access is via a limited set of interfaces you define on the server.
As has been already said, you have to connect to a server which handles the database connection. There is no way to effectively prevent someone from breaking your security, with 30 minutes of effort.
If the clients are connecting somewhat locally, within an intranet, using EJB's on your appserver is probably the best choice... though you probably want stateless session beans, i wouldnt necessarily discount message driven beans.
For longer distances where the traffic is coming from the outside, I would use webservices over HTTPS
In any event, most appservers have mechanisms to expose their EJB's as webservices, with the WSDL; and there are about a hundred utilities to generate clients, to call the webservice, from a WSDL (axis's wsdl2java works well enough)