Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I am using jboss server for my servlets and the postgresql as the database server, listening on port 5432 on localhost. My jboss server is bound to a public IP. I want to know that since my postgesql is bound only to the localhost, is there any chance of an attack at all.
Will any one be able to see the all the table data even if they have the user name and password for the database?

share|improve this question

2 Answers 2

up vote 5 down vote accepted

Starting by securing PostgreSQL according to Erwins answer is a good start. However, there are other ways to attack and gain access to data. Even if you are after data as an attacker, one wouldn't assume that the database is directly accessible from the internet.

But data might be accessible indirectly due to flaws in the application server, in this case JBoss, and its configuration or in the application code (sql injection).

JBoss had a seriuos security vulnerability about a year ago that allowed you to gain root access - and as a consequence full access to any PostgreSQL server on localhost. http://www.darknet.org.uk/2011/02/jboss-autopwn-jsp-hacking-tool-for-jboss-as-server/

UPDATE:

Yes, Ashwin, using prepared statements or stored procedures/functions is a good way to minimize the risks of sql injections attacks. OWASP has a check list for prevention of SQL injections. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29

One advantage of stored procedures/functions is the granular control of permissions. For example you can grant access for the application user to only be able to run specific procedures/functions, whilst access is denied to the underlying tables and other objects. The procedure/function is instead run by the permission of the owner of the procedure/function (a user also with restrictive permissions, just able to operate on the specific tables). This setting can be controlled with SECURITY DEFINER, as in this example function.

CREATE OR REPLACE FUNCTION myschema.myfunction() RETURNS void AS 
$BODY$
BEGIN
    INSERT INTO myschema.mytable(msg) VALUES('value goes here');
END;
$BODY$  
LANGUAGE 'plpgsql' VOLATILE SECURITY DEFINER;
ALTER FUNCTION myschema.myfunction() OWNER TO myinsertupdateuser;    
GRANT EXECUTE ON FUNCTION myschema.myfunction() TO myappuser;

This function can be executed by myappuser, but myappuser can not access myschema.mytable directly. In other words myappuser can only run the code you specify in the function. The function is run as myinsertupdateuser, which is assumed to have insert permission on the myschema.mytable table.

share|improve this answer
1  
To minimize such risks, applications like PostgreSQL and JBoss should never be run as root, should not use the login as each other, the OS rights of the logins used by each should be as limited as practical, and the rights of the database login used by JBoss should be as limited as possible for the work needed in production deployment. (For example, DDL rights are not normally needed.) That's not a cure-all, but some common sense limits hazards. On top of that, a real (hardware) firewall should always be used, which exposes just the necessary ports. –  kgrittn Jun 24 '12 at 16:34
    
@JohnP : As far as SQL Injection is concerned, I have used PreparedStatements in my application. So is there any chance of an sql injection taking place? If yes can you show me how or point to a webpage? –  Ashwin Jun 25 '12 at 4:20

Only local connections are allowed, so nobody can log into your database cluster, who doesn't have access to your local operating system. One can forward a port to localhost, but that requires local access first. So nobody "from the internet" can access your database.

You can (and should) adjust the settings in pg_hba.conf additionally (and reload the Postgres server) to be sure. It's kind of a PostgreSQL-firewall. Details in the manual

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.