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"
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|
|A Rails application that mimics the account registration process of a bank. It is vulnerable to unmarshalling attacks.||https://github.com/Meristem-Infosec/MarshalBank|