Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Whether this is about ha.ckers.org, sla.ckers.org or some other project you are interested in or want to talk about, throw it in here to get feedback. 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Building JSP website with PostgreSQL
Posted by: doody
Date: March 07, 2010 12:58AM

I'm currently working on a project that involves building a website in JSP and with a backend PostgreSQL database. Are there any points that I can look out for with regards to securing this website against attacks? The only thing I can think of currently is SQL injection, which has already been covered by using PreparedStatement for all SQL queries. Are there any other attack vectors that I should be looking out for?

Options: ReplyQuote
Re: Building JSP website with PostgreSQL
Posted by: Spyware
Date: March 07, 2010 09:09AM

Filter all input.

Options: ReplyQuote
Re: Building JSP website with PostgreSQL
Posted by: Matt Presson
Date: March 07, 2010 10:24AM

Prevent XSS:
Validate all input as close to the input source a feasible, AND encode any user controlled output when being included in the JSP. Be sure when you perform your encoding to do it based on the proper context (HTML, JavaScript, URL, HTML Attribute).

Session Management:
Do not generate your own session identifier. Use the built in session mechanism provided by your JSP container or application sever (Tomcat, WebLogic, JBoss, Glassfish, etc)

Data Transportation:
Ensure that any data that is considered "sensitive" by your application is only transmitted over a secure channel (HTTPS in this case).

Data Storage:
Ensure that any data that in considered "sensitive" by your application is stored encrypted if at all possible.
Do not allow that application to connect to the database as the schema (table) owner. Instead, create an application account that only has the minimum set of permissions necessary for the application to function. For instance, if you have a lookup table that only provides a set of statuses and normal users cannot add values to this table as part of the normal function of the application, only grant select on that table to the application user which you connect to the database with.

Access Control:
If your application requires login, ensure that login only happens over a secure channel (HTTPS).
Check that a user is authenticated at every entry point (URL) in the application. Also check that the user is authorized to access the requested URL before performing any business logic.


There are a lot more things you need to consider, but if you get these right then you should be well on your way to being secure.

Options: ReplyQuote
Re: Building JSP website with PostgreSQL
Posted by: doody
Date: March 07, 2010 12:09PM

Thanks Matt, I should be able to implement most of that, except the HTTPS one. It's actually just a project, so it's running on a local Tomcat server.

Matt Presson Wrote:
-------------------------------------------------------
> Session Management:
> Do not generate your own session identifier. Use
> the built in session mechanism provided by your
> JSP container or application sever (Tomcat,
> WebLogic, JBoss, Glassfish, etc)

Just a while ago I was checking out the session id generated in my web application. First I logged in using FF, and got the cookie. Then I used IE and confirmed that I wasn't logged in, before setting the cookie. I was then logged on in my IE window as well. Is this just an isolated case caused by me running my Tomcat locally? Or is it an issue that needs to be looked at?

Options: ReplyQuote
Re: Building JSP website with PostgreSQL
Posted by: Matt Presson
Date: March 07, 2010 05:38PM

The short answer is this is how things are supposed to work.

The short explanation for why is this:
When you first visit your website, or for that matter any website on the internet the uses session cookies, the server parses the HTTP request and looks for a valid session cookie. If one is not present in the request, then it generates one for you and sends the id back to the user in the response - generally in the Set-Cookie header. Going forward, your browser will send this value back to the server every time you make a request.

Now that your browser is sending this value to the server with each request, when the browser parses the request to look for a valid session id it finds one. The server then does some more checks like seeing if the timeout for that session id has expired, etc. The other thing that happens is that the server checks to see if that id is in the list of ids it generated. If all of the above checks are successful, then the server trusts the session. Any other checks to see if the session should belong to that client are required to be performed by the application.

It is for these reasons that moving the session id between your browser sessions works. In webapp security speak, this "attack" is called session hijacking. In the real-world this is most often accomplished by an an attacker utilizing a cross site scripting attack to read a user's cookies and sending the values off to another site. When the values are received by the attacker, all they have to do is open a browser and replace the values of their cookies with those from the unsuspecting user. Once this happens, as far as the server is concerned the attacker is that user.

Hope all this helps and makes sense.


-Matt

Options: ReplyQuote
Re: Building JSP website with PostgreSQL
Posted by: doody
Date: March 07, 2010 09:05PM

How can I do validation (server/client/anywhere) such that I can prevent session hijacking? It's probably out of the scope of my project (school stuff) but now I'm just interested to know!

Options: ReplyQuote
Re: Building JSP website with PostgreSQL
Posted by: Matt Presson
Date: March 08, 2010 01:09PM

That gets very hard as you cannot really go by IP address or anything like that because users could be coming through proxies, concentrators, or any number of things that make them look the same.

As far as I know, it all comes down to the application itself and the architecture supporting it. I have written code to do it, but the only reason it as possible was because I was utilizing a single sign-on mechanism that allowed me guarantee some assumptions that would not be possible otherwise.

Options: ReplyQuote


Sorry, only registered users may post in this forum.