Book Promotion : Hacking Exposed: J2EE and Java

[Brian Buege]

Originally posted by Rick Salsa:

If you could that be great! So does the book cover programatic security as well? I'm assuming this might be something like isUserInRole, type of thing?
Also, you mentioned that the book talks about securing communcation from client to server, with a swing-jdbc app. What about securing communications with an app server using rmi? Is this mentioned at all and would it be similar to what you describe for the client-sever scenario?
Thanks Brian. The first answer was very informative!
/rick
[ October 23, 2002: Message edited by: Rick Salsa ]

Rick-
Yup. The book does cover programmatic authorization in standalone, web based (servlet/JSP) and EJB pieces of an application.
Also, there's an entire chapter on implementing a security scheme with RMI. It covers everything from SSLizing your RMI connectivity to some examples of easy authentication/authorization schemes, to writing a custom socket factory for the RMI runtime to use.
Hope this answers your question!

[Brian Buege]

Originally posted by Deb Williams:
Brian,
Are there any security issues when using dynamic or static includes? If so, is one better to use than the other?
Thanks,
Deb

Deb-
Sorry I missed your post the first pass through... It was so concise and to the point, that I jumped right over it!
There really aren't any specific issues with jsp:include vs. <%@include... that should cause you excessive worry.
Some people might point out that the page include (the static, compile-time one) is nice because if you turn off automatic server-side recompilation and then batch compile all of your JSPs, an attacker could not force new functionality into your app merely by placing (or replacing) a JSP file on your server. If all you're doing is using includes for inclusion of static code, it's probably a good idea to stick with the static include. Understand though that if you do this and change one of the included files, on some containers, you'll have to manually force recompilation of all dependant JSPs.
But, there's a ton of stuff that you lose if you don't use dynamic includes, like the ability to look at the current request params, etc.
One thing to be careful of if you build resources that are meant to be dynamically included or forwarded to is to make sure that cross-context mapping is turned off for your application (only some web containers support this feature anyway). This will prevent other web apps from forwarding to or including your resources using RequestDispatcher and also inspecting your ServletContext object. Usually this isn't a problem, but an attacker could potentially take advantage of it.
Other than that, I can't add much more right now. However I could be overlooking a significant issue. Let me know if there's a specific one that you're concerned about and we can discuss it.
Thanks for posting!

[swap Inam]

Hi Brian,
I am about to start working on a assignment which is supposed to be a web portal.
It is going to use application server, web server, directory server and portal server.
I was just wondering what are ( is there any ? ) impacts of using so many servers on security of the application ?
Hope it makes sense
Swap

[Cathy Gorchkova]

Hi, Brian
What is the best solution for handling instance-level security in Entity beans? How to return to the user a subset of entity beans he can access?
I wish to avoid retreiving all the beans first and then check authorization for every entity.

[Guennadiy VANIN]

Brian, thank you answering me in
https://coderanch.com/t/132992/Security/digital-encryption
I have more questions there basically abt what was the evolution in security and what will be next.
It is also very important for running the code from articles on Internet, since things change, there are articles 3 years old, and no explanation abt what they were/are using. A little bit of confusion.
For ex., IBM's security suite is evaluating since April 1999. It is interesting, if I read an article from 2000 (or even 1999) how may I get that suite from 2000, etc.?
How many your books are on promotion? Whether the CD is self-sufficient for reproducing examples without referring to Internet (I use JDK1.3.1, and access Internet through library or books' CDs)

[Brian Buege]

Originally posted by Cathy Gorchkova:
Hi, Brian
What is the best solution for handling instance-level security in Entity beans? How to return to the user a subset of entity beans he can access?
I wish to avoid retreiving all the beans first and then check authorization for every entity.

Cathy-
This is a very good question! It's also a question that I could write at least an article on (maybe a whole chapter for a book...) So, I apologize in advance if my response isn't totally comprehensive.
Here's a quick answer:
Whenever anybody says "instance level" security my ears always perk up... I'm assuming what you mean is that you want the ability to create a constrained entity bean "view" of the data based on the identity of the caller... Kind of like setting up a view in the DB where one of the criteria was identity based... Tell me if I'm on track here...
It's a common issue. And one, in my opinion, that most people try to solve at the wrong level. When you think about it, this is a place where you need application logic to help determine access. Don't try to rely on infrastructure to solve this whole problem for you - it'll give you the tools, but you need to build the solution yourself (the J2EE spec doesn't know what your schema looks like!). Asking the J2EE infrastructure to do this for you is like asking the OS (NT or UNIX) to prevent specific users from editing files containing the word "gumbo." It would be something better implemented in the editor (the application), but using information provided from the OS - the user identity to make the decision. I would recommend the same approach with J2EE.
Here are several solutions:
1. Use the Session Facade pattern. Keep your entity beans wide open (no attribute based security), enable the use of Local interfaces on them and turn off remote access. This will generally protect them from anything not running in the same VM. Then, have your session bean execute custom finder methods on the ebeans that only return the proper instances for each user (which you can inspect with the getCallerPrincipal method in your session bean)... For example, your session bean extracts the principal, gets some identifying info about the user, then passes it on to the ebean finder method along with the actual search criteria. This should alleviate you having to sort through all of the beans (the DB and CMP mechanism will do it for you)
2. Another way to tackle this if you don't want to facade the entity bean with a session bean, is to use BMP. Then you can look at the caller principal in your finder methods (since you're writing them) and make the appropriate decisions.
3. If you're using CMP (which I'd recommend anyway) and still don't want to use the session facade (persistent, aren't you!), lock the findByPrimaryKey method using J2EE security to prevent arbitrary users from calling it, then write findXXX methods that take two arguments: the argument you want to search on, and a Principal object (representing the user identity). Then write the EJB-QL for the finder to filter based on key and identity. Set the security on these methods to a role that no actual user belongs to. Have all code calling these methods "run-as" that role -- use impersonation. That way, an arbitrary user won't be able to construct a fake principal object and call the method from outside your container.
4. This is a wild one... If using CMR (with EJB CMP 2.0) is something that excites you, create a User entity bean and a Product (or whatever) bean. In the user bean, create a getProductsByXXX method for a M:M relationship with the Product bean. Look up the user bean and traverse the values that way.
5. ... I can come up with some more, but I'm going to have to cut this post off now - I'm getting to article length! These should be good to get you started.
Bottom line is: The type of security you're looking for is extremely granular; It's a valid, realistic need, but super granular. So granular in fact that operating systems, databases, etc don't support it (you can't easily set security on a single row in a *standard* database table -- you have to use the view method I outlined above). The reason this generally isn't supported is because trying to build a generalized solution would slow things down too much and blur the role of the OS or DB. However, it's very attainable at the application level, as a matter of fact, it's probably part of the purpose of your application (to only display info relevant to a particular user).
Hope this helps! If I'm onthe wrong track here, let me know and I'll try to go ramble off on another tangent...

