I have made a Java application using Swing. I use a total of 12 classes, 10 forms and one main class. All are packed in a jar with all the necessary libraries and resources. The jar is an executable and is working fine with no issues.
The problem is that it is a database related distributed application.
I have used many Connection objects to connect with mysql.
The connection is public. If a hacker or attacker imports my jar to his own project
and try to get the clone of that connection will he be able to hack the database?
If yes, what is the solution and if no, why can't he?
It depends on what exactly is in the jar and how you are connecting to the database.
A jar file that just has class-files in it, can be reverse engineered rather easily. This would let a hacker see a great deal of what you have coded, especially things like URL and SQL strings. You can try to be really clever and build up the strings, but you would probably have to be twice as clever as the hacker to be able to hide things from him.
So, instead of trying to make the jar hack-proof, protect your database. The public connection should not have very many privileges, and the admin account should not be accessible remotely for the most security. There are likely more things one should do to secure your database, but I am not a DBA.
Good luck.
Related
Recently we found a jar in our application phoning home. See details: https://github.com/nextgenhealthcare/connect/issues/3431)
This is very undesired behaviour.
What would be the best approach to detect this in one of our depedencies?
ps. I can unzip all the jars and scan for HttpClient or UrlConnection, but there are many ways to connect to external systems, and preferably I don't want to reinvent the wheel.
I am aware of the OWASP Dependency-Check, but phoning home is not a CVE per se.
If you scan your jar's, and they do have network connectivity, then what can do then? You can't recompile the source, as you don't have it. A case of finding something you can do nothing about (apart from find an alternative).
The only way is it firewall your application, or network, use containers, and have a fine grained control of what you application talk to. Basically run your jars with zero trust!
I guess it really boils down to trusting your jar files, and that means in turn trusting the humans that make that everything that goes into jar file. (design, coding, build, distribution, maintenance ). The whole SDLC
If you approach the problem of zero trust, you can either get the JVM (security manager), The operating system (SELINUX/System Cap's/Docker) or the network (firewall/proxy/ids) (or all three) to control and audit access attempts..and either deny or permit these access depending on a policy that you set.
Scanning the jars for network calls can be done, but i'm sure if a jar really wants to obfuscate it's network behaviour, it will be able to, especially if it can run shell commands, or dynamically load jar's itself.
A jar you scan today, might not have the same behaviour on the next update? The classic supply chain attack.
If you don't trust you jar's, then if you must establish that trust, either thought scanning, auditing the source code.
There are many tools for this. I'm not sure if i'm allowed to recommend a particular product here that i've had success with, so i won't.
I'm currently learning to use maven, I understood how to create a maven project using dependencies from maven repository - and now I have the following question:
If I have an application which uses a database access, for example via Hibernate, then I need to add a dependency representing the corresponding database driver, for example mysql-connector-java for MySql, ojdbc for Oracle and so on.
But what if I want the program to run on a different machine and I don't know what database engine it uses? What is the common way to solve this? Just import all possible drivers as dependencies? Or is there a more elegant way?
Using a ORM (Object Relational Mapping) like Hibernate is the best solution since you write Java code that will be interpreted by Hibernate and translated into SQL queries.
At some point, you will have to decide which database are you going to use, then you will have to add the driver.
Another solution can be making configurations for different environments using maven: https://maven.apache.org/guides/mini/guide-building-for-different-environments.html
The problem is not particularly maven bound. Whenever you move to a new database, the administrator would have to use the correct JDBC driver according to DB, and yes, it requires different jar files.
The thing is, that you don't want to bundle the database jar file with your code. It may already exist (e.g. in the application server) or you may specify a path to drop it during installation.
Assuming you are creating a webapp. If you bundle a war-file with maven, it will include all dependencies inside the war file, so you must specify that the dependency is there during compilation and testing, but not in any package. The way to do so, is by specifying it as provided
<dependency>
<groupId>some.db</groupId>
<artifactId>jdbc-driver<artifactId>
<scope>provided</scope>
</dependency>
This means that the jar file will exist on the target platform, and hence, should not be packaged in a any bundle.
So the assumption I make is really, is this a web-app? Or is it standalone? Anyway, hope it helps.
You don't need a dependency at all. What you need is a driver to be available at runtime. It's true that one way to do this is with a dependency, but if you don't know the database you can't really bundle everything in there. You could stick some most common drivers, but then as said there would be licensing issues.
If you're talking about a web application, you could just tell the user to get the appropriate driver and configure a JNDI datasource that the software uses. This is/was a standard from back in the days, but it assumes that the application is a webapp and the end user knows how to configure things (although if he doesn't, he probably shouldn't be setting up the system in the first place).
For a standalone program using a local database, you have the easy choice of using an in memory database like H2 and not allowing any other databases. Naturally this case doesn't work for everything, but I'm including it as an example. In any case it would boil down to the same as with a webapp. Have the end user get the correct driver. If they're running a database server and your app, they should be able to find the right driver too. Then you just need to make sure it's included in the runtime classpath, which might be a bit harder.
The way this is done by SquirrelSQL for example, is by explicitly selecting the drivers as shown in the below picture. This of course again means the user needs to understand what he's doing.
I assume that you want everything to happen automagically and you're not too eager to instruct each user/machine admin how to configure system to have your app working. I am afraid it is not possible in the way you might have hoped.
The standalone database solution that Kayaman suggested might be the best solution in your case but hard to say without knowing further.
However here are some aspects regarding using maven and possible difficulties with some notes.
If I have an application which uses a database access, for example via
Hibernate, then I need to add a dependency representing the
corresponding database driver, for example mysql-connector-java for
MySql, ojdbc for Oracle and so on.
Yes. And you also would need to tell hibernate about this Driver and perhaps other stuff related. It is not just adding dependency but also filtering some prop file or persistence.xml. That might be a job for maven and some of its plugins. But still it would require knowledge about all the possible db alternatives and maven profiles for each of those to handle them.
But what if I want the program to run on a different machine and I
don't know what databse it uses? What is the common way to solve this?
What options do I have? Just import all possible drivers as
dependencies? Is there a more elegant way?
All programs have dependencies. Was it related to DB or not. In a sense as other answers suggest this is not maven specific (but quite related still! ) thing. You need to be aware of the requirements of any environment if you really want to develop on the level of JDBC drivers.
This specific question of yours is something that - I believe - is the motivation to develop things like:
ODBC
JNDI
NOTE 1 even similar naming ODBC & JDBC are totally in different level (I mean how JDBC drivers are found which actually might be the main problem...)
NOTE 2 JNDI is not restricted to DataSources
However maven can be a great help depending on what you need and finally decide to do. But not in so big role if you can use ODBC / JNDI.
I am currently helping a small hosting company. There is no experience existing in regards to writing Java code.
They now have the order of a customer to host a complicated product using Tomcat, which needs some prelimanary work to be done beforehands. In detail, some Java Proxy classes need to be created using NetBeans (and Eclipse).
I think this is subject to be done by the software manufacturer. However when starting to work with this topic following a documentation of the manufacturer I see that i.e. when creating a WSDL the connect to an internal server (inclusing user name/password) is necessary.
So I wonder how to have this work to be done by the manufacturer without having access to our webserver? I.e. creating a WAR-file?
Usually, the developers should create a deployable artifact that - if the Tomcat itself is configured correctly - simply needs to be deployed and will run out of the box. That is the war file! So basically there is no need to access the hosting company server itself, neither to write any code in Eclipse/NetBeans to get the application up and running. If the customers say so, they either have a really weird code base there, or they simply do not know what they are talking about.
What are ways of getting database and other service passwords out of your code? I've read about using per server properties files but when you have a large number of servers it gets to hard to maintain. I've also seen a solution using a CI's build process to "inject" passwords but that makes it difficult to update the password on-the-fly.
Some requirements to help narrow the field of answers...
The password should be easy to change and propagate in the event of a security breach.
Password can not appear in code (due to point 1)
It should be "non trivial" for a human to get a plain-text version of the password
Should work well in the web application and stand alone applications
Easy to adopt from a application developer standpoint
Some nice-to-haves include not introducing a single point of failure, a quick development time, and easy to understand.
This is similar in spirit to this question but with an strong emphasis on maintainability and focuses more on the server side case.
You could store it in plain text in a file in a protected directory that can only be read by the account in which the application is run. In case of a web application, you should always store the password outside the web root folder.
If you use a database connection pool then the username, password and other database details are generally managed in the Java Web Container and presented to the Java code as a Datasource. You just ask for a Database connection without having to know any of these details.
In addition to storing it in a text file outside web root, how about using encryption? With most languages, it's pretty trivial to use an encryption method and, though it might not be strictly necessary to protect from web attacks, it makes it more difficult for another person who may gain access to the file on your system. Additionally, a bit of obfuscation, disguising the file as something else with a boring name that will be likely overlooked, makes it less likely that someone will find it even in the event they have physical access to the server.
We have following problem. Developers frequently need to make small changes to our web applications. When I say small, I mean things like correcting the spelling on a web page or similar. Generating and redeploying war archives can be slow and costly in such scenarios.
How could we automate and install changes incrementally? For example, generate new exploded war, compare files with exploded war in production and then replace in production only the files affected by change: .jsp .html .class etc.
This need not be hot deployment, it’s ok to restart the server. What I wish to avoid is having to copy and deploy wars that can be 80Mb in size. Sometimes connections are slow and making such minuscule change to web application as simple spelling correction can take hours.
We use Maven to automate our build process. The key issue is to automate the whole process, so that I can be sure that app v2.2.3 in my Subversion is exactly what I have in production after incremental deployment.
We used to do this sort of thing all of the time. We worked in a bank, and there were sometimes changes to legal phrases or terms and conditions that needed to be changed today (or more usually yesterday).
We did two things to help us deploy quickly. We had a good change control and build process. We could change and deploy any version we liked. We also had a good test suite, with which we could test changes easily.
The second was more controversial. All of our html was deployed as separate files on the server. There was no WAR. Therefore, when the circumstances came up that we needed to change something textual quickly, we could do it. If java needed changing, we always did a FULL build and deploy.
This is not something I'd recommend, but it was good for our situation.
The point of a WAR is so that everything gets deployed at the same time. If you're using a WAR, that means you want it to be deployed all at once.
One suggestion is not to do such corrections so often (once a week?). Then you don't have so much pain.
Hard to say. You can ofcourse replace single class files in an exploded webapp, but this is generally a bad idea and you don't see many people doing this.
The reason is that when you make small changes it becomes harder and harder to detect differences between production and development. The chances of you sending a wrong classfile and breaking the production server increases over time.
When you say text changes, isn't it an idea to keep the text resources seperate from the war file? That way, not only developers but maybe even the customer can easily add/change translations.
To the customer it's important, but technically it's silly to do a 80MB deploy over a slow line to fix a small typo.
You can also try to look at your build/delivery cycle and increase testing efforts to prevent these small changes.
Hope this helps.
You can have the master war deployed somewhere the running servers can access it, and instead of deploying war files to the individual servers you can use rsync and perl to determine if there are changes to any files in the master war, distribute them to the servers and execute restarts.
diff and patch:
http://stephenjungels.com/jungels.net/articles/diff-patch-ten-minutes.html
At the moment I installed SVN on the remote server so in case of a simple udate you can just update single file. Transfering the big WAR file would be quite impractical.
You can automate to a single click deployment using putty / plink [if you are using windows] by creating a simple script on the local machine an another one in the remote machine.
At the moment I have a DEVELOPMENT SVN and a LIVE SVN. The ANT build is merging the DEV to LIVE and the commit again back to the LIVE repository. At that stage the remote server can do a SVN UP and you will get automatically the file requested.
You can furter improve the update script to restart the server in case some classes are changed and do not restart in case of updating scripts/JSP.
In this way you will have also the option to rollback to a previous version to be sure that you have a working web app all the times.
To improve the process of merging SVN this tool is quite useful. : http://www.orcaware.com/svn/wiki/Svnmerge.py
The usual answer is to use a Continuous Integration sstem which watches your subversion and build the artifacts and deploy them - you just want your web application to be abel to work even after being redeployed. Question is if that is fast enough for you?
I don't think there's a straightforward answer to this one. T
The key here is modularisation - a problem which I don't think is solved very well with Java applications at present. You may want to look at OSGi or dynamic modules lathough I'm not sure how effective they are in terms of this problem.
I've seen solutions where people drop classes into application server/servlet container, I don't agree with it, but it does appear to work... I'm sure there are horror stories though!
Maven certainly makes things easier by splitting applications into modules, but if you do this and deploy modules independently you need to make sure that the various versions play nice together in a test environment to begin with...
An alternative is to partition your application in terms of functionality and host separate functions on various servers, e.g:
Customer Accounts - Server A
Search - Server B
Online Booking - Server C
Payment Services - Server D
The partitioning makes it easier to deploy applications, but again you have to make sure that your modules play nicely together first. Hope that helps.
I have had a similar situation before. It really is a separation of concerns issue, and it's not too straight forward. What you need to do is separate the text from the template/HTML page.
We solved this by placing our text in a database table, and using the table as a message resource - the same way people use myMessages.properties for internationalization (i8n). This gives you two advantages, you can i8n the text, and make changes in prod instantly and easily without a code deployment. We also cached the table to ensure performance didn't suffer much at all.
Not a solution for all, but it did work really well for us.