Develop Reference

Safety of allowing custom CSS stylsheets for a JavaFX program

I am planning to allow users of my JavaFX program to select a custom CSS stylesheet, so that they can fully customize their UI layout and design.
I am wondering whether this is a safe idea as I am aware this can be dangerous for certain programs as it allows for people to inject code, though I can't seem to find any information on the possibility of using CSS for anything other than defining styles in JavaFX.

This is not a topic you need be concerned about.
Only read on if you are still concerned...
Ah, so there is no chance a user could use a stylesheet to somehow manipulate the program maliciously?
Well I would not say no chance. Software is complex and exploits can be unusual and unexpected.
But, the chance that it would happen and cause enough harm to the users of your app that it was worth investments by yourself in potential countermeasures is IMO, infinitesimal.
Your, and other’s, effort is best spent elsewhere. Use secure servers and packaging, use up to date frameworks and libraries, patch or redeploy for known exploits, etc.
A JavaFX app where you supply all the code and the app is installed as a package on a client machine is an inherently different attack surface than a web browser sourcing from many network locations that you do not control.
There is no server side cross site code injection without cross site servers. So trying to apply a website css attack (which is not normal by the way, most site attacks are scripting, phishing, server infected malware, etc) to a JavaFX client isn’t going to work.
If you are still concerned then do your own further research into the subject.

What is this hacker trying to do with this Java code?

In my server log of my web server, I've noticed a hacker trying this:
https://[domain name]/index.action?action:${%23a%3d(new%20java.lang.processbuilder(new%20java.lang.string[]{'sh','-c','id'})).start(),%23b%3d%23a.getinputstream(),%23c%3dnew%20java.io.inputstreamreader(%23b),%23d%3dnew%20java.io.bufferedreader(%23c),%23e%3dnew%20char[50000],%23d.read(%23e),%23matt%3d%23context.get(%27com.opensymphony.xwork2.dispatcher.httpservletresponse%27),%23matt.getwriter().println(%23e),%23matt.getwriter().flush(),%23matt.getwriter().close()}
Which URL decodes to this:
https://[domain name]/index.action?action:${#a=(new java.lang.processbuilder(new java.lang.string[]{'sh','-c','id'})).start(),#b=#a.getinputstream(),#c=new java.io.inputstreamreader(#b),#d=new java.io.bufferedreader(#c),#e=new char[50000],#d.read(#e),#matt=#context.get('com.opensymphony.xwork2.dispatcher.httpservletresponse'),#matt.getwriter().println(#e),#matt.getwriter().flush(),#matt.getwriter().close()}
My server doesn't use Java but I'm trying to understand what this hacker is trying to do here and why this could be a vulnerability. After all, I'm not just a developer but also need to know about how to protect a server, including servers not set up by me.
Code seems to start a new process and then tries to read data from the input stream. I'm assuming this is the input stream of the current web session.
As this attack is also tried over /login.action and various other URL's and different Java code, I am considering it to be potential dangerous. But I can't explain why this is dangerous.
The specific domain is under attack right now as the hacker tries to see if it's running WordPress or Magenta or other known systems and also tries several different attacks.
But what matters is this: the domain is currently under development and the owner still has to decide which development tools will be used. The choices are between Java and ASP-NET so is this attack dangerous if he chooses to pick Java?

It's trying to exploit a RCE vulnerability in Struts 2, I think this one. A bad one, Freemarker would execute any code inside ${} tags.
The Freemarker code starts a process to execute id to see if the server is running as root, giving full access to the box. Even a vulnerable Struts version might not be too bad here, since the attacker might not be interested unless you were root.
The attacker's program has a lot of these old vulnerabilities that would work on very unsafe servers, but even simple admin protocol will protect against these amateur attacks. You would only be vulnerable when running as root, using an old version of a software, opening up your db server to the internet with a weak or default password, etc.
Regardless of the technology you choose, there will be security issues and you need to follow the CVEs. For example a modern Java framework like Spring has a few, but remote code execution is quite rare, and that's what those attack programs look for.

Auto-update of Java application converted to a Windows installable

I found a lot of discussions around this point but speaking either of a Java program running from the jar (in this case it is easy to replace it) or a C# application (I do not have knowledge on C#).
I use a tool (install4j, ..) to generate an installable file for Windows from the jar of my java swing application. My product installed and running on Windows should be able to "auto-update" itself, so I must have a component in my application that checks online if a newer version was to download and put in place of the currently executing.
I do not know how my application is installed in Windows (where are put the files? in one place? ... ) So what can I do to replace the current version being run with a new version (probably from a new installable file télchargé in this case) ? what's the best way?
how can I hide the questions like "do you accept ...?" and keep the original configuration during the update?

