example - remarks c#

Funciones explotables de C#

Question

Esta pregunta es similar a las Funciones explotables de PHP .

Los datos contaminados provienen del usuario, o más específicamente de un atacante. Cuando una variable contaminada alcanza una función de sumidero, entonces usted tiene una vulnerabilidad. Por ejemplo, una función que ejecuta una consulta SQL es un receptor, y las variables GET / POST son fuentes de contaminación.

¿Cuáles son todas las funciones de sumidero en C #? Estoy buscando funciones que introduzcan una vulnerabilidad o debilidad del software . Estoy particularmente interesado en las vulnerabilidades de ejecución remota de código. ¿Hay clases / bibliotecas enteras que contengan funcionalidades desagradables que un hacker quiera influenciar? ¿Cómo hace la gente accidentalmente el peligroso código C #?

Answer 1

Aparte del obvio Process.Start() ya mencionado, puedo ver un par de formas de potencial explotación indirecta.

• Llamadas de WinAPI a través de PInvoke a CreateProcess() y otras cosas.
• Cualquier tipo de mecanismo de carga de ensamblaje dinámico utilizando Assembly.Load() y otras sobrecargas. Si un ensamblado comprometido llegó al sistema y se cargó.
• Si se ejecuta con plena confianza en general.
• Con los permisos adecuados, cualquier operación de registro podría ponerlo en riesgo.

Eso es todo lo que viene a la mente en este momento.

Answer 2

Cualquier cosa que use expresiones regulares (particularmente el RegularExpressionValidator). Para ver esto, ejecuta un RegularExpressionValidator con la expresión regular ^(/d+)+$ y dale 30 dígitos y un carácter alfabético para validar.

Algunas publicaciones:

• http://msdn.microsoft.com/en-us/magazine/ff646973.aspx
• http://www.abemiester.com/abemiester/post/RegEx-DOS-attack-Regular-Expressions-Now-you-have-3-problems.aspx (esta es una publicación de blog de mi propio blog que entra en más detalles sobre el artículo de MSDN).

Esto se conoce como ataque de Denegación de Servicio de Expresión Regular y puede hacer que un sitio web se ponga de rodillas.

Answer 3

Cualquier información que obtenga del usuario (o de cualquier otra fuente externa) y que pase a otro sistema u otro usuario es un posible exploit.

Si obtiene una cadena del usuario y la muestra a otro usuario sin utilizar HtmlEncode, es un posible exploit.

Si obtiene una cadena del usuario y la usa para construir SQL, es una posible inyección SQL.

Si obtiene una cadena del usuario y la usa para contratar un nombre de archivo para Process.Start o Assembly.Load es una vulnerabilidad de ejecución remota

Entiende el punto, el peligro proviene de utilizar datos no optimizados, si nunca pasas la entrada del usuario al sistema externo sin desinfectarlo (ejemplo: HtmlEncode) o usando interfaces de inyección segura (ejemplo: parámetros de SQL) estás relativamente seguro, en el momento que olvídate de desinfectar algo, el método más inocente puede convertirse en una vulnerabilidad de seguridad.

Nota: las cookies, los encabezados html y cualquier otra cosa que pase a través de una red también son datos del usuario, en la mayoría de los casos, incluso los datos en su base de datos son datos del usuario.

Answer 4

He visto un código donde el usuario puede establecer el nombre y los parámetros para una llamada de función en una base de datos. El sistema entonces ejecutaría la función nombrada a través de Reflection sin verificar nada ...

Answer 5

OMI: Las n. 1 funciones explotables son inocentes, pero muy peligrosas cuando se usan sin pensar.

En ASP.Net Response.Write o el acceso directo:

 <%= searchTermFromUser %>

En ADO.Net:

• El operador string +
var sql = "SELECT * FROM table WHERE name = ''" + searchTermFromUser + "''"

Answer 6

Probablemente la mitad del marco contiene funciones muy aterradoras. Yo mismo creo que File.WriteAllText() da mucho miedo ya que puede sobrescribir cualquier archivo al que tenga acceso el usuario actual.