[Brian Buege]

Originally posted by G Vanin:
Brian, thank you answering me in
https://coderanch.com/t/132992/Security/digital-encryption
I have more questions there basically abt what was the evolution in security and what will be next.
It is also very important for running the code from articles on Internet, since things change, there are articles 3 years old, and no explanation abt what they were/are using. A little bit of confusion.
For ex., IBM's security suite is evaluating since April 1999. It is interesting, if I read an article from 2000 (or even 1999) how may I get that suite from 2000, etc.?
How many your books are on promotion? Whether the CD is self-sufficient for reproducing examples without referring to Internet (I use JDK1.3.1, and access Internet through library or books' CDs)

Guennadii
Unfortunately, some security specifications and mechanisms are changing rapidly in the J2EE arena (especially in the area of web services).
However, some of them are starting to standardize and mature - Servlet / JSP / and EJB security. This is natural given the young age of the technology.
Your best bet is to keep up with forums like this one to stay informed about what's going on. Often, I learn more from my peers who actually build this stuff every day than the "experts." In this vein, writing and running test code and apps is also helpful to get ideas about what's possible, and within that set, what's practical.
Unfortunately, the book doesn't come with a CD
We've got a companion website (see link below) where you can download the complete source code from the book (along with ant build scripts), but unfortunately it requires you to download the tools used by the app separately (and some of these are pretty huge: Tomcat, Ant, the J2EE RI, etc). Also, the sample code is built to run on JDK 1.4 and above because one of the major changes from 1.3.1 to 1.4 was the integration of many important security features into the JDK (like JAAS, JCE, and so on).
If you're really super bandwidth constrained and live within the US, send me a private message and we can work out a solution to get you the stuff you need.
Hope this helps!

[Cathy Gorchkova]

Brian,
thank you for the answers. I also want to mention that security requirements are very likely to be changed. Very often when the development starts, the customer has not made decision about the authorization rules. This is very inconvenient, because the earlier we know the requirements, the safer system we will have. And relying on the power of EJB security is a risk in that sense. But, anyway I want to add one more rule to the security solutions: keep security logic and business logic orthogonal, if possible

[Doug Wang]

Welcome Brian!
I am also interested in such app-level security. How to secure web content and web application, which may reside on top of Domino server or WAS 4.0?

[Greg Ostravich]

Welcome Brian.
This book looks great!
It looks like it has examples of all sorts of great stuff from Applets to Server-Side.
Do you speak at Java User Groups?
It looks like you could do a full talk just on J2EE security.
[ October 24, 2002: Message edited by: Greg Ostravich ]

[Brian Buege]

Originally posted by Greg Ostravich:
Welcome Brian.
This book looks great!
It looks like it has examples of all sorts of great stuff from Applets to Server-Side.
Do you speak at Java User Groups?
It looks like you could do a full talk just on J2EE security.
[ October 24, 2002: Message edited by: Greg Ostravich ]

Greg-
Thanks for the nice post!
Not only could someone do a full talk just on J2EE security, they could write a whole book about it! Seriously though, there's a lot of stuff there to cover... Enough to fill a multi-day course easily.
I occasionlly speak to groups of people about security on the Java platform, but am not making the JUG circuit on a speaking tour or anything...
If you've got a specific need, shoot me a private message and we might be able to work something out.
Thanks for the post!