Those third-party libraries and services today comprise more than 70% of web apps’ code and functionality. Usually, an attacker will either compromise the third-party’s code or the actual web application code and insert modified code that will, for example, sniff credit card information and send it to another server somewhere else via an encrypted connection. These types of stealthy attacks are difficult to spot because they don’t obviously impact web application performance, are invisible to users and happy outside the site operator’s perimeter.
Approach 1: Static Code Analysis
Shortened as SCA and also known as static application security testing (SAST), this method is usually performed as part of a code review. Developers and DevOps teams usually undertake this by running web application code through various SCA tools tuned to highlight possible vulnerabilities in static (non-running) source code. SCA tools do this using various common techniques including data-flow analysis, taint analysis and lexical analysis, among others. SCA looks for a variety of known code flaws such as unbuffered form fields or other ways to overwhelm user input mechanisms and override business logic.
Approach 2: Dynamic Application Security Testing (DAST)
Application security testing is a method using automated tools to scan web apps from the outside in as a “black box,” analyzing the application and looking for well-known vulnerabilities such as cross-site scripting, SQL injection, or command injection. There are dozens of scanning tools available, including several really good open source products. Effective passive scanning tools can identify well-understood problems in live code that is running in a web application. More sophisticated scanners also can analyze code as it is running (in runtime), making it more difficult for malicious hackers to hide attacks.
Passive scanning tools have crucial weaknesses. Advanced attackers will identify scanners by mapping their IP addresses or detecting the automated clients running the test. These attackers will serve a benign code to scanners and requests that could be coming from the site owner, and will serve the vulnerable code only to verified targeted users (e.g. cryptowallet holders).
Approach 3: Real-User Runtime Analysis
Which Approach Should You Use?