We Keep Coding

Best way to block XSS injection having decode and getParameter

I have a lot of this type of old code in my Liferay app :
String code = request.getParameter("code");
It seems that in Liferay there is a "HtmlUtil.escape" function, so I assume I can use it like :
String code = HtmlUtil.escapeAttribute(request.getParameter("code"));
Is this the safest way to do it ?
I also have another simple java project :
public void buildParams(String[] items, HttpServletRequest request) throws Exception {
typeRequest = URLDecoder.decode(request.getParameter(ReportUtil.PARAMETER_REQUEST_TYPE));
countEx = URLDecoder.decode(request.getParameter(ReportUtil.PARAMETER_COUNT));
Map<String, String> parametres = ReportGenerator.decodeMap(request.getParameter("parameters"), String.class);
...
What is the classic way to block injection without the Liferay "HtmlUtil.escape" function here ?

HtmlUtil.escape allows you to escape certain text so that it is safe to use in an HTML context.
As a drop in replacement you can use the different methods provided by the Apache commons-text library StringEscapeUtils class, especially the escapeXml** ones.
Please, in any way, consider read the documentation created by OWASP about Cross Site Scripting prevention.
It provides great insights about the different related types of attacks involved in the term, and how you can prevent or mitigate everyone of them.
The documentation provides references to several related libraries like the OWASP Java Encoder project and OWASP Java Html Sanitizer.
The first project gives you some examples for handling untrusted content in different scenarios.
The second one allows you for a more structured HTML processing based on user defined policies. Please, consider review the different examples provided in the Github repository.
If you require a full fledged prevention framework, you can use in your application the artifacts provided for ESAPI project, from OWASP as well.
There is nothing wrong with escaping the information you are receiving with classes like HtmtUtil in your server side code but, as you can see in the different examples provided, in order to prevent XSS related attacks, it is typical to perform some kind of encoding/escaping when outputting the HTML code fragment instead, when you are providing the information to your client: the important thing is to prevent that somebody may, for example, introduce a terminal </textarea> tag that terminates a textarea and then a <script>...</script> block with some malicious code next:
</textarea><script>alert('hello')</script>
The kind of server side processing you are describing is more frequently used when you want to prevent other types of code injection. Please, consider read this other documentation again from the OWASP website, I think it could be useful.

Spring MVC Validating all parameters in POST/PUT methods in controllers

I have plenty of controllers and I want to validate all of parameters submitted in forms against XSS attacks. Instead securing each controller separately I would like to have one component that works as interceptor for all submitted forms and checks the parameters submitted.
I wrote a Filter that uses antisamy for correcting values of parameters but it works too good. I mean it escapes everything, even rich content that should not be escaped.
Sanitizing user inputs with Spring MVC framework
https://jeevanpatil.wordpress.com/2011/07/22/prevention_of_xss/
Therefre I need some solution to escape concrete parameters in controlers, do u know any solution ? I plan to create annotation next to parameters in every method in controller, for example #XSSEscaped, then only those parameters would be escaped.

HTML encoding at the time of input can corrupt the data. It may still not be secure because data inserted into an attribute, stylesheet, or script could still execute code even with HTML encoding. It may not cover all the data on the page as some values might not have come through the controller, or could have been modified since then.
There are many ways to bypass input filters (see XSS Filter evasion cheatsheet). The RequestWrapper in the linked answer for example filters out eval(), but pass in e<script></script>val() instead and you get eval() as output again. Fix that, then they'll be something else.
HTML encoding is the the responsibility of the view layer. This is where you can make sure all the data used on the page is encoded appropriately for the context where it's used. XSS is prevented by following the rules at the Cross Site Scripting Prevention Cheatsheet. Templating systems like Thymeleaf will do HTML encoding by default of its values.

What is difference b/w org.owasp.esapi.Encoder.encodeForHTML and org.owasp.esapi.Encoder.encodeForJavaScript methods

I Know, we can use encodeForHTML for HTMl and encodeForJavascript for javaScript.
There is a Cross-Site Scripting: "Reflected fortify scan problem" in my code
String errorDesc = HttpServletRequest.getParameter("error_description");
I have to validate this using Encoder but I am confused to use which one should i use between them. As we do not know the return type of HttpServletRequest.getParameter.
1. org.owasp.esapi.Encoder.encodeForHTML
2. org.owasp.esapi.Encoder.encodeForJavaScript

What we have here dear asker is a rather common misunderstanding about the differences between output encoding--which is what you're working with when you look at the Encoder calls, and input validation, which is a completely separate operation that has little to do with the Encoder class.
The Encoder methods you're dealing with here are to be used only when you're presenting data to a user, and only for the correct context. For example, if the application is a "Single Page Application" (SPA) then very likely you're just going to want to ensure that the output is encoded for JavaScript as the client-facing framework will almost certainly be JavaScript.
If you were using an older style of application, then you would encode for HTML anytime you were going to place data between <some_tag> data </some_tag>.
XSS requires you to understand one thing for every variable in your application: Its data flow, from when the value is generated (Server, User, DB, etc.) and understand all of the transformations it might undergo as it traverses to the user and back to the system. If the value starts in the browser, it will enter into some kind of Controller on the backend, and before you process the value you'll whitelist validate it--ESAPI has a validator class--and then if it passes validation you'll ensure that the database will only treat it as data (PreparedStatement, or through use of an ORM framework's utilities.) Best practice is to
Canonicalize the data
Validate against the canonicalized value
If valid, discard the canonicalized value and store the original data
If used properly, the Validator class is defaulted to help you do this.
The methods you're asking about in this question are for instances where user input is being sent back to the browser, either from the database or from a previous request in your session that hasn't yet been persisted.

The main difference is how the output encoding is done. Encoder.encodeForHTML() does HTML entity encoding via the org.owasp.esapi.codecs.HTMLEntityCodec class, whereas Encoder.encodeForJavaScript() uses JavaScript's backslash encoding via org.owasp.esapi.codecs.JavaScriptCodec.
Which one you choose depends on the context of how your "error_description" parameter will be rendered in your application. If it is rendered between HTML tags, use encodeForHTML(), if you are rendering it in purely a JavaScript context, use encodeForJavaScript(). Refer to https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html for a more thorough explanation of all this.

How to C14N, Whitelist validation user input

I am currently trying to create a safe login that only deals with username and passwords.
I've been reading about ways to prevent injection attacks, and C14N / Whitelist validation seems like a common practice. However, I can't figure out exactly how to canonicalize then validate user input.
My login is in a JSP page, which then processes the input through an httpservlet and checks if the user input matches the one in the database.
I have a few questions :
How do I canonicalize? Is there existing tools for me to use or do I have to create my own version?
Where do I canonicalize and validate - in the JSP page or Java servlet?
Do I need to whitelist validate, or is sanitization good enough for user input (usrname/pw)?
Are there tutorials / examples of the actual implementation so I can further understand this?
Theoretically, it all makes sense. But all the web docs that I am viewing don't explain how to do it.

Which is more secured and why JSON or XML

I want to implement web services in Java EE whose response is going to be a JSON. This is my first attempt for doing so but before that I just want to know are there any security issues with JSON because everywhere in many blogs I read it is mentioned Like "JSON is not secured in comparison to XML". JSON has several advantages like easy to use, greater speed.
So anyone can explain me the truth whether JSON is really unsecured or not. If so why it is. Please explain with an example.
There are couple old articles on the topic:
JSON vs XML - 2006
concerns about eval
JSON is not as safe as people think it is
Claims only protection for non-public data available via JSON is to use unique urls.
CSRF (Cross Site Request Fogery) - 2007
Array hack highjacking parsing of JavaScript by browser.

This is nonsense. Both, json and xml are just methods for representation of structured data. None of them could be considered as "more secured" or "less secured".

There is no difference security wise between JSON and XML. The "insecurities" referred to by people regarding JSON have to do with the way JSON can (but should never be) parsed in Javascript.
JSON is based on the syntax for coding objects in javascript, so evaluating a JSON result in javascript returns a valid object.
This may open JSON to a variety of javascript injection exploits.
The way to resolve this: don't use eval() to parse JSON in javascript, use a JSON parser and fix any security issues in your server that allow unescaped user generated content in the response.

There is no more secure version. There are other features to consider though:
Example 1
Example 2
It doesn't matter whether you work with java, php or perl. They can all parse json and xml. json is lightweight, though xml can handle more. I would say, start with json unless you really need features of xml.

There is no security benefit to go with one or the other. Both formats are meant to provide a simple protocol for sending data, and neither use encryption by default (you could add something yourself). JSON is generally considered faster, since it takes less characters to assemble. It is also easy to use in JavaScript, since JSON is simply JavaScript Object Notation, and all JavaScript Objects can be converted to or from JSON representation.
Many (especially newer) developers prefer using XML because of its readability. It is structured in such a way that it is much easier for a human to read through it. This of course is what makes it bulkier than JSON, but it is by no means less secure.
Vulnerabilities that can occur as a result of these transfer protocols are a result of bad parsing. Parsers for services on an open network cannot simply assume that the data is valid, since that may lead to attacks such as code injection - but that has nothing to do with JSON or XML.

Both of the formats are representing data therefore there is no difference in security, i have been using JSON for years and never had any security issues.

JSON and XML both serves as a medium for server client communication. So, why are security concerns with one and not other?
The fundamental difference is that JSON(JavaScript Object Notation) as name suggests is very near and dear to JavaScript and hence in design of some JavaScript methods and functionalities, JavaScript treats JSON strings as it's cup of tea and tries to interpret it directly, which give workarounds to attackers to fool JavaScript interpreter to run malicious JavaScript embedded in the string causing vulnerabilities, while XML has to go through a parsing stage to be parsed into an object making it harder to attack with.
2 such JavaScript functionalities are eval() method and tag.
How does these create a security vulnerabilities?
Although web follows the same-origin policy, historically there have been loopholes found to bypass it and malicious sites use them to send cross site request to authenticated user website, breaking the intent of same-origin policy.
Example :
In spite of same-origin policy being in place, web has allowed some tags like <img> <script> to make cross origin GET requests.
let us say you are on a website www.authenticatedwebsite.com, but lured to open a www.malicious.com which has a tag in its html
<script src="www.authenticatedwebsite.com/get-user-order-history" />
Attacker from www.malicious.com use this script tag behavior to access your private data from www.authenticatedwebsite.com.
Now, how does a script tag which is calling a src url, store the url response to a javascript object[to perform operations like POSTing it to malicious site server]?
Here comes the role of JSON and XML proves out to be safer here. As JavaScript understands JSON pretty well, some JavaScript interpreters interprets naked JSON string as a valid JavaScript and run it.
What can running a JSON string potentially do, as it is still not assigned to a variable?
This can be achieved by another fancy hack.
If the returned JSON string represents an array. JavaScript will try to run the constructor of Array class. Now it is possible to override the constructor of Array in JavaScript. You can do something like :
Array = function(){ yourObject = this };
This is basically overriding JavaScript Array constructor, such that whenever JavaScript calls constructor, the current interpreted array is assigned to yourObject, thus giving malicious website access to your private data.
Now, this attack can be used with variants of JSON strings, with more sophisticated hacks.
Although above represents a valid scenario, where JSON can be dangerous as a return format of your GET APIs. This is actually possible in only some versions of some browsers, and as far as I know, all modern versions of famous browsers have mitigated it, but as your user base can be divided across versions of browsers, you need to be careful with GET APIs giving out private information in naked JSON format.
One of the technique used to circumvent this is adding a while(true) in front of your JSON response strings, which will never allow JavaScript interpreter to reach to the actual string. But it creates parsing overhead on your client side.
Another possible mishaps that JSON can cause is use of eval() method on browser client side to parse JSON. As eval() has capability to run script, if your JSON string contains some hidden script which eval() runs and perform dangerous actions what attacker injected script asks it to do, can prove out to be security issues for your system. But as others have mentioned, this attack can be easily prevented by strictly abandoning eval() method as your JSON parser everywhere in client code. This vulnerability plug in is highly important for websites which stores user generated content.

This post does a good job comparing the security issues found in the two data sharing formats. It even has code snippets with explanations of how attacks can be pulled off on the common vulnerabilities like XXE and DTD validation. Then it shows how to remediate/harden against these security issues so that both XML and JSON can be used safely.
https://blog.securityevaluators.com/xml-vs-json-security-risks-22e5320cf529
In terms of security, XML parsers in their default configuration are open to XXE injection attacks and DTD validation attacks, so XML data exchanges need to be hardened if used.
JSON, on the other hand, is in itself secure in its default state, but as soon as JSONP is utilized to bypass Same-Origin Policy restrictions (CSRF attacks), it becomes vulnerable because:
it allows cross-origin exchanges of data.
The author summarizes the comparison here:
In regard to security, processing untrusted Internet-facing requests is one of the most basic functions of an XML or JSON parser. Unfortunately, common XML parsers are not suitable for this purpose in their default configuration; only with hardening to disable external entity expansion and external DTD validation are they safe. Conversely, JSON parsing is almost always safe, so long as the programmer uses modern techniques rather than JSONP. As long as web developers are aware of these security risks and take the steps to defend against them, either option is completely viable in the current web environment.