Client-Side Detection of Cross-Site Request Forgery Attacks
Bibliographic record
Abstract
Cross Site Request Forgery (CSRF) allows an attacker to perform unauthorized activities without the knowledge of a user. An attack request takes advantage of the fact that a browser appends valid session information for each request. As a result, a browser is the first place to look for attack symptoms and take appropriate actions. Current browser-based detection methods are based on cross-origin policies that allow white listed third party websites to perform requests to a trusted website. These approaches are not effective if policies are specified incorrectly. Moreover, these approaches do not focus on the detection of stored CSRF attacks where attack payloads reside in trusted web pages. To alleviate these limitations, we present a CSRF attack detection mechanism for the client side. Our approach relies on the matching of parameters and values present in a suspected request with a form's input fields and values that are being displayed on a webpage (visibility). To overcome an attacker's attempt to circumvent form visibility checking, we compare the response content type of a suspected request with the expected content type. We have implemented a prototype plug-in tool for the Firefox browser and evaluated our approach on three real PHP programs vulnerable to CSRF attacks. We have also developed a benchmark test suite containing 134 test cases for emulating CSRF attack requests for the three programs. The evaluation results indicate that our approach can detect most of the common form of reflected and stored CSRF attacks. Moreover, our approach can stop attack requests that include subsets of visible form fields and values.
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 machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.003 | 0.019 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.002 | 0.001 |
| Science and technology studies | 0.000 | 0.001 |
| Scholarly communication | 0.002 | 0.002 |
| Open science | 0.002 | 0.002 |
| Research integrity | 0.002 | 0.001 |
| Insufficient payload (model declined to judge) | 0.002 | 0.002 |
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 source (direct Gemma or distilled Codex), 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".