#Learn365 Day-11: Cache Poisoned Denial of Service (CPDos)
AIO Resource: cpdos.org
- One of a kind of Web Cache Poisoning attack that affects the resources used by an application to create a denial of service situation.
The working of this attack is theoretically very simple to understand:
1. The attacker sends a request to the server containing a malicious header with a malicious value. This can be any random header.
ex: x-mal-example: tohackthehacker
(3/n) 2. This request is first processed by the intermediate cache server to check if the copy exists. 3. The cache server forwards the attacker's request with malicious headers to the origin server as it doesn't store a fresh copy of the requested resource.
(4/n) 4. At the origin server, when this request comes, due to a malformed req bcz of a malicious header, the origin server returns an error page back to the intermediate cache server. 5. The cache server stores this error page considering it as a fresh copy of the req resource
(5/n) 6. Whenever someone visits this page next after the cache is poisoned they are presented with the error page/message instead of original content.
This issue doesn't affect the integrity of the origin server but the cache server is fooled to store an invalid page that is...
(6/n)
..served to the legitimate user making the original content unavailable.
# Types of CPDoS Attacks 1. HTTP Header Oversize (HHO) 2. HTTP Meta Character (HMC) 3. HTTP Method Override (HMO)
- It is possible to perform a CPDoS attack by abusing Hop-by-Hop Headers.
(7/n)
# HTTP Header Oversize
The HTTP Standard hasn't defined any size limit for the HTTP Request Headers. This thing can be utilized by an attacker to perform a multitude of attacks. This is the base for HHO based CPDoS Attack.
(8/n)
- HHO CPDoS attacks work in scenarios where a web app uses a cache that accepts a larger header size limit than the origin server.
- A malicious client sends an HTTP GET request including a header larger than the size supported by the origin server but smaller than.......
(9/n)
.... the size supported by the cache.
- Working is similar to the above-described method, however, the header is sent like this:
X-Oversized-Header-x: Big_Value
- Upon receiving this the origin server will not be able to handle this and will return with Header.....
(10/n)
...Size Exceeded message which will be cache and displayed to the end-user.
# HTTP Meta Characters (HMC)
This is again a similar technique the only difference is that in a malicious header, you send some harmful meta characters such as \n \r \a, etc.
(11/n)
- The origin server will not process these characters and may throw an error like character not allowed which will be presented to the victim user.
- The malicious header can be like this:
X-Meta-Malicious-Header: \r\n
(12/n)
# HTTP Method Override Attack
There are several headers present in HTTP Standard that allow modifying overriding the original HTTP header as the request goes forward through proxies before reaching the origin server. Some of these headers are:
When these headers are supplied and supported, the header instructs the application to override the HTTP method in request to the header mentioned in these headers upon reaching the Origin Server.
(14/n)
This can be abused to perform a Cache Poisoned Denial of Service Attack. The steps to perform the attack are the same, only the used HTTP headers change.
- The malicious header will look like this:
X-HTTP-Method-Override: DELETE
(15/n)
- Now if the origin server doesn't support the DELETE method, it will return with Method Not Supported error which will be stored at intermediate cache & will be displayed to the legitimate users.
# Remediations: Mentioned on the cpdos.org website.
WebSocket is a network protocol that enables 2-way communication b/w client & server. In the HTTP standard, where the one-party has to wait for the req./res from another party before performing the next action.
(2/n)
The major goal of WebSocket is to enable real-time communication and can widely be seen in IM applications.
I will be diving the WebSocket learning into 3 parts and I will post more about various attacks in the next two days.
(3/n)
# Web socket Protocol Scheme
1. Websockets use wss:// and ws:// as the protocol scheme. 2. This is similar to HTTPS and HTTP. Here, the WSS:// is a secure channel where WS:// is an insecure channel.
#learn365 Day-12: Unicode Normalization
This attack is hard to explain w/o proper graphics. Please refer to the references mentioned for a detailed explanation. This is a really good attack vector to try and consider while doing PT/BB.
(1/n) #bugbountytips#AppSec#infosec
(2/n)
Unicode to ASCII Transformation is a two-step process.
1. Normalization: Where the characters are converted to a standardized form 2. Punycoding: Where the Unicode is turned into ASCII
There are two overall types of equivalence between characters:......
(3/n) 1. Canonical Equivalence: Characters are assumed to have the same appearance and meaning when printed or displayed.
2. Compatibility Equivalence: This is a weaker equivalence, in that two values may represent the same abstract character but can be displayed differently.
#Learn365 Day - 8: JSONP Attack
(Deleted prev. post and re-sharing as there are some modifications & to avoid false statement)
JSONP stands for JavaScript Object Notation with Padding which allows sending JSON data across domains without worrying about Cross-Domain Issues. (1/n)
(2/n)
It utilizes <script> tag to perform the action instead of using XHR. However, the function requires to be existing in the global scope.
It is an insecure communication method & should be used when no personal/sensitive data is involved & sanitizing the callback function.
(3/n)There are multiple attacks affecting the JSONP implementation as it doesn't have a security feature.
The “padding” or function to call with the JSON data, is often specified as a parameter. Often this parameter is called callback and is reflected as-is in the response.
#learn365 Day-7: Cross-Site Script Inclusion (XSSI)
- XSS & XSSI are differemt.
In XSS, the payload is included on the victim to perform an action. However, In the case of XSSI, the victim's code (JS) is embedded in the attacker-controlled page.
(2/n)
In XSSI, the goal is to usually steal the data bypassing the restrictions such as the Same Origin Policy (SOP).
XSSI is less utilized and I never paid much attention to this attack vector. This seems to be an interesting and realistic, easy to exploit attack vector.
(3/n)
This attack is to mainly target the sensitive information that might get dynamically stored in the javascript files when a user performs some activity. If there are not proper restrictions set, an attacker can easily read and get hold of sensitive information.
Cross-Site Leaks/XS-Leaks is a less explored security issue that usually comes from Side-Channel Attacks. I found this an interesting vector but unusual.
(2/n)
This basically utilizes the web's core principle of composability in order to determine & extract useful information.
XS-Leaks take advantage of small pieces of information that are exposed during interactions between websites.
(3/n)
Cross-Site Oracle.
This can be considered as a querying mechanism. The information used for this attack is of binary form and called Oracles. It usually has an answer of "Yes" or "No". You can say True or False.
#Learn365 Day-5: Client-Side Template Injection (CSTI) 1. This occurs at the client-side like other JS attacks such as XSS. 2. This is mainly seen in the various JS libraries like AngularJS, VueJS etc which utilize the template engines at the client-side.
(1/n) #bugbountytips
(2/n) 3. The presence of "ng-app" in the page source identifies the use of templates. 4. If the application directly accepts the input and process it without any validation, it may be vulnerable to CSTI. 5. CSTI leads to perform cross-site scripting attacks by escaping...
(3/n) 6. Testing this issue is similar to Server-Side Template Injection. 7. Steps:
a. In the suspected field, provide a payload like {{11*5}}
b. If the response reflected is 55, this tells that there is the use of the template and further you can try performing CSTI to XSS