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.
Related
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)
I've read a lot of posts that ESAPI for Java can be used to prevent XSS by using Validator & Encoder. By the way, I am using Eclipse. I'm not using Maven nor Spring.
My questions are:
How to implement Java ESAPI for preventing XSS?
Are there other configurations needed aside from adding the ESAPI jar in the Build Path?
Thanks in advance for your answers.
Preventing XSS has some trickery to it. Validator lets you define input characters to accept/reject. But there's also the concept of differing contexts, and that's where the Encoder class comes in. There will be instances in your career where you'll be forced to accept characters as input that can be used to attack a browser.
The basic ESAPI implementation is like this: reject input characters According to whitelists. Use the Encoder implementations according to the output contexts... the trick part comes in when making decisions in regards to "Do I encode for HTML first, or for Javascript first? Either of those can have impacts on your application, and they need to be decided upon based on your application's needs. I've had applications that required users to input valid Javascript for example... and in those contexts, you need to be very careful.
Answering your part 2: Yes. ESAPI as by now you probably know, requires two properties files to be defined... validation.properties, and esapi.properties. You can compile them into the jarfile yourself (which, would require you to learn maven, so probably not...) or to specify at runtime, java locations, using the standard -Dmy.property syntax. The loading exceptions actually guide you to the right path.
how could I use ESAPI to check for unsafe input texts in web forms ? My application is built using struts 1.X, so I assume the validations should be added to Actions classes. Any samples / tutorials you recommend ? Thanks.
For something as specific as that there is not usually going to be great tutorials out.
Hopefully I am wrong about this, but I would have to suggest their wiki due to lack of good resources.
I was looking to find input validation for you... seems they don't even have that up themselves. I coudn't find any information on it either. The videos below might have it or I would email them if it provides no real good answer. They should be able to put you in the right direction... and if you do that do us all a favor and demand they update their wiki!
Email: jeff.williams%owasp.org#gtempaccount.com (Leader, owner)
Since that email doesn't look right though I would also check this one.
Email: kevin.w.wall#gmail.com (Owner, coder of crypto libs)
Their are these youtube video's that might help. They even mention that their are not a lot of good resources to teach you how to use ESAPI, but said they hope to fix that in these four videos.
http://www.youtube.com/watch?v=suphwAsb-To
http://www.youtube.com/watch?v=13O9RyjuB3o
http://www.youtube.com/watch?v=_B2kv2mSJhE
http://www.youtube.com/watch?v=mMW4fiUI5kQ
Hope it helped!
Validation of form fields normally is done in the ActionForm class. There are all input values available and all validations can be done there. A tutorial (one of many available) cna be found here Struts form validation and error handling. More can be found using google (struts validation).
I have been working with the ESAPI library for a few months now. The library cannot do too much to validate your input, since it cannot know what the input could be or should be. That is especially true when you factor in all the international characters that could be in legitimate user input.
We use the ESAPI library mostly for encoding server output. The purpose is to send user (or possible attacker) input back to the browser in such a way that it cannot be executed. Instead HTML or JavaScript interprets it as text only.
That is why both my validation and ESAPI's encoding of user input are important for security.
In Android applications, resources are specified in xml documents, which automatically are built into the R class, readily accessible within the source code as strongly typed.
Is there any way I could use a similar approach for a regular Java desktop application?
What I'd like to accomplish, is both the removal of strings from the code (as a separation of "layers", more or less) and to make it easy to add support for localization, by simply telling the program to choose the xml file corresponding to the desired language.
I've googled around a bit, but the things I'm looking for seem to be drowning in results about parsing or outputting xml, rather than tools utilizing xml to generate code.
Eclipse's message bundle implementation (used by plugins for example) integrates with the Externalize Strings feature and generates both a static class and a resource properties file for your strings:
http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html
For this integration to work Eclipse needs to see org.eclipse.osgi.util.NLS on the class path. From memory, the dependencies of the libraries it was available in were a little tricky for the project I used this approach in, so I just got the source and have it as a stand-alone class in my core module (see the comments for more on that).
It provides the type safety you're looking for and the IDE features save a lot of time. I've found no downsides to the approach so far.
Edit: this is actually what ghostbust555 mentioned in the comments, but not clear in that article that this isn't limited to Eclipse plugins and you refer to your resources via static members of a messages class.
I haven't seen any mention of others using this approach with their own applications, but to me it makes complete sense given the IDE integration and type safety.
I'm not sure if this is what you mean but check out internationalization- http://netbeans.org/kb/docs/java/gui-automatic-i18n.html
Are you looking for something that parses XML files and generates Java instances of similar "struct-like" objects, like JAXP, and JAXB?
I came across ResGen which, given resource bundle XML files generates Java files that can be used to access the resources in a type-safe way.
http://eigenbase.sourceforge.net/resgen/
We need to add anti-XSS support in our Struts application. Most specifically the architect requires that all user input must be "sanitized" before storing in DB. As I don't want to reinvent the square wheel, which Java library can I use for this ? And where to put it ? Ideally it should be configurable (which input fields to check, not all of them in request) and fast. My first thought is Struts Validator.
Thanks in advance
Lluis
I recommend you look into OWASP's ESAPI project. It has been under development for over a year, and is approaching its 2.0 release.
For escaping values stored in the database, check out the Encoder.encodeForSQL() method (reference implementation).
For input validation, check out the Validator (reference implementation).
Note: my understanding is that the functionality provided by older projects such as Stinger and CSRFGuard is being included in ESAPI.
If you seach google for XSS Java Filter, you'll come up with many open source solutions, such as this one.
You could also look at the OWASP validation project.