TOP 25 errores más peligrosos en el desarrollo de software

CWE (Common Weakness Enumeration) y la SANS han publicado un estudio donde enumeran los 25 errores de programación mas peligrosos en el desarrollo de software para el año 2011, en la lista encontraremos errores que mucha gente toma como inofensivos pero que realmente abren una brecha de seguridad en sus aplicaciones.

El TOP 25 errores más peligrosos en el software es:

• No filtrar propiamente las sentencias SQL (Inyección SQL) (Puntaje 93.8) (ID CWE-89)
• No filtrar las llamadas al sistema de forma adecuada (Inyección en comandos del SO) (Puntaje 83.3) (ID CWE-78)
• No chequear el tamaño de la memoria reservada a la hora de copiar datos (desbordamiento de memoria) (Puntaje 79.0) (ID CWE-120)
• No detectar la inyección de scripting (XSS) (Puntaje 77.7) (ID CWE-79)
• No autentificar en llamada a funciones críticas (Puntaje 76.9) (ID CWE-306)
• No autorización (Puntaje 76.8) (ID CWE-862)
• Usar credenciales estáticos en el código (Puntaje 75.0) (ID CWE-798)
• No cifrado de datos sensibles (Puntaje 75.0) (ID CWE-311)
• No restringir la subida de ficheros a ciertos formatos (Puntaje 74.0) (ID CWE-434)
• Confiar en una fuente de datos no confiable a la hora de tomar una decisión de seguridad (Puntaje 73.8) (ID CWE-807)
• Ejecución con privilegios innecesarios (Puntaje 73.1) (ID CWE-250)
• Cross-Site Request Forgery (CSRF) (Puntaje 70.1) (ID CWE-352)
• No limitar el acceso al sistema de ficheros a directorios restringidos (Puntaje 69.3) (IDCWE-22)
• Descarga de código sin chequear la integridad del mismo (Puntaje 68.5) (ID CWE-494)
• Autorización incorrecta (Puntaje 67.8) (ID CWE-863)
• Permitir la integración de funcionalidades de fuentes no confiables (Puntaje 66.0) (IDCWE-829)
• Asignación de permisos incorrecta a recursos críticos (Puntaje 65.5) (ID CWE-732)
• Uso de funciones potencialmente peligrosas (Puntaje 64.6) (ID CWE-676)
• User un algoritmo de cifrado que ha sido comprometido o roto (Puntaje 64.1) (ID CWE-327)
• Cálculo incorrecto del tamaño de memoria (Puntaje 62.4) (ID CWE-131)
• No restricción a un número de intentos fallidos de acceso (Puntaje 61.5) (ID CWE-307)
• Redirección URL a sitios no confiables (‘Open Redirect’) (Puntaje 61.1) (ID CWE-601)
• Formato de cadena no controlado (Puntaje 61.0) (ID CWE-134)
• Desbordamiento de enterios (Puntaje 60.3) (ID CWE-190)
• Aplicar una función hash sin usar la sal (Puntaje 59.9) (ID CWE-759)

Si cometes por lo menos uno de estos errores en el desarrollo de tus aplicaciones, no dudes en hacer click en su respectivo ID, donde encontraras toda la información necesaria para entender mejor el problema y corregirlo.

Puedes descargar todo el informe en PDF o verla online en la pagina oficial de la Common Weakness Enumeration.

Fuente: DragonJar

SQL Server 2011 Denali, publica tablas como carpetas compartidas en Windows

He estado probando la nueva Community Tech Preview de SQL Server 2011, cuyo nombre clave es "Denali".

Donde podremos usar una caracterisca en la cual podremos crear un tipo de tabla denominada FileTable. Una FileTable se asigna a una carpeta en el sistema de archivos, aunque no se tiene el propósito de acceder a la carpeta directamente, Esta es administrada por SQL Server. Sin embargo, puede se acceder a la carpeta en el Explorador de Windows, o en la red, como un recurso compartido de red. Al hacer esto, un componente de SQL Server intercepta las llamadas de la API de Windows y las actualizaciones de la FileTable. FileTables se basan en la característica FILESTREAM existentes en SQL Server 2008, y los documentos de la carpeta se almacenan los datos FILESTREAM.

La ilustración muestra una carpeta en el Explorador de Windows que también es un FileTable SQL Server.

¿Es este el regreso de WinFS, el sistema mítico archivo relacional, que se había planeado originalmente para Windows Longhorn, pero que se había abandonado? En realidad no. De acuerdo con la documentación :

FileTables eliminan una importante barrera para el uso de SQL Server para el almacenamiento y gestión de datos no estructurados que residen actualmente en los archivos en servidores de archivos. Las empresas pueden mover estos datos desde los servidores de archivo en FileTables aprovechando  los servicios ofrecidos e integrados de gestión en SQL Server. Al mismo tiempo, pueden mantener la compatibilidad de aplicaciones de Windows para sus aplicaciones existentes de Windows que verán estos datos como archivos en el sistema de archivos.

Fuente: itwriting

Variables de entorno en Windows Azure

