3

Aside from having an excessive input length, is there a way of doing an exploit with a regular expression (assuming the underlying language/platform is secure)?

Practically I was wondering if the following solution in StackOverflow for using LIKE-like queries in MongoDB would be secure namely:

var query = { Zip: new RegExp('^' + zipCode) };
collection.find(query);

I know they can put in invalid queries but that's not relevant.

1

If the buffer holding the regular expression is of sufficient length and regular expression parser is implemented using a regular language and not using a Turing complete language (more accurately, using the regular-language-instruction subset of a Turing complete language), it should be impossible to do code injection. A feature of regular languages is that very simple cases and control flow is sufficient to implement the parser. If implemented with these simple programming tools, then hacks should be very difficult.

Please keep in mind that one of the biggest vulnerabilities is the buffer-overrun code-injection attack. The way to avoid this attack is to write really tight and accurate code. Check your buffer length in maniacal fashion to avoid problems.

  • 1
    I'm not sure that you answered the question. The OP is asking whether using a specific MongoDB function call is secure, but your answer is discussing the theory of RE parsing. You don't state if that MongoDB call uses a regular language (I bet it doesn't). Nor do you state if that function uses appropriate buffer length checking. – Neil Smithline Mar 19 '16 at 13:40
  • Well, my comment happens to apply to all RE parsers, including MongoDB. All one needs to do is a code review and keep in mind the principles of tight, secure coding. MongoDB appears to be open source. – Brent Kirkpatrick Mar 19 '16 at 18:26
0

I don't think your question has sufficient detail for a definitive answer. The code you post appears to be creating a map with a key of Zip and a value which is a regular expression. All we can tell is that the regular expression will start with the '^". It appears that the ^ is appended with the 'real' regexp, called zipCode, but we cannot determine what that is or what it will match from what is provided. I suspect it will be a number class with a count specification with the number of digits which are allowed for a zip code, but that is a guess.

In general, there is nothing special about regular expressions in themselves which will ensure a query is secure or safe. You can use a regular expression to sanitize or escape input so that it is safe, but how well that works depends on how well the regular expression is written. My experience has taught me there are far more badly written regular expressions out there than well written ones.

However, this might be a mute point depending on how the actual database query is executed. If the regular expression is used simply to clean or validate input AND that input is only used as parameters in a prepared statement, then there probably isn't an issue. However, if the regular expression is used to pre-parse a string which is then either appended to a string which is then executed as the query, then you could have big problems.

In general, sql injection and code injection in scripting languages are very similar. In SQL, you are vulnerable when you build up a dynamic query using strings and concatenation and one of the strings is provided by the user. This is a very easy way to have very dynamic SQL statements which is tempting due to the flexibility it gives your end user. the problem is the end user can enter malicious code and cause all sorts of problems for you. Likewise, in scripted languages, the same problem can occur with the infamous 'eval' statement, which allows you to define code to be evaluated at run time.

The basic fix for SQL is to not use dynamically generated SQl statements. Instead, use prepared statements which accept arguments. With prepared statements, the supplied arguments are not 'executed' in the same sense theya re when concatenated onto an SQl statement. Well written SQl engines will take the parameters and perform various checks to ensure they are valid. this does not happen with a dynamic SQL statement built from concatenated strings.

If you have no other option than to use a dynamic SQl statement, then you can use a regular expression to sanitize the values the user provides i.e. escape or remove characters which could cause problems. If done correctly, then it should work well. However, it is hard to do correctly. The regexp can quickly become complex and complexity means it is easier to make a subtle mistake. The approach also relies on the person writing the expression to be aware of all the subtle injection tricks. I've seen some Oracle SQL injection techniques which were really surprising and not something I would have thought of (such as using a combination of environment variable settings relating to date formats and cleverly crafted SQL date format strings which on the surface appear to be quite legitimate. For this reason, I would avoid relying on a regular expression approach to protect against code injection and would instead use things like stored procedures and prepared statements instead. This also has the advanage of making it much easier to test your application and verify things like performance. Allowing dynamic queries, even if the input is sanitized, can be a nightmare with regards to performance. You can easily end up with a denial of service issue if a user just happens to enter a legal, but extremely long running and resource intensive query. In production systems, it is very rare that you will want your customers to be able to execute any type of query - they will usually be reducable to a subset, which may be large or complex, but which can be mapped to stored proceures and prepared statements.

There are other possible issues with regexp, such as vulnerabilities in the regexp engine, buffer overflow vulnerabilities etc. I'm not raising these as I think they are far less likely than simply exposure through badly written regexp. They will also tend to be implementation specific.

  • Its just a simplistic example where I just want to execute an arbitrary regexp that is taken from the an "unsecure" source. As long as it is not possible to do something like :(){ :|: & };: (fork bomb askubuntu.com/questions/159491/…) I am more content with the previous, more direct answer. – Archimedes Trajano Mar 19 '16 at 5:02
  • If your regular expression is coming from an insecure source, then you definitely have a security problem and you can definitely inject malicious code via the regular expression. Remember, any string of characters is a regular expression (which only matches itself) and all regular expression engines allow you to escape characters with 'special' meanings so you can escape the |, (, {, etc to easily generate the fork bomb you reference. – Tim X Mar 20 '16 at 2:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.