We Keep Coding

Is OWASP Java Encoder Project enough to prevent reflected XSS?

I've been reading articles about reflected XSS prevention. From what I understand, output encoding is the primary way to deal with reflected XSS. Some tools available would be the OWASP Java Encoder project and OWASP ESAPI. I have a java/JSP web application. I'm not sure if input validation should be also performed on the .jsp file when there is already input validation in the corresponding .java file. So I have the following questions:
Is OWASP Java Encoder project sufficient to prevent reflected XSS?
Do I need to do input validation on the .jsp file?
If 2. is a yes, would creating my own input validation functions or using the ESAPI Validator class be better?
If I have to use ESAPI, it means that I need to add ESAPI.properties and validation.properties. Given my project is an Ant project, where do I add these files?
Thanks in advance.

I will address your individual questions in a moment, but first I want to suggest that you thoroughly read the OWASP Cross-Site Scripting Prevention Cheat Sheet. That will cover all the basics that you need to know, including discussions about defense-in-depth approaches. Now on to your specific questions.
Is OWASP Java Encoder project sufficient to prevent reflected XSS? Answer: If used correctly (that is you use the correct contextual encoder), for Java/JSPs, either the OWASP Java Encoder project or the ESAPI Encoder should be sufficient to prevent XSS in all but a few edge cases. Those edge cases are would including DOM-based XSS (so, technically, not 'reflected', I know) or cases where you have requirements that some HTML mark-up be allowed. (E.g., maybe in collecting user comments.) In those cases, you will want to also leverage HTML sanitizers such as the OWASP AntiSamy project or the OWASP Java HTML Sanitizer project.
Do I need to do input validation on the .jsp file? Answer: It is not absolutely necessary (assuming you use the output encoding correctly), but it wouldn't hurt. It is considered a part of the defense-in-depth strategy, especially in those tricky areas where mixed-encoding contexts are involved, such as rendering a URL in JavaScript. Along with input validation, Content-Security-Policy headers should are also strongly recommended, although CSPs are much easier to use in a green-field approach than in legacy applications.
If 2. is a yes, would creating my own input validation functions or using the ESAPI Validator class be better? Answer: In most cases you can probably do your own allow-list validation based on some simple regular expression matching. (Do not write the validation as block-lists though.) ESAPI Validation is probably more than you need and even as the ESAPI project co-lead, I personally wouldn't recommend it unless you are planning to use ESAPI for some other purpose (because it drags in a lot of transitive dependencies).
If I have to use ESAPI, it means that I need to add ESAPI.properties and validation.properties. Given my project is an Ant project, where do I add these files? Answer: You don''t have to use ESAPI, but if you do, where the ESAPI.properties and Validation.properties files go is not relevant to whether you use Ant or Maven or Gradle, etc. Look at class Javadoc for the ESAPI class org.owasp.esapi.reference.DefaultSecurityConfiguration for details of how the ESAPI.properties and Validation.properties files are located.
Hope that helps answer your questions.

Is there a validation in ESAPI library that can make sure the CWE-93 vulnerability does not come up in veracode SAST scan?

I did SAST scan of my code on Veracode platform and I got this vulnerability in Java mail functionality which I am using to send mails from my application. The following is the vulnerability that is coming - Improper Neutralization of CRLF Sequences('CRLF Injection') (CWE ID 93).
message.setSubject(subjectOfEmail);
I have heard that we can use ESAPI library but I cannot find an appropriate validation function for this. Someone please help me re-mediate this issue so that is does not come up in the scan again.

Check out this page on the Veracode Help Centre that lists out the validation libraries that will remediate certain flaw classes:
https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/y52kZojXR27Y8XY51KtvvA
There are a whole slew of ESAPI libraries that will remediate CWSE 93 flaws, including
org.owasp.esapi.Encoder.encodeForHTML

If all you are looking to prevent in this case is header injection issue (which is what CWE ID 93 is related to), then look at ESAPI's org.owasp.esapi.StringUtilities class. In particular the static method stripControls() is probably exactly what you need. Using Encoder.encodeForHTML() will probably encode for more than what you want since it assumes an HTML context. (Of course, you may want that if you are concerned about preventing XSS on the Subject headers of certain web email clients. Generally those clients should already have that protection built into them though, so if you encode it, it could end up being encoded twice and not render correctly.)
Keep in mind that if you use StringUtilities.stripControls(), that you Veracode's SAST engine may still flag your code for the CWE though as I am not sure that it recognizes that class' method as removing the taint flag in this particular case. (But you can always mention it as a mitigation comment.)

Use ESAPI's decodeForHTML() method like below sample.
ESAPI.encoder().decodeForHTML(subjectOfEmail)

What's the purpose of Properties.loadFromXML() and Properties.storeToXML() methods?

