Vulnerabilities > CVE-2022-3730 - Improper Enforcement of Message or Data Structure vulnerability in Ehoney Project Ehoney

An attacker utilizes crafted XML user-controllable input to probe, attack, and inject data into the XML database, using techniques similar to SQL injection. The user-controllable input can allow for unauthorized viewing of data, bypassing authentication or the front-end application for direct XML database access, and possibly altering database information.

An attacker intentionally introduces leading characters that enable getting the input past the filters. The API that is being targeted, ignores the leading "ghost" characters, and therefore processes the attackers' input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API. Some APIs will strip certain leading characters from a string of parameters. Perhaps these characters are considered redundant, and for this reason they are removed. Another possibility is the parser logic at the beginning of analysis is specialized in some way that causes some characters to be removed. The attacker can specify multiple types of alternative encodings at the beginning of a string as a set of probes. One commonly used possibility involves adding ghost characters--extra characters that don't affect the validity of the request at the API layer. If the attacker has access to the API libraries being targeted, certain attack ideas can be tested directly in advance. Once alternative ghost encodings emerge through testing, the attacker can move from lab-based API testing to testing real-world service implementations.

HTTP Request Smuggling results from the discrepancies in parsing HTTP requests between HTTP entities such as web caching proxies or application firewalls. Entities such as web servers, web caching proxies, application firewalls or simple proxies often parse HTTP requests in slightly different ways. Under specific situations where there are two or more such entities in the path of the HTTP request, a specially crafted request is seen by two attacked entities as two different sets of requests. This allows certain requests to be smuggled through to a second entity without the first one realizing it.

This attack uses a maliciously-crafted HTTP request in order to cause a vulnerable web server to respond with an HTTP response stream that will be interpreted by the client as two separate responses instead of one. This is possible when user-controlled input is used unvalidated as part of the response headers. The target software, the client, will interpret the injected header as being a response to a second request, thereby causing the maliciously-crafted contents be displayed and possibly cached. To achieve HTTP Response Splitting on a vulnerable web server, the attacker:

This attack relies on the attacker using unexpected formats for representing IP addresses. Networked applications may expect network location information in a specific format, such as fully qualified domains names, URL, IP address, or IP Address ranges. The issue that the attacker can exploit is that these design assumptions may not be validated against a variety of different possible encodings and network address location formats. Applications that use naming for creating policy namespaces for managing access control may be susceptible to being queried directly by IP addresses, which is ultimately a more generally authoritative way of communicating on a network. Alternative IP addresses can be used by the attacker to bypass application access control in order to gain access to data that is only protected by obscuring its location. In addition this type of attack can be used as a reconnaissance mechanism to provide entry point information that the attacker gathers to penetrate deeper into the system.