I have a Java Applet inserted on a simple HTML page located at http://localhost:8080/index.html:
<applet id="applet" code="SomeCode.class" archive="lib.jar" Width="1" Height="1"></applet>
The Java Applet has a method that looks similar to the code below:
public void PostStuffToServer() {
String server = "http://localhost:8080/PostHandler.ashx";
URL u = new URL(server);
URLConnection con = u.openConnection();
con.setDoOutput(true);
con.getOutputStream().write(stream.toByteArray());
con.connect();
}
When I execute the applet code from JavaScript like so:
obj = document.getElementById('applet');
obj.getClipboardImageURL();
I get the following error:
access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)
It seems like the Java code resolves the domain localhost to its equivalent IP address and therefore raises a cross domain security restrain. It works fine when I execute the same code from http://127.0.0.1:8080/index.html. The lib.jar file is signed.
Is there anyway to avoid this?
I encountered the same problem after installing Java 6 Update 22. My applet has been online for several years with no reported errors. When I downgrade to version 6 Update 21, everything works perfect. My applet is not signed.
SOLUTION:
It took me ha while to find the cause of the problem. Actually in my case there were several factors causing the security error. The problem was solved by the crossdomain.xml file. The Java applet tried to download the crossdomain file, failed, and did not even bother to display an error in the java console (debug level 5). Java tried to download the file from the ip adress of my domain (http://ip-address/crossdomain.xml), and not the root of my website (http://domain-name/crossdomain.xml). I guess it is better for the security aspect? I then had to configure the webserver to expose the crossdomainfile on the IP address. In my case I have removed the default website in ISS for security reasons, and had to create a new website. I then discovered that the java applet did not work with the crossdomain files i use with flash:
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-http-request-headers-from domain="*" headers="*"/>
<allow-access-from domain="*" />
</cross-domain-policy>
I had to remove the site-control and allow-http-request-headers-from nodes from the xml file in order to make the applet work.
I think I'm too late, but anyways... Guys you cannot believe how easy a solution this problem has.
The problem is that Java applet code called from JavaScript has only permissions that are the intersection of the JavaScript's code and your applet code - and somehow the JavaScript's permissions are seen as less, which results in this Exception.
Here is what I did: assume you have a function innocentFunc() that throws the java.net.SocketPermission exception, so your code is something like so:
String s = innocentFunc();
Now what you can do is to change it to something like so:
String s = AccessController.doPrivileged(
new PrivilegedAction<String>() {
public String run() {
return innocentFunc();
}
}
);
This AccessController call basically states to the Java Virtual Machine that the code it runs should not obey to the permissions from the call chain, but rather only the caller's permissions in its own.
Of course, you should do something like this only after making sure that this innocentFunc call can't do anything bad, even if invoked by malicious code.
Just to add, there's some stuff here which exactly matches the issue I've been getting - it specifically mentions controlling an applet with JavaScript.
http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html
The fix for CVE-2010-3560 could cause
certain Java applets running in the
new Java Plug-in to stop working if
they are embedded in web pages which
contain JavaScript that calls into
Java in order to perform actions which
require network security permissions.
These applets may fail with a network
security exception under some
circumstances if the name service
which resolved the original web page
URL host name does not return a
matching name as the result of a
reverse address lookup.
Their suggestion is to add a special crazy just-for-Java A record to the DNS, like:
10.11.12.13 foo.bar.com.auth.13.12.11.10.in-addr.arpa
I'm getting the same thing with Update 22, and not Update 21.
I'm using the TinyPlayer applet, which I'm controlling via JavaScript.
I'm loading audio files from the same domain (mydomain.example.com, IP 1.2.3.4) as the page the applet is loading on - everything is referenced using relative URLs.
When I try to play the audio, it fails to play and I get:
access denied (java.net.SocketPermission 1.2.3.4:80 connect,resolve)
Looking at the access logs, I get a request for crossdomain.xml right before this happens. But the catch is that Java isn't asking for a crossdomain.xml from
mydomain.example.com/crossdomain.xml
...but instead from
1.2.3.4/crossdomain.xml
The workaround that seems to work for me is to set up a virtual host that responds for the IP address 1.2.3.4, and give it a crossdomain.xml, so that Java can find the crossdomain.xml in the (wrong) place that it's looking for it.
I just tested with the contents:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
...but it's probably possible to make this more restrictive.
With that in there, the audio plays correctly.
IIRC, the JavaScript same-origin policy prevents access to same-host/different-port. The PlugIn's LiveConnect enforces this policy for localhost only.
See: http://download.oracle.com/javase/tutorial/deployment/applet/security.html
Unsigned applets can perform the following operations:
They can make network connections to the host they came from.
If Java does not resolve the originating system to localhost then the applet will not be able to open sockets.
I had the similar issue and it only occurs when I use the "localhost" as a part of the URL for the page with the applet. When I used the URL with the actual host name or IP address as a part of the URL, the problem didn't happen. I am not sure this is a defect for the Java plug-in...
For example when I used the URL like http://localhost:9080/app_id/appletPage the problem occurred but when I use the URL by using the actual IP or host name, the problem did not occur.
I don't think is possible to made the crossdomain.xml file more restrictive, at current time Java applets only support the (domain="*")
see here http://www.oracle.com/technetwork/java/javase/index-135519.html#CROSSDOMAINXML
You should check your virtual directory permissions.
Update from #Kristian above saved my day.
I had access denied (java.net.SocketPermission <server_ip>:<server port> connect,resolve) from an applet in a web application.
There had been change in our DNS, such that the IP of the load-balancer of the application server was not resolving to a name with domain. Therefore the suspected "cross-domain connection" from applet back to server was blocked.
I added crossdomain.xml with
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
to <tomcat-home>/webapps and checked that it is accessible with http://<server name>:<server port>/crossdomain.xml
Related
I have a Java web app which has a JSP page which has a couple c:import lines in it. The content referenced is on the same web server as the Java app, but is not bundled in the war file. My site has dns entries to allow for access to this app from a browser with a full name https://abc.123.def.com/app or a short name of just https://abc/app for users on our network.
If I access the jsp page via the alias https://abc/app I can get to the jsp page in the browser, but I get a server exception Problem accessing the absolute URL "https://abc//webfiles/included_file.html". java.net.SocketException: Connection reset on the page. But, when I access the jsp page via the fqdn like https://abc.123.def.com/app the include works perfectly, the jsp compiles, and all is well.
If I put the address of the file to be included in my browser it works with either short name or fqdn. So even though the error is saying the JSP can't find the file https://abc//webfiles/included_file.html I can plug that address in my browser and get to it fine. That's true from my separate user machine, or from a browser on the server itself. (Yes I see that double // there, it seems to not be a problem, it loads in the browser and loads fine as an include when using the fqdn).
I have good reason to believe the code is fine, this code worked fine on my old server which had JBoss 5. We've moved it to JBoss 6.4 on a new server and are now encountering this alias/short name include problem. I'm thinking it's some JBoss or IIS configuration issue. Of course we have lots of external links to this application utilizing the short name so simply using the fqdn will not work.
So IIS can serve up both the jsp via a fqdn or short name, it can also serve up the included_file path using the fqdn or short name. But Java for some reason can't see that included_file when using the short name, only the fqdn.
I've confirmed that the DNS suffix search list in the server's ipconfig includes the domain the site is in.
I'm not a JBoss config admin, and have no experience with IIS really, just a developer of the app, but I've been thrust into JBoss config/debugging out of desperation. Any help much appreciated.
I am having a problem running my PHP script to store login/registration details into MySQL Database on a Bluehost site.
S placed my PHP files in public_html/mobileapp/registration/ on the server. I have three files: config.php, db_connect.php and db_functions.php. (I used these same functions in local test using localhost and they worked fine). Here are my database connection details:
define('DB_USER', "user");
define('DB_PASSWORD', "password");
define('DB_DATABASE', "test");
define('DB_HOST', "server-name.com");
$con = mysql_connect(DB_HOST, DB_USER, DB_PASSWORD);
I can access these files from server-name.com/mobileapp/registration/ and I don't get an error. However, in my Android App/Java code I keep getting a 404 Page Not Found error, and see this in the error log for Bluehost server:
[Sun Jan 19 20:09:12 2014] [error] [client 184.65.36.11] Attempt to serve directory: /public_html/mobileapp/registration/
So my question is, what page is it not finding? The PHP Script?
Sorry if its an easy question but I can't figure it out. From some searching online the Attempt to server directory error has to do with the DirectoryIndex?
I am somewhat confused by this question. There are only a handful of things that are likely to occur when accessing a directory without a filename specified as an end result.
There is an existing permalink structure that will handle this.
You are served with a listing of the files in the directory (less options -indexes).
You will be served with the default page found through hierarchical traversing the DirectoryIndex directive.
You will be served a 403 error due to the a DirectoryIndex not found, options -indexes being present and there is no permalink structure to handle this request.
In your case, the scenario that you've described is only possible if there is a permalink structure that is specifically for non-mobile platforms.
Otherwise, inside of public_html/mobileapp/registration/ make an .htaccess file and then give it a directory index.
DirectoryIndex config.php index.php index.html
By default, this will serve config.php if it exists. if not, then it will serve index.php so on and so forth.
Escalate Hosting actually in depth tutorials for these exact kinds of issues.
Maybe not with bluehost, no. But they do have an extensive database of tutorials for different kinds of scripting for different types of OSs.
I have a URL shortener app (similar to tinyurl.com, bit.ly etc) which redirects to file:// URLs as well.
Internally, this is a Servlet based web-app, and all I do is, retrieve the targetURL and do a response.sendRedirect(targetURL) from the server side.
This works fine for file:// URLs too. However, recently, this has stopped working on Chrome. When I try to redirect to file://foo.txt (via a response.sendRedirect('file://foo.txt'), things simply fail (the Chrome debugger says "Cancelled").
Things work fine in FF and IE however. Any clues ?
I'd say this is a bad idea, and I'm glad at least chrome denies this (although I would suspect that other browsers would as well). It would be a pretty big security hole if you could instruct someone else's browser to open an arbitrary file.
Second, why would you want to do this? It would require that the user actually have this same file, at the same location on their computer. Seems like a pretty narrow use case. I tested your use case with bit.ly, and it you try to add a file:/// url there, it's regarded as an invalid URL and cannot be shortned.
Edit: There's a very good answer covering the same topic here. It references this useful resource about security restrictions with redirection.
You also specify that this is for an internal app. If you're attempting to do some sort of document sharing, I'd say you should look into dedicated systems for this. Another option is to extend your service with a "dropbox light", where your users can upload the file in question to a storage service, and you can generate a shortned url based on serving the file from your storage via regular http/https.
Why doesn't my Java Applet ask me for permission to start when I open HTML page with it on my localhost?
What is more, the applet starts but it cannot do anything. One of its duties is to connect with a webpage. But it doesn't. In console I can read:
java.security.AccessControlException: access denied (java.net.SocketPermission www.onet.pl:80 connect,resolve)
I guess there is a problem with the security settings of my Java.
It's some time since I programmed my last Applet, but I think you probably need to sign your jars.
The general policy for untrusted (i.e. not signed) applets is that they are only allowed (network-wise) to connect to the server they are loaded from. For applets loaded locally from the file system, this means they can connect localhost.
Asking the user for permission will only occur if either the applet is signed (but then the user gives permission for everything, if there is not a special security policy file) or the applet uses the JNLP functions to request some access (but this is only for local access) - for this, you would need the latest plugin (1.6.0_10 or later).
As Tom mentioned, a remote server can permit applets (and other dynamic web-content like JavaScript, Flash and so on) from other sites to access his server with a cross domain policy file. I'm not sure from which version on the Java plugin implements this, though.
I have a non-signed java applet interacting with the same host. Every time I click on an element in my page, the applet (which is a third part applet I have no control on) should load data from a URL. I say should, because for some files, I get
java.security.AccessControlException : access denied (java.util.PropertyPermission http.agent read)
and some other files are correctly loaded. All files are correctly readable and downloadable from the web server, and they are very simple text files.
I also found that, in some cases, files that previously returned the error are now loaded and continue to load, so it seems a cache is involved somehow.
Does any of you have an idea of what's going on here ? The behavior seems to be absolutely random, and I have no way of performing debug on this thing. Note: I used this applet to perform many other "single shot" file access, and it never gave me any problem. The only apparent difference I have is that now I do it "on-demand" via a javascript event.
What could be the cause, in the java of the applet or anywhere else ?
This is a bug in the Java VM. http://bugs.sun.com/view_bug.do?bug_id=6593830 This problem seems only occur with an applet. Java Web Start seems not affected.
Some http and https URL handlers use the http.agent to set the User-Agent header.
The correct way to handle this would be to make a copy of this particular system property available whether the permission is granted or not (as with a number of others). However, what has been done is to add it on to the permissions give to applets and JNLP apps. This means that if any code is loaded through another mechanism (say a call from JavaScript over LiveConnect), it wont have the permissions and there might be a failure. If the item is already cached, then there wont be a need to write a HTTP header, and therefore the property need not be read.
The applet is broken. It is trying to access the value of a property that the sandbox security rules say that it cannot.
Report this to the supplier of the applet, and ask for a bug fix or workaround.