Suricata

correction:

Pay particular attention to sid:4 and sid:2 where the only difference is how far into the base64 encoded string are decoded.

should be

Pay particular attention to sid:4 and sid:1 where the only difference is how far into the base64 encoded string are decoded.

in testing, the following alerts are produced

03/30/2022-14:59:10.243824  [**] [1:2:1] base64 decode - url_decode [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.104.20:12926 -> 172.16.72.94:80
03/30/2022-14:59:10.243824  [**] [1:4:1] base64 decode - no url_decode grab only the first two bytes [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.104.20:12926 -> 172.16.72.94:80

the following rule, when run on snort 2.9.18 (only tested version) works as expected. this is equivalent to sid:1; of the above suricata rules.

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"base64 decode"; flow:established,to_server; content:"foobar="; http_cookie; base64_decode:relative; base64_data; content:"|9e|"; depth:1; sid:1; rev:1;)

[**] [1:1:1] base64 decode [**]
[Priority: 0] 
03/30-14:59:10.246444 192.168.104.20:12926 -> 172.16.72.94:80
TCP TTL:64 TOS:0x0 ID:1 IpLen:20 DgmLen:125
***AP*** Seq: 0xB  Ack: 0x65  Win: 0x2000  TcpLen: 20F

Victor Julien wrote in #note-3:

Shivani could you craft an SV test for this and have a look at the issue? AFAICS we could introduce a new Base64Mode like BASE64_MODE_RELAX_PASSTROUGH that would just copy any invalid byte into dest. We should be careful with the buffer sizes though, as the dest buffer might be smaller than expected due to there normally being a size ratio between encoded and decoded data.

I was looking at this with this approach and realized that dest buffer would indeed be a problem but wondered why should we try to add some data that is not decoded to the decoded buffer?
I referred to the RFC again and it is advisable for the decoding software to skip on any such invalid chars in a stream of b64 encoded data. So, I was wondering if it makes sense to make our decoder such that it always skips on anything that is not supposed to be there?
Even if I try to put the string in this pcap on any reliable decoder, the results are the same as they would be if there were no special characters..

But, I am clearly missing the point of BASE64_MODE_RELAX while proposing this (which I don't know btw)..