Is there a chance to automate the search for non-localized text on startup in Thymeleaf Templates and log occurrences?
My Infrastructure: Ant, Spring, Thymeleaf.
Unfortunately there is no clean documented way in which to do it (that I know of).
Having said that, I have done something similar where I wanted to check the template for something and log an occurrence, however the implementation is ugly.
I have to warn you that this is beyond horrible and because it is not standard is likely to break in future releases so I would use sparingly, and definitely not use in any production code.
This requires for you template resolver to be cacheble to be true - org.thymeleaf.templateresolver.TemplateResolver#setCacheable(true) the default is true.
I was able to do it by extending org.thymeleaf.cache.StandardCacheManager (you need to set the cache manager on the org.thymeleaf.TemplateEngine) and overriding initializeTemplateCache() that returned a custom version of org.thymeleaf.cache.StandardCache. My implementation of the cache override the put(..) method which passed in a org.thymeleaf.Template as the value.
That then has org.thymeleaf.dom.Document accessible via getDocument() and from there you can recursivly iterate through the children (some of which will be org.thymeleaf.dom.AbstractTextNode). In your case you may also want to iterate through all the attributes on element nodes as well.
For you, you will then have to write some logic to determine if the text is not going to be localised, working out whether the #{} expression is not being used or if that expression in not in a th:...="#{}" tag or being inline [[#{}]]
Ugly I know but it works for me. If anyone has a cleaner solution I'm all ears.
Related
Further to Tainted_source JAVA, I want to add more information regarding the error os_command_sink I am getting.
Below is the section of code that's entry point of data from front end and marks parameter as tainted_souce
Now when the DTO - CssEmailWithAttachment is sent to static method of CommandUtils, it reports os_command_sink issue. Below is the code for the method
I tried various ways to sanitize the source in controller method - referenceDataExport i.e. using allowlist, using #Pattern annotation but coverity reports os_command_sink all the times.
I understand the reason as any data coming from http is marked as tainted by default. And the code is using the data to construct an OS command hence the issue is reported.
Coverity provides below information regarding the issue
So I tried strict validation of entityType that it should be one of the known values only but that also doesn't remove the issue.
Is there anyway this can be resolved?
Thanks
The main issue is that the code, as it currently stands, is insecure. To summarize the Coverity report:
entityType comes from an HTTP parameter, hence is under attacker control.
entityType is concatenated into tagline.
tagline is passed as the body and subject of CdsEmailWithAttachment. (You haven't included the constructor of that class, so this is partially speculation on my part.)
The subject and body are concatenated into an sh command line. Consequently, anyone who can invoke your HTTP service can execute arbitrary command lines on your server backend!
There is an attempt at validation in sendEmailWithAttachment, where certain shell metacharacters are filtered out. However, the filtering is incomplete (missing at least single and double quote) and is not applied to the subject.
So, your first task here is to fix the vulnerability. The Coverity tool has correctly reported that there is a problem, but making Coverity happy is not the goal, and even if it stops reporting after you make a change, that does not necessarily mean the vulnerability is fixed.
There are at least two straightforward ways I see to fix this code:
Use a whitelist filter on entityType, rejecting the request if the value is not among a fixed list of safe strings. You mentioned trying the #Pattern annotation, and that could work if used correctly. Be sure to test that your filter works and provides a sensible error message.
Instead of invoking mailx via sh, invoke it directly using ProcessBuilder. This way you can safely transport arbitrary data into mailx without the risks of a shell command line.
Personally, I would do both of these. It appears that entityType is meant to be one of a fixed set of values, so should be validated regardless of any vulnerability potential; and using sh is both risky from a security perspective and makes controlling the underlying process difficult (e.g., implementing a timeout).
Whatever you decide to do, test the fix. In fact, I recommend first (before changing the code) demonstrating that the code is vulnerable by constructing an exploit, as that will be needed later to test any fix, and is a valuable exercise in its own right. When you think you have fixed the problem, write more tests to really be sure. Think like an attacker; be devious!
Finally, I suspect you may be inexperienced at dealing with potential security vulnerabilities (I apologize if I'm mistaken). If so, please understand that code security is very important, and getting it right is difficult. If you have the option, I recommend consulting with someone in your organization who has more experience with this topic. Do not rely only on Coverity.
What is the possible usage of ZuulFilter.run() return value?
All the examples (for instance Spring example) return null.
The official documentation says:
Some arbitrary artifact may be returned. Current implementation ignores it.
So why to have it at all?
I've used this lib in multiple projects and I never thought to look into and stumbled upon this question so I had to look. Just tracing the code in IntelliJ, it does look like the results are pointless.
I'm on zuul-core:1.3.1:
Looking at FilterProcessor, when the routing methods are called to route based on the type, they all call runFilters(sType) which ultimately get the the return Object in question of the implementing IZuulFilter classes. The trail seems to stop here.
I then stopped to looked at their test classes and nothing seems to do anything with the return Object either nor the ZuulFilterResult that wraps it.
I then thought, ok, well maybe there is a way to pass data from one IZuulFilter to another (e.g. from pre to route) but that doesn't seem possible either since FilterProcessor.processZuulFilter(ZuulFilter) doesn't do anything with the results and just passes it back to runFilters(sType) which we know ignores it.
My next line of questioning was, "well, perhaps you can provide your own FilterProcessor implementation and swap it out and actually use the Object somewhere". But alas, it looks like that isn't the case either unless you want/need to implement a lot more even into the ZuulServlet?
Lastly, I thought, "well, maybe it's just a convention thing". But java.lang.Runnable.run() is void and javax.servlet.Filter.doFilter is also void.
So for now, my best guess is that like all of us at some point in our careers, we sometimes fall into a YAGNI situation; perhaps this is just one example.
There may be some related questions, but I think my situation is peculiar enough to justify a question on its own.
I'm working on a historically grown huge Java project (far over one million LOC, due to other reasons we're still bound to Java 6 at the moment), where reflection is used to display data in tables - reflection is not used for dynamically changing the displayed data, but just for using some kind of short cuts in the code. A simplified part of the code looks like this.
TableColumns taco = new TableColumns(Bean.class);
taco.add(new TableColumn("myFirstMember"));
taco.add(new TableColumn("mySecondMember"));
...
List<Bean> dataList = getDataFromDB(myFilterSettings);
taco.displayTable(dataList);
So the values of the table cells of each row are stored in an instance of Bean. The values for the first cell comes from calling itemOfDataList.getMyFirstMember() (so here comes the reflection part of the code). The rendering of the table cells is done depending on the return type of the itemOfDataList.getMyFirstMember().
This way, it's easy to add new columns to the table, getting them rendered in a standard way without caring about any details.
Problem of this approach: when the getter name changes, the compiler doesn't notice and there will be an exception at runtime in case Bean.getMyFirstMember() was renamed to Bean.getMyFirstMemberChanged().
While reflection is used to determine which getter is called, the needed info is in fact available at compile time, there are no variables used for the column info.
My goal: having a validator that will check at compile time whether the needed getter methods in the Bean class do exist.
Possible solultions:
modifying the code (using more specific infos, writing an adapter, using annotations or whatever that can be checked at compile time by the compiler), I explicitely don't want a solution of this kind, due to the huge code basis. I just need to guarantee that the reflection won't fail at runtime.
writing a custom validator: I guess this shouldn't be too complex, but I have no real idea how to start, we use eclipse as ide, so it should be possible to write such a custom validator - any hints for a good starting point?
The validator should show a warning in eclipse if the parameter in the TableColumn(parameter) isn't final (should be a literal or constant). The validator should show an error in eclipse if the TableColumn is added to TableColumns and the corresponding Bean.getParameter() doesn't exist.
as we use SonarQube for quality checking, we could also implement a custom rule checking if the methods do exist - not completely sure if such a custom rule is possible (probably yes)
maybe other solutions that will give a fast feedback within eclipse that some tables won't render correctly after some getter methods were renamed
What I'm asking for:
what will be easier in this situation: writing a custom validator for eclipse or writing a custom rule for SonarQube?
hints where to start either approach
hints for other solultions
Thanks for your help.
Some alternatives:
You could migrate to more modern Java for this pattern, it is a prime candidate for method references. Then, your IDE of choice can automatically take care of the problem when you refactor/rename. This can be done bit-by-bit as the opportunity/necessity arises.
You could write your own custom annotations:
Which you can probably get SonarQube to scan for
Which could allow you to take advantage of javax.validation.* goodies, so your code may look/feel more like 'standard' Java EE code.
Annotations can be covered by a processor during the build step, various build tools have ways to hook this up -- and the processor can do more advanced/costly introspection so you can push the validation to compile-time as opposed to run-time.
Is it possible to define the type of the view commands in Spring? As it is right now, it is dangerous for us to change anything in our command classes. Properties on these classes may be used by the view (path="myDto.persons[0].name"), but if anything in the command class changes, the view will only fail runtime.
All other parts of our MVC stack is tested, so we can safely do refactorings when needed. The only problem is with the view, as the paths are "just strings", and we cannot in any reasonable way search and replace everywhere we use the specific command.
It would be a great help if there was some way to tell Spring what type the command actually is, so it could be validated when we do precompilation of our .jsp's. An added bonus would also be completion when editing the view, but I guess that is more of an IDE issue.
So, do any of you know how and if this is possible?
It might be possible to add type safety to your views if you completely redesign your JSP files (in a very ugly way if I may say so myself).
Servlets offer you type safety since that's Java code. If you refactor your classes and miss something, the compiler will immediately tell you you missed it. But JSPs replace servlets as a view technology offering a much more dynamic/rapid development pace (no more endless out.write instructions opening tags, closing them, escaping quotes etc).
EL expressions, as you noticed, are basically strings which later get evaluated and fail at runtime if something is off. Even if you precompile the JSPs, it would still fail because ELs remains as strings in the generated servlet. They are either passed as such to tags and they evaluate it themselves, or if using a JSP 2.x version, the servlet container itself wraps the expression in an evaluation call before passing it as a value.
Basically for a version less than JSP 2, for a tag like:
<my:tag value="${bean.someProp}" />
You get a result like:
myTagInstance.setValue("${bean.someProp}");
in the servlet.
The tag itself will do the evaluation of that string, at runtime.
For JSP 2 you don't get any better, the evaluation still occurs at runtime but the servlet container takes this burden away from the tag, generating a code like:
myTagInstance.setValue((SomePropTypeCastHere) ProprietaryServletContainerEvaluationUtil.evaluate("${bean.someProp}"));
If the content of the object itself isn't the expected one when evaluation occurs, you get weird results or errors.
The only way (I know) to enforce static typing in a JSP is to bring Java code back in the JSP (the thing EL was invented to eliminate). That is why I said at the begging that you have to change your JSP in an ugly way.
If all your tags can use <rtexprvalue>true</rtexprvalue> values, you can use scriptlets to enforce type safety.
A tag like:
<my:tag value="<%=bean.getSomeProp()%>" />
now gets converted to this:
myTagInstance.setValue(bean.getSomeProp());
If the someProp property was renamed, deleted, changed type or whatever, the compiler can tell you about it. The IDE itself should be able to tell you, you don't even need to precompile the JSPs.
If I'm not mistaken, the Spring tags support runtime expressions so this should work... if you are willing to mess up your JSPs that is!
As for the IDE support for completion, you have that for scriptlets but not for EL. That's because for EL it's the same discussion, it happens at runtime. How is the IDE to know what's in context (page, request, session etc) when the JSP is executed, and know that when you are developing the JSP?
Our Topic object has BOTH isChannel and getChannel public methods. The object graph is too complex to change this. Channel has an Integer type.
We are migrating from one application server to Tomcat. When using this expression ${topic.channel.type}, in JSPs our current app server finds the getChannel method. However, Tomcat finds the isChannel method and we get errors since the return type is a Boolean, not a Channel. Is there a way to tell Tomcat to prefer getters over boolean public methods?
For now I'm just going to write a helper function or expose a new method, but I have a feeling I'm going to come across this quite a bit during the migration.
Unfortunately, you can't force a method call like that.
I have checked the Javabeans and EL specifications, but nowhere is specified what the preferred method is when both isXXX() and getXXX() methods are present. However, I do agree that it makes more sense to prefer the getXXX() one in this particular case. This should also be programmatically possible. I think it's worth the effort to report this as an issue against the Tomcat EL implementation.
In theory, this should be more of a JavaBeans issue than an EL implementation issue. One thing you might try is to find out how the java.beans.Introspector views your Topic class. One way to do that would be to run this code I wrote a while back for the Struts wiki. Depending on the complexity of your class, it might make sense to create an explicit java.beans.BeanInfo class to force the channel property to always be exposed as an Integer.