Issue with invalid Base64 decoding?

[kikayli]

In the getDecoder function, it claims to support obtaining the Base64, but the actual code implements encoding rather than decoding. Is there a problem with this?

busboy/lib/utils.js

Line 409 in 6b3dcf6

return decoders.base64;

busboy/lib/utils.js

Line 458 in 6b3dcf6

return data.base64Slice(0, data.length);

[mscdex]

I don't understand your question. The code you pointed to is obviously decoding. Why do you think it's encoding?

It's probably better if you can supply a simple example of a specific problem you're running into.

[kikayli]

I don't understand your question. The code you pointed to is obviously decoding. Why do you think it's encoding?

It's probably better if you can supply a simple example of a specific problem you're running into.

I mean this part should be base64 decoding, but in reality, the code implements base64 encoding via data.base64Slice. You can test it, for example:

`POST / HTTP/1.1
Host: localhost:3000
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7Td39oqth29ZMUR6
Content-Length: 179

------WebKitFormBoundary7Td39oqth29ZMUR6
Content-Disposition: form-data; name="1"
Content-Type: text/plain;charset=base64

dGVzdA==
------WebKitFormBoundary7Td39oqth29ZMUR6--`

You'll understand once you test it.

[davidje13]

@kikayli is correct: base64Slice performs encoding not decoding:

console.log(Buffer.from('test').base64Slice()); // prints dGVzdA==
console.log(Buffer.from('dGVzdA==').base64Slice()); // prints ZEdWemRBPT0=

I'm not aware of any existing clients that would use base64 as a charset though, and base64 is not listed as a recognised charset on the official list. It would make more sense to send this as the content-encoding (in which case it's up to the application to perform its own decoding, since busboy just forwards that header without using it)

Personally I'd suggest busboy simply drop this charset as it is currently implemented incorrectly and is not part of any standard.

[davidje13]

From a bit of looking around the internet, it seems like maybe the motivation for using this is to deliver React2Shell exploits? (i.e. bypassing filters which protect against standard encodings of the attack)

That seems like a very strong reason to remove this feature entirely: since it isn't standard, the firewall-level protections some deployments are relying on (even though they shouldn't be relying on them!) are less likely to catch it, making it a potentially useful feature for hackers.

Legitimate users wanting to use base64 encoding who control both the client and server can (and should) use content-transfer-encoding: base64 instead, which is standardised.