EvoCrawl: Exploring Web Application Code and State using Evolutionary Search
Bibliographic record
Abstract
As more critical services move onto the web, it has become increasingly important to detect and address vulnerabilities in web applications.These vulnerabilities only occur under specific conditions: when 1) the vulnerable code is executed and 2) the web application is in the required state.If the application is not in the required state, then even if the vulnerable code is executed, the vulnerability may not be triggered.Previous work naively explores the application state by filling every field and triggering every JavaScript event before submitting HTML forms.However, this simplistic approach can fail to satisfy constraints between the web page elements, as well as input format constraints.To address this, we present EvoCrawl, a web crawler that uses evolutionary search to efficiently find different sequences of web interactions.EvoCrawl finds sequences that can successfully submit inputs to web applications and thus explore more code and server-side states than previous approaches.To assess the benefits of EvoCrawl, we evaluate it against three stateof-the-art vulnerability scanners on ten web applications.We find that EvoCrawl achieves better code coverage due to its ability to execute code that can only be executed when the application is in a particular state.On average, EvoCrawl achieves a 59% increase in code coverage and successfully submits HTML forms 5 more frequently than the next best tool.By integrating IDOR and XSS vulnerability scanners, we used EvoCrawl to find eight zero-day IDOR and XSS vulnerabilities in WordPress, HotCRP, Kanboard, ImpressCMS, and GitLab. I. INTRODUCTIONSince 2017, broken access control and XSS code injection have been consistently ranked among the most prevalent vulnerabilities in OWASP Top 10.As stated in OWASP's 2021 report [1], 94% of tested applications exhibited some form of broken access control or injection vulnerabilities, underscoring the need for developers to safeguard their web applications against these defects.There are two main approaches to detecting such vulnerabilities: static analysis and dynamic analysis. Static analysis tools [2], [3], [4],[5] require the application's source code, which limits their applicability to applications written in other programming languages.Conversely, dynamic analysis can be agnostic to the programming language, but can only detect vulnerabilities if they occur during the tool's application exploration.Therefore, dynamic analysis focuses on exploring as much code as possible.Web vulnerability scanners are often paired with a web crawler, which attempts to maximize the code coverage of an application by scanning as many pages as possible.However, simply crawling pages is not sufficient to maximize code coverage.This is because some code in a web application is associated with functionality that can only be triggered when the application is in a specific server-side state.For instance, in GitLab, a web-based revision control system, functions that enable users to manipulate code repositories require a repository to be created first.As a result, a vulnerability scanner will be unable to test any of that code if it is unable to interact with GitLab and create new repositories.Therefore, to achieve good code coverage, and thus find more vulnerabilities, a web crawler must explore both web pages and application states.This importance has not been lost in previous approaches to web application vulnerability detection.For example, Black-Widow [6] and Enemy of the State [7] incorporate HTML forms into their navigation graph, and submitting these HTML forms enables them to explore different server-side states.In addition, to handle AJAX-enabled dynamic web pages, BlackWidow also adds JavaScript events to its navigation graph.Triggering JavaScript events can enable additional fields and elements on a web page, allowing BlackWidow to submit more data and explore more server-side states.However, to correctly submit data to a web application that will modify the server-side state, a web crawler must satisfy both ordering and formatting constraints on interactions with HTML elements and trigger JavaScript events in the right order.For example, to submit data via a form, the web application may impose an ordering constraint that requires the crawler to first enter data into text fields, or select the correct options from dropdown boxes or radio buttons, before hitting the submit button.Similarly, a web application may impose formatting constraints such that fields that require a date or an e-mail must have well-formed inputs.Finding a sequence that meets ordering constraints requires a search over all possible sequences of interactions with HTML elements and JavaScript events (which we collectively refer to as web elements), which grows exponentially with the number of such elements and events.BlackWidow and Enemy of the State naively avoid searching this large space by filling in
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.000 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.001 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.000 |
| Open science | 0.000 | 0.000 |
| Research integrity | 0.000 | 0.000 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one teacher head, not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".