The problem for me is that my client wants/does not necessarily install java
Use the Deployment Toolkit Script to ensure the client has a suitable minimum version of Java installed. Then deploy it using Java Web Start to provide auto-update. I realize you don't want to make the client install Java, but you might be making the client install Windows if you make an executable. You'll typically lose more users by forcing them to install Windows, than by forcing them to install Java.
Now, when I give this advice to some people, they say words to the effect:
But my client only uses Windows OS! It will never be run on Mac OS or Linux/Unix.
And to that I would point out:
OK fine, but it seems yo are trying to make a left-hand turn at a right turn only intersection. If you need to turn left, you should have done that 6 blocks back.
What I mean by that is: Windows has its own languages and IDEs specialized for Windows. Being a language designed for Windows would mean it has:
Better ways to delve into the OS. Java keeps its functionality to a core set of functions that can be reliably supported across all major platforms. Anything beyond that requires native code.
Faster development time for any GUI elements. Java GUIs need to be designed using layout managers which are harder to learn and not conducive to Drag-and-Drop GUI design, which can be much faster.
A Windows based language probably has a slew of APIs and tools for providing auto-update, or if not, more free or reasonably priced 3rd party APIs for that.
..there are customers who imposed to not install java..
There is something you don't seem to understand. The GNU Compiler for the JavaTM Programming Language compiles code to natives. That is the only way to 'turn a Java app. into an executable. The GNU Compiler..
..supports most of the 1.4 libraries plus some 1.5 additions.
It does not even claim to support all of Java 1.3.
There are other utilities to install Java apps. with a private JRE. It might seem the JRE installation is invisible to the average user. But the power user would not be fooled. E.G.
Look and Feel
A Swing based app. using the Native Pluggable Look and Feel might look 'much like' a Windows app., but many people can still tell the difference. Swing does particular components differently to native Windows components (most notably JFileChooser, but there are others), and although the rest of the components look a lot like Windows equivalents, they are not exactly the same. Even the AWT based FileDialog looks different to the Windows file dialog.
Security
If the user has a problem with their PC and decides to kill a misbehaving app. they might type the following command sequence to bring up the Task Manager: Ctrl Alt Del
Even most non-power users know that key combo.
Now, let's say I am a potential customer that thinks 'Java is insecure - I don't want it on my PC'. Your app. comes along, I look at the box, no mention of Java. Good so far. Look at the one or two screenshots of it on the back of the box - looks much like a Windows app., OK.
So I fork out $24.95 for it.
I get it back to the office, install it and run, thinking:
It has an odd feel to it, but I'm too busy now, I'll check it out later.
Then I go surfing off to the net, visit a site infected with malware, and that malware causes MS Word to lock up. So I go to kill MS Word in preparation for restarting it, but.. As I'm scrolling down the available processes I notice.. Java is running.
What the huh..?
I immediately kill every Java process and see.. your app. drop off screen.
Let's go even further to assume the Malware (that is still running) goes on to cause $2000 damage to my hardware & wipes the client database I spent 3 years putting together ($50,000 loss).
I would get on the phone immediately to my lawyer and take you to court, suing you for the sum total of $1,052,024.95.
Later, in court:
Judge: What is the million collars for?
Me: Mental stress, your honor. The defendant lied to me and now I have become paranoid. Since that malware was installed, I've lost my business, my home, my wife and my peace of mind. It has caused me to become deeply depressed and I am experiencing suicidal thoughts.
Who do you think the judge is going to side with? Do you really think you can prove that your app. was in no way responsible for the problem?
Sure, you can put a disclaimer on the box:
No claims of responsibility, use at own risk.
But there are any number of US states as well as other entire countries, that will toss that entire End User Lisense Agreement right out the window and hold you responsible.
What I'm getting at, is that you are taking a huge legal risk to pretend that a Java app. is anything but a Java app. So don't do that!

I am also very keen to know that, as per my knowledge, I deployed my application using JNLP (java network launch protocol) after signing your jar file, Client's jar itself replace with the newer version.
The confirmation question "Do you Accept" in JNLP is because of the certificate windows security and JVM certification didn't recognize that.
here is tutorial for JNLP
http://www.mkyong.com/java/java-web-start-jnlp-tutorial-unofficial-guide/

