You can find out more about fine-tuning best practices in our blog post.
RIPS analyzes the data flow through your code out of the box without the need for further configuration.
Its analysis includes all custom user-defined functions, classes, and methods which are contained in the scanned code, as well as all relevant PHP built-in functions and features.
With Analysis Profiles, additional settings for the RIPS engine can be added in order to fine-tune the security analysis specifically to your application.
The profiles can be accessed by clicking on the settings icon on the top right menu (see image below).
The already created profiles can be selected when starting a new scan.
Via the ID of a profile, it can also be used by different integration plugins.
Furthermore, only one profile can be applied to a scan at a time.
The profiles differ for the different programming languages. It is not possible to change the language of a profile afterwards.
Analysis profiles can be created for a specific application. So that the settings can only be used for the scan of that application.
Alternatively, a profile can be created as global so that the settings can be reused for different scans.
Profiles are used by default when no other selection has been made. A global default profile will be used for every application and application-wide default profiles only for scans of this particular application.
There can only be one default profile globally and per application.
By clicking on the name of a porfile, the analysis refinements can be changed at any time.
In addition, profiles can be duplicated so that all or part of their settings can be applied to a new profile.
Overview of created Analysis Profiles and link to menu link
Creating a new profile
The following analysis refinements are available:
In the general settings you can set various settings for the overall analysis behavior of the engines, as well as the further procedure with the application and result data.
In the php preferences you can specify the configuration of the used server. Also the different issue types can be excluded from the analysis.
In the java preferences you can specify the configuration of the used server. Also the different issue types can be excluded from the analysis.
Sources of malicious user input are the root for security vulnerabilities. By adding new source to the engine, new data flows can be detected and new issues can be discovered if present.
The sink is the second operation along with the source, which is part of a valid security vulnerability. Should user input flow unsenatized to a sink, then a potential attacker based on the sensitive sink operation can change the process of application for his purposes.
A sanitizer transforms malicious characters of a source into a safe character set, such that the source can be safely used in a sensitive sink.
A validator checks if the characters of a given source are within a safe character set. Otherwise, the data is rejected.
In some cases, the application code contains functions and methods that lead to issues in the report, although these should not be recognized as such. This can be test or debug code, for example, or intentional functionality that includes an intended vulnerability. These operations can be ignored by the analysis.
Not always the whole application code should be included in the analysis process or you don't want to see results from third-party libraries. To customize the analysis and the report, whole paths or single folders can be ignored.