Assess Deny of Service risk and potentially limit the buffer size

[ririsoft]

Initially discussed in #21, stripping of data (such white spaces) at the beginning of input buffer can lead to a Denial Of Service for inputs with a very large amount of data to be stripped before reaching the content to be actually sniffed.

Shall we:

1. Ignore this issue because we believe there is no such risk.
2. Let the caller be responsible for this. In such case we should comment this at crate level.
3. Restrict the size of the buffer globally?
4. Restrict the size of the buffer for matchers expose to this risk?

[paolobarbolini]

I looked into it and most matchers don't seem to be affected by the size of the input buffer.

Some of them are a bit more sophisticated, like

image

https://github.com/bojand/infer/blob/f4635f81b925eaa21c82f3f9f5142a47fe479063/src/matchers/image.rs#L81-L160

here at line 153 a malicious user could set a very big number (they would still be limited by a u32::MAX) and make us iterate over the entire buffer. If it's necessary we could put a limit to the number of iterations.

doc

https://github.com/bojand/infer/blob/f4635f81b925eaa21c82f3f9f5142a47fe479063/src/matchers/doc.rs#L69-L175

Here it's doing a lot of stuff to try to recognize what type of document it is, but it still feels under control. The range on the search fn is hard coded by us, everything else seems ok.

[ririsoft]

Good catch for the image loop size 👍