Builder DP and CLR Security

 
.NET and its VM, the Common Language Run-time (CLR), have been designed with security as a top priority.
 
One of the many malicious hacks they are able to withstand is the Buffer Overflow hack.
 
Applications developed in C or C++ that use pointers and pointer manipulation functions could be vulnerable to this hack.
 
In C and C++, strings and arrays are pointers.
 
So, what’s the big deal? Only apps developed in C or C++ are potentially affected by this hack.
 
Well, the "big" deal is that most apps are developed in either C or C++.
 
The strategy in .NET to avoid this problem is two-fold:
Strings are constants, and the Framework has a facility to manipulate strings that is hack-safe.
 
Now, let’s take a closer look at the Builder DP.
 
The GoF book lists Builder as a creational pattern, so its main function is related to the construction of objects.
 
The Intent section for Builder in GoF (page 97) says the following:
"Separate the construction of a complex object from its representation so that the same construction process can create different representations."
 
Some of the consequences listed in GoF for Builder are:
 
"It isolates code for construction and representation."
 
"It gives you finer control over the construction process. Unlike creational patterns that construct products in one shot, the Builder pattern constructs the product step by step …"
 
But how is Builder related to CLR security?
 
The hack-safe facility to manipulate strings in .NET is StringBuilder, which happens to be an implementation of Builder.
 
Since Builder allows step-by-step product construction, it is perfect for tasks like string concatenation.
 
Since Builder separates product construction from product representation (and in this context, "representation" means conversion to string), CLR security is enforced by design.
 
Step by step product construction enables the abstraction of string manipulation, in such a way that it is hack-proof.
 
The conversion to string is independent of either the construction process or the internal structure.
 
Once again, abstraction plays a major role in solving design problems with grace and elegance.
 
In this case, the abstraction of the concept "representation" is used to the fullest (representation = mapping = conversion) to provide hack safety.
 
In Builder, abstraction is played as "separation of concerns". This "separation" is the key behind security.
We should be aware of the fact that these security measures are only available to managed code.
 
 
El patrón Builder y la seguridad del CLR
 
.NET y su VM, el Common Language Run-time (CLR), han sido diseñados con la seguridad como una prioridad primaria.
Uno de los hacks maliciosos que ellos pueden tolerar es el hack de Buffer Overflow.
 
Las aplicaciones desarrolladas en C o C++ que usan punteros y funciones de manipuleo de punteros podrían ser vulnerables a este hack.
 
En C y C++, los strings y los arrays son punteros.
 
Pero, porqué tanto alboroto con esto? Solo las aplicaciones desarrolladas en C o C++ estarían potencialmente afectadas por este hack.
 
Bueno, el alboroto se debe a que muchas aplicaciones están desarrolladas en  C o C++.
 
La estrategia en .NET para evitar este problema tiene dos partes:
Los strings son constantes, y el Framework cuenta con una solución para manipular strings que es hack-safe.
 
Ahora, veamos con más detalle el DP Builder.
 
El libro GoF lista a Builder como un patrón de creación, de tal forma que su función principal esta relacionada con la construcción de objetos.
La sección de Intención para Builder en GoF (página 97 en el original), dice lo siguiente:
 
“Separar la construcción de un objeto complejo de su representación de tal forma que el mismo proceso de construcción puede crear diferentes representaciones.”
Algunas de las consecuencias listadas en GoF para Builder son:
 
“Aísla el código de construcción del código de representación.”
“Brinda mayor control sobre el proceso de construcción. A diferencia de aquellos patrones de creación que construyen productos en una movida, el patrón Builder construye el producto paso a paso …”
 
Pero cómo es que Builder esta vinculado con la seguridad del CLR?
La solución hack-safe que manipula strings en .NET es StringBuilder, que resulta ser una implementación de Builder.
 
Dado que Builder permite una construcción paso a paso, es perfecta para tareas tales como la concatenación de strings.
Puesto que Builder separa la construcción del producto de la representación del mismo (y en este contexto, “representación” significa conversión a string), la seguridad del CLR es garantizada por diseño.
 
La construcción paso a paso del producto permite una abstracción del proceso de manipulación de strings, en una forma tal que resulta a prueba de hacks.
 
Por su parte, la conversión a string es independiente tanto del proceso de construcción como de la estructura interna del objeto.
Nuevamente, la abstracción juega un rol fundamental en la resolución de problemas de diseño, con gracia y elegancia.
 
En este caso, la abstracción del concepto “representación” es usada al máximo  (representación = mapeo = conversión) para proveer hack safety.
En Builder, la abstracción se expresa como “separación de intereses”. Esta “separación” es la clave detrás de la seguridad.
 
Deberíamos tener presente el hecho que estas medidas de seguridad solo están disponibles en managed code.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s