It’s estimated that 90 percent of security incidents result from attackers exploiting known software bugs. Needless to say, squashing those bugs in the development phase of software could reduce the information security risks facing many organizations today. To do that, a number of technologies are available to help developers catch security flaws before they’re baked into a final software release.
In 2014, Gartner put forward the concept of self-protection for application during operation, that is, the protection of applications, should not be accomplished by external systems; applications should have the ability to protect themselves.
IAST is designed to address the shortcomings of SAST and DAST by combining elements of both approaches. IAST places an agent within an application and performs all its analysis in the app in real-time and anywhere in the development process IDE, continuous integrated environment, QA or even in production.
Because the IAST agent is working inside the app, it can apply its analysis to the entire app all its code; its runtime control and data flow information; its configuration information; HTTP requests and responses; libraries, frameworks and other components; and backend connection information. Access to all that information allows the IAST engine to cover more code, produce more accurate results and verify a broader range of security rules than either SAST or DAST.
RASP, or Run-time Application Security Protection As with IAST, RASP, or Runtime Application Security Protection, works inside the application, but it is less a testing tool and more a security tool. It’s plugged into an application or its runtime environment and can control application execution. That allows RASP to protect the app even if a network’s perimeter defenses are breached and the apps contain security vulnerabilities missed by the development team. RASP lets an app run continuous security checks on itself and respond to live attacks by terminating an attacker’s session and alerting defenders to the attack.
Further than DAST, Dynamic Reviewer provides an optimized implementation of IAST+RASP, technologies, which rely on the request feature to intercept the attack pattern. For each leaked hole of the injected class, we can identify the part entered by the user and check the program logic whether the information flow has been modified, throwing an alarm. Since we do not rely on the request characteristics, each of our alarms is a successful attack.
HAST-Hybrid Application Security Testing
IAST and RASP are promising techniques, but as noted they both have issues with how they might affect your application as it runs for your users.
To achieve the security benefits of run-time knowledge during the development process, but not in a way that affects your users, we devised a hybrid approach to obtain run-time code execution insight during Dynamic testing, using agent technology, and combined those insights with Static testing to make it faster and easier to locate and fix those vulnerabilities most accessible to attackers.
We’ve taken to calling this Hybrid Application Security Testing, or HAST, to highlight its role as part of the overall application security testing process. HAST merges and correlates the results from SAST, IAST and DAST tools to focus your efforts on the vulnerabilities that matter most, and deliver a huge benefit to application security testing.
SAST tools identify potential vulnerabilities. Results need to be cross-referenced with issues found by IAST and DAST to determine if potential vulnerabilities are exploitable threats.
HAST accomplishes this, combining and correlating the results. You are able to identify which vulnerabilities are truly exploitable, and should be at the top of your remediation list.
HAST once again uses the same technology as IAST and RASP, by installing an agent within the application.
The agent works in the running application while DAST penetration testing (BlackBox) or GreyBox Scanning or Functional Tests are taking place, and identifies which dynamic findings are associated with which SAST findings.
The latest version ofSecurity Reviewer now offers HAST.
This newer application security testing tool makes application security testing better. But does not replace SAST and DAST (BlackBox or GreyBox) tools.
A proper application security testing strategy uses SAST, DAST, IAST, RASP, and HAST to identify vulnerabilities, prioritize them, and provide an extra layer of protection against attack.
But you still need to fix the issues that are found, which requires a remediation process.
Using the right tools gives you comprehensive coverage, and streamlines the entire process by automatically correlating results to help you identify those that need immediate attention.
As new tools and technologies emerge, you need to educate yourself to see how you can keep your application secure.
Dynamic Reviewer IAST is an Agent-based solution. It shares the same Agent of Dynamic Reviewer APM. APM features can enabled and purchased separately.
Interactive Application Security Testing (IAST) is a solution that assesses applications from within using software instrumentation. This technique allows IAST to combine the strengths of both SAST and DAST methods as well as providing access to code, HTTP traffic, library information, backend connections and configuration information.
Consider IAST when speed and accuracy are paramount, especially in DevSecOps initiatives.
Dynamic Reviewer IAST is based 100% on software that is deployed within your applications. it means that there is no need for any additional hardware component. In addition, and thanks to the integrated approach within the application, there is no centralized entry point as WAF solutions require, so your network deployment model remains exactly the same.
Dynamic Reviewer IAST integrated and lightweight approach does not require any additional instrumentation and can work with the default hardware assigned to your applications. This means that IAST scales with your applications removing the traditional extra hardware cost of the security solutions.
False Positives Reduction
Dynamic Reviewer IAST automatically export the results to Security Reviewer Static Analysis and Dynamic Reviewer Penetration Testing tools, for a very efficient False Positives reduction.
That can be done directly importing results in Static Reviewer, or via Team Reviewer, OWASP Defect Dojo / ThreadFix transformers. This allows users to better prioritize their remediation efforts and have a better way to overview the security posture of their projects.
Unlike perimeter control solutions like WAF, Security Reviewer RASP directly integrates its protection engine into the application server by automatic instrumentation, together with APM and IAST modules. It can monitor various events including database queries, file operations and network requests etc.
When an attack happens, WAF matches the malicious request with its signatures and blocks it. Security Reviewer RASP takes a different approach by hooking sensitive functions and examines/blocks the inputs fed into them. As a result, this examination is context-aware and in-place. It brings in the following benefits:
Only successful attacks can trigger alarms, resulting in lower false positive and higher detection rate;
Detailed stack trace is logged, which makes the forensic analysis easier;
Insusceptible to malformed protocol.
Security Reviewer RASP abandons the traditional firewall-dependent request feature detection pattern, creatively uses RASP technology (application runtime self-protection), directly injects function-level protection into the services of protected applications, can detect/protect unknown vulnerabilities without updating policies and upgrading protected application code, especially for Internet applications that use open source components and financial applications developed by third-party integrators.
Gray-box Scanning Tool
Further than DAST (Black Box with login recording), a Gray-Box scanner is available. Is can be useful for automated testing. It is implemented in Python3, the database is MySQL, and the communication is HTTP + JSON. The overall architecture diagram is as follows:
The tool is divided into a Scanner side and an Agent side. The Agent side is used to collect the running information of the web application. The Scanner side is used to process the request information generated by the plugin and complete the entire IAST scanning logic.
It consists of a separate IAST/RASP plug-in, the same of Dynamic Reviewer IAST/RASP solution, which is used to extract the information generated by the hook point in the HTTP request and send it to the scanner side in JSON form through the HTTP protocol.
This is a standalone scanning tool that uses the information obtained from the IAST/RASP plug-in to complete the scanning task.
Functional design and module division
The scanning module includes three modules: Pre-processor, Scanner, and Monitor.
The pre-processing module is the HTTP Server part in the figure, which is used to receive the HTTP request of the agent plugin, and process, store, and distribute the HTTP request information.
The scanning module is used to run the scanning plug-in and execute the vulnerability scanning logic
The monitoring module is used to periodically obtain the runtime information of other modules, adjust parameters, and provide HTTP services for the console.
Example of running process
A typical scanning process, taking the scanning process of SQL injection as an example:
1. Run the scanner side and initialize all modules
2. The tester sent an HTTP request to the web server. The request and the corresponding HOOK information were obtained by the IAST/RASP plug-in and sent to http_server.
3, http_server finds that the request is not issued by the scanner, and deduplicates it and writes it to the database
4. The scanning module obtains a HOOK message from the database and sends it to all scanning plugins.
5. The SQL injection scan plugin analyzed HOOK information and found that the user input parameters were spliced into the sql query, and the corresponding scanning logic was run.
6, the scan plugin generates a scan request, replacing the input parameters of the original request into the query with single quotes
7. The scan plugin adds scan_request_id to identify the scan request in the request header, and sends the scan request to the web server.
10. The web server processes the request and returns the result. The scanning plugin obtains the HTTP response. At the same time, the IAST/RASP plugin obtains the request hook information and sends it to http_server.
11, http_server found that the request was issued by the scanner, write it to the rasp_result_queue queue
12. The scan module reads the rasp_result_queue queue and passes the rasp_result to the corresponding scan plugin
13. The scanning plugin checks the received hook information and finds that the query logic has been changed. It is considered that there is SQL injection and the vulnerability information is written into the database.
Supported Application Servers
We've fully tested Security Reviewer RASP and IAST on the following application servers:
Oracle JDK, IBM JDK, and OpenJDK 1.5, 1.6, 1.7, 1.8, 9-14.
Apache Tomcat 6-9 (legacy) or 3.x (new architecture)
While APM support more languages than IAST/RASP, a 2020 Roadmap will be accomplished for the following programming languages:
Ruby (coming soon, Q3-2020)
The support of other Application Servers will also be soon included in the coming releases.
Dynamic Reviewer provides a solution for unsupported languages, named Generic Agent.
This Active Scan feature will run when the system is paused (no requests) and is suitable for apps written in unsupported languages.
The agent will store in a secured buffer the app credential used in the last Functional Test session, when it acts in Passive mode, and will use those credentials to execute the Active Scan as a lightweight client.
It has been tested in native C,/C++ engines, ErLang, Haskell, Objective-C, Ruby and Rust apps.
Supported DB Servers
Microsoft SQL Server
hql compliant (e.g. access via Hibernate, NHibernate, MyBatis, MapReduce)
Dynamic Reviewer IAST supports most servless environments, including Amazon EC2, Microsoft Azure, Google App Engine, Docker containers and PaaS cloud infrastructures such as Cloud Foundry
Pivotal Cloud Foundry
Any other APP-compliant container platform
Further to its own Dashboard, called Management Background:
Dynamic Reviewer integrates with OWASP Defect Dojo, permitting the results correlation between SAST, DAST and IAST from different tools. We take charge of your Defect Dojo implementation with a support contract included in the solution.
Our dashboard user interface relies on ElasticSearch v6.8.8, and provides user profiling with different roles. Every page can be accessed in different ways, for authorized users or groups only.
All objects are stored in an encrypted MongoDBv4.2.5 instance.
It offers three robust user management modes that are directly backed by the Elastic Stack Security features:
Standard Mode: With the Standard mode, users are managed by Workplace Search. Using this mode maintains user management within the Workplace Search experience. Users are invited and managed by an administrator via the Workplace Search administrative dashboard.
ElasticSearch Native Realm: With the ElasticSearch Native Realm, users are managed at the ElasticSearch layer. If your cluster is already configured to manage users (and their respective role mappings), this may be a straightforward way to roll out user management for your organization. Whether you’re using Kibana or automating user creation via ElasticSearch APIs, you can configure Workplace Search to inherit user attributes and rely on Role Mapping to tie existing roles to Workplace Search users and associated permissions.
ElasticSearch SAML: With the ElasticSearch SAML, you may delegate user management to third-party authentication providers and identity management platforms like Auth0 or Okta. In other words, Workplace Search inherits SAML settings and configuration from ElasticSearch itself. Role Mapping provides an interface to associate SAML-governed roles with Workplace Search users and permissions.
In order to group IAST-RASP Agents and introduce the concept of APP in the Management Background Dashboard, each APP represents a line of business. Each APP has an independent Secret to provide authentication. Each APP can manage multiple IAST-RASP Agent configurations and plug-ins.
At present, the agent management background is written in GO language, the database is MongoDB + ElasticSearch, and the communication uses HTTP / HTTPS + JSON regular communication. The overall architecture diagram is as follows:
As shown in figure
The dotted line below the IAST-RASP server installation, above the background control for the cloud, the cloud is divided into the background control Agent Server and Panel Server, Agent Server responsibility and IAST-RASP Agent communication, Panel Server is responsible for user interaction with the front end. Agent Server Multiple instances can be deployed, and Panel Server only one can be deployed.
Secrete authentication: The authentication method between IAST-RASP Agent and the cloud control backend adopts the form of appID + secrete private key for authentication.
Host registration: In the startup phase, if IAST-RASP Agent open remote management, every five minutes, try to Agent Server register once, until it is successful, the registration information will be stored in MongoDB, front-end display.
Heartbeat Timing: every 3 minutes IAST-RASP Agent Drive communication with the primary, heartbeat time configurable. When sending a heartbeat, the locally configured version number is also submitted. If there is a newer version of the configuration or plug-in, the cloud will return the new configuration and plug-in through heartbeat.
Alarm log upload: The green arrows flow alarm log upload, Agent Server acquisition of log there are two selectable modes, a first mode directly IAST-RASP Agent uploaded log into ElasticSearch, in this way there will be a large amount of logs where In the case of log loss, the second method is to write the log to a file, and then collect and import it into ElasticSearch by Logstash. This method is more complicated, but the log is not easy to lose. The IAST-RASP internal log upload method in different languages is as follows:
The PHP version checks for new logs every 10s. If the upload is successful, the file read offset will be recorded and the status file will be placed on the ground.
The Java/ Scala/ Kotlin/ Clojure version uses Log4j's built-in buffer, and the default size is 128. If the amount of unsent logs exceeds the buffer size, the oldest logs will be discarded.
Insert and configuration upgrade: user Panel Server to configure and plug MongoDB issued, then a IAST-RASP Agent by Agent Server heart removed and the new configuration plug
IAST / RASP Agent configuration allows you to fine-tune your agent configuration directly inside the Dashboard. Best of all, changes are automatically propagated to your Agents so there’s no need to redeploy.
To get started, simply choose the services and environments you wish to configure. The Dashboard will let you know when your configurations have been applied by your agents.
Performance impact on Application Servers
Under high concurrency pressure, the interface response time is delayed 1~7ms and acceptable.
We ran multiple intense and long-lasting stress tests prior to release. Even in the worst-case scenario (where the hook point got continuously triggered) the server’s performance was only reduced by 1~4%
Before deploying online, please contact QA for testing in the test environment, and pay attention to these issues:
How much does the average request response time decrease?
How much will the QPS drop if the CPU is full?
We have tested a large number of business systems and also tested multiple open source applications; many financial customers have helped us perform full-chain stress tests.The performance impact is typically 2%~4%between a response delay in the interface 2~8ms between the perfectly acceptable.
JeeCMS itself has a performance bottleneck. Without the installation of OpenRASP, when the concurrency reaches 15, 2 CPUs are already full, so we cannot simulate more users
IAST-RASP is not installed
IAST-RASP is not installed
Test report # 1-discuz x3.2
php-fpm is configured as,
pm = static
max_children = 100
max_requests = 1000
IAST-RASP is not installed
IAST-RASP is not installed
Test report # 2-wordpress 4.9.4
php-fpm is configured as,
pm = static
max_children = 100
max_requests = 1000
IAST-RASP is not installed
IAST-RASP is not installed
Background load balancing
In actual scenarios, we need to deploy multiple servers to handle connections from hundreds of thousands of hosts. Therefore, we will split into management background Agent AgentServer and PanelServer. The former is used to communicate with agents, such as heartbeats and log uploads, and multiple ones can be deployed; the latter is used to display data, timing alarms, and modify configurations. Users can access this background to view alarms. The latter is used to send alarm emails. If multiple deployments have the problem of repeated alarms, currently only one can be deployed.
ElasticSearch load balancing
When using ES cluster, EsAddr can fill in the address of a server. We will automatically call the /_nodes/interface to obtain all the information and poll the server to avoid single-point problem.
Integration with existing SIEM or SOC
Security Reviewer IAST/RASP logs alarms in JSON format, which can be easily picked up by any SIEM/SOC solution. Tested Platforms:
Splunk (via dedicated plugin or via log)
In most case you would add some metadata to the Analysis results. We handle two kind of metadata at application level:
Standard Application Portfolio Metadata (APM Code, Package Code, Outsourcer and Development Team)
Custom Metadata (you can define them yourself)
The Custom Metadata will be stored in Dashboard's encrypted DB (MongoDB) together with JSON results. Metadata can be also viewed in:
Dynamic Reviewer Dashboard (Management Backgroud)
OWASP Defect Dojo
All result data can be included in the report, Metadata included, both Compliance and Technical ones:
OWASP Top Ten 2017 compliance report
CWE - 2019 SANS Top 25 Most Dangerous Software Errors
3rd-party dependency report, based on CVE and CVSS
Reports are easy customizable, you can put up to 2 logos, personalize the cover letter in ISO-9001 style, define your responsability chain as well as the confidentiality level.
This form is classified by reference to OWASP TOP 10 2017,please contact us if you have any doubts.
OWASP TOP 10 coverage description
Description of classification
Type of attack
Description of classification
Type of attack
Failed authentication and session management
Not yet realized
Not yet realized
Sensitive data breaches
Sensitive file downloads
Any file read
Database slow queries
File directory listed
XML External Entity (XXE)
Failed access control
Any file upload
The file contains
Print sensitive log information
Struts OGNL Code Execution
Remote command execution
Cross-Station Scripts (XSS)
In the test, not published
Deserialization user input
Use components with known vulnerabilities
Asset Weakness Identification
Inadequate logging and monitoring
IP and Domain Reputation
Dynamic Reviewer IAST-RASP make use of CISCO Talos IP and Domain Reputation Center, the world’s most comprehensive real-time threat detection network.
An IP address or a domain earn a negative reputation when a suspicious activity is detected, such as spam or viruses originating from that address or domain.
IP addresses and domains are assigned a negative reputation when they are found to be open proxies, zombies, payload servers or when they send high levels of spam or viruses to spam traps and users.
An open proxy is a computer that allows e-mail or messages to be sent from arbitrary users (or machines). Modern mail hosts and messaging servers only allow mail/message to be delivered locally to their own users or transferred remotely from their own authenticated users. Open proxies are often old or improperly configured servers, but they can also be compromised personal computers. Open proxies can occur on both personal computers and UNIX systems.
A zombie computer, or zombie for short, is a computer attached to the Internet that has been compromised by a computer virus or worm. Such a machine can be controlled from a central location, without the knowledge of the machine's owner, and can be made to perform various malicious tasks including, but not limited to, sending spam. Millions of such zombie computers are known to exist, linked up into a number of "zombie networks" (sometimes referred to as botnets) to form a massive distributed server farm for the purpose of delivering spam simultaneously from origins distributed across the entire Internet. Zombies are now the most common delivery method of spam, accounting for a majority of all spam worldwide.
Dynamic Reviewer is a server-based tool. Anyway, we can detect important client-side vulnerabilities, like:
Asset weakness identification
and other Client-Side Detections able to reveal JSON and XML attacks.
Further, CLIENTS DON’T BREACH WIDELY. Most of the time, if a client is compromised, that particular client’s been compromised -- not all the clients. So let’s look at our portfolio again, but this time let’s overlay where all the breaches take place:
Certainly there are issues in client-side applications. Even though a client issue only compromises one single client, in extreme situations that’s all it takes to make the impact of a vulnerability truly critical.
Data breach detection
For enterprises, API interfaces are a common source of data breaches. As the company's business expands, it will be a challenge to comb the type of sensitive data or the data presentation interface. As a result, we have added HTTP response detection points to support the detection of requests. To ensure performance, we default to sampling only 5 requests per minute (configurable) for detection and processing only HTML/ JSON/ XML three response types (configurable):
In the latest official plug-in, we have added the identification of ID card,mobile phone number,bank carddata, when the interface returns such data, and no coding, we will issue an alarm.
If such pages are not authenticated, there is a level of overreach, or a large number of search engines indexed, will pose a significant risk to the enterprise.
Another common source of data breaches is sensitive files at the Web root. In the early days of the company's existence, it was not common to have a streamlined line-of-business release process, and it was common to place a full-site source code, SQL files, or business logs in a downloadable directory. Therefore, we have added a Web root scan to the PHP version, and if there are such sensitive files as (configurable), we will issue an alarm. To ensure performance, we scan every 6 hours by default (configurable) to detect up to 100 files, like: .git/.tar/.sql/.log
In cases where the root is not an open directory, there is also a risk of data leakage if the file name can be guessed.
In the last two years, there have been more and more vulnerabilities based on third-party libraries. While deploying RASPs for protection, security engineers should also push lines of business to upgrade class libraries and fix vulnerabilities. Therefore, we added the collection of class library information in the current version, which is performed every 6 hours by default (configurable). Currently supports the following types: Java (and other maven supported languages) POM information, PHP composer.json and .NET NuGet and Web.Config
When a vulnerability breaks out, security engineers can quickly locate the list of affected businesses and drive upgrades.
Enhanced detection capability
First, we have strengthened the detection algorithm for command injection. During the scan probe phase, syntax errors are usually generated, such as the number of quotation marks is not even, and during the exploit phase, an attacker typically uses a separator to execute commands such as curl, bash, and so on:
We check out and alert the above malicious injection behavior.
Second, we have strengthened the detection of SSRF. During the HTTP request process, if a jump occurs (corresponding to status code 301, 302), we call the plug-in again for detection. We pass the message before the jump, as well as the message after the jump:
Combined with the post-jump information, we can very well identify DNS rebinding attacks, as well as HTTP intranet jump attacks. In the official plug-in, if the original request is a normal request, but the jump address is an intranet address, we will determine the DNS rebinding attack and issue an alarm.
Finally, we've added detection of the header attack. For SQL injection, command injection, and other attacks, if the attack parameters come from the HTTP request header, we can also protect.
Current Version Preview
The current version has the following advanced features:
Dynamic spot tracking. Be able to identify the source of key parameters and prejudge the interface for vulnerabilities.
More vulnerability detection capabilities. Supports 22 types of attack detection, hard-coded passwords, such as NoSQL injection, and other 30 types of baseline detection.
Multi-account system and rights management. You can create multiple users and grant different permissions.
Auto-upgrade support. The app catalog isautomatically identified and deployed, and subsequent versions are upgraded as the app restarts without re-deployment.