Una de las necesidades que puede tener nuestro servicio en la nube es registrar variables de entorno dentro de nuestras máquinas virtuales. En este post vamos a ver las distintas opciones que tenemos para llevar a cabo esta tarea.

Sección Runtime en ServiceDefinition.csdef

La primera posibilidad a la hora de declarar variables de entorno sería a través de la sección Runtime en el archivo de definición del role.

01	<?xml version="1.0" encoding="utf-8"?>

02	<ServiceDefinition name="WindowsAzureEnvironmentVariables"xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">

03	<WebRole name="WebRole">

04	<Runtime executionContext="elevated">

05	<Environment>

06	<Variable name="EnviromentVariable" value="Hello from environment variable!"/>

07	</Environment>

08	</Runtime>

09

<Sites>

10	<Site name="Web">

11	<Bindings>

12	<Binding name="Endpoint1" endpointName="Endpoint1" />

13	</Bindings>

14

</Site>

15

</Sites>

16	<Endpoints>

17	<InputEndpoint name="Endpoint1" protocol="http" port="80" />

18	</Endpoints>

19

<Imports>

20	<Import moduleName="Diagnostics" />

21	</Imports>

22	<ConfigurationSettings>

23	</ConfigurationSettings>

24	</WebRole>

25	<WorkerRole name="WorkerRole">

26

<Imports>

27	<Import moduleName="Diagnostics" />

28	</Imports>

29	</WorkerRole>

30	</ServiceDefinition>

Sin embargo desde la aparición de Full IIS donde nuestro servicio tiene total disponibilidad sobre IIS, e Internet Information Service Hosteable Web Core pasa a un segundo plano, esta opción ya no funciona con propiedad en aquellos roles de tipo Web. El motivo es que esta sección solamente nos permite declarar variables de entorno a nivel de proceso. Para comprobarlo podemos comentar la sección Sites, la cual habilita Full IIS, en el archivo de definición y comprobar de esta forma que podemos recuperar dicha variable a través de la clase Environment sin problemas.

1	Environment.GetEnvironmentVariable("EnviromentVariable");

De lo contrario, al intentar realizar la misma acción mostrada en el código anterior, el resultado de la misma será null.

En el caso de los worker role no es necesario tomar ninguna medida adicional, a no ser que utilicemos múltiples procesos para llevar a cabo las tareas.

Nota: Es importante especificar el contexto de ejecución como elevated ya que, de no ser así, el servicio no arrancará (suele aparecer el mensaje de Aborted…).

Clase Environment

La opción más efectiva a la hora de declarar las variables de entorno sigue siendo a través de la claseEnvironment. Dentro de la misma tenemos varios métodos que nos permitirán definir las variables necesarias con distintos ámbitos. Para ello podemos definir una variable cualquiera de la siguiente forma:

1	Environment.SetEnvironmentVariable("MyNewVariable","New variable for Windows Azure!");

De esta manera lo que estamos haciendo es declarar la variable llamada MyNewVariable con el valor que le sigue en la declaración pero a nivel de proceso, es decir que si cualquier otro proceso que intentara recuperar dicha variable obtendría como resultado null. Por ello, a través de una sobrecarga en este mismo método podemos especificar cuál es el ámbito que queremos que tenga nuestra variable (funcionalidad todavía no disponible en la sección Runtime de ServiceDefinition.csdef  ). Generalmente podemos necesitar tres tipos de ámbitos distintos:

01	using System;

02	using Microsoft.WindowsAzure.ServiceRuntime;

03

04	namespace WebRole

05

{

06	public class WebRole : RoleEntryPoint

07

{

08	public override bool OnStart()

09

{

10	Environment.SetEnvironmentVariable("MyNewVariable", "New variable for Windows Azure!"); //Current Process

11	Environment.SetEnvironmentVariable("MachineVariable", "Hello", EnvironmentVariableTarget.Machine); //All processes

12	Environment.SetEnvironmentVariable("UserVariable", "Hello", EnvironmentVariableTarget.User); //All user processes

13

14	return base.OnStart();

15

}

16

}

17

}

Como podemos ver en el código anterior, dependiendo del target asignado a la hora de la definición de la variable la misma tendrá menor o mayor acceso por parte de los procesos que intenten recuperarlas.

Sección Startup en ServiceDefinition.csdef

Por último una de las necesidades más comunes es la modificación de variables ya existentes como es el caso de Path. Para ello la manera más eficaz sería utilizando el comando REG ADD desde la sección Startup donde podemos lanzar ejecutables. Lo primero que debemos saber es dónde están los valores de las variables de entorno en el registro. Para evitaros la búsqueda, las mismas se encuentran en HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment  .

En el caso de Path vamos a crear un archivo txt e incluimos el siguiente comando:

1	REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment" /v "Path" /t REG_EXPAND_SZ /d "%PATH%;%ProgramFiles%\Microsoft SQL Server\100\Tools\Binn" /f

Con él vamos a conseguir agregar al contenido que ya tenía Path la ruta de Microsoft SQL Server.

Espero que sea de utilidad 

¡Saludos!