Are regular expressions vulnerable to code injection?

Question

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.

Answer 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.

Answer 2

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.