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)
Related
So I have a Java Program that just runs in the windows console at the moment. When the program first starts, I want to have it go through a login prompt with a username & password. I’ve previously used a MySQL database to check if a username + password combo exists, and then allow that user to login. I know how to encrypt passwords and such when I compare them to the database info. However, when I did this, the MySQL login details were left in the code so that the program could connect to the database. This leaves a huge problem in that someone could decompile the program and find those login details, then use them to access the database.
So my question is, is there a way to access these logins using the program, WITHOUT exposing my database details to a snooping person. Is there a library out there that could accomplish this?
Yeah you can do it, But you need to re-architect your application.
You should separate you application into two different application.(In short: you have long way to go)
1- Client Application: Where your Java Application is interacting with the end user.
2- Server Application: Where your Application is interacting with your DataBase. This Application can talk to your Client through your network.
Note: keep in mind that, any application at client, can be decompiled. All traffic even any communication between client-server can be monitored.
There are many methods out there, to make the communication between the server and clients. The choice is yours, you can make your own one (Socket communication) or follow some standards like REST or SOAP.
If you want to use REST or SOAP, there are many ready framework and libraries available where Spring is one of them. Since you need to have Server Application(Ex: Rest Server), you need to run your server application in a container, where in this case, Tomcat is the most famous one in JAVA world.
But there is better way to Start ; you can make an Spring Boot Application for your Server app. Most of the libraries even your container is already embedded, and you only need to focus in your Application Logic. Once it's done, you just need to run a single jar file and your client can start talk to the server app, through network. The drawback is that you need to follow the spring boot standard.
You can also Secure your Rest API by Spring Security framework (Which is totally separate topic), but you can simplify it to, token exchange between your server-client for each REST call.
So in this scenario, let say someone decompile your client application, he would
see nothing but, some rest API links, which can not work without login and token.
Also keep in mid that you also need to Secure the communication between Server and Client Throw the Network by TLS.(Which is totally separate topic)
If you're giving out db access then deal with the side effects of that choice. I think mysql offers some kind of row level security option. Check the docs.
If you want some level of backend obfuscation then put it between your users and backend via REST or some other scheme.
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.
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'm using GWT for a web-app and I need to access to a mySql-database. There will be only one client (The app is used on a iPad localy). Is there any way to access the database without RPC? I'm looking for a possibility to direkty query a database.
Thanks!
There are 2.5 reasons you cannot use gwt to directly access MySQL.
Reason #1.
GWT is compiled into Javascript. You need to open a socket to the database server. GWT does not allow you to open a socket. In fact, no unaugmented browser (before advent of html5) is able to open a socket. But you can open a socket using Flash actionscript, or HTML 5 javascript.
Reason #2.
OK, let's say you used HTML5 sockets. And you spent 6 months writing in Javascript a JDBC connectivity. But, your websocket would still need to address a servlet on the server which would help your websocket establish a persistent connection - and mysql is unable to perform such an establishment.
Reason #3.
SLD - SOP restriction:
(Second Level Domain Same Origin Policy)
Standard browser restricts its pages to only be able to request for, and to include, content from within the same second-level domain (SLD) as the server that provided that page to the browser. Top level domains (and top-level and a half) are such as .com, .org, .net, .me.us or .co.uk. So, domain names such as google.com, fbi.gov, mit.edu are second level domains. While, mail.google.com would be a third-level domain. Therefore, GWT would work only within the confines of an SLD. Your web server must also be accessible at the same SLD as your mysql server.
SLD-SOP and tunneling requirement is to close a security hole that could have allowed any tom-rick-or-mary to log into your system thro your browser. Tunneling is always required for a browser to connect to a server other than a http server. Tunneling is when a browser exploits the web server as a yenta (yiddish for busy-body/go-between/match-maker) to get to another server.
You have no choice but to use GWT-RPC. Perhaps you don't wish to use RPC, then you could use RequestBuilder, or Script-Include or RequestFactory. But they are all still diverse means of tunneling. http://h2g2java.blessedgeek.com/2011/06/gwt-requestbuilder-vs-rpc-vs-script.html.
There is one reason why you can connect to your database server from your gwt client:
Your database server must run httpd connection engine. That is, your gwt app would access the db server thro http. I am not familiar with which relational database has a http access available. Most probably, you would have to query thro xml or json.
However, a company I had worked for created our own http service to allow "direct" client access. "direct" is a misnomer because we used tomcat. It is stil tunneling. Any database company that offers "direct" http access is still tunneling. Tunneling - no escape from it.
You could augment the browser with Flash and write a Flash application rather than using GWT. If direct access is so essential to you, you would have to abandon GWT and develop in Flash and run a httpd engine for your database server.
GWT is ultimately Javascript. As noted at Are there JavaScript bindings for MySQL?
, there is currently no way of accessing MySQL from Javascript.
Therefore you can't access it from client-side GWT code.
AFAIK it's not possible, and even if it were, it would be a really bad idea. Are you sure you actually need a database? Maybe something like gwt-client-storage would be more appropriate.
EDIT
Your database would we publicly accessible and open for any sort of attacks.
EDIT 2
This may even be a better solution, as it offers support for accessing the HTML5 Database API and is targeted to iPhone/iPad.
gwt-mobile-webkit
If you were even successful in doing so, in short, doing a CTRL + U on the browser would make your database name, username, password, tables names etc visible... And done, any developer curious to know your code has a way to hack anything and everything in your server.
I think it's not possible, I mean, if you want all your data stored in DBs. I mean, GWT compiles into javascript and javascript executes on the client (typically a web browser).
If you want to access data stored somewhere (by some mean) in a server, then you have no option but RPC. If I were you, I would stop thinking in client-server paradigm (GWT was developed with that in mind). Perhaps some embedded database like H2 and then hold connections through JDBC.
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...