Application security risks posed by open source Java frameworks
In terms of which is the most secure framework, CAST looked at 496 applications with 152 million lines of code and found the biggest problem was actually that most apps were misconfigured. I'm not sure of the statistical conclusions that can be drawn from some of the other survey results, but this finding highlights the importance of training so that developers know how to properly use their chosen framework.
The planning stage of any application development should produce a set of specific security requirements such as authentication, authorization and encryption to enable the development team to choose the framework that best suits these needs. It may be that multiple frameworks are needed to support all requirements, though this can lead to difficulties in integrating different parts of an application.
Personally, I think using a good framework does lead to better coding discipline and reduces the overall bug count. The CAST report found applications built without a framework of any kind had a huge variance in quality. Other factors affecting the choice of framework include the quality of the documentation, particularly the documentation on security APIs, as they can be quite complex and obviously need to be used correctly. Another consideration is the responsiveness of the framework's user community, as this is an important source of help and support.
Hardening a framework involves changing somebody else's code, and that is always tricky. Any updates or patches they release may overwrite your changes or affect their behavior. If you feel it is important, then I would review any code that handles user input and entry points to the application. Is input validated and cleansed of any unexpected characters or values? If not, you could add your own validation and filtering functions to ensure data passed to your application is always safe.
As with any third-party code or application, you need to stay in touch with the vendor or bug list so that any security alerts are picked up. For example, researchers at Aspect Security found a flaw in the "expression language" function of the Spring framework that allows remote-code execution and could lead to the complete compromise of an application. This problem is proving tricky to patch, and current advice is to turn off the expression-language feature. Any developers unaware of these vulnerabilities are leaving their applications wide open to abuse and compromise. A member of the development team should be made responsible for following the security news for the programming languages and tools being used in an application, and knowing how to deal with alerts and critical patch releases.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.