Hubble POST requests with the type "application/octet-stream" which is blocked by WAF

[sagarmujumale]

Hi Team,

We noticed that for some reason the control_stream endpoint in hubble now sends POST requests with the type "application/octet-stream" which is blocked by WAF as its challenging for WAF to inspect and analyze for potential threats. Binary data can contain malicious code or exploit patterns that are difficult to detect.

Previously this was using "application/grpc-web-text" which is fine to allow through the WAF.

Here is the code which needs to change :-

hubble-ui/src/api/http-client/index.ts

Lines 91 to 97 in a06e19b

	private getContentProps(data: any): Option<[string, string]> {
	if (data instanceof Uint8Array) {
	return Option.some(['application/octet-stream', `${data.length}`]);
	} else if (data instanceof ArrayBuffer) {
	return Option.some(['application/octet-stream', `${data.byteLength}`]);
	} else if (typeof Buffer !== 'undefined' && data instanceof Buffer) {
	return Option.some(['application/octet-stream', `${data.length}`]);

This change was made in https://github.com/cilium/hubble-ui/releases/tag/v0.13.0.
Commit request #767

WAFs might not be able to recognize or understand the specific format or structure of data encoded as "application/octet-stream." This lack of understanding can make it difficult to analyze and filter the content effectively. This content type can be used to bypass certain WAF rules or detection mechanisms. Attackers might attempt to hide malicious content within binary data to evade detection. Processing binary data can be computationally expensive and resource-intensive for WAFs. Blocking this content type can help optimize WAF performance and reduce the risk of resource exhaustion.

[tqn-org]

Also encountered this. Not sure if this PR went through without security and integration testing