What is the best way to port a java desktop application to run in browser?

I'm a pretty skilled java programmer that has dabbled in web development but I find that I'm much better at doing desktop based stuff than I am at anything related to web development. I've been trying to find an easy way of porting some of my desktop apps to run in browser but can't seem to find anything. I guess what I'm looking for is something similar to an applet but they a largely unsupported and get more buggy by the day. Is there anything similar that would allow me to keep my desktop style mindset and still run in browser or should I just break down and rewrite the whole thing in rails or another common web platform.

Java WebStart has been mentioned by others - It's a technology that aids redistribution of Java applications that then have the full rights of desktop applications, but they also have auto-update support built in. It's basically a launcher that fetches a JAR from the internet and runs it as a desktop application. These don't run within the browser.
Applets are an old technology that can be embedded directly into the web-page. They are not buggy, but they have several security restrictions. Also, the support is steadily declining because of the amount of critical bugs found in the technology. Desktop users that want applet support typically don't have trouble ensuring it, however. Currently, both the Chrome and the Java platform itself issue a warning before an applet is allowed to run - and that assumes the Java Runtime Environment is already installed.
Google Web Toolkit is a framework that allows creating single-page applications in Java, which are then compiled to Javascript. GWT handles multiple things behind the scenes, including server-client communication, localisation and internationalisation, and its own layout engine.
When translating an existing application to GWT, you need to:
separate the code into a part that runs on the client and a part that runs on the server. The server does not have direct access to the user, and the client does not have direct access to the database. If your application does not use centralised storage, it probably can run entirely within the web browser. Since client-server communication happens over the internet, you should reduce it to the minimum.
translate the front-end to GWT widgets. Forget Swing or AWT - they are impossible to compile efficiently to Javascript.
remove dependency on other Java classes that the GWT does not know how to translate into Javascript in the client part of the application. A large part of java.util. is supported but none of javax. (as of Jan 2014). The GWT site hosts the list of supported Java classes. Also, Javascript's regexes are less powerful than those of Java. Lookbehinds, in particular, are not supported. The server-side is a full-blown Java environment, but remember - you want to reduce the server-client communication to the minimum.
But, the most common strategy is to code the client side directly in Javascript.
Javascript is a language very similar in syntax to C/C++ and Java. It uses curly braces to denote blocks of code, and it uses semicolons to separate statements (though Javascript features automatic semicolon insertion, sometimes it understands two lines as a single statement if the first line is not terminated by a semicolon. Its data types include numbers (double-precision floating point), strings, booleans, two types of null, plain objects (which are basically hash-maps [string -> x]), arrays (untyped and dynamically extensible), regexes and functions (named or anonymous), all of which have their own literal syntax.
When coding in Javascript, your mindset should be:
Javascript is single-threaded and event-driven. You don't have to worry about concurrency issues, but you cannot say "now wait for x" either. Since Your Java code should be event-driven as well, this should not be an issue.
Lots of things in Javascript are asynchronous. Want to know something from the user? You should paint a dialog, and attach event handlers to its components. Want to get the user's GPS position? Ask for permission, passing it an event handler for when the user decides if the permission should be granted, from which you ask for the position, which also takes an event handler as an argument. Talking to the server? Asynchronous. Do you want to display something before doing a long calculation? You have to actually wait a little before you start computing. Ecmascript 6 improves the syntax a lot, but it's not yet supported in modern browsers.
Browsers only let you do so much. Disk access? Only to a file or folder the user explicitly points to. Clipboard access? The only reliable way is copy/paste into a textbox. Talking to a foreign webserver? Only if that webserver explicitly lets you (and lot of them don't even know how to). Of course, "foreign" includes a different sub-domain, different port number or a different protocol (http:// or https://). Desktop notifications? Geolocation? Ask for permissions first. Java applets have comparable security restrictions, and for the very same reason.
In Java, everything is a class. In Javascript, you can enjoy bare functions without any class. A typical event handler is just an anonymous function that you pass as an argument to a library function. Also, you can have anonymous objects using a very conscise syntax. This makes Javascript code much denser than that of Java and with very few classes, if any. Object Oriented Programming is still possible in Javascript, but much less pronounced.
When layouting your display, you need to think in terms of HTML and CSS. The best approach is to modify only the document structure (adding/removing elements or HTML classes) using the Document Object Model (DOM), and leave all CSS in an external file. In any case, you need to know CSS enough to be able to layout your page. Modern browsers support canvas, but it has no built-in layouting engine - its closest Java relative is JCanvas - just a blank area where you can draw graphics primitives - or a WebGL canvas - where you can place triangles in a 3D space.
When designing your own API, you need to know which operations might need to be asynchronous. If they are, either take a function as an argument (a callback), or return an object that does (a promise).
Except for the this variable, Javascript is function-scoped and lexically scoped and has closures. If a variable exists in a surrounding scope, it can be read from and written to - even from within a function that is only defined in that scope and called much later. In Java, you can't close over non-final function-local variables.
However, you need to be careful about timing - don't think you can just assign to a variable within a callback and use it outside. When you try to use it, it won't have been assigned to yet. Many have tried to cheat the time this way, and failed.
When the user leaves your page, it's a game over. If you want to remember anything past that point, you need to store it somewhere, be it cookies (very little space, outdated API), localStorage (decent amount of space, not supported by very old browsers) or the server (lots of space, but talking to the server when your page is being shut down is tricky).
the DOM API is often criticised, but there are several frameworks and libraries that ease the usage of it, of which the most popular is jQuery, which also handles browser inconsistencies, improves the AJAX API, event delegation (you can't attach an event handler to an element that doesn't yet exist) and includes an animation engine (though modern CSS is almost as powerful and often easier to use).

I think java web start could help you
http://www.java.com/it/download/faq/java_webstart.xml

I suggest you to take a look at Java Web Start. It offers you a possibility to start your application software for the Java Platform directly from the Internet using a web browser.
For more details see: Java Web Start

Nowadays Web Start is not a good option since, the user needs to have JVM installed and with all the vulnerabilities buzz around Java is more difficult to convince users to download it. The latest versions of JDK 1.8+ include scripts to pack your application along the jvm runtime in just one installer: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/
For using your application in a browser like an applet, you can use Bck2Brwsr or TeaVM both can run java applications in a browser without Java Plugin. Bck2Brwsr also uses Java Plug in if it is available.
You can also use GWT to compile your Java application to JavaScript. Note: Swing is not supported.
Regards

How can I run untrusted code on behalf of third parties?

I want to create a Java-based website that will execute completely untrusted code from third parties. This third-party code will need to be able to access websites on the Internet, but not, for example, attempt a DoS on them.
I can choose the language, but if its obscure it will hurt adoption of the service I'm building.
Can anyone provide some pointers as to open source tools I should investigate?

Are you thinking of something like the Google App Engine? They do this for Java by providing a "sandbox" where the app has access only to carefully restricted subset of the Java API. You might take a look at their JRE White List for ideas. (They also provide other languages.)
Yahoo App Platform and Amazon Web Services provide similar functionality, but not in Java (which, from your tag, I assume is your main interest).

The key to do this with Java code, of course, is defining a SecurityManager and then carefully specifying the policy. Aside from that, you'd host on a Linux system and use a chroot jail -- or better yet, a chroot jail on a virtualized system.
You don't have to worry about someone using your single server to launch a DDOS attack, though, by definition!

First things first, you need to build an excellent jail or sandbox for your application. Virtualization can help, but even within a guest VM there are a lot of operations you wouldn't want your untrusted code to perform.
So investigate mandatory access control such as AppArmor, SElinux, TOMOYO, or SMACK. Any of these can lock down your server code to only a subset of allowed operations. There are patches available that can lock your application to a subset of system calls that is probably worth investigating as well. (Since I've worked on AppArmor for almost a decade, it's the tool I know best. It's also the tool I think best suited for the task, but SMACK's utter simplicity is really appealing.)
You can perform rate limiting at the firewall level to try to limit the amount of outside annoyances that your code hosting can cause. Rate limiting isn't the same as preventing :) but it gives you an opportunity to see obvious attempts to do stupid things in your logs.

Wait you all.
There is no reason for #sanity to look for 3rd party solutions, because Java already has a policy mechanism which allows untrusted code to access only a given subset of the Java API. See package java.security and SecurityManager. It allows you to say the JVM, "this app must have permission to access this stuff but not this other one".
But I think #sanity wants to grant a given permission to run untrusted code, without allowing it to do harmful things with that permission...

I'm not sure if I understand your question. But from what I understand you just need the user to be able to execute code (in a java-based website, however the code doesn't need to be java), in that case have you considered letting the user execute only client-side code (ie javascript)? This way the only machine they can harm is their own. You can read more about how other websites handle malicious code here and you can read about the few dangers of letting users execute JS here.