I am a newbie to java security, I need to implement input validator to my project , we are using struts 2.5.13 and we are testing through contrast security tool.
We had one vulnerability shown by contrast tool and that is “Expression Language Injection” and During my research on Owasp website , I have seen two projects one is Stinger Filter and Other Parameter Validation Filter . I am confused and not being able to decide which one is better and could provide more protection to my application.
Any of the security experts can answer this, I would like to know the thought on both the projects and which one I should use and why you think that’s better.
I will be thankful to you , if you provide me some detailed insight and help me in understanding security principles.
Both Stinger and PVF are ancient. I wouldn't use either. Fortunately, you don't need validation. You need to prevent untrusted input (like an HTTP parameter) from getting into an Expression Engine. So look at the full stack that Contrast gives you. Find where in your code is making that happen. Then fix it. Unfortunately, the problem may not be in your code, it may be in Struts itself. In that case, you should upgrade to the latest version. If that doesn't fix the problem, then you've discovered a new vulnerability in Struts -- fame and fortune await. Or you can just turn on Contrast Protect to prevent all EL vulnerabilities from being exploited.
Related
We are running into an interesting situation on a project where we're trying implement multisite functionality.
There is a component called RequestParameterRuleFilter that we are trying to use to override the “siteid” under certain circumstances.
Oracle's ATG documentation says that this component needs to be turned off in production, and we are trying to figure out why. Using this component saves us a lot of time, but we don’t want to risk any security holes or performance issues because of it.
Does anyone on here have any experience with this component, or know why we should not use this? Or, are there other alternative components built in to ATG that can be easily leveraged to provide multisite functionality?
Here is the link to the documentation: http://docs.oracle.com/cd/E35318_02/Platform.10-1-1/ATGPlatformProgGuide/html/s0902installedrulefilters01.html
I think site runs on domain name not on some param bases which can be manipulated easily, may be that y atg dosn't recommend this. We are using URLPatternMatchingRuleFilter, that resolve site based on domain name...and it is working fine...
I know there are many security frameworks and "building" a security framework is a bad idea.
In the recent project I have worked on, I used spring security to secure the web application. In the process, I over rided/tweaked some spring security classes to fit my requirement.
My management now wants me to "takeout" the things I did and distribute it as a re usable code in an internal portal.
Now, Is this is a fair thing to ask? I tried to explain them it's just some classes build on spring security and nothing special. But they are insisting on "creating" this framework.
Is this a fair requirement ? Any ideas on how to start ? I understand that getting started with spring security is not very easy.
If I am building this, what are the functions I need to provide?
If they need you to "takeout" the things you did then they should know what they want the framework to do. So Its probably better to ask them for requirements directly.
Regarding:
Is this a fair requirement ?
The answer is probably no. If they want you to do something they should give you specific requirements.
Just Yesterday I asked wheter someone knows a security-library which provides security-apis but at a bit lowerlevl than spring-security. Meaning a library which I call instead of a framework where I have to organize the code according to it (ie using a spring context).
So something I would need are apis for example to create safe remember-me tokens, do basic and dighest authentication, connecting to ldap - or just simply where I could use spring-security but without the spring-container).
I have a simple CRUD website in development process, almost done. I was asked to refactor the code but this time use struts 2 and commons chain. I read a couple of sites like this but wasn't able to know exactly what will be the key roles done by these two (struts 2 and commons chain) in my project. I was also asked that don't worry about struts tags like in this tutorial as the code that i made earlier can be used.
Can anyone give me an insight. Thanks
Note: A day back I started to see about struts 2
Well any framework is designed (most of them) to provide some sort of ease of use. That should be the driver when you chose one.
In your case, I can comment on Struts2.
Using Struts2 provides and enforces a better design in terms of separation of your code responsibilities (model view controller). This way the over all application design is well formed.
On top of this, framework provides many interesting features like interceptors, out of box request parameter assignments, validation, ui tags etc etc which you can benefit from.
So if you are still in the starting phase, yes - go through various frameworks available and weigh them out in terms of what ease you are looking for.
If the website is almost done, I don't see any compelling reason to adapt Struts 2. In fact, the person who asked you all this is the best person to contact, in this case.
Regarding commons chain, yes it can help you implement Chain of Responsibility pattern if it can solve the cases in hand.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have written a pretty extensive REST API using Java Jersey (and JAXB). I have also written the documentation using a Wiki, but its been a totally manual process, which is very error-prone, especially when we need to make modifications, people tend to forget to update the wiki.
From looking around, most other REST API's are also manually creating their documentation. But I'm wondering if theres maybe a good solution to this.
The kind of things which need to be documented for each endpoint are:
Service Name
Category
URI
Parameter
Parameter Types
Response Types
Response Type Schema (XSD)
Sample requests and responses
Request type (Get/Put/Post/Delete)
Description
Error codes which may be returned
And then of course there are some general things which are global such as
Security
Overview of REST
Error handling
Etc
These general things are fine to describe once and don't need to be automated, but for the web service methods themselves it seems highly desirable to automate it.
I've thought of maybe using annotations, and writing a small program which generates XML, and then an XSLT which should generate the actual documentation in HTML. Does it make more sense to use custom XDoclet?
Swagger is a beautiful option. It's a project on GitHub, has Maven integration and loads of other options to keep it flexible.
Integration guide: https://github.com/swagger-api/swagger-core/wiki
More Information: http://swagger.io/
Unfortunately, Darrel's answer is technically correct, but is hocus-pocus in the real world. It's based on the ideal that only some agree on and even if you were very careful about it, the chances are that for some reason outside your control, you can't conform exactly.
Even if you could, other developers that might have to use your API may not care or know the details of RESTful patterns... Remember that the point of creating the API is to make it easy for others to use it and good documentation is a must.
Achim's point about the WADL is good however. Because it exists, we should be able to create a basic tool for generating documentation of the API.
Some folks have taken this route, and an XSL stylesheet has been developed to do the transform:
https://wadl.dev.java.net/
Although i'm not sure it will totally fit your needs, take a look at enunciate. It seems like a good documentation generator for various web-services architectures.
EDIT Enunciate is available under github umbrella
you might be interested in Jersey's ability to provide so called WADL description for all published resources in XML format at runtime (generated automatically from annotations). This should be containing already what you need for basic documentation. Further you might be able to add additional JavaDoc, though that requires more configuration.
Please look here:
https://jersey.java.net/documentation/latest/wadl.html
Darrel's answer is exactly right. The kind of description must not be given to clients of a REST API because it will lead the client developer to couple the implementation of the client to the current implementation of the service. This is what REST's hypermedia constraint aims to avoid.
You might still develop an API that is described that way, but you should be aware that the resulting system will not implement the REST architectural style and will therefore not have the properties (esp. evolvability) guaranteed by REST.
Your interface might still be a better solution than RPC for example. But be aware what it is that you are building.
Jan
You might find rest-tool useful.
It follows language agnostic approach to write specification, mock implementation and automated unit-testing for RESTful APIs.
You can use it only for documenting your APIs, but this specification can immediately be used to quality assure the implementation of the real services.
If your services are not fully implemented yet, but for example should be used by a web frontend application, rest-tool provides instant mocking based on the service description. content schema validation (JSON schema) also can be easily added beside the documentation as well as used by the unit tests.
I hate to be the bearer of bad news, but if you feel the need to document the things you listed, then you probably did not create a REST interface.
REST interfaces are documented by identifying a single root URL and then by describing the media type of the representation that is returned from that URL and all the media types that can be accessed via links in that representation.
What media types are you using?
Also, put a link to RFC2616 in your docs. That should explain to any consumer how to interact with your service.
I recently added Struts 1.3 to my application on Tomcat. Here are my observations,
MVC. Servlet/JSP does this fine for me, where JSP is the view and servlet is the controller. I don't see any benefit to get the mapping from an XML file since our mapping is very static.
Action Form. I can see some benefits of action form but not huge.
Tags. I already uses JSTL and don't see any advantage using Struts tags.
So I am thinking about removing Struts. Anyone can think of any other benefits I might have missed?
Personally I myself prefer jsp/servlet but theoretically Struts has some advantages.
Here are some of the advantages i know of, you might have mentioned them already, but i thought it would be better if i list all of them here.
Centralized File-Based Configuration.
Struts values/mapping are represented in XML or property files. This loose coupling means that many changes can be made without modifying or recompiling Java code, and that wholesale changes can be made by editing a single file. This approach also lets Java and Web developers focus on their specific tasks (implementing business logic, presenting certain values to clients, etc.) without needing to know about the overall system layout.
Form Beans.
Bean Tags.
Struts provides a set of custom JSP tags that let you easily output the properties of JavaBeans components.
HTML Tags.
Struts provides a set of custom JSP tags to create HTML forms that are associated with JavaBeans components. This bean/form association serves two useful purposes:
It lets you get initial form-field values from Java objects.
It lets you redisplay forms with some or all previously entered values intact.
Form Field Validation.
Struts has a robust, extensible validator that can be used to uniformly validate your form fields. This validation can be performed on the server (in Java), or both on the server and on the client (in JavaScript).
"Plumbing code" contained within the Struts framework.
Mapping HTTP request parameters to Java objects is handled by Struts, for example. You don't have to do it. This allows you to focus more on the domain problem instead of building infrastructure.
Good documentation & plenty of books.
If you have to leave the project and/or someone else has to maintain it then using a well known and well documented framework will make that job much easier. A homebrewed framework just can't match that.
Broad user testing.
Since Struts is used in plenty web-apps the framework will get looked at by many more eyes than anything you could write alone. Usually, but not always, that means any problems you have will have been seen by someone else (and hopefully resolved) first.
Large knowledge base.
I agree that this perhaps isn't as valid as it used to be but Struts has been used in a lot of projects over the years. From a maintainability point of view using a well known framework makes it easier for other people to work on your application and also help build your own resumé for the future. Right now most development is either in the component based space (like JSF, wicket, tapestry) or in the rails-like space (like rails, grails, lift) but the struts arcitechture is still in use and valid.
You didn't say if you develop in a corporate environment or not, for a personal project perhaps the maintainability issue isn't that much of a problem.
If you decide that struts suits you well you could also have a look at stripes, a struts-like framework that's based on the same concepts but is less verbose when it comes to configuration with more sensible defaults, less xml and support for annotations.
I totally agree with your points about Struts - personally I think its time has come and gone.
I went off Struts in v1 (which I believe is nothing like the latest versions) because the form beans where just added boilerplate code to write.
Since then most applications I've worked on are using Spring as the dependency injection framework, which has made Spring MVC the natural choice - it's simple, straight forward and minimal.
Not just for Struts. But some points to consider for using a framework:
Standarization.
Specialized IDE or plugins for your favourite IDE.
Portability. For example, someone can develope a portlet for integrate your existing struts application in a portal server.
Internationalization.
The most important for me:
You dont have to worry about the issues on the struts code, just upgrade.
You can focus your work in business logic.
Struts is Open Source--
Large Community----
Number of Books available-----
Proven FrameWork----
Popular framework-----
Available since 2001----
+----
the features mentioned above...........
but when u r using struts,the better choice is struts2.
I think your feeling about removing Struts is a sound and understandable reaction. Struts just doesn't seem to do very much for an application.