Context
EAR (Execution After Redirect) is a redirect vulnerability where unintended code is executed and sent to the user after a redirect. EARs are technically back-end logic flaws
Approach
- We developed a black-box classification system to detect different types of EAR vulnerabilities by analyzing the HTTP response
- large-scale analysis to determine the prevalence of EARs on the Internet
- crawled 8,097,283 URLs from 255,957 domains and found 2173 security critical EARs among 416 domains
Detecting EAR
For an HTTP response to indicate an EAR vulnerability, two things are needed:
- the response must be an HTTP redirect response
- the HTTP redirect response content must divulge confidential information about the web application
Distinguish between vulnerable and legitimate HTTP redirect response
- legitimate responses are often empty or simply report the current HTML of the page
- string patterns that match text commonly used in legitimate redirections can be used
- pattern are recognizable because HTTP redirect responses often respect rules
Classification of non-EARs
- generic redirect: the content of a redirect message aims to warn a user of a changed location
- irrelevant or broken content: here is a bit of information but it is not sensitive or relevant
- near duplicate: the HTTP body returned is similar to the content of the redirect location’s content. A NCD (Normalized Compression Distance) is used to calculate the textual similarity
Classification of EARs
- error message: some content sent by the server contains error messages, which ==can reveal sensitive information about the web server (paths of the server, which can be used in directory traversal (path traversal) attacks, details about the framework, the language and often the version number, SQL query syntax details, which can lead to SQLIA (SQL injection attack))==
- HTTPS redirect: HTTP redirect response contains a full web page and the redirect leads to a page served through a secure channel. This is a security-critical EAR because, by redirecting to a secure channel, the web application is signaling that the content is sensitive. These EARs most likely contain sensitive information or information that should not be available to unauthorized users
- Pre-login access: HTTP redirect response redirect to a login page, but the body of the HTTP message include the content of the page, even though the user is not authenticated. This is a authentication bypass.
- In a case, a social platform had a EAR that allowed anyone to access a user’s profile, violating user’s privacy
- Transparent barrier: web application developers sometimes want the user to visit a certain page prior to allowing access to the full content of the web application. For example the user is redirected to the same page until she has “signed” a Terms of Use form.
- in this cases, sometimes developers set a redirection but keep the old web application version in the HTTP body
- Other: body content not included in the previous categories
The classification follows a progressive and ordered approach, meaning that the HTTP response is categorized on the last category whose criteria are met (if a response matches the criteria for pre-login, it is not classified as near duplicate even if both criteria are met)
