Good,

I am no friend of the regular expressiones, it is probably because except the simplest, they tend to be a hell of characters in a single line that can save you work but give you more than one headache. Also added to the number of examples on the internet of different regex for all kinds of scenarios, because things can go very wrong almost without realizing.

¿Why it can go wrong?, because because more that seems it not, solving a RegExp, it must be processed the same and this process, depending on the input data may give rise to very long process times or inclisve memory leaks.

¿What now you looks so nice that copying a line of internet and put it in your code?

The MSDN Magazinearticle: “Regular Expression Denial of Service Attacks and proactive” deals with this topic and also shows how bad RegExp implementation can lead to DoS attacks.

In addition, the results of an evaluation of a RegExp we can create a bug directly in Team Foundation Server 2010. This tool is part of SDL (Security Development Lifecycle) and integration with TFS is minimal, us allows create Bugs in Team Foundation Server.

For example, if we analyze the RegExp “^(\d|\d?)”+$“, with one of the more ugly forms I’ve seen in a long time ”:

From it we can create a Bug in our Team Project

with the fields:

Title: Exponential execution time in regular expression pattern ^(\d|\d?)+$

Description: The regular expression pattern ^(\d|\d?)+$ can operate in a worst – case exponential execution time, potentially causing a denial of service to the application.

and leave it as a point to be solved without it slip 

So now you know, before using a RegExp, give a review with this tool to analyze vulnerabilities.

Greetings @ Here

The Bruno

Download: http://www.microsoft.com/download/en/details.aspx?id=20095

Reference: http://msdn.microsoft.com/en-us/site/ff646973

Security Development LifeCycle: http://blogs.msdn.com/b/sdl/archive/2010/10/12/new-tool-sdl-regex-fuzzer.aspx

Buenas,

yo no soy muy amigo de las expressiones regulares, seguramente es porque salvo las más simples, suelen ser un infierno de caractéres en una single line que pueden ahorrarte trabajo pero darte más de un dolor de cabeza. Además sumado a la cantidad de ejemplos que hay en internet de diferentes expresiones regulares para todo tipo de escenarios, pues la cosa puede ir muy mal casi sin darte cuenta.

¿Por qué puede ir mal?, pues porque por más que no lo parezca, para resolver una RegExp, hay que procesar la misma y este proceso, dependiendo del dato de entrada puede dar lugar a tiempos de proceso muy largos o inclisve memory leaks.

¿A qué ahora no te parece tan bonito eso de copiar de internet una línea y ponerla en tu código?

El artículo de la MSDN Magazine: “Regular Expression Denial of Service Attacks and Defenses” trata este tema y además nos muestra como la mala implementación de RegExp puede llevar a ataques DoS.

Además, a partir del resultado de una evaluación de una RegExp podemos crear un bug directamente en Team Foundation Server 2010. Esta herramienta es parte de SDL (Security Development Lifecycle) y si bien la integración con TFS es mínima, nos pemite crear Bugs en Team Foundation Server.

Por ejemplo si analizamos la RegExp “^(\d|\d?)+$”, con uno de los formularios más feos que he visto en mucho tiempo:

A partir de la misma podremos crear un Bug en nuestro Team Project

con los campos:

Title: Exponential execution time in regular expression pattern ^(\d|\d?)+$

Description: The regular expression pattern ^(\d|\d?)+$ can operate in a worst-case exponential execution time, potentially causing a denial of service to the application.

y dejarlo como un punto a solucionar sin que se nos escape

Asi que ya sabes, antes de utlizar una RegExp, darle un repaso con esta herramienta para analizar vulnerabilidades.

Saludos @ Here

El Bruno

Descarga: http://www.microsoft.com/download/en/details.aspx?id=20095

Referencia: http://msdn.microsoft.com/en-us/site/ff646973

Security Development LifeCycle: http://blogs.msdn.com/b/sdl/archive/2010/10/12/new-tool-sdl-regex-fuzzer.aspx