What are the risks of uploading and downloading data in binary (non-encoded) format to servers and browsers?

Question

I admit up-front that this question may be the result of unfounded paranoia. But I am concerned that uploading and downloading data in binary form opens the door to exploits that might not be possible if the data were encoded during transfer and decoded at the destination.

I will stipulate definitions because I see the term "binary" thrown around a lot and I am not sure if everyone means the same thing when using it. When I say "binary" in the context of this question, I mean a stream of bytes that may have the high order bits set in at least some of those bytes. I don't mean a stream of bytes merely representing binary data, such as base64 encoding.

I am imagining that in the lowest levels of some possible network protocol used for Internet data transfers, there might be various "handshakes" using bytes with high-order bits set. If this were true, then a web server or browser that accepted arbitrary 8 bit streams of data could become vulnerable to some forms of attacks that employ some kind of "handshake doping" or the like.

I might agree that at the web server/web browser "level" of the data transmission hierarchy, perhaps this issue is irrelevant. That is what I want to know: Is a web "connection" (handshake and associated data transfers) immune from manipulation this way?

The scenario I am thinking of might result if a browser or server has been running for some time and its internal data page tables have become cluttered and possibly corrupted, maybe by some minor flaw in javascript or perl (how dare I insinuate that!). At that point, it seems like browsers and servers could become particularly vulnerable. (And I would agree that using a reliable operating system and reliable software will help a lot to prevent this and other horror shows.)

I'm not asking for advice on safeguards and recovery; I am only asking if there is a possibility of the kind of scenario I am suggesting.

Answer 1

On the network, bytes are sent and received. What these bytes represent is a matter of convention between client and server. However, if the client and server use some sort of open encoding (e.g. Base64) that everybody knows, then it is easy for any attacker in-between to apply and unapply that encoding at will. So this will have zero benefit for security.

If the encoding used a secret convention between client and server, then we enter the realm of cryptography, and then "it depends".

There is nothing inherently toxic in "binary data"; conversely, there is nothing tame in "characters". Bytes are bytes. If some code has trouble with arbitrary bytes, that it would not have with "characters", then this means that the code in question is interpreting raw bytes as characters, and that's a bug all right. You can call it "corrupted data page tables" if you like; it does not change things in any way: a bug is a bug. It does not occur through accumulation of time; it occurs through programming mistakes or hardware errors. There is no byte value which makes such issues more probable than any other.

What makes bugs more probable are unwarranted assumptions from careless programmers. E.g. a programmer who expects, in his code, some bytes representing characters, and not putting in any code to deal with null bytes or other "invalid" incoming data. That's the deal with attackers: they do not always follow encoding rules. There is no encoding thingy which will protect a careless programmer against carelessness. There are tools which will mitigate consequences, e.g. programming languages which check for array bounds and enforce strong typing; but these operate at another level.