This might sound a bit weird (and even some think I'm wasting my time), but anyways, I'll try to ask here
I'm doing a master thesis on "Web Security: Web Content Security and Distribution". I have a totally signed and encrypted web application (all the .class files, configuration files, jar files, any files - are encrypted). Now I need to write a sort of "plugin" for tomcat, so that it decrypts the bytecodes before loading any file.
I've managed to extend the WebappClassLoader to decrypt all the class files in my webapp before loading them into the JVM. However, I'm having troubles implementing the same stuff for regular files, jsp files, and jar files.
Please please, any suggestions on the design (where would be the best place to decrypt, what tomcat classes would be the best override) or implementation are highly appreciated!
Maybe I need to implement a custom DirContext, extending org.apache.naming.resources.FileDirContext and storing my files decrypted in some temp location and virtually mapping them? But in this case the whole notion of "security" would have no point.
Or maybe I need to implement a ProxyDirContext, storing all my files on a different, secure proxy, and have a strong authentication (public-key auth, rsa?) between tomcat and the proxy and let tomcat fetch the files securely from the proxy?
Or just write a couple of custom plugins, as I did with the classLoader?
Hope to hear from you guys soon!
Btw, this is my first message, and hope it's not too informal
Welcome to the JavaRanch, Ikrom! You've logged into a website whose mascot is a mouldy moose head and worry about being too informal?
I'm fairly paranoid about security myself, having seen what a feeble job is done in most shops, but I mostly rely on keeping my servers secured at the machine and network levels. Haven't worried about anything lower.
My own approach would probably be to use an encrypted filesystem to hold critical resources. That way EVERYTHING is encrypted and I don't have to worry about patching classloaders and other resource access facilities right and left. And possibly missing one, which is one of the primary ways security schemes fail - if they're "opt-in" instead of "opt-out".
However, there's a very strong chance that at least one group of people at Sun or IBM has done stuff at the encypted-bytecode level, so if you haven't done in-depth research for that sort of study, I recommend doing so. I'm only amateur-paranoid myself. They're pros. Literally. That's how they make their living.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: May 28, 2010
Thanks for the reply. Really appreciate!
Well if it was for me, I would have it on an encrypted server, of course. But the thing is, that in this master thesis, an encrypted web application should be possible to deploy on any tomcat instance. For instance, imagine you have an encrypted .war package, and you want to install it on your client's machine. You cannot guarantee what machine they might be using, or what security measures they have taken, etc.
As for the Sun people doing bytecode-encryption, we already have a security encryption algorithm which I'm using. I just need to scrutinize the tomcat sources and find out which classes I may extend (possibly configurable parts, so that I dont have to recompile the whole tomcat project), so that I could just have my custom classes in a jar, and tomcat, using those could transparently load all the other stuff.
For now, I've decided to override FileDirContext and ProxyDirContext to load simple files, and it seems to be working. However, I'm not sure how to configure my context to use my custom ProxyDirContext.
I know that in the <Resources> subcontext I may point to an instance of DirContext, but that's where I have my custom FileDirContext.
Well, anyways, I'll try to do more debugging
Well, let's see. There's roughly 5 different kinds of classpath in Tomcat, but with luck, they can all devolve to a master classloader, That would take care of all resources fetched via the classpath, which would include class binaries, resource bundles, property files, and things like log4j config files.
Then there's WEB-INF access. Things like WEB-INF.xml, which Tomcat has to be able to read and parse, but aren't on the classpath.
Then there's general content. Things like web pages, client (java)scripts, downloadable applets (if any), stylesheets and so forth. Many of these files are basically read and copied out to the response output stream. In some cases, that's done by the default content handler, in others, it's done by application code.
And don't forget Tomcat's own files, especially the config, session, and work files. Including deployment descriptions (TOMCAT_HOME/conf/Catalina/localhost contexts).
I'll leave external files for you.
In some ways, the easiest thing to do would be to simply override java's internal I/O classes. Except that Java security means that you'd have to build a custom set runtime jars with signatures appropriate for the modified classes.