Un enfoque diferente a esta pregunta sería cómo puede administrar la seguridad. El artículo en http://ondotnet.com/pub/a/dotnet/2003/02/18/permissions.html contiene una descripción básica sobre el sistema de seguridad .NET, con el espacio de nombres System.Security.Permissions contiene todos los permisos .NET pone a disposición. También puede consultar http://msdn.microsoft.com/en-us/library/5ba4k1c5.aspx para obtener más información.

En resumen, .NET le permite limitar los permisos que un proceso puede tener, por ejemplo, negando métodos que cambian los datos en el disco. Luego puede verificar estos permisos y decidir si el proceso los tiene o no.

Answer 7

Reflection.Emit y CodeDom

Editar :

Permitir complementos o bibliotecas de terceros que utilicen subprocesos puede hacer que toda la aplicación descienda a menos que cargue esas bibliotecas / complementos en un dominio de aplicaciones separado.

Answer 8

Un montón de cosas en System.Net, System.XML, System.IO, (todo lo que toma un URI y / o una ruta de archivo y realmente trata con el recurso que identifican) System.Reflection, System.Security, System.Web, System .Data y System.Threading namespaces puede ser peligroso, ya que se pueden usar para hacer cosas malas que van más allá de solo estropear la ejecución actual. Tanto que tomaría mucho tiempo tratar de identificar cada uno.

Por supuesto, todos los métodos en todas las asambleas de terceros deberán considerarse peligrosos hasta que se demuestre lo contrario. Más tiempo consumiendo de nuevo.

Tampoco creo que sea un enfoque particularmente fructífero. Producir una lista de verificación de funciones solo funciona realmente con una biblioteca limitada, o con un idioma extenso en el que mucho de lo que sería una biblioteca con un lenguaje como C # está en el idioma en sí.

Hay algunos ejemplos clásicamente peligrosos como Process.Start() o cualquier cosa que ejecute otro proceso directamente, pero se equilibran por ser obviamente bastante peligrosos. Incluso un codificador relativamente temerario e incompetente puede tener cuidado cuando usan eso, mientras que dejan datos que se destinan a otros métodos sin esterilizar.

Que el saneamiento de datos es algo más fructífero de mirar que cualquier lista de funciones. ¿Se validan los datos para eliminar entradas obviamente incorrectas (que pueden deberse a un ataque, o simplemente pueden ser un error) y se codifican y escapan de la manera apropiada para una capa determinada (se habla demasiado sobre secuencias de caracteres "peligrosas"). , '' nunca le hicimos daño a nadie, no se escapó correctamente para SQL, eso puede doler cuando se encuentra en una capa SQL; el trabajo requerido para asegurarse de que los datos lleguen correctamente es el mismo para evitar exploits). Son las capas en las que la comunicación con algo fuera del código es sólida. Por ejemplo, los URI se construyen con entradas no examinadas; si no, puede convertir algunos de los métodos System.Net y System.XML utilizados con más frecuencia en agujeros.

Answer 9

Usar cualquier tipo de código inseguro puede causar problemas como punteros. Microsoft proporcionó un buen artículo sobre el código inseguro aquí: http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

Answer 10

incluso una simple comparación de cadenas puede ser un problema.

Si una aplicación toma una decisión de confianza basada en los resultados de esta operación String.Compare, el resultado de esa decisión podría ser subvertido al cambiar la CurrentCulture

Eche un vistazo al example . Bastante fácil de perder

Answer 11

Process.Start es el primero en venir a la mente.

Estoy seguro de que WindowsIdentity y gran parte de System.Security también pueden usarse para maldad.

Por supuesto, hay ataques de inyección SQL, pero no creo que eso sea lo que quiere decir (aunque la ejecución remota puede ocurrir a través de SQL Server).

Answer 12

En el lado basado en la web, C # (y, en general, ASP.NET) es comúnmente vulnerable a lo siguiente (elementos enumerados por OWASP Top 10 2013 ). Me doy cuenta de que usted estaba interesado principalmente en las funciones del fregadero, de las cuales cubro algunas, sin embargo, usted preguntó cómo la gente accidentalmente hace el peligroso código C #, así que con suerte le di algunas ideas aquí.

A1-Inyección

Inyección SQL

