This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes Security and the fly likes Web security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "Web security" Watch "Web security" New topic

Web security

Saket Barve
Ranch Hand

Joined: Dec 19, 2002
Posts: 229
I am working on a database backed website. The database used is Oracle. At front end, its JSP and Servlets along with JDBC to establish database connection.
Can someone direct me as to how I can implement security issues?
For e.g. there's an administrator login/logout option. After logout, one can easily hit the "Back" button on the browser to work on the previous pages.
These pages are accessible through the "History" option in the browser too.
What is the way for me to "Expire" the web page appropriately? I'd appreciate any feedback.
Peter den Haan
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
The first thing to do is to add a few HTTP headers in an attempt to force browsers and proxies not to cache your pages. Something like:
Pragma: No-Cache
Cache-Control: no-cache
Expires: 0
Last-Modified: Fri, 10 Jan 2031 23:59:59 GMT
Beware that, although this looks like complete overkill, some browser/proxy combos still seem to ignore it (especially some stuff from a certain company in Redmond).
To make browser history essentially unusable on some browsers, simply ensure that the pages are created using POST requests (i.e. form submissions). The browser won't redisplay, but wants to re-post the request. Your remaining problem is then just to refuse the request.
The easiest way by far to do this is to leverage container security: declare security roles and protected pages in your deployment descriptor, done.
The only downside is that there is no standardised API to make containers use a source of authentication information that you already might have (XML file, database table, directory, whatever). Conversely, there also is no standard API to add, delete or modify users in whatever security realm implementation your container uses. All containers worth the name have some kind of API, but they're all different and non-portable.
Alternatively, if you are using a Servlet 2.2 container, you will be able to set up a servlet filter which will filter requests to protected areas of the webapp and take appropriate action if the user isn't logged in or not authorised. This basically mimics the action of container-based security but allows you to do your own thing in a container-independent way.
Assuming you did the right thing and implemented your business logic in session EJBs, plain old Java business objects or the like, you could conceivably check credentials there. The disadvantage is that it'd get scattered a bit and problems would be flagged up only fairly late.
Finally, if you are using a Model II architecture, you will be routing all requests through a front controller. That gives you a single access point where you can implement security checks. This is probably the least desirable option though.
- Peter
[ March 12, 2003: Message edited by: Peter den Haan ]
Saket Barve
Ranch Hand

Joined: Dec 19, 2002
Posts: 229
Hi Peter,
Thanks for the detailed and precise reply. I appreciate your prompt feedback.
I agree. Here's the link:
subject: Web security
It's not a secret anymore!