17

I think it's OK to post this because it's already clear that null bytes can be entered into posts and comments, and possibly other fields.

If one takes a look at this answer , it's clear that one can use null bytes to circumvent minimum character limits. However, this can create problems well beyond circumvention of minimum character limits.

This is an instance of CWE-158 and is a potential security risk, creating the risk of attacks such as poison null bytes (CWE-626; see also Hakipedia article). The Stack Exchange team should strongly consider stripping any null bytes from any field where a user can enter text at the time it is submitted.

Edit: For those who aren't seeing the null bytes, I suspect that the browser is neutralizing the null bytes, replacing them with spaces. Firefox 15 on Windows 7 is rendering the null bytes. You may be able to see them if you use a program such as Wireshark to read the raw HTML as you load the page.

Edit 2: I'm not able to see any null bytes in Wireshark. I got null bytes when I pasted it to HxD, but when I pasted it into Notepad++ with the correct encoding, saved the file, and opened it in HxD, I saw proper Unicode e2 80 8b. It turns out HxD did not read the Unicode correctly, so this is .

17
  • 15
    ‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮‮
    – Naftali
    Aug 31, 2012 at 13:04
  • Hmmmm I see the issue ^ [That was a bunch of RTL characters btw]
    – Naftali
    Aug 31, 2012 at 13:05
  • 2
    At last, it's your time to shine!
    – user229044
    Aug 31, 2012 at 13:45
  • Wait, didn't we filter those out a long time ago due to people abusing them for fun and profit? I could have sworn we did, or was that just whitespace?
    – Tim Post
    Aug 31, 2012 at 14:29
  • 11
    It's absolutely not clear if null bytes can be entered into posts and comments. Unicode zero-width space characters, byte order markers and RTL indicators have nothing to do with the null bytes discussed in those security advisories.
    – sth
    Aug 31, 2012 at 14:52
  • When I try to submit a post containing 0x00 bytes, I get the "body is missing" error. Can you elaborate on how this is used to circumvent the length limit?
    – Jeremy
    Aug 31, 2012 at 16:48
  • (I get that error if there are any NULs, not just if the message is only NULs, but maybe setting NUL chars w/ JS is different.) I'd also like to know how you could tell that there were NUL bytes in Welbot's post, according to your hex editor. As far as I can tell (maybe I'm using the wrong commands), they don't appear to be in the source of the on the edit page (curl http://meta.stackoverflow.com/posts/10518/edit | hexdump -C | grep " 00 ") or the question page (curl http://meta.stackexchange.com/questions/10504/enforcing-a-question-minimum-character-length/ | hexdump -C | grep " 00 ").
    – Jeremy
    Aug 31, 2012 at 16:57
  • I clicked on the 'edit' link, hit Control-A to select all of the (invisible) text, and pasted it into the HxD hex editor. The editor showed 0x00--null bytes.
    – bwDraco
    Aug 31, 2012 at 17:27
  • 3
    @DragonLordtheFiery Ah... when I try the same thing (select-all, copy, then pbpaste | hexdump) I actually see e2 80 8b repeatedly - the non-breaking space character.
    – Jeremy
    Aug 31, 2012 at 18:12
  • @TheElementofMagic - When I request that page and look at the response in Fiddler HexView I see the exact same thing as you. Aug 31, 2012 at 18:55
  • It works if I copy null bytes from a source and paste it into the field. This could be due to the way the browser is rendering it. On Firefox 15, the null bytes are indeed being rendered. Try using Wireshark to extract the HTML being sent over the network.
    – bwDraco
    Aug 31, 2012 at 21:45
  • @DragonLordtheFiery - The bytes sent over the network are compressed. Fiddler just uncompresses it without changing anything AFAIK and shows e2 80 8b Aug 31, 2012 at 21:55
  • @MartinSmith, what OS and browser are you running? Also, have you refreshed the page bypassing the cache?
    – bwDraco
    Aug 31, 2012 at 22:09
  • Doubt it makes any difference what OS and browser I'm using as fiddler acts as a proxy between the browser and the server. Have you actually bothered looking at the network traffic your end as you are advising others to do? If you confirm you have and you see something different I'll let you know. Aug 31, 2012 at 22:17
  • I captured the network traffic for the edit page using WireShark and used its built-in HTTP filter to decompress the traffic. There are no NUL bytes. I think this report is in error. [CC @MartinSmith]
    – Jeremy
    Aug 31, 2012 at 22:19

1 Answer 1

5

While you may have posted your answer with null bytes, and that may have let you circumvent the minimum character limit, the post is not, in fact, served with null bytes, and so there is no related security issue.

If you see any null bytes in this post, it's because your browser is mangling it. Report a bug against your browser.

You can download the HTML file and look at the source. You'll see:

    <div class="post-text"><p>​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​</p>
</div>

This may not be very visible: there's a bunch of U+200B ZERO WIDTH SPACE between the <p> and the </p>. An alternate way to write the same content would be.

    <div class="post-text"><p>&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;&x200B;</p>
</div>

You get the same content from the API version 1 or API version 2.

I checked Firefox 10 (Iceweasel from Debian squeeze) and Chrome stable (21.0.1180.81), and both do render zero-width spaces.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .