At the Denver OWASP meeting in October, Mark Hoopes vented about the marketing claims made by application security vendors. By examining the fundamental technical capabilities that several families of tools have to offer, he challenges some of the more outrageous claims made. You never know who might have developed a game changing technology, but by focusing on the typical limitations of the technology, you can ask the right questions to cut through the marketing and get to the useful details needed to make an informed tool buying decision. The slides of the presentation are shared here.
The calendar shared at DEF CON 31 and BSides Las Vegas is a collection of application security vulnerabilities observed on multiple pentests or that simply caught our eye. No one application is expected to have all, or even many of the vulnerabilities, but over the course of a year, by considering each one, a web application developer should pick up a few new tricks and hopefully will avoid at least one potential bug in their own code. The art was generated using DALL-E with a prompt that had some loose connection to each vulnerability. Some of them more loose than others.
Feel free to use some or all of the images. Our only ask is that the Meristem logo remain part of the finished product. Enjoy!
To get a quality application assessment, you'll want to provide more than just the URL of your website. Sure that's all an attacker usually starts with, but an attacker can spend months working on a chosen target, or scan the whole internet looking for a specific vulnerability they know how to exploit. For an assessment, the more information provided to the tester, the more efficient they will be and the more value you'll receive from your investment.
Meristem typically conducts at least two meetings prior to the actual start of testing. The first meeting is to get an understanding of what your application does and how it does it so that the testing scope can be agreed to and a Statement of Work written. To facilitate that conversation, Meristem uses the questionnaire below. While most of the information can be gathered during the meeting, knowing what's going to be asked, or even providing the information ahead of time helps to keep the meeting short and productive.
Once the Statement of Work has been agreed to, Meristem will work with you to gather all of the information needed to actually execute the assessment. This includes network access to the testing environment, credentials to sign in, and contact points to be used at various points of the engagement. Again, this questionnaire can be completed outside of a meeting, or during the pre-assessment kickoff meeting. Knowing what information, and by extension what preparations, need to be made helps keep the project on schedule.
Questionnaire 2 - Assessment Preparation
Both questionnaires contain field helps and of course Meristem is available to answer any questions that may come up.
Determining the quality of the assessment you receive can be tricky. Was the report short because the application is secure or because the tester cut corners? Are there no high findings because they don't exist or because they were missed? One method of judging the quality of the test is to take a good look at the level of detail in the findings that were written. Do they describe your environment specifically or do they look like they were copied from somewhere? A good finding should contain details that not only show that the the tester spent time examining your application, but also provide your developers with instructions on how to find, and how to start fixing the vulnerability.
The findings below are examples of how Meristem approaches writing a finding. These come from an open source application (findings from a previous contract would be a breach of confidentiality), but are representative of findings we commonly report. Each finding begins with a description of the way the application works, discusses the mechanics of the vulnerability, outlines potential abuse cases, and provides recommendations on how the vulnerability can be addressed in this specific application.
There are certainly findings that are common and where a standard write-up provides all the detail necessary, but if the top severity findings do not contain details that reflect the details of your environment specifically, then you have reason to question the thoroughness of the assessment.
Materials from "Gaps in the Magic: Exploiting Security Edge Cases in Rails"
Presentation Slides
Download "EdgeCasesInRailsSecurity.pdf"
Workshop Applications
Rails SQLi Workbook |
A multi-tenant Rails application that allows users to explore Active Record methods vulnerable to SQLi. | https://github.com/Meristem-Infosec/rails-sqli-workbook |
Marshal Bank |
A Rails application that mimics the account registration process of a bank. It is vulnerable to unmarshalling attacks. | https://github.com/Meristem-Infosec/MarshalBank |