I am designing a simple library that deals with properties files.
I noticed that since JRE 1.5 the class Properties defines methods like:
public synchronized void loadFromXML(InputStream in)
public void storeToXML(OutputStream os, String comment)
I am questioning the fact that this is a real enhancement in the API of this class. Properties files have been, since JRE 1.5 text based files, and the newly introduced XML format is not adding anything to the functionalities, other than the possibility to use a different forma which is
more verbose
more complex (to understand, to change, to parse)
more inefficient (it uses dom internally to parse into an hastable: it consumes more memory, it requires helper classes in the implementation, and most likely is also slower)
more fragile (xml requires escaping of characters <>&"' while properties only need to escape backslashes, since it also supports Java backslash escaping)
it breaks backward compatibility of the programs using it, since users running JDK 1.4 won't be able to read xml properties. (ok, who cares...)
So I fail to understand the reason behind why engineers in Sun added this feature.
The question is:
Does anybody finds some advantage of using an XML-based properties files over a traditional text based one?
I need to evaluate this problem, since I don't want to add a useless feature to my simple library that I cited before.
Did you ever used an XML-based properties file over a Java Properties file? And why?
Note: same question can be made for Log4J xml file format, but at least Log4J xml format adds nesting ability and some sort of syntax which has some meaning, and I do understand that. But with this xml format for properties, I don't.

If staying within the Java environment, using a Java properties file works great. Even if you expect other programming languages to interact with your library, you'll probably be ok with a 'regular' properties file. However, for hierarchical data, XML is the standard. The reason you may want to support this change, and possibly the reason why Sun included it, is that other programming languages have extensive libraries for parsing XML files for hierarchical data.
The reason I'm answering is because I have actually used this feature before! But not for a great reason. In one program I'm working on now, I've found it easiest to keep a set of data in a properties object and I output the object to XML so that it can later be read by Python. At the moment, the data is further manipulated in a Python script and more children are added to the XML file. Without being able to output easily to XML, this would be a little more painful.
If I had the time, I wouldn't bother outputting to XML though. The main reason I'm using the Python code that takes in the XML is because somebody else wrote it and I'm temporarily using it until I have the time to reevaluate that section of my program and re-code it.
So there's a reason for using the XML! It isn't a good one, but it's a reason.
I imagine there are other cases like this where having the properties outputted as an XML aids in compatibility with other languages, since most languages have a robust XML parsing library and it makes it easier to manipulate hierarchical data. And in scientific programming, it seems you rarely get the luxury of sticking to one language.

Some points:
You can use standard, cross-platform tools to create it
You don't need to worry about peculiarities of escaping and character encoding, as you can use standard tools, which actually makes it more robust. The old properties file format is poorly specified.
Standard, cross-platform tools can use the data.
For most applications Java is used in, a bit of start up time isn't going to make much difference (particularly given the start up time of the rest of the system).
Java SE 1.6 is a bout to complete its end-of-life. Pre-1.5 isn't particularly relevant for Java SE (or EE).
But no, I've never seen it actually used.

Afaik the XML format is encouraged because of the encoding: (by specs) strictly ASCII for plain files (may I suggest you http://mojo.codehaus.org/native2ascii-maven-plugin/), UTF-8 (default) for XML property files as stated in http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Properties.html
edit: I beg your pardon: ISO-8859-1 for property plain files

How to evaluate user expressions in a sandbox

I want my app to evaluate an expression from an untrusted user, that I'll be reading from a JSON file. Such as:
value = "(getTime() == 60) AND isFoo('bar')"
I've found many threads about this here on StackOverflow. Usually recommending using Java's own ScriptEngine class, which can read JavaScript. Or recommending the user to either use an existing library such as JEXL, MVEL, or any other from this list:
http://java-source.net/open-source/expression-languages
But they all seem to rely on a trusted user (ex.: a configuration file you write yourself and want to do some scripting in it). But in my case, I want my expression evaluation to run in a secure sandbox. So the user cannot do something as simple as:
value = "while(true)" // or
value = "new java.io.File(\"R:/t.txt\").delete()" // this works on MVEL
And lock up my app, or access unwanted resources.
1) So are any of those existing libraries able to be easily configured so that it can run on a safe box? By 'easily', I mean high level configuration API that would faster for me to use than to write my own expression evaluator. After doing a little bit of my own research, both JEXL and MVEL seem to be out.
2) Or is there an existing expression language that is extremely simple so that it cannot be exploited by an untrusted user? All the ones I found are very complex, and implement things like loops, import statements etc. All I need is to parse math, logic operators and my own defined variables and methods. Anything beyond that is outside of my scope.
3) If the only solution is to write my own expression evaluator, then where can I find some guidance on how to write a consistent security model? I'm new to this, and have no idea of what are the common tricks used for code injection. Which is why I wanted avoid having to write this on my own.

I could recommend embedding Rhino, enabling the user to write javascript. It fits your criteria in (2) perfectly being a java library that enables you to run javascript (or run java from javascript).
You set up a context and the user only has access to what you put in the context or make accessible from it. The javascript expressions can be as simple as the simplest case you show above, or can get as complex as they need to. Embedding Rhino and exposing a limited set of objects was a great way to enable all sorts of user scripting in a past project and that was some years ago, Rhino is quite mature now.
You've also got the advantage that if your problem requires it, you may well be able to set it up so that the same expressions will happily run client or server side.
More information on embedding Rhino to accomplish what you need at http://www.mozilla.org/rhino/tutorial.html#runScript

Localizing a JSF 1.2 application with UTF-8 resources

(WARNING: this is my first java application, coming from .NET, so don't bash me if I write too much garbage)
I'm developing a simple JSF 1.2 web application which should support Russian, Chinese, and other languages outside ISO 8859-1, which is automatically used in Properties.load().
Is there a way to use the Properties loaded from XML files, with Properties.loadFromXml(), inside JSF, without writing too much code?
I know there are alternative ways to do so (writing my own loader, escaping the characters...), but I'd really love to find a simple solution, and I don't see it in all the forums I checked.
Thanks in advance for any help

I think the most widely used approach is to encode your .properties files with unicode escape sequences. This can easily be done with the AnyEdit plugin for Eclipse.
The problem is that ResourceBundle uses the Properties(inputStream) constructor, rather than Properties(reader).
You can use your own LoadBundle component instead of f:loadBundle to overcome this, but you'll have to:
extend the original one
define it as custom component (facelets and/or jsp)
define a new ResourceBundle implementation
instantiate it, using new InputStreamReader(classloader.getResourceAsStream(..))