Ruby 4 should do what every other sane programming language does and require users to opt into multi-line mode via the /m flag.
The fact that Ruby has this behavior at all is a major security issue.
The dangers of single line regular expressions
101–110 of 133 posts
Re: The dangers of single line regular expressions
#102Earlier quoted context omitted.
>If a user wants their title to be “hello%0a%3C%25%3D%20File.open%28%27flag.txt%27%29.read%20%25%3E”, so be it. that's a good way to horizontally propagate/reflect XSS and other Code As Data vulnerabilities. better to strip the known-bad/problematic characters https://en.wikipedia.org/wiki/Code_as_data
And that's how you end up pissing off users with apostrophes in their names.
"Alright. If you’re gonna go ahead with it, I want to make sure you get one thing right. It’s “O’Neill,” with two L’s. There is another Colonel O’Neil with only one L and he has no sense of humor at all."
Re: The dangers of single line regular expressions
#103[flagged]
Re: The dangers of single line regular expressions
#104[dead]
Re: The dangers of single line regular expressions
#105[flagged]
Re: The dangers of single line regular expressions
#106This was interesting and new to me, but as other commenters indicate, part of the problem is that we're trying to find the bad thing rather than trying to verify it is the good thing There's a related concept of "failing open vs failing closed" (fail open: fire exit, fail closed: ranch gate) In Jurassic park (amazing book/film to understand system failures), when the power goes out, the fence is functionally an open…
I don't think this is a good example, because the regex does just that: it doesn't try to filter out bad input, it specifically only accepts known good input. If the regex did what it was meant to do, only allowing strings composed of ascii letters and numbers, and space, than the code would have not been exploitable.
Still seems like that is broken. Shouldn't they be escaping whatever control characters? Like if your user wanted to highlight "Now 75% off". Seems like it is reasonable to want to allow that.
Re: The dangers of single line regular expressions
#107Earlier quoted context omitted.
I don't think this is a good example, because the regex does just that: it doesn't try to filter out bad input, it specifically only accepts known good input. If the regex did what it was meant to do, only allowing strings composed of ascii letters and numbers, and space, than the code would have not been exploitable.
Still seems like that is broken. Shouldn't they be escaping whatever control characters? Like if your user wanted to highlight "Now 75% off". Seems like it is reasonable to want to allow that.
That's a completely different problem: it may be too closed. But it's definitely not a fail open system. It's a fail closed system with a bug.
Re: The dangers of single line regular expressions
#108[flagged]
Re: The dangers of single line regular expressions
#109[dead]
Re: The dangers of single line regular expressions
#110[dead]