OWASP ASVS

OWASP Security Knowledge Framework – the missing tutorial

Adrian Citu

skf-miniA few months  ago (during BeneLux OWASP Days 2016) I’ve seen 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 on paper what I have learned.

Introduction

SKF is a tools 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 web application which can be accessed after creating an account.

SKF web site have 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).

Installation

If you want to install SKF in-house, then you can follow the installation instructions (installation instructions under Ubuntu, MacOS and Windows are provided and also 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 First run page; what is important to note is that on the “first login” page you must use the pincode 1234 and the email [email protected] (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.

Security Checklists

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 contains a list of security checklists and security requirements.

The admin user (the user that have been  unlocked after the installation) can create projects and users. For the user creation, a unique pincode is generated and the new user need to use this pincode 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 checklists can be downloaded as a .docx document.

The OWASP ASVS contains the following verification criteria:

  • Architecture, design ant threat modeling.
  • Authentication.
  • Session management.
  • Access control.
  • Malicious input handling.
  • Cryptography at rest.
  • Error handling and logging.
  • Data protection.
  • Communications.
  • HTTP security configuration.
  • Malicious controls.
  • Business logic.
  • Files and resources.
  • Mobile
  • Web services
  • Configuration

Security requirements

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 of the feature that should be implemented; for example you if for 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:

  1. third party software
  2. sub-domains
  3. Access controls or Login systems
  4. User registration
  5. Form
  6. Sessions
  7. Password forget functions
  8. Forward or redirect
  9. GET variables or parameters
  10. XML files
  11. File Download
  12. File upload
  13. Regular expressions
  14. Eval type functions
  15. Private user data
  16. System commands
  17.  SSI commands
  18. XSLT input and output
  19. HTTP headers
  20. LDAP commands
  21. User-input in HTML output
  22. X-Path
  23. File inclusion
  24. Path or Filename
  25. SQL commands

(My) Conclusion

What I like about OWASP SKF is that it tries to introduce the secure coding practices into the SDLC in a 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 understood right away that the 4 SKF features can be used independently.

(My) OWASP BeNeLux Days 2016 Notes – Conference Day

Adrian Citu

Here are my quick notes from the OWASP BeNeLux Days 2016  conference day. All the slides can be found on this page.

Gamers, You’re the new Botnets

This presentation was about OWASP_BeNeLux_2016_logohow to educate the teenagers to be aware of the dangers installing cracked video games.

The first part of the presentation was an practical example of what a system containing cracked video games is doing in background:the system was connected to external IP addresses from different countries, various ports were open to the target machine, even an cloud hard drive data backup software it was silently operating.

The second part of the presentation was about a process that could be applied in order to reduce the risk of transforming the pc in a botnet client. This process implied:

  • the use of an intermediary pc on which a scan of the downloaded games could be done.
  • a virtual machine on which the Wireshark is installed. On this VM, the game could be eventually installed.

Top 10 privacy risks in web applications

The goal of this presentation was to present the OWASP Top 10 Privacy Risks Project which have as goal to identify the most important technical and organizational privacy risks for web applications and to propose some mitigations techniques.

The top 10 privacy risks:

  1. Web Application Vulnerabilities
  2. Operator-sided Data Leakage
  3. Insufficient Data Breach Response
  4. Insufficient Deletion of personal data
  5. Non-transparent Policies, Terms and Conditions
  6. Collection of data not required for the primary purpose
  7. Sharing of data with third party
  8. Outdated personal data
  9. Missing or Insufficient Session Expiration
  10. Insecure Data Transfer

LangSec meets State Machines

For me this presentation contained two separate and independent tracks.

The first track was around LANGSEC: Language-theoretic Security The LangSec idea (which sounds very appealing) is to treat all  inputs of an applcation (valid or invalid) as a formal language. In this case then the input validation would be done using a a recognizer for that language.

LangSec principle: no more handwriter parsers but:

  1. precisely defined input languages
  2. generated parsers
  3. complete parsing before processing
  4. keep the input language simple & clear

The second track was around the use of state diagrams in order to detect security flows in different protocols (GSM, SSH). Lot of protocols have states and it is possible to compute the state machine of a protocol using a black box testing approach.

The Tales of a Bug Bounty Hunter

The author is participating to the Facebook Bug Bounty Program and the presentation was about the different security vulnerabilities found in the Instagram application. For each  vulnerability, a detailed description was made.

The most surprising fact was that the impact of the vulnerabilities found was not at all linked to the time/effort spent to find the vulnerabilities :).

OWASP Secure Knowledge Framework (SKF)

The OWASP SKF is intended to be a tool that is used as a guide for building and verifying secure software.

The 4 Core usage of SKF:

  • Security Requirements using OWASP Application Security Verification Standard (ASVS) for development and for third party vendor applications.
  • Security knowledge reference (Code examples/ Knowledge Base items) in PHP and C# (not yet in Java)
  • Security as part of design with the pre-development functionality. The developer can choose the type of functionality taht he wants to implement and SKF will make a reports with all the security hints/infos that he should be aware.
  • Security post-development functionality for verification with the OWASP ASVS

The application is an web application and can be runned on local systems of developers or on a server.

Challenges in Android Malware Detection

A traditional way of malware detection:

  • collect suspicious samples
  • analyze the samples (usually manually)
  • extract the signature

A smarter solution could be that given a set of known malwares + known goodwares + use data mining techniques to detect unknown samples.

The main problem of this approach is that :

  • there are a few small sets of known malwares
  • there are no set of known goodwares

The conclusion is that is very difficult to build the wright set of malwares and goodwares so there is not possible to have an automatic malware detection process.

Serial Killer: Silently Pwning your Java Endpoints

This presentation is about the Java deserialization vulnerability.  Tha authors explains how the vulnerability works, what products/frameworks are affected and also what are the possible mitigations. The best mitigations is to not use at all the serialization/deserialization process and/or replace it by JSON or XML.

The slides of this presentation can be found here.