All..
I am hoping someone who can confirm for me, what I read and what I have observed, regarding the Tomcat Java applet server?
I have Linux server running Tomcat (I built two new ones, but based the configuration off the previous two that were present when I came on the job). I am fairly new to Tomcat servers -vs- web servers.
When a client connects to the Tomcat server address...
A static web page is served, with a link to a java applet:
When they click a link, Tomcat serves up an applet to the browser.
When the applet is served:
All connections and traffic that the applet creates is tunneled back to the Tomcat server? (pretty sure this is happening, and what is supposed to happen)
All connections connect through the client network connection? (All tests I have done can not confirm this.)
Is the tunneling a reason why Tomcat is used over just serving up the Java applet via a Apache server?
We have a SSL secure connection with certificates setup to allow https connections to the Tomcat server, and I am assuming all the data between Tomcat server and the applet is encrypted because of this?
Thanks!
There's no good reason from what you've told us so far to use Tomcat over a lighter httpd such as apache or nginx - if it's really just serving a Java applet and web page (static content). The former two are application servers, and as that implies that means a little more than just static content - although it will serve static content just fine, too. But there is no "Default" integration between the two technologies. In particular - your data will not be encrypted by default, you've got to make sure that your applet makes secure request. Serving the applet offer SSL only protects the connection that actually serves the applet, not subsequent ones - though there's no reason these shouldn't also go through the same SSL endpoint, the applet has to initiate that, there's nothing "magical" going on.
Here's a good article on when you'd want to use one or the other.
As for the other part - there is a security model that comes with an applet. By default, the applet will only be able to make connections back to the server from which it came - this is to prevent certain kinds of "cross-site" attacks which were seen in the past. These days, different sites interoperating are more common so there are many technologies you could use to for that, if you need to - but applets are largely considered outdated and not widely used - but your end user may also configure applets to get around this default policy.
Here is information about the appliet security model, including network restrictions.
Related
So I have two Java applications, a server and a client. They are simple programs no GUI elements just console applications. They work just fine running on my machine, and I have a client version that can even connect to the server via the internet.
Instead of hosting the Server on my local machine I would like to host it from a site like Openshift. Which I already have a HTML site up at using Tomcat 7. I would also like to be able to go to a page on the web server and have that page act as the client program.
I want to embedded the client program into the web server but....
How do I make the connection between the two servers? Pretty much how do I get the Web Page to reach out to the other server and make the connection(I am using sockets)? Do I need to be using a servlet, JSP, or something like Jquery?
If you feel like you need to see either the server program or the client let me know and I will post them.
I would like to host a client version on the web page.
Your JSP or servlet would be the client in that case, it would open a socket to the server process. Have a look at HttpServlet and its doGet method, this is basically what you would implement, and where you would place much of your client code, like opening a socket to your server process and returning data. You'll find tons of examples on the internet, see for instance
how to write hello world servlet Example
Browsing to the servlet's URL will invoke the doGet method and execute your client code. It should be stateless though, i.e. take whatever parameters are in the HttpServletRequest, do its thing based on that, and return as soon as possible. If your clients need to retain their connection to the server process, it will be a different story, and you may need for instance websockets (I have insufficient experience with that but it would sound like a good fit in that case).
I am trying to block certain websites using a web application. So, when a I type a url suppose "http://www.google.com" it should first check whether google is blocked by my application or not. If not open the website otherwise reject the browser request to open it. I am unable to find a way to capture all HTTP request from browser so that I can process it.
I Know proxies are the most suitable option but is there any alternative solution to this. After some searching I found a library - jpcap (a network packet capture library) and I was wondering if this could help me or not?
What you are trying to create is a proxy-server.
You have to configure the browser to go through the proxy, then you can deny websites, reroute them etc.
There are many proxies already there (open source and commercial) that offer what you want.
For example: Squid http://www.squid-cache.org/
See Wikipedia description of a proxy here: https://en.wikipedia.org/wiki/Proxy_server
Many firewall products offer the service of a transparent proxy, redirecting all http/https traffic going through the firewall into a proxy server. It seems, you have a direct connection but your packages are really filtered. Aka transparent proxy.
If your assignment does not allow this context, you need to check the assignment again, if you really got the scope of filtering right.
You cannot take over the browser's ip communication from a servlet or servlet filter. Using a (servlet) filter, you can only filter requests directed to your application. One step above, using an application server valve (Tomcat uses this term, others may use a different one), you can only filter requests directed at that server. One step above (or below) your application server is the physical server and the network it is running in.
If your client does not share the same network as your server, you can't even apply transparent proxy to it. Since browsers are running on the client computer, most clients in the world do not share the same network zone as the server.
It just does not work as you expect it.
Where should we get started setting up single sign on for a single Windows (Active Directory) domain with a Java web application?
What I DON'T mean by single sign on is that the user signs into one Java website explicitly, and then stays signed in for other Websphere sites.
We're looking for something that will effectively "detect" the Windows user that is currently logged in on the client browser's PC (Windows XP, soon to be Windows 7), and supply that user's login name to the Java WebSphere application.
The software is Java/WebSphere, with a Flex front end which we can put in a JSP if needed. (Currently it's just an html page, which is preferrable. GraniteDS is used for remoting.)
The server is NOT a Windows server, so Waffle is not an option. Research so far seems to indicate that we need to use something called SPNEGO, but I've yet to find information about what the Java developer's role is when setting it up.
I'd be interested in both server-side (WebSphere) config & requirements as well as Java application configuration & code required (this seems to be difficult to locate even via Google).
The Java application developer only needs to configure the Web application to rely on authentication from the container (Websphere Application Server).
The rest is all up to the configuration of the container to provide the right credentials, etc. The WAS administrator would do something like this for SPNEGO/Kerboros: http://www.redbooks.ibm.com/abstracts/sg247771.html. Further, browser configuration would need to add the site hosted by Websphere to the domains allowed within the Intranet zone and the security mechanism.
A much better 'hack' might be (not tested) to put Websphere behind IIS as in http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing.
In all cases, you will still need to figure out how to get Flex to get the browser to do Windows NTLM authentiation, or for it to so itself. Best of luck.
I would like to know if there is an easy (or hard) way to spy the secure sockets from a java applet ? (without having the source code)
The goal here is to know exactly what for informations send an (very good obfuscated) applet.
I thought i can simply compile myself a modified java version with a log function but the full source code from java is not available for security reasons...
Set up a proxy server with a security certificate that the applet accepts. Afterwards, you just have to configure your browser to use that proxy and the applet should use the same config.
See Does https prevent man in the middle attacks by proxy server? for how it works technically.
Some things you will need: A proxy than can act as a web server and which is probably reachable with the name of the real server from your browser. You will need to create a valid certificate for this combination which isn't trivial unless the applet is configured to accept certificates from untrusted sources (no CA authority will issue a certificate for, say, "google.com" so that you can feed that to your proxy).
Googling for "man in the middle attack ssl proxy" turns up many links that should be useful.
This article seems to describe an out-of-the-box solution: Understanding Man-In-The-Middle Attacks - Part 4: SSL Hijacking
It doesn't mention applets but Fiddler might fit the bill (from Capturing HTTPS traffic in the clear?)
Just set -Djavax.net.debug=all in the JVM properties. You will get all kinds of output from different layers of the network stack, including the pre-encrypted SSL traffic.
If you're talking about SSL, it wouldn't be secure if that was possible, and it is secure, so it isn't.
I'm connection to web servers using HttpURLConnection.
Is there a way to ask to the server to send the language that the page is built (PHP, Java, Python, Ruby, etc) and the web server that is running (Apache, ISS, etc.)?
As web servers just deliver whatever the end content is (html/javascript/a mp3 -- whatever), they are only obligated to tell you what the content they are giving you is, not how they created it. Often you will find a Server header that tells you the Apache/PHP version, but most people see that as as security vulnerability and a lot of people will disable it.
The two headers you'll want to look for are Server and X-Powered-By.
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
As far as I know, no servers have any kind of built in API for asking what the server is. If you own the server you're wondering this about, you could of course make an API with JSP or PHP or whatever. I'm assuming that's not the case though or you'd already know :).