ATTENTION: You are on the develop branch.
This has been renamed to master.
The develop branch will not be maintained anymore.
It is only left here to avoid broken links to existing content.
Please update links to point to the master branch.
For details look at issue #320.
Security is todays most important cross-cutting concern of an application and an enterprise IT-landscape. We seriously care about security and give you detailed guides to prevent pitfalls, vulnerabilities, and other disasters. While many mistakes can be avoided by following our guidelines you still have to consider security and think about it in your design and implementation. The security guide will not only automatically prevent you from any harm, but will provide you hints and best practices already used in different software products.
An important aspect of security is proper authentication and authorization as described in access-control. In the following we discuss about potential vulnerabilities and protection to prevent them.
Independent from classical authentication and authorization mechanisms there are many common pitfalls that can lead to vulnerabilities and security issues in your application such as XSS, CSRF, SQL-injection, log-forging, etc. A good source of information about this is the OWASP. We address these common threats individually in security sections of our technological guides as a concrete solution to prevent an attack typically depends on the according technology. The following table illustrates common threats and contains links to the solutions and protection-mechanisms provided by the devonfw:
| Threat | Protection | Link to details |
|---|---|---|
validate input, escape output, use proper frameworks |
||
encrypt all channels, use a central identity management with strong password-policy |
||
Use secured exception facade, design your data model accordingly |
||
Prefer JSON over XML, ensure FSP when parsing (external) XML |
||
Ensure proper authorization for all use-cases, use |
Access-control guide especially method authorization |
|
Use devon4j application template and guides to avoid |
||
prevent injection (see A1) for HTML, JavaScript and CSS and understand same-origin-policy |
||
Use simple and established serialization formats such as JSON, prevent generic deserialization (for polymorphic types) |
JSON guide especially inheritence, XML guide |
|
subscribe to security newsletters, recheck products and their versions continuously, use devonfw dependency management |
||
Ensure to log all security related events (login, logout, errors), establish effective monitoring |
||
Using direct object references (IDs) only with appropriate authorization |
||
secure mutable service operations with an explicit CSRF security token sent in HTTP header and verified on the server |
||
Escape newlines in log messages |
||
Avoid using redirects and forwards, in case you need them do a security audit on the solution. |
devonfw proposes to use rich-clients (SPA/RIA). We only use redirects for login in a safe way. |
To address the thread Using Components with Known Vulnerabilities we integrated OWASP dependency check into the devon4j maven build. If you build an devon4j application (sample or any app created from our app-template) you can activate dependency check with the security profile:
mvn clean install -P securityThis does not run by default as it causes a huge overhead for the build performance. However, consider to build this in your CI at least nightly.
After the dependency check is performed, you will find the results in target/dependency-check-report.html of each module. The report will also be generated when the site is build (mvn site) even without the profile.
For penetration testing (testing for vulnerabilities) of your web application, we recommend the following tools:
-
ZAP (OWASP Zed Attack Proxy Project)
-
See the marvelous presentation Toolbox of a security professional from Christian Schneider.