• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Better ways of securing webpages access

 
Ranch Hand
Posts: 355
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
I wish you could share some methods for securing access to webpages of websites you had had a hand on?
I know of:
- asking for user credentials from an entry page and processing them inside a javabean to confirm they are equal to those kept in the system before granting further access.
- masking servlets paths in web.xml
- hiding client scripts in libraries that are kept on server
Do you know of other methods?
Kind regards.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's best to use the security built in to the Servlet container (or other framework).
 
Paul Ngom
Ranch Hand
Posts: 355
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have wanted to change the title to 'Better ways of securing webpages access'.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Title changed as per request.
 
Rancher
Posts: 43081
77
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bear's advice is spot on: use built-in and existing mechanisms rather than develop your own. It's easy to put an insecure system in place. so not writing security code yourself is generally preferable. Security is huge topic, though, that goes way beyond authentication and authorization. Web apps specifically have their own attacks like XSS, CSRF, HTTP response splitting, SQL injection etc. The SecurityFaq goes into a lot of detail on all of this.


- masking servlets paths in web.xml
- hiding client scripts in libraries that are kept on server


I'm not sure what you mean by these two, specifically "masking" and "client scripts in libraries".
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ulf Dittmer wrote:Bear's advice is spot on: use built-in and existing mechanisms rather than develop your own. It's easy to put an insecure system in place. so not writing security code yourself is generally preferable.



Some perspective.

When I started working with Enterprise Java, JSPs hadn't been invented yet. Only servlets. I've been working with it daily since then, and encountered applications for financial and even military use among other domains.

Of all these apps over all these years, virtually none of the ones that had Do-it-Yourself security managers were secure. In fact, most of them could be cracked by non-technical persons in 15 minutes or less.

A lot of "clever" people and design teams have designed their own security systems, and they've made themselves look like idiots, whether they were aware of it or not.

Security is hard. One weakness spoils the whole thing. Unless you are professionally-trained and a full-time security professional with lots of backup, you really shouldn't try. Definitely not if you're the typical grunt programmer implementing something that the local Bright Boy cooked up and being made to do this as a sideline of getting the app done.

Fortunately, we do have pre-defined, pre-debugged, well-documented security available for Enterprise Java and it has - so far as I'm aware - a perfect track record. While it's relatively coarse-grained, virtually all webapps can benefit from it, especially if you augment it with a fine-grained secondary security system (which is somewhat safer to invent yourself, though there are some good ready-made ones).

And one of the best things about this security standard is that it acts at the container level, blocking many attacks before they can ever be sent to the web applications. And what doesn't get sent to applications cannot exploit security holes or bugs within the applications.
 
Paul Ngom
Ranch Hand
Posts: 355
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
By


- masking servlets paths in web.xml


i simply mean mapping of servlets urls.
And by


- hiding client scripts in libraries that are kept on server


i simply mean putting all clients scripts such as javascripts on webpages in js files.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't see a connection between those two points and security; can you elaborate?
 
Paul Ngom
Ranch Hand
Posts: 355
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


I don't see a connection between those two points and security; can you elaborate?


- When an url mapping is done in web.xml let say WebServlet servlet has an url-pattern /MyPage.do, the user cannot easily guess the name of the servlet called by /MyPage.do.
- when javascripts functions are hidden in js file, the user can hardly guess the logic involved.
I think these relate to security.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JS files are just as accessible to the user as is JS code embedded in web pages, so that is not an improvement.

MyPage.do vs. WebServlet seems an insignificant improvement. But I do agree that public names of server-side resources and of HTML form variables should be chosen with care, so as not to give away information.
 
Paul Ngom
Ranch Hand
Posts: 355
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there a way of password protecting a webpage or a whole website so that webpages cannot be edited by unauthorized people?
Assuming i have a webpage in a client's machine where application was deployed, i don't want any user to be able to change the code. How can i do
that?
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What code? The HTML? The JavaScript? You can't. Which is why security on the server is so important.

If you are talking about the server-side code, they can't unless your server has huge security issues beyond the scope of the web app.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Ngom wrote:Assuming i have a webpage in a client's machine where application was deployed, i don't want any user to be able to change the code.


That being the case, I would urge you to reconsider your relationship with your client. The licensing agreement should make it clear what is or is not allowed. If you don't trust the client to honor a legally binding document, either get other clients, or provide him with a web app that can only harm the client, not you, if its is altered.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah, yes, if you are handing the completed application over to a client for deployment, you can provide a war file that does not contain the Java sources, but you can do nothing to prevent them from changing the non-compiled resources.

I misunderstood what was meant by "client" (by nature, I assume it means the browser, not a customer. )
 
Paul Ngom
Ranch Hand
Posts: 355
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


I misunderstood what was meant by "client" (by nature, I assume it means the browser, not a customer)


That was my fear. :-)
The problem is, when the war file is unpacked by container all app files can be accessed. Even with compiled resources, there are tools that can translate them back to their source files.
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's pretty far off-base.

There are 2 ways to get to WAR resources. One is if you physically invade the server and have complete access to the local filesystem. In which case, protecting the webapp is probably the least of your concerns.

The other is via the webapp server's normal client channel. This isn't as open.

Firstly, it doesn't matter whether the resource is in a packed WAR or an exploded one. WAR resources can only be retrieved by direct URL access if they are not located in the WEB-INF directory or its children. The webapp server will NEVER directly serve up anything under WEB-INF, per the J2EE standard.

Secondly, the web.xml file can be used to hide resources. For example you can define an applet named "Bonk" that returns the error message "Bonk", map it to URLs beginning with "/secret", and the actual WAR's "/secret" directory will no longer be accessible to HTTP clients, because the servlet mapping will override the default servlet (which is what returns a webapp resource when no JSPs or servlets match the URL).

And thirdly, if you map a webapp resource URL to a security role in web.xml and use the container security system, the webapp server will only allow that URL access if the requesting user has the proper security role. Define a "nobody" role, assign it to no users, and you have essentially a higher-level implementation of the "Bonk" servlet.

You can further limit access using things like servlet filters, but that's enough for starters.

The one thing you cannot do, of course, is hide stuff that MUST be sent to clients. Since CSS and JavaScript are both client-side functions, the best you can do is obfuscate them. Class files, on the other hand, live in the WEB-INF/classes directory, and since WEB-INF is hidden, so is the server-side Java code.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tim, I think you are making the same mistake I did. I believe (as Ulf did) that Paul is talking about delivering a war file to the client (person) to deploy at their own site, and wants to prevent them from making any changes to the web app.
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm. I did miss that sub-thread. The original question was:


I wish you could share some methods for securing access to webpages of websites you had had a hand on?



And to me "webpages" means HTTP requests, since they're only potential pages in the deliverable.

Of course, getting your hands directly on the WAR itself is tantamount to full filesystem access for the WAR anyway.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic