OWASP Security Knowledge Framework: The Missing Tutorial
OWASP Security Knowledge Framework: The Missing Tutorial
Do you think the OWASP docs are a little lacking? Here is some additional information about the framework that you should bookmark for the next time you use it.
Join the DZone community and get the full member experience.Join For Free
A few months ago (during BeneLux OWASP Days 2016) I watched a presentation of the OWASP Security Knowledge Framework. I found the presentation very interesting so I decided to dig a little bit to learn more about OWASP Security Knowledge Framework, a.k.a SKF. I found the official documentation a little bit sparse so after playing with SKF a few days I decided to write about what I learned.
SKF is a tool that helps the software developers to ease the integration of security into SDLC (Software Development Lifecycle). For the end-user, SKF can be used as a web application which can be accessed after creating an account.
The SKF website has deployed a demo application, that can be accessed here: SKF demo site (the username is admin and the password is test-skf. Be aware that the site content is scratched every hour).
If you want to install SKF in-house, then you can follow the installation instructions (installation instructions under Ubuntu, MacOS, and Windows are provided, as well as Chef and AWS). Another installation option would be to use Docker; in this case, you could use the following Docker image that I created. (the image is based on Ubuntu 14.04 64 bits version).
Once the application is running (in the case of Ubuntu manual installation it will run over HTTPS on port 5443) you have to unlock the default admin account (I will speak later about user and group management in SKF). This procedure is described in the First run page; what is important to note is that on the “first login” page you must use the pin code 1234 and the email email@example.com (these values are hard-coded).
SKF Big Picture
The SKF is articulated around 4 security topics:
- (security) knowledge base
- (security) code examples
- introduction of the security checklists for applications using the OWASP Application Security Verification Standard (ASVS) project
- introduction of the security requirements in the SDLC
The Knowledge Base
The SKF knowledge base contains the descriptions and the solutions to over 200 vulnerabilities, attacks and security best practices: API responses security headers, Access Control patterns, Command injection, and many, many more.
The Code Examples
SKF also contains a few dozens of code examples of best practices to write secure code; the examples are written in PHP and C# languages.
SKF offers also the possibility to create projects and users, the idea being that the users can be part of one or more projects and each project can contain a list of security checklists and security requirements.
The admin user (the user that has been unlocked after the installation) can create projects and users. For the user creation, a unique pin code is generated and the new user needs to use this pin code the first time when he connects to the application.
The security checklists are representing a way to testing web application technical security controls and also provides developers with a list of requirements for secure development. SKF uses the OWASP Application Security Verification Standard (ASVS) checklists. SKF shows the checklists in a very user-friendly way and the checklists can be customized in case your project have special security requirements. It is possible to add as many checklists as wanted end every checklist can be downloaded as a .docx document.
The OWASP ASVS contains the following verification criteria:
- Architecture, design ant threat modeling
- Session management
- Access control
- Malicious input handling
- Cryptography at rest
- Error handling and logging
- Data protection
- HTTP security configuration
- Malicious controls
- Business logic
- Files and resources
- Web services
For me, the most interesting feature of the SFK is the ability to create and attach to each project multiple items called functions. The basic idea is that the user can choose from a list of security requirements depending on the feature that should be implemented; for example, when implementing a new feature, an eternal library will be used then you can add as security requirement the “third party software” function. Each security requirement contains a description and a solution about how to be handled.
The OWASP SKF contains the following security requirements:
- Third party software
- Access controls or Login systems
- User registration
- Password forget functions
- Forward or redirect
- GET variables or parameters
- XML files
- File Download
- File upload
- Regular expressions
- Eval type functions
- Private user data
- System commands
- SSI commands
- XSLT input and output
- HTTP headers
- LDAP commands
- User-input in HTML output
- File inclusion
- Path or Filename
- SQL commands
What I like about OWASP SKF is that it tries to introduce the secure coding practices into the SDLC in an easy and customizable way; ideally, you should use all the features of the SKF but it’s up to each team/project to choose how SKF could help to have a more secure code.
On the negative side I would have the following remarks:
- the application looks unstable; very often I have “Internal server error” on my Docker instance.
- the code examples for Java are in the “Coming Soon” status for the last (at least) 8 months; maybe should be removed to not set-up unreasonable expectations.
- I (personally) do not appreciate the ergonomy of the user interface; the actions linked projects (project creation, results) are mixed with the user management actions (user and group creation) and with other actions which are independent of projects and groups (code examples and knowledge base). As a new user, I was very confused and I didn’t understand right away that the 4 SKF features can be used independently.
Published at DZone with permission of Adrian CITU , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.