Audit Your Web Applications with AVA
Hosting a web application is an excellent way to expose useful services to the public, but it comes at a cost: vulnerabilities in your web apps could allow attackers to access important systems, endangering your customers and your business.
The Indeed Security team developed Another Vulnerability Auditor (AVA) to address this problem. By using AVA to automate application scans, we can continuously monitor production and QA systems for potential vulnerabilities. And, because we have released it as an open source tool, you can use it to monitor your applications as well.
How does it work?
AVA scans a set of application endpoints, defined in HTTP Archive (HAR) format. The HAR file catalogs the URL, headers, cookies, and POST data for HTTP requests. AVA uses this information to model endpoints and scan them using a combination of auditors and checks.
Auditors
Auditors determine the HTTP elements that AVA audits. These include URLs, headers, cookies, and POST data.
Auditor types and what each type audits:
- Cookie: Individual cookies in the Cookie request header
- Header: Most request headers
- JSON: JSON data in the request body
- Multipart: Multipart form data in the request body
- Parameters: Parameters in the URL query string and request body
- Response: Aspects of a response (passive audit)
- Text: Plain text data in the request body
- URL: Request URL
Checks
Checks determine the types of security vulnerabilities AVA checks. These include cross-site scripting, open redirects, SQL injection, and shell injection.
Check types and what each type checks for:
- Code injection: Code injection in Python’s pickle and eval statements
- Header injection: Header injection in responses
- Open redirect: Open redirects to arbitrary URLs
- Path traversal: Path traversal on the local filesystem
- Shell injection: Shell injection in Bash statements
- SQL injection: SQL injection in database queries
- Cross-site scripting: HTML and JavaScript injection in responses
- XML external entity: XML external entities in XML documents
- Personally Identifiable Information (PII): Email addresses, credit cards, and Social Security numbers
How can I use it?
We designed AVA for use within automated systems. We automate AVA with Docker Swarm and Jenkins. However, you can use AVA anywhere Python can be installed.
Use in Docker Swarm
Indeed’s Security team uses Docker Swarm to automate AVA and scan public-facing applications daily. This allows us to identify vulnerabilities shortly after they are introduced. The pipeline has three components:
- Enricher combines data from sources, such as WES, into endpoint definitions
- Scheduler maintains a schedule and configuration
- Vulnerability manager stores reports and displays vulnerability information
The process is as follows:
- The scheduler contacts the enricher and requests endpoint definitions for the current application.
- The enricher returns these definitions in HAR format.
- The scheduler pushes the HAR data and configuration settings to AVA.
- AVA runs the configured scan against the application and generates a report.
- AVA sends the report to the vulnerability manager for storage.
Use in Jenkins
We also use AVA in Jenkins to examine systems in our QA environment. This allows us to identify vulnerabilities before they reach production. The pipeline has two components: functional tests and AVA. The functional tests are a collection of Selenium-based test cases for verifying release candidates in QA.
The process is as follows:
- Functional tests run against the application.
- A proxy collects traffic from the tests and exports it as HAR files.
- AVA scans the application using the exported HAR files.
- AVA provides a report documenting the results of the scan.
How can I get AVA?
We’ve made AVA available and open source on Git. Download it, try it out, and reach out to us on GitHub or Twitter if you need any help. You can open an issue on the GitHub repository, or hit us up on Twitter.
Published also at Indeed Engineering Blog.