CAPEC-462: Cross-Domain Search Timing
An attacker initiates cross domain HTTP / GET requests and times the server responses. The timing of these responses may leak important information on what is happening on the server. Browser's same origin policy prevents the attacker from directly reading the server responses (in the absence of any other weaknesses), but does not prevent the attacker from timing the responses to requests that the attacker issued cross domain.
Last updated
Overview
For GET requests an attacker could for instance leverage the "img" tag in conjunction with "onload() / onerror()" javascript events. For the POST requests, an attacker could leverage the "iframe" element and leverage the "onload()" event. There is nothing in the current browser security model that prevents an attacker to use these methods to time responses to the attackers' cross domain requests. The timing for these responses leaks information. For instance, if a victim has an active session with their online e-mail account, an attacker could issue search requests in the victim's mailbox. While the attacker is not able to view the responses, based on the timings of the responses, the attacker could ask yes / no questions as to the content of victim's e-mails, who the victim e-mailed, when, etc. This is but one example; There are other scenarios where an attacker could infer potentially sensitive information from cross domain requests by timing the responses while asking the right questions that leak information.
How the attack works
The phases an attacker typically follows to carry out this attack.
- Step 1Explore
[Determine service to send cross domain requests to] The adversary first determines which service they will be sending the requests to
- Step 2Experiment
[Send and time various cross domain requests] Adversaries will send a variety of cross domain requests to the target, timing the time it takes for the target to respond. Although they won't be able to read the response, the adversary can use the time to infer information about what the service did upon receiving the request.
- Using a GET request, leverage the "img" tag in conjunction with "onload() / onerror()" javascript events to time a response
- Using a POST request, leverage the "iframe" element and use the "onload()" event to time a response
- Step 3Exploit
[Infer information from the response time] After obtaining reponse times to various requests, the adversary will compare these times and infer potentially sensitive information. An example of this could be asking a service to retrieve information and random usernames. If one request took longer to process, it is likely that a user with that username exists, which could be useful knowledge to an adversary.
- Compare timing of different requests to infer potentially sensitive information about a target service
What the attacker needs
Prerequisites
- Ability to issue GET / POST requests cross domainJava Script is enabled in the victim's browserThe victim has an active session with the site from which the attacker would like to receive informationThe victim's site does not protect search functionality with cross site request forgery (CSRF) protection
Skills required
- Low skill: Some knowledge of Java Script
Resources required
- Ability to issue GET / POST requests cross domain
Consequences
What a successful CAPEC-462 attack can achieve.
Read Data
Affects: Confidentiality
How to mitigate it
Defenses that reduce the risk of CAPEC-462.
- Design: The victim's site could protect all potentially sensitive functionality (e.g. search functions) with cross site request forgery (CSRF) protection and not perform any work on behalf of forged requests
- Design: The browser's security model could be fixed to not leak timing information for cross domain requests
Frequently asked questions
Common questions about CAPEC-462.
- What is CAPEC-462?
- An attacker initiates cross domain HTTP / GET requests and times the server responses. The timing of these responses may leak important information on what is happening on the server. Browser's same origin policy prevents the attacker from directly reading the server responses (in the absence of any other weaknesses), but does not prevent the attacker from timing the responses to requests that the attacker issued cross domain.
- How does a Cross-Domain Search Timing attack work?
- It typically unfolds over 3 phases. It begins with: [Determine service to send cross domain requests to] The adversary first determines which service they will be sending the requests to
- How do you prevent CAPEC-462?
- Design: The victim's site could protect all potentially sensitive functionality (e.g. search functions) with cross site request forgery (CSRF) protection and not perform any work on behalf of forged requests
- What weaknesses does CAPEC-462 target?
- CAPEC-462 exploits 3 CWE weaknesses, including CWE-208 (Observable Timing Discrepancy), CWE-352 (Cross-Site Request Forgery (CSRF)), CWE-385 (Covert Timing Channel).
- How severe is CAPEC-462?
- MITRE rates CAPEC-462 as Medium severity.
References
Attack-pattern data is sourced from the MITRE CAPEC catalog (v3.9). Weakness associations link to the corresponding CWE entries on RadicalNotion.AI.
Defend against CAPEC-462
Track the CVEs and weaknesses attackers exploit with this technique, with AI-written analysis and remediation guidance.