Fix ReDoS with autolink

[Alcaro]

Patterns like <<<<<<<<<<:/:/:/:/:/:/:/:/:/:/ currently exhibit O(n^3) complexity, allowing a 5KB document to take 7174ms to parse. With this change, it drops to O(n^2) and 73ms.

Tested with

<script src="simple-markdown.min.js"></script>
<script>
var str = "<".repeat(2000)+":/".repeat(1500);
var t1 = performance.now();
SimpleMarkdown.defaultInlineParse(str);
var t2 = performance.now();
document.write(str.length+" bytes, "+(t2-t1)+"ms");
</script>

This PR will change parsing of weird things like <foo:bar:/baz>. If you'd prefer leaving behavior 100% unchanged, the regex can instead be changed to /^<(?=[^ >]+:\/)([^ >]+)>/, with no meaningful performance difference.

What is the project policy for what counts as a DoS? Quadratic complexity is fine, anything higher is a bug? More than 1ms per byte on a 10KB document is a bug? Anything superlinear is a bug? If the latter, I can name a few other inputs with quadratic runtime.

[ariabuckles]

This looks great; thanks for contributing it! I think the parsing change is fine.

Yeah, I think anything superlinear is probably a problem. If you have examples I'd be happy to look into and fix them, or happy to accept your fixes! (I haven't done a lot of measuring times per document size, but I expect if we had everything linear most of those would be fine too.)

[ariabuckles]

Actually, I might have missed something: what's still quadratic about the fixed version here? The whole parse, or the individual autolink match?

I think the whole parse in general will be quadratic as it may re-run any regex for each character in the worst case (like your example), but the matchers themselves should ideally all be linear.

[Alcaro]

I'm referring to it being quadratic (formerly cubic) in the entire parse. All other superlinears I'm aware of mean quadratic documents as well, per my definition. I apologize for the confusion, I should've been clearer.

I wrote this analysis of the quadratic documents before you submitted your second post, so I'll post it even though it's not necessarily interesting.

<<<<<<<<<<<<<<<<<<<< - autolink tries to start at every one, fails because no :/ (and no >). Could be fixed by rejecting < in autolinks, but unless the other quadratic documents are fixed, fixing this doesn't really solve anything.
******************** - the outermost pair of asterisks become italics, which is parsed recursively. The inner parser also sees a long string of asterisks, and turns the outermost into italics; repeat until there's only one or two asterisks left. Can be fixed by rejecting recursive italics, but that'd be more effort than it's worth. And the strong rule would most likely require something similar.
____________________ - same as the above. Still italics, even.
\``\``\``\``\``\``\``\``\``\`` - the first backtick is a perfectly normal escape. Second one tries to find a sequence of exactly 1 backtick so it can close, but all subsequent ones are doubles, so it scans to the end of the string and fails, emitting a single plaintext backtick. Next up is a backslash, which eats the third backtick, and the fourth one scans to the end again. I cannot think of any way to fix this without altering parsing of realistic documents.

There are most likely other ways to cause quadratic (or worse) document parsing; I didn't check all parsing rules. Some of them exceed my brain capacity.

[ariabuckles]

Thanks & sorry for the late reply! That was a thoughtful and helpful explanation!

I think you're right in that right now the quadratic document cases would be pretty challenging to address without a major re-thinking of how this works. I believe most parsing algorithms are quadratic in the worst case, so while we could probably do better for markdown specifically, that might be generally okay.

There are most likely other ways to cause quadratic (or worse) document parsing; I didn't check all parsing rules. Some of them exceed my brain capacity.

I've generally tried to check these visually as well, but as in this example, I don't always see them. If you run into any more, I'd love to hear about them so we can fix them :).

Thanks again for your comments and PR here and for making this project better for everyone!