Generando consultas por concatenación de cadenas.

var sql = "SELECT * FROM UserAccount WHERE Username = ''" + username "''";
SqlCommand command = new SqlCommand(sql , connection);
SqlDataReader reader = command.ExecuteReader();

Esto a menudo puede resolverse mediante consultas parametrizadas , pero si está utilizando una condición IN , actualmente no es posible sin la concatenación de cadenas.

Inyección LDAP

Código como

searcher.Filter = string.Format("(sAMAccountName={1})", loginName);

puede hacer que la aplicación sea vulnerable. Más información here .

Inyección de comando OS

Este código es vulnerable a la inyección de comandos porque el segundo parámetro de Process.Start puede tener comandos adicionales que se le pasan usando el carácter & para agrupar varios comandos

string strCmdText= @"/C dir c:/files/" + Request.QueryString["dir"];
ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText);
Process.Start(info);

por ejemplo, nombre de foldername && ipconfig

A2-Broken Authentication y Session Management

Desconectar

El método predeterminado SignOut Autenticación de SignOut no actualiza nada del lado del servidor, lo que permite que se continúe utilizando un token de autenticación capturado.

Llamar al método SignOut solo elimina la cookie de autenticación de formularios. El servidor web no almacena tickets de autenticación válidos y caducados para una comparación posterior. Esto hace que su sitio sea vulnerable a un ataque de reproducción si un usuario malintencionado obtiene una cookie de autenticación de formularios válida.

Usar el estado de la sesión para la autenticación

Una vulnerabilidad de fijación de sesión podría estar presente si un usuario ha usado el estado de sesión para la autenticación .

A3-Cross-Site Scripting (XSS)

Response.Write (y el acceso directo <%= => ) son vulnerables de forma predeterminada, a menos que el desarrollador haya recordado que HTML codifica la salida. El acceso directo más reciente <%: HTML codifica de manera predeterminada, aunque algunos desarrolladores pueden usar esto para insertar valores en JavaScript, donde aún pueden ser escapados por un atacante. Incluso utilizando el moderno motor Razor es difícil hacer esto bien:

var name = ''@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))'';

ASP.NET de forma predeterminada habilita Validación de solicitud , que bloqueará cualquier entrada de cookies, la cadena de consulta y de datos POST que podrían ser potencialmente maliciosos (por ejemplo, etiquetas HTML). Esto parece funcionar bien con la entrada que llega a través de la aplicación en particular, pero si hay contenido en la base de datos que se inserta de otras fuentes como una aplicación escrita utilizando otras tecnologías, entonces es posible que aún se pueda generar código de script malicioso. Otra debilidad es cuando los datos se insertan dentro de un valor de atributo. p.ej

<%
alt = Request.QueryString["alt"];
%>
<img src="http://example.com/foo.jpg" alt="<%=alt %>" />

Esto puede explotarse sin activar Validación de solicitud:

Si alt es

" onload="alert(''xss'')

entonces esto rinde

<img src="http://example.com/foo.jpg" alt="" onload="alert(''xss'')" />

En versiones anteriores de .NET, era un mine-field de mine-field para un desarrollador asegurarse de que su salida se codificara correctamente utilizando algunos de los controles web predeterminados.

Desafortunadamente, la sintaxis de enlace de datos aún no contiene una sintaxis de codificación incorporada; viene en la próxima versión de ASP.NET

por ejemplo, no vulnerable:

 <asp:Repeater ID="Repeater1" runat="server">
<ItemTemplate>
<asp:TextBox ID="txtYourField" Text=''<%# Bind("YourField") %>''
runat="server"></asp:TextBox>
</ItemTemplate>
</asp:Repeater>

vulnerable:

<asp:Repeater ID="Repeater2" runat="server">
<ItemTemplate>
<%# Eval("YourField") %>
</ItemTemplate>
</asp:Repeater>

Referencias de objetos directos A4-inseguros

El enlace del modelo MVC puede permitir que los parámetros agregados a los datos POST se mapeen en el modelo de datos. Esto puede ocurrir involuntariamente ya que el desarrollador no se ha dado cuenta de que un usuario malintencionado puede modificar los parámetros de esta manera. El atributo Bind se puede usar para prevenir esto .

A5-Misconfiguración de seguridad

Hay muchas opciones de configuración que pueden debilitar la seguridad de una aplicación. Por ejemplo, configurar customErrors en On o habilitar trace.

Los escáneres como ASafaWeb pueden verificar estas configuraciones ASafaWeb comunes.

Exposición de datos sensibles a A6

Hashing predeterminado

Los métodos de hash de contraseña predeterminados en ASP.NET a veces no son los mejores.

• HashPasswordForStoringInConfigFile() : también podría ser malo si se utiliza para hash una contraseña simple sin sal añadida.
• Artículo " Nuestro hashing de contraseña no tiene ropa " con respecto al proveedor de membresía de ASP.NET en .NET 4.

A7-Falta control de acceso a nivel de función

Error al restringir el acceso a la URL

En el modo de canalización integrada, .NET puede ver cada solicitud y los identificadores pueden autorizar cada solicitud, incluso a recursos que no sean .NET (por ejemplo, .js e imágenes). Sin embargo, si la aplicación i se ejecuta en modo clásico, .NET solo ve solicitudes a archivos como .aspx por lo que otros archivos pueden ser accidentalmente no protegidos. Vea esta respuesta para más detalles sobre las diferencias.

por ejemplo, www.example.com/images/private_photograph_user1.jpg es más probable que sea vulnerable en una aplicación que se ejecuta en modo clásico, aunque hay workarounds .

A8-Cross-Site Request Forgery (CSRF)

Aunque las aplicaciones heredadas de formularios web suelen ser más seguras contra CSRF debido a que requieren que el atacante falsifique los valores Ver estado y Validación de eventos , las nuevas aplicaciones MVC podrían ser vulnerables a menos que el desarrollador haya implementado manualmente tokens antifalsificación . Tenga en cuenta que no estoy diciendo que los formularios web no son vulnerables, solo que es más difícil que simplemente pasar algunos parámetros básicos; sin embargo, existen soluciones, como la integración de la clave del usuario en el valor de Ver estado.

Cuando la propiedad EnableEventValidation se establece en true, ASP.NET valida que un evento de control se originó a partir de la interfaz de usuario que fue representada por ese control. Un control registra sus eventos durante el procesamiento y luego valida los eventos durante la devolución de datos o el manejo de devolución de llamada. Por ejemplo, si un control de lista incluye opciones numeradas 1, 2 o 3 cuando se procesa la página, y si se recibe una solicitud de devolución de información que especifica la opción número 4, ASP.NET genera una excepción. Todos los controles controlados por eventos en ASP.NET usan esta característica por defecto.

La función [EnableEventValidation] reduce el riesgo de solicitudes y devoluciones de devolución de datos no autorizadas o maliciosas. Se recomienda encarecidamente que no desactive la validación de eventos.

A10-No validado - Redirecciones y reenvíos

Agregar código como

Response.Redirect(Request.QueryString["Url"]);

hará que tu sitio sea vulnerable El ataque podría iniciarse enviando un correo electrónico de phishing a un usuario que contenga un enlace. Si el usuario está atento, es posible que haya verificado dos veces el dominio de la URL antes de hacer clic. Sin embargo, como el dominio coincidirá con su dominio en el que el usuario confía, hará clic en el enlace sin saber que la página redireccionará al usuario al dominio del atacante.

La validación debe realizarse en la Url para garantizar que sea una URL relativa, permitida o una URL absoluta para uno de sus dominios y páginas permitidos. Es posible que desee comprobar que alguien no esté redirigiendo a sus usuarios a /Logout.aspx por ejemplo. Aunque puede que no haya nada que impida que un atacante vincule directamente a http://www.example.com/Logout.aspx , podría usar el redireccionamiento para ocultar la URL, por lo que es más difícil para un usuario saber a qué página se está accediendo ( http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78 ).

Otros

Las otras categorías de OWASP son:

• A9: uso de componentes con vulnerabilidades conocidas

de los cuales no puedo pensar en ninguna que sea específica de C # / ASP.NET. Actualizaré mi respuesta si pienso en alguna (si cree que son relevantes para su pregunta).