¿Qué es XSS Reflejado?

 Este es el primero de una serie de artículos relacionados con la seguridad. 

• Los 10 principales riesgos de seguridad de las aplicaciones web  
• Inyección SQL 
• Falsificación de solicitud del lado del servidor (SSRF)
  • Ejemplo de falsificación de solicitud del lado del servidor
• Falsificación de solicitud entre sitios (CSRF)
• Secuencias de comandos entre sitios (XSS)
  • Ejemplo de Cross-Site Scripting, reflejado ---  este artículo
  • Ejemplo de Cross-Site Scripting, DOM
• Secuencias de comandos entre fotogramas (XFS)
  • Ejemplo de secuencias de comandos entre fotogramas
• Comparaciones entre SSRF, CSRF, XSS y XFS 
• CORS (1), consumir .NET Core Web API por MVC en el mismo origen

Este artículo es parte de  Cross-Site Scripting (XSS) , este es un ejemplo de un problema real de alta seguridad creado por  Fortify Static Code Scanning.

Esta es la estructura de este artículo,

• F-0: Introducción
• F-1: Resumen
• F-2: Detalles
• F-3: Ejemplo
• F - 4: Recomendación
• F - 5: La solución o sugerencia
• F - 6: Falso positivo aceptado

F-1: Resumen

El XSS reflejado  es la variedad más simple de secuencias de comandos entre sitios. Surge cuando una aplicación recibe datos en una solicitud HTTP y los incluye dentro de la respuesta inmediata de forma no segura. Aquí hay un ejemplo simple de una   vulnerabilidad XSS reflejada :

https://insecure-website.com/status?message=All+is+well. <p>Status: All is well.</p>

Margen

La aplicación no realiza ningún otro procesamiento de los datos, por lo que un atacante puede construir fácilmente un ataque como este:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script> <p>Status: <script>/* Bad stuff here... */</script></p>

Margen

Si el usuario visita la URL construida por el atacante, la secuencia de comandos del atacante se ejecuta en el navegador del usuario, en el contexto de la sesión de ese usuario con la aplicación. En ese momento, el script puede realizar cualquier acción y recuperar cualquier dato al que el usuario tenga acceso.

En nuestro caso , el siguiente código envía datos no validados a un navegador web en la línea 378, lo que puede provocar que el navegador ejecute código malicioso.

F-2: Detalles

Las vulnerabilidades de secuencias de comandos entre sitios (XSS) ocurren cuando:

• Los datos ingresan a una aplicación web a través de una fuente no confiable. En el caso de XSS reflejado , la fuente que no es de confianza suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos de back-end. En este caso, los datos ingresan en get_Text() en CSR_UserInfo.aspx.cs en la línea 43.

• Los datos se incluyen en contenido dinámico que se envía a un usuario web sin validación. En este caso, los datos se envían en Write() en AdminBasePage_Transactions.cs en la línea 378.

El contenido malicioso que se envía al navegador web suele adoptar la forma de un segmento de JavaScript, pero también puede incluir HTML, Flash o cualquier otro tipo de código que ejecute el navegador. La variedad de ataques basados ​​en XSS es casi ilimitada, pero comúnmente incluyen la transmisión de datos privados como cookies u otra información de la sesión al atacante, redirigir a la víctima al contenido web controlado por el atacante o realizar otras operaciones maliciosas en la máquina del usuario bajo el apariencia del sitio vulnerable.

F-3: Ejemplo

Ejemplo 1

El siguiente formulario web de ASP.NET lee un número de ID de empleado de una solicitud HTTP y se lo muestra al usuario.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

Margen

Donde Login y EmployeeID son controles de formulario definidos de la siguiente manera:

<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>

Margen

Ejemplo 2

El siguiente segmento de código ASP.NET muestra la forma programática de implementar el ejemplo 1.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

C++

El código de estos ejemplos funciona correctamente si Login contiene solo texto alfanumérico estándar. Si Login tiene un valor que incluye metacaracteres o código fuente, el navegador web ejecutará el código cuando muestre la respuesta HTTP.

Inicialmente, esto podría no parecer una gran vulnerabilidad. Después de todo, ¿por qué alguien ingresaría una URL que hace que se ejecute un código malicioso en su propia computadora? El peligro real es que un atacante cree la URL maliciosa y luego use el correo electrónico o trucos de ingeniería social para atraer a las víctimas para que hagan clic en un enlace. Cuando las víctimas hacen clic en el enlace, sin saberlo, reflejan el contenido malicioso a través de la aplicación web vulnerable y de regreso a sus propias computadoras. Este mecanismo de explotación de aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3

El siguiente formulario web de ASP.NET consulta una base de datos para un empleado con una identificación de empleado determinada e imprime el nombre correspondiente a la identificación.

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>

Margen

Donde EmployeeName es un control de formulario definido de la siguiente manera:

<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>

Margen

Ejemplo 4

El siguiente segmento de código ASP.NET es funcionalmente equivalente al Ejemplo 3, pero implementa todos los elementos del formulario mediante programación.

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;

C#

Al igual que en el Ejemplo 1 y el Ejemplo 2, estos ejemplos de código funcionan correctamente cuando los valores de nombre se comportan bien, pero no evitan las vulnerabilidades si los valores no lo hacen. Nuevamente, estos pueden parecer menos peligrosos porque el valor del nombre se lee de una base de datos, cuyo contenido aparentemente es administrado por la aplicación. Sin embargo, si el valor del nombre se origina a partir de datos proporcionados por el usuario, la base de datos puede ser un conducto para el contenido malicioso. Sin una validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos maliciosos en el navegador web del usuario. Este tipo de exploit, conocido como XSS persistente (o almacenado), es particularmente insidioso porque la indirección causada por el almacenamiento de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a múltiples usuarios. XSS comenzó de esta forma con sitios web que ofrecían un "libro de visitas" a los visitantes. Los atacantes incluirían JavaScript en las entradas de su libro de visitas, y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malicioso.

Como demuestran los ejemplos, las vulnerabilidades XSS son causadas por un código que incluye datos no validados en una respuesta HTTP. Hay tres vectores por los que un ataque XSS puede llegar a una víctima:

• Como en el Ejemplo 1 y el Ejemplo 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los exploits XSS reflejados ocurren cuando un atacante hace que un usuario suministre contenido peligroso a una aplicación web vulnerable, que luego se refleja al usuario y lo ejecuta el navegador web. El mecanismo más común para entregar contenido malicioso es incluirlo como parámetro en una URL que se publica públicamente o se envía por correo electrónico directamente a las víctimas. Las URL construidas de esta manera constituyen el núcleo de muchos esquemas de phishing, en los que un atacante convence a las víctimas para que visiten una URL que hace referencia a un sitio vulnerable. Después de que el sitio refleje el contenido del atacante al usuario, el contenido se ejecuta y procede a transferir información privada, como cookies que pueden incluir información de la sesión, del usuario.
• Como en el Ejemplo 3 y el Ejemplo 4, la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos confiable. Posteriormente, los datos peligrosos se vuelven a leer en la aplicación y se incluyen en el contenido dinámico. Los exploits XSS persistentes ocurren cuando un atacante inyecta contenido peligroso en un almacén de datos que luego se lee e incluye en el contenido dinámico. Desde la perspectiva de un atacante, el lugar óptimo para inyectar contenido malicioso es un área que se muestra a muchos usuarios oa usuarios particularmente interesantes. Los usuarios interesantes suelen tener privilegios elevados en la aplicación o interactúan con datos confidenciales que son valiosos para el atacante. Si uno de estos usuarios ejecuta contenido malicioso, el atacante puede realizar operaciones privilegiadas en nombre del usuario u obtener acceso a datos confidenciales que pertenecen al usuario.
• Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, los datos peligrosos se vuelven a leer en la aplicación como datos confiables y se incluyen en el contenido dinámico.

F - 4: Recomendación

La solución para XSS es garantizar que la validación se realice en los lugares correctos y que se verifiquen las propiedades correctas.

Debido a que las vulnerabilidades XSS ocurren cuando una aplicación incluye datos maliciosos en su salida, un enfoque lógico es validar los datos inmediatamente antes de que abandonen la aplicación. Sin embargo, debido a que las aplicaciones web a menudo tienen un código complejo e intrincado para generar contenido dinámico, este método es propenso a errores de omisión (falta de validación). Una forma efectiva de mitigar este riesgo es realizar también la validación de entrada para XSS.

Las aplicaciones web deben validar su entrada para evitar otras vulnerabilidades, como la inyección SQL, por lo que generalmente es relativamente fácil aumentar el mecanismo de validación de entrada existente de una aplicación para incluir comprobaciones de XSS. A pesar de su valor, la validación de entrada para XSS no reemplaza una validación de salida rigurosa. Una aplicación puede aceptar entradas a través de un almacén de datos compartido u otra fuente confiable, y ese almacén de datos puede aceptar entradas de una fuente que no realiza una validación de entrada adecuada. Por lo tanto, la aplicación no puede confiar implícitamente en la seguridad de este o cualquier otro dato. Esto significa que la mejor manera de prevenir vulnerabilidades XSS es validar todo lo que ingresa a la aplicación y sale de la aplicación destinada al usuario.

El enfoque más seguro para la validación de XSS es crear una lista de permitidos de caracteres seguros que pueden aparecer en contenido HTTP y aceptar entradas compuestas exclusivamente por caracteres del conjunto aprobado. Por ejemplo, un nombre de usuario válido puede incluir solo caracteres alfanuméricos o un número de teléfono puede incluir solo dígitos del 0 al 9. Sin embargo, esta solución a menudo no es factible en aplicaciones web porque muchos caracteres que tienen un significado especial para el navegador deben considerarse entradas válidas después de codificarse, como un tablero de anuncios de diseño web que debe aceptar fragmentos HTML de sus usuarios.

Un enfoque más flexible, pero menos seguro, es implementar una lista de denegación, que rechaza o escapa selectivamente los caracteres potencialmente peligrosos antes de usar la entrada. Para formar una lista de este tipo, primero debe comprender el conjunto de caracteres que tienen un significado especial para los navegadores web. Aunque el estándar HTML define qué caracteres tienen un significado especial, muchos navegadores web intentan corregir errores comunes en HTML y pueden tratar otros caracteres como especiales en ciertos contextos. Es por eso que no recomendamos el uso de listas de denegación como medio para prevenir XSS. El Centro de Coordinación CERT(R) del Instituto de Ingeniería de Software de la Universidad Carnegie Mellon proporciona los siguientes detalles sobre los caracteres especiales en varios contextos [1]:

En el contenido de un elemento a nivel de bloque (en medio de un párrafo de texto),

• "<" es especial porque introduce una etiqueta.
• "&" es especial porque introduce una entidad de carácter.
• ">" es especial porque algunos navegadores lo tratan como especial, asumiendo que el autor de la página tenía la intención de incluir una apertura "<", pero la omitió por error.

Los siguientes principios se aplican a los valores de atributo:

• En los valores de atributo entre comillas dobles, las comillas dobles son especiales porque marcan el final del valor del atributo.
• En los valores de atributo entre comillas simples, las comillas simples son especiales porque marcan el final del valor del atributo.
• En los valores de atributo sin comillas, los caracteres de espacio en blanco, como el espacio y el tabulador, son especiales.
• "&" es especial cuando se usa con ciertos atributos, porque introduce una entidad de carácter.

En las URL, por ejemplo, un motor de búsqueda puede proporcionar un enlace dentro de la página de resultados en el que el usuario puede hacer clic para volver a ejecutar la búsqueda. Esto se puede implementar codificando la consulta de búsqueda dentro de la URL, que introduce caracteres especiales adicionales:

• El espacio, el tabulador y la nueva línea son especiales porque marcan el final de la URL.
• "&" es especial porque introduce una entidad de carácter o separa los parámetros CGI.
• Los caracteres que no son ASCII (es decir, todo lo que sea mayor a 127 en la codificación ISO-8859-1) no están permitidos en las URL, por lo que se consideran especiales en este contexto.
• El símbolo "%" debe filtrarse desde la entrada en cualquier lugar donde los parámetros codificados con secuencias de escape HTTP sean decodificados por el código del lado del servidor. Por ejemplo, "%" se debe filtrar si una entrada como "%68%65%6C%6C%6F" se convierte en "hola" cuando aparece en la página web.

Dentro del cuerpo de un <SCRIPT> </SCRIPT>:

• Los puntos y comas, los paréntesis, las llaves y los caracteres de nueva línea deben filtrarse en situaciones en las que el texto podría insertarse directamente en una etiqueta de script preexistente.

Scripts del lado del servidor

• Las secuencias de comandos del lado del servidor que convierten los caracteres de exclamación (!) en la entrada en caracteres de comillas dobles (") en la salida pueden requerir un filtrado adicional.

Otras posibilidades

• Si un atacante envía una solicitud en UTF-7, el carácter especial '<' aparece como '+ADw-' y puede pasar por alto el filtrado. Si el resultado se incluye en una página que no especifica explícitamente un formato de codificación, algunos navegadores intentan identificar de forma inteligente la codificación en función del contenido (en este caso, UTF-7).

Después de identificar los puntos correctos en una aplicación para realizar la validación de ataques XSS y qué caracteres especiales debe considerar la validación, el próximo desafío es identificar cómo su validación maneja los caracteres especiales. Si los caracteres especiales no se consideran entradas válidas para la aplicación, puede rechazar cualquier entrada que contenga caracteres especiales como no válida. Una segunda opción es eliminar caracteres especiales con filtrado. Sin embargo, el filtrado tiene el efecto secundario de cambiar cualquier representación visual del contenido filtrado y podría ser inaceptable en circunstancias en las que se deba preservar la integridad de la entrada para su visualización.

Si la entrada que contiene caracteres especiales debe aceptarse y mostrarse con precisión, la validación debe codificar cualquier carácter especial para eliminar su significado. Se proporciona una lista completa de valores codificados ISO 8859-1 para caracteres especiales como parte de la especificación HTML oficial [2].

Muchos servidores de aplicaciones intentan limitar la exposición de una aplicación a las vulnerabilidades de secuencias de comandos entre sitios proporcionando implementaciones para las funciones responsables de establecer cierto contenido de respuesta HTTP específico que realiza la validación de los caracteres esenciales para un ataque de secuencias de comandos entre sitios. No confíe en el servidor que ejecuta su aplicación para que sea segura. Para cualquier aplicación desarrollada, no hay garantías sobre en qué servidores de aplicaciones se ejecutará durante su vida útil. A medida que evolucionan los estándares y las vulnerabilidades conocidas, no hay garantías de que los servidores de aplicaciones continúen sincronizados.

Nota
Los F - 1 a F - 4 son principalmente del detector automático de fortificación (Micro Focus) con algunos de mis aportes (gráficos o explicaciones), F - 5 y los siguientes son aportes míos --- la solución.

F - 5: La solución o sugerencia

Análisis

El problema en la sección F - 2: Detalles, Línea 43:

De hecho, es una página de inicio de sesión,

con el código HTML,

 

Hay dos protecciones (validaciones) en la entrada del usuario ID de usuario: txtIWRUserId ,

• uno es un RequiredRieldValidator que requiere que se cambie la entrada, en realidad no está vacía porque originalmente está vacía;
• el segundo es un CustomValidator que desencadena una validación de eventos, en realidad en el código subyacente, es el método: cvAccountNumberValid_ServerValidate. Sin embargo, en el controlador de eventos, además de realizar una segunda validación no vacía, el código no hace nada sobre la validación en el formato de la entrada. --- Ese es el problema.

La solución

Tenemos dos maneras de hacer la corrección,

• Use una validación de modo de diseño, como el siguiente código que usa un controlador ASP RegularExpressionValidator, para realizar la validación de un formato de correo electrónico:

• Use el código detrás para hacer una validación, esto es lo que hicimos, de esta manera será eficiente para deshacerse de la Vulnerabilidad de la entrada HTML.

La solicitud de un falso positivo

Después de nuestra solución, el problema debería desaparecer, sin embargo, Micro Focus Fortify (un software de escaneo automático para vulnerabilidades de seguridad) no puede indicar el cambio de solución, entonces tenemos que abrir una solicitud de falso positivo al equipo del sistema Fortufy (AppSec: Application Security Equipo).

F - 6: Falso positivo aceptado

Certificado de desarrollador aceptado. --- Del Equipo de Seguridad de Aplicaciones.

Nota
Falso positivo aceptado significa que la herramienta (Fortify Scanner) es incorrecta:

Los falsos positivos ocurren cuando una herramienta de prueba de seguridad señala incorrectamente un problema que no es legítimo (es decir, la herramienta dice que SSL 3.0 está habilitado, pero no lo está; la herramienta estaba equivocada). En estos casos, se alienta a los equipos a seguir el proceso descrito a continuación para eliminar los problemas y asegurarnos de que se resuelva el error.

Fuente: https://www.c-sharpcorner.com/article/example-of-cross-site-scripting-reflected/

#xss 

What is GEEK

Buddha Community

¿Qué es XSS Reflejado?

 Este es el primero de una serie de artículos relacionados con la seguridad. 

• Los 10 principales riesgos de seguridad de las aplicaciones web  
• Inyección SQL 
• Falsificación de solicitud del lado del servidor (SSRF)
  • Ejemplo de falsificación de solicitud del lado del servidor
• Falsificación de solicitud entre sitios (CSRF)
• Secuencias de comandos entre sitios (XSS)
  • Ejemplo de Cross-Site Scripting, reflejado ---  este artículo
  • Ejemplo de Cross-Site Scripting, DOM
• Secuencias de comandos entre fotogramas (XFS)
  • Ejemplo de secuencias de comandos entre fotogramas
• Comparaciones entre SSRF, CSRF, XSS y XFS 
• CORS (1), consumir .NET Core Web API por MVC en el mismo origen

Este artículo es parte de  Cross-Site Scripting (XSS) , este es un ejemplo de un problema real de alta seguridad creado por  Fortify Static Code Scanning.

Esta es la estructura de este artículo,

• F-0: Introducción
• F-1: Resumen
• F-2: Detalles
• F-3: Ejemplo
• F - 4: Recomendación
• F - 5: La solución o sugerencia
• F - 6: Falso positivo aceptado

F-1: Resumen

El XSS reflejado  es la variedad más simple de secuencias de comandos entre sitios. Surge cuando una aplicación recibe datos en una solicitud HTTP y los incluye dentro de la respuesta inmediata de forma no segura. Aquí hay un ejemplo simple de una   vulnerabilidad XSS reflejada :

https://insecure-website.com/status?message=All+is+well. <p>Status: All is well.</p>

Margen

La aplicación no realiza ningún otro procesamiento de los datos, por lo que un atacante puede construir fácilmente un ataque como este:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script> <p>Status: <script>/* Bad stuff here... */</script></p>

Margen

Si el usuario visita la URL construida por el atacante, la secuencia de comandos del atacante se ejecuta en el navegador del usuario, en el contexto de la sesión de ese usuario con la aplicación. En ese momento, el script puede realizar cualquier acción y recuperar cualquier dato al que el usuario tenga acceso.

En nuestro caso , el siguiente código envía datos no validados a un navegador web en la línea 378, lo que puede provocar que el navegador ejecute código malicioso.

F-2: Detalles

Las vulnerabilidades de secuencias de comandos entre sitios (XSS) ocurren cuando:

• Los datos ingresan a una aplicación web a través de una fuente no confiable. En el caso de XSS reflejado , la fuente que no es de confianza suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos de back-end. En este caso, los datos ingresan en get_Text() en CSR_UserInfo.aspx.cs en la línea 43.

• Los datos se incluyen en contenido dinámico que se envía a un usuario web sin validación. En este caso, los datos se envían en Write() en AdminBasePage_Transactions.cs en la línea 378.

El contenido malicioso que se envía al navegador web suele adoptar la forma de un segmento de JavaScript, pero también puede incluir HTML, Flash o cualquier otro tipo de código que ejecute el navegador. La variedad de ataques basados ​​en XSS es casi ilimitada, pero comúnmente incluyen la transmisión de datos privados como cookies u otra información de la sesión al atacante, redirigir a la víctima al contenido web controlado por el atacante o realizar otras operaciones maliciosas en la máquina del usuario bajo el apariencia del sitio vulnerable.

F-3: Ejemplo

Ejemplo 1

El siguiente formulario web de ASP.NET lee un número de ID de empleado de una solicitud HTTP y se lo muestra al usuario.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

Margen

Donde Login y EmployeeID son controles de formulario definidos de la siguiente manera:

<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>

Margen

Ejemplo 2

El siguiente segmento de código ASP.NET muestra la forma programática de implementar el ejemplo 1.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

C++

El código de estos ejemplos funciona correctamente si Login contiene solo texto alfanumérico estándar. Si Login tiene un valor que incluye metacaracteres o código fuente, el navegador web ejecutará el código cuando muestre la respuesta HTTP.

Inicialmente, esto podría no parecer una gran vulnerabilidad. Después de todo, ¿por qué alguien ingresaría una URL que hace que se ejecute un código malicioso en su propia computadora? El peligro real es que un atacante cree la URL maliciosa y luego use el correo electrónico o trucos de ingeniería social para atraer a las víctimas para que hagan clic en un enlace. Cuando las víctimas hacen clic en el enlace, sin saberlo, reflejan el contenido malicioso a través de la aplicación web vulnerable y de regreso a sus propias computadoras. Este mecanismo de explotación de aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3

El siguiente formulario web de ASP.NET consulta una base de datos para un empleado con una identificación de empleado determinada e imprime el nombre correspondiente a la identificación.

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>

Margen

Donde EmployeeName es un control de formulario definido de la siguiente manera:

<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>

Margen

Ejemplo 4

El siguiente segmento de código ASP.NET es funcionalmente equivalente al Ejemplo 3, pero implementa todos los elementos del formulario mediante programación.

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;

C#

Al igual que en el Ejemplo 1 y el Ejemplo 2, estos ejemplos de código funcionan correctamente cuando los valores de nombre se comportan bien, pero no evitan las vulnerabilidades si los valores no lo hacen. Nuevamente, estos pueden parecer menos peligrosos porque el valor del nombre se lee de una base de datos, cuyo contenido aparentemente es administrado por la aplicación. Sin embargo, si el valor del nombre se origina a partir de datos proporcionados por el usuario, la base de datos puede ser un conducto para el contenido malicioso. Sin una validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos maliciosos en el navegador web del usuario. Este tipo de exploit, conocido como XSS persistente (o almacenado), es particularmente insidioso porque la indirección causada por el almacenamiento de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a múltiples usuarios. XSS comenzó de esta forma con sitios web que ofrecían un "libro de visitas" a los visitantes. Los atacantes incluirían JavaScript en las entradas de su libro de visitas, y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malicioso.

Como demuestran los ejemplos, las vulnerabilidades XSS son causadas por un código que incluye datos no validados en una respuesta HTTP. Hay tres vectores por los que un ataque XSS puede llegar a una víctima:

• Como en el Ejemplo 1 y el Ejemplo 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los exploits XSS reflejados ocurren cuando un atacante hace que un usuario suministre contenido peligroso a una aplicación web vulnerable, que luego se refleja al usuario y lo ejecuta el navegador web. El mecanismo más común para entregar contenido malicioso es incluirlo como parámetro en una URL que se publica públicamente o se envía por correo electrónico directamente a las víctimas. Las URL construidas de esta manera constituyen el núcleo de muchos esquemas de phishing, en los que un atacante convence a las víctimas para que visiten una URL que hace referencia a un sitio vulnerable. Después de que el sitio refleje el contenido del atacante al usuario, el contenido se ejecuta y procede a transferir información privada, como cookies que pueden incluir información de la sesión, del usuario.
• Como en el Ejemplo 3 y el Ejemplo 4, la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos confiable. Posteriormente, los datos peligrosos se vuelven a leer en la aplicación y se incluyen en el contenido dinámico. Los exploits XSS persistentes ocurren cuando un atacante inyecta contenido peligroso en un almacén de datos que luego se lee e incluye en el contenido dinámico. Desde la perspectiva de un atacante, el lugar óptimo para inyectar contenido malicioso es un área que se muestra a muchos usuarios oa usuarios particularmente interesantes. Los usuarios interesantes suelen tener privilegios elevados en la aplicación o interactúan con datos confidenciales que son valiosos para el atacante. Si uno de estos usuarios ejecuta contenido malicioso, el atacante puede realizar operaciones privilegiadas en nombre del usuario u obtener acceso a datos confidenciales que pertenecen al usuario.
• Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, los datos peligrosos se vuelven a leer en la aplicación como datos confiables y se incluyen en el contenido dinámico.

F - 4: Recomendación

La solución para XSS es garantizar que la validación se realice en los lugares correctos y que se verifiquen las propiedades correctas.

Debido a que las vulnerabilidades XSS ocurren cuando una aplicación incluye datos maliciosos en su salida, un enfoque lógico es validar los datos inmediatamente antes de que abandonen la aplicación. Sin embargo, debido a que las aplicaciones web a menudo tienen un código complejo e intrincado para generar contenido dinámico, este método es propenso a errores de omisión (falta de validación). Una forma efectiva de mitigar este riesgo es realizar también la validación de entrada para XSS.

Las aplicaciones web deben validar su entrada para evitar otras vulnerabilidades, como la inyección SQL, por lo que generalmente es relativamente fácil aumentar el mecanismo de validación de entrada existente de una aplicación para incluir comprobaciones de XSS. A pesar de su valor, la validación de entrada para XSS no reemplaza una validación de salida rigurosa. Una aplicación puede aceptar entradas a través de un almacén de datos compartido u otra fuente confiable, y ese almacén de datos puede aceptar entradas de una fuente que no realiza una validación de entrada adecuada. Por lo tanto, la aplicación no puede confiar implícitamente en la seguridad de este o cualquier otro dato. Esto significa que la mejor manera de prevenir vulnerabilidades XSS es validar todo lo que ingresa a la aplicación y sale de la aplicación destinada al usuario.

El enfoque más seguro para la validación de XSS es crear una lista de permitidos de caracteres seguros que pueden aparecer en contenido HTTP y aceptar entradas compuestas exclusivamente por caracteres del conjunto aprobado. Por ejemplo, un nombre de usuario válido puede incluir solo caracteres alfanuméricos o un número de teléfono puede incluir solo dígitos del 0 al 9. Sin embargo, esta solución a menudo no es factible en aplicaciones web porque muchos caracteres que tienen un significado especial para el navegador deben considerarse entradas válidas después de codificarse, como un tablero de anuncios de diseño web que debe aceptar fragmentos HTML de sus usuarios.

Un enfoque más flexible, pero menos seguro, es implementar una lista de denegación, que rechaza o escapa selectivamente los caracteres potencialmente peligrosos antes de usar la entrada. Para formar una lista de este tipo, primero debe comprender el conjunto de caracteres que tienen un significado especial para los navegadores web. Aunque el estándar HTML define qué caracteres tienen un significado especial, muchos navegadores web intentan corregir errores comunes en HTML y pueden tratar otros caracteres como especiales en ciertos contextos. Es por eso que no recomendamos el uso de listas de denegación como medio para prevenir XSS. El Centro de Coordinación CERT(R) del Instituto de Ingeniería de Software de la Universidad Carnegie Mellon proporciona los siguientes detalles sobre los caracteres especiales en varios contextos [1]:

En el contenido de un elemento a nivel de bloque (en medio de un párrafo de texto),

• "<" es especial porque introduce una etiqueta.
• "&" es especial porque introduce una entidad de carácter.
• ">" es especial porque algunos navegadores lo tratan como especial, asumiendo que el autor de la página tenía la intención de incluir una apertura "<", pero la omitió por error.

Los siguientes principios se aplican a los valores de atributo:

• En los valores de atributo entre comillas dobles, las comillas dobles son especiales porque marcan el final del valor del atributo.
• En los valores de atributo entre comillas simples, las comillas simples son especiales porque marcan el final del valor del atributo.
• En los valores de atributo sin comillas, los caracteres de espacio en blanco, como el espacio y el tabulador, son especiales.
• "&" es especial cuando se usa con ciertos atributos, porque introduce una entidad de carácter.

En las URL, por ejemplo, un motor de búsqueda puede proporcionar un enlace dentro de la página de resultados en el que el usuario puede hacer clic para volver a ejecutar la búsqueda. Esto se puede implementar codificando la consulta de búsqueda dentro de la URL, que introduce caracteres especiales adicionales:

• El espacio, el tabulador y la nueva línea son especiales porque marcan el final de la URL.
• "&" es especial porque introduce una entidad de carácter o separa los parámetros CGI.
• Los caracteres que no son ASCII (es decir, todo lo que sea mayor a 127 en la codificación ISO-8859-1) no están permitidos en las URL, por lo que se consideran especiales en este contexto.
• El símbolo "%" debe filtrarse desde la entrada en cualquier lugar donde los parámetros codificados con secuencias de escape HTTP sean decodificados por el código del lado del servidor. Por ejemplo, "%" se debe filtrar si una entrada como "%68%65%6C%6C%6F" se convierte en "hola" cuando aparece en la página web.

Dentro del cuerpo de un <SCRIPT> </SCRIPT>:

• Los puntos y comas, los paréntesis, las llaves y los caracteres de nueva línea deben filtrarse en situaciones en las que el texto podría insertarse directamente en una etiqueta de script preexistente.

Scripts del lado del servidor

• Las secuencias de comandos del lado del servidor que convierten los caracteres de exclamación (!) en la entrada en caracteres de comillas dobles (") en la salida pueden requerir un filtrado adicional.

Otras posibilidades

• Si un atacante envía una solicitud en UTF-7, el carácter especial '<' aparece como '+ADw-' y puede pasar por alto el filtrado. Si el resultado se incluye en una página que no especifica explícitamente un formato de codificación, algunos navegadores intentan identificar de forma inteligente la codificación en función del contenido (en este caso, UTF-7).

Después de identificar los puntos correctos en una aplicación para realizar la validación de ataques XSS y qué caracteres especiales debe considerar la validación, el próximo desafío es identificar cómo su validación maneja los caracteres especiales. Si los caracteres especiales no se consideran entradas válidas para la aplicación, puede rechazar cualquier entrada que contenga caracteres especiales como no válida. Una segunda opción es eliminar caracteres especiales con filtrado. Sin embargo, el filtrado tiene el efecto secundario de cambiar cualquier representación visual del contenido filtrado y podría ser inaceptable en circunstancias en las que se deba preservar la integridad de la entrada para su visualización.

Si la entrada que contiene caracteres especiales debe aceptarse y mostrarse con precisión, la validación debe codificar cualquier carácter especial para eliminar su significado. Se proporciona una lista completa de valores codificados ISO 8859-1 para caracteres especiales como parte de la especificación HTML oficial [2].

Muchos servidores de aplicaciones intentan limitar la exposición de una aplicación a las vulnerabilidades de secuencias de comandos entre sitios proporcionando implementaciones para las funciones responsables de establecer cierto contenido de respuesta HTTP específico que realiza la validación de los caracteres esenciales para un ataque de secuencias de comandos entre sitios. No confíe en el servidor que ejecuta su aplicación para que sea segura. Para cualquier aplicación desarrollada, no hay garantías sobre en qué servidores de aplicaciones se ejecutará durante su vida útil. A medida que evolucionan los estándares y las vulnerabilidades conocidas, no hay garantías de que los servidores de aplicaciones continúen sincronizados.

Nota
Los F - 1 a F - 4 son principalmente del detector automático de fortificación (Micro Focus) con algunos de mis aportes (gráficos o explicaciones), F - 5 y los siguientes son aportes míos --- la solución.

F - 5: La solución o sugerencia

Análisis

El problema en la sección F - 2: Detalles, Línea 43:

De hecho, es una página de inicio de sesión,

con el código HTML,

 

Hay dos protecciones (validaciones) en la entrada del usuario ID de usuario: txtIWRUserId ,

• uno es un RequiredRieldValidator que requiere que se cambie la entrada, en realidad no está vacía porque originalmente está vacía;
• el segundo es un CustomValidator que desencadena una validación de eventos, en realidad en el código subyacente, es el método: cvAccountNumberValid_ServerValidate. Sin embargo, en el controlador de eventos, además de realizar una segunda validación no vacía, el código no hace nada sobre la validación en el formato de la entrada. --- Ese es el problema.

La solución

Tenemos dos maneras de hacer la corrección,

• Use una validación de modo de diseño, como el siguiente código que usa un controlador ASP RegularExpressionValidator, para realizar la validación de un formato de correo electrónico:

• Use el código detrás para hacer una validación, esto es lo que hicimos, de esta manera será eficiente para deshacerse de la Vulnerabilidad de la entrada HTML.

La solicitud de un falso positivo

Después de nuestra solución, el problema debería desaparecer, sin embargo, Micro Focus Fortify (un software de escaneo automático para vulnerabilidades de seguridad) no puede indicar el cambio de solución, entonces tenemos que abrir una solicitud de falso positivo al equipo del sistema Fortufy (AppSec: Application Security Equipo).

F - 6: Falso positivo aceptado

Certificado de desarrollador aceptado. --- Del Equipo de Seguridad de Aplicaciones.

Nota
Falso positivo aceptado significa que la herramienta (Fortify Scanner) es incorrecta:

Los falsos positivos ocurren cuando una herramienta de prueba de seguridad señala incorrectamente un problema que no es legítimo (es decir, la herramienta dice que SSL 3.0 está habilitado, pero no lo está; la herramienta estaba equivocada). En estos casos, se alienta a los equipos a seguir el proceso descrito a continuación para eliminar los problemas y asegurarnos de que se resuelva el error.

Fuente: https://www.c-sharpcorner.com/article/example-of-cross-site-scripting-reflected/

#xss 

¿Qué es Cross-Site Scripting (XSS)?

Esta es una serie de artículos relacionados con la seguridad que escribí. Este artículo es el primero.

Este es el primero de una serie de artículos relacionados con la seguridad. 

• Los 10 principales riesgos de seguridad de las aplicaciones web  
• Inyección SQL 
• Falsificación de solicitud del lado del servidor (SSRF)
  • Ejemplo de falsificación de solicitud del lado del servidor
• Falsificación de solicitud entre sitios (CSRF)
• Secuencias de comandos entre sitios (XSS) ---  este artículo
  • Ejemplo de Cross-Site Scripting, reflejado
  • Ejemplo de Cross-Site Scripting, DOM
• Secuencias de comandos entre fotogramas (XFS)
  • Ejemplo de secuencias de comandos entre fotogramas
• Comparaciones entre SSRF, CSRF, XSS y XFS 
• CORS (1), consumir .NET Core Web API por MVC en el mismo origen

Introducción

Cross-site scripting  ( XSS ) es un tipo de vulnerabilidad de seguridad   que se puede encontrar en algunas  aplicaciones web . Los ataques XSS permiten a los atacantes  inyectar  secuencias de comandos del lado del cliente  en páginas web vistas por otros usuarios. Los atacantes pueden utilizar una vulnerabilidad de secuencias de comandos entre sitios para eludir  los controles de acceso  , como la  política del mismo origen .

Las secuencias de comandos entre sitios realizadas en  sitios web  representaron aproximadamente el 84 % de todas las vulnerabilidades de seguridad documentadas por  Symantec  hasta 2007. [ ref ]

Esta es la estructura de este artículo,

• Introducción
• A - ¿Qué es Cross-Site Scripting (XSS)?
• B - ¿Cómo funciona XSS?
• C - Por qué son posibles los ataques Cross-Site Scripting
• D - Impactos de una vulnerabilidad XSS
• E - ¿Cuáles son los tipos de ataques XSS?

A - ¿Qué es Cross-Site Scripting (XSS)?

Cross-site Scripting (XSS) es un ataque de inyección de código  del lado del cliente . El atacante tiene como objetivo ejecutar scripts maliciosos en un navegador web de la víctima mediante la inclusión de código malicioso en una página web o aplicación web legítima. Las vulnerabilidades de secuencias de comandos entre sitios normalmente permiten que un atacante se haga pasar por un usuario víctima, lleve a cabo cualquier acción que el usuario pueda realizar y acceda a cualquiera de los datos del usuario. Si el usuario de la víctima tiene acceso privilegiado dentro de la aplicación, entonces el atacante podría obtener control total sobre toda la funcionalidad y los datos de la aplicación.

Los puntos son que el adjunto puede

• Acceda al navegador web del cliente;
• Ejecute el código malicioso en el navegador.
• Acceda y controle la funcionalidad y los datos de la aplicación

B - ¿Cómo funciona XSS?

Las secuencias de comandos entre sitios funcionan mediante la manipulación de un sitio web vulnerable para que devuelva JavaScript malicioso a los usuarios. Cuando el código malicioso se ejecuta dentro del navegador de la víctima, el atacante puede comprometer completamente su interacción con la aplicación.

C - Por qué son posibles los ataques Cross-Site Scripting

Los ataques XSS son ataques  de inyección  que insertan código de script malicioso en una página web procesada por el navegador de un usuario. La parte “ cross-site ” significa que el código de ataque tiene un origen diferente al del sitio visitado. Normalmente, esto debería ser imposible debido a  la política del mismo origen (SOP)  , una función de seguridad fundamental del navegador que solo permite que las aplicaciones web carguen scripts que tienen el mismo origen.

Nota :

A los efectos de la política del mismo origen y XSS, dos sitios tienen el mismo origen si tienen el mismo protocolo (esquema de URI, como  https://), nombre de host (como  www.example.com) y número de puerto (generalmente se omite en las URL del sitio web). [ver: CORS (1), Consumir .NET Core Web API por MVC en el mismo origen ]

Una página web que es vulnerable a secuencias de comandos entre sitios utiliza entradas de usuario sin desinfectar para crear dinámicamente su código HTML. Si esta entrada contiene un script malicioso, el script se incluirá en el código de la página y el navegador lo ejecutará en el contexto actual (porque ahora se origina en la misma página web). Esto abre el camino a una amplia variedad de ataques basados ​​en scripts.

D - Impactos de una vulnerabilidad XSS

Un atacante que explota una vulnerabilidad de secuencias de comandos entre sitios normalmente puede:

• Suplantar o hacerse pasar por el usuario víctima.
• Realizar cualquier acción que el usuario sea capaz de realizar.
• Lea todos los datos a los que el usuario pueda acceder.
• Capture las credenciales de inicio de sesión del usuario.
• Realizar desfiguración virtual del sitio web.
• Inyectar funcionalidad troyana en el sitio web.

E - ¿Cuáles son los tipos de ataques XSS?

Hay tres tipos principales de ataques XSS. Estos son:

• XSS reflejado , donde el script malicioso proviene de la solicitud HTTP actual.
• XSS almacenado , donde el script malicioso proviene de la base de datos del sitio web.
• XSS basado en DOM , donde la vulnerabilidad existe en el código del lado del cliente en lugar del código del lado del servidor.

Secuencias de comandos entre sitios reflejadas

El XSS reflejado  es la variedad más simple de secuencias de comandos entre sitios. Surge cuando una aplicación recibe datos en una solicitud HTTP y los incluye dentro de la respuesta inmediata de forma no segura.

Aquí hay un ejemplo simple de una   vulnerabilidad XSS reflejada :

https://insecure-website.com/status?message=All+is+well. <p>Status: All is well.</p>

HTTP

La aplicación no realiza ningún otro procesamiento de los datos, por lo que un atacante puede construir fácilmente un ataque como este:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script> <p>Status: <script>/* Bad stuff here... */</script></p>

HTTP

Si el usuario visita la URL construida por el atacante, la secuencia de comandos del atacante se ejecuta en el navegador del usuario, en el contexto de la sesión de ese usuario con la aplicación. En ese momento, el script puede realizar cualquier acción y recuperar cualquier dato al que el usuario tenga acceso.

Scripts entre sitios almacenados

El XSS almacenado  (también conocido como XSS persistente o de segundo orden) surge cuando una aplicación recibe datos de una fuente que no es de confianza e incluye esos datos en sus respuestas HTTP posteriores de forma no segura.

Los datos en cuestión pueden enviarse a la aplicación a través de solicitudes HTTP; por ejemplo, comentarios en una publicación de blog, apodos de usuario en una sala de chat o detalles de contacto en un pedido de cliente. En otros casos, los datos pueden llegar de otras fuentes no confiables; por ejemplo, una aplicación de correo web que muestra mensajes recibidos a través de SMTP, una aplicación de marketing que muestra publicaciones en redes sociales o una aplicación de monitoreo de red que muestra paquetes de datos del tráfico de red.

Aquí hay un ejemplo simple de una   vulnerabilidad XSS almacenada . Una aplicación de tablero de mensajes permite a los usuarios enviar mensajes, que se muestran a otros usuarios:

<p>Hello, this is my message!</p>

Margen

La aplicación no realiza ningún otro procesamiento de los datos, por lo que un atacante puede enviar fácilmente un mensaje que ataque a otros usuarios:

<p><script>/* Bad stuff here... */</script></p>

Margen

Scripting entre sitios basado en DOM

XSS basado en DOM (también conocido como  DOM XSS ) surge cuando una aplicación contiene JavaScript del lado del cliente que procesa datos de una fuente que no es de confianza de una manera no segura, generalmente escribiendo los datos nuevamente en el DOM.

En el siguiente ejemplo, una aplicación usa algo de JavaScript para leer el valor de un campo de entrada y escribir ese valor en un elemento dentro del HTML:

var search = document.getElementById('search').value;

var results = document.getElementById('results');

results.innerHTML = 'You searched for: ' + search;

JavaScript

Si el atacante puede controlar el valor del campo de entrada, puede construir fácilmente un valor malicioso que haga que se ejecute su propio script:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

JavaScript

En un caso típico, el campo de entrada se completaría con parte de la solicitud HTTP, como un parámetro de cadena de consulta de URL, lo que permitiría al atacante realizar un ataque utilizando una URL maliciosa, de la misma manera que se refleja XSS. 

Fuente: https://www.c-sharpcorner.com/article/cross-site-scripting-xss4/ 

#http #xss 

Upgrading XSS Hunter with A Basic Reverse JavaScript Shell

Before you start reading this article, please keep in mind that this is a very basic reverse shell, and still needs a lot of work to get the most out of it. A few of the limitations are:

• Errors could occur if more the payload is active on multiple pages. The payload gets executed on all pages where it’s active, but the multiple pages could be distinct from each other, and when they all send back their response, only one of them is saved by the interface.
• The reverse shell interface is made to be placed on a webserver, which means that everyone can find it when you don’t have proper authorization in place. That also means that an adversary can find it and use it with bad intentions.

Recently I have found my first blind XSS, and I quickly noticed that it’s hard to figure out what’s possible with your blind XSS and what impact it can have. To figure this out, I tried several payloads, but felt the need to execute payloads in real time. Because of that, I came up with the idea to make a reverse shell, that I can use as soon as I receive an email from XSS Hunter to notify me the XSS has been triggered. The only problem is that the reverse shell would only work if the victim stays on the vulnerable page. Once he goes to another page or closes the page, the connection will be lost.

This reverse shell isn’t the best solution, but it’s helpful for beginners to experiment with it. And it was a fun little project for me to make.

To start the project, I opened up notepad and started writing down how I wanted the shell to function.

Notes

#bug-bounty #blind-xss #javascript #xss-attack

¿Qué es Rust y por qué es tan popular?

Rust ha sido el lenguaje más querido de Stack Overflow durante cuatro años seguidos , lo que indica que muchos de los que han tenido la oportunidad de usar Rust se han enamorado de él. Sin embargo, aproximadamente el 97% de los encuestados que no han usado Rust pueden preguntarse: "¿Cuál es el problema con Rust?"

La respuesta corta es que Rust resuelve los puntos débiles presentes en muchos otros idiomas, proporcionando un sólido paso adelante con un número limitado de desventajas.

Mostraré una muestra de lo que ofrece Rust a los usuarios de otros lenguajes de programación y cómo se ve el ecosistema actual. No todo son rosas en Rust-land, así que también hablo de las desventajas. 

Procedente de lenguajes tipados dinámicamente

Es probable que las discusiones entre programadores que prefieren sistemas de tipo dinámico versus estático duren décadas más, pero es difícil discutir sobre los beneficios de los tipos estáticos. Solo necesita observar el auge de lenguajes como TypeScript o características como las sugerencias de tipo de Python, ya que la gente se ha frustrado con el estado actual de la escritura dinámica en las bases de código más grandes de la actualidad. Los lenguajes de tipado estático permiten restricciones comprobadas por el compilador sobre los datos y su comportamiento, lo que alivia la sobrecarga cognitiva y los malentendidos.

Esto no quiere decir que todos los sistemas de tipo estático sean equivalentes. Muchos lenguajes de tipo estático tienen un gran asterisco junto a ellos: permiten el concepto de NULL. Esto significa que cualquier valor puede ser lo que dice o nada , creando efectivamente un segundo tipo posible para cada tipo . Como Haskell y algunos otros lenguajes de programación modernos, Rust codifica esta posibilidad usando un tipo opcional , y el compilador requiere que usted maneje el Nonecaso. Esto evita que se produzca el temido TypeError: Cannot read property 'foo' of nullerror de tiempo de ejecución (o un idioma equivalente), en lugar de promoverlo a un error de tiempo de compilación que puede resolver antes de que un usuario lo vea. Aquí hay un ejemplo de una función para saludar a alguien, sepamos o no su nombre; si hubiéramos olvidado elNonecaso en el matcho intentó usar namecomo si fuera un Stringvalor siempre presente , el compilador se quejaría.

fn greet_user(name: Option<String>) {
    match name {
        Some(name) => println!("Hello there, {}!", name),
        None => println!("Well howdy, stranger!"),
    }
}

La escritura estática de Rust hace todo lo posible para salirse del camino del programador al mismo tiempo que fomenta la mantenibilidad a largo plazo. Algunos lenguajes de tipado estático suponen una gran carga para el programador, lo que les obliga a repetir el tipo de una variable varias veces, lo que dificulta la legibilidad y la refactorización. Otros lenguajes de tipado estático permiten la inferencia de tipo de programa completo. Si bien es conveniente durante el desarrollo inicial, esto reduce la capacidad del compilador para proporcionar información de error útil cuando los tipos ya no coinciden. Rust aprende de estos dos estilos y requiere que los elementos de nivel superior, como los argumentos de función y las constantes, tengan tipos explícitos, al tiempo que permite la inferencia de tipos dentro de los cuerpos de las funciones. En este ejemplo, el compilador Rust puede inferir el tipo de twice, 2y 1porque elval El parámetro y el tipo de retorno se declaran como enteros de 32 bits con signo.

fn simple_math(val: i32) -> i32 {
    let twice = val * 2;
    twice - 1
}

Procedente de lenguajes recolectados de basura

Uno de los mayores beneficios de usar un lenguaje de programación de sistemas es la capacidad de tener control sobre detalles de bajo nivel.

Rust le da la opción de almacenar datos en la pila o en el montón y determina en el momento de la compilación cuando la memoria ya no es necesaria y se puede limpiar. Esto permite un uso eficiente de la memoria, así como un acceso a la memoria de mayor rendimiento. Tilde , uno de los primeros usuarios de producción de Rust en su producto Skylight , descubrió que podían reducir el uso de memoria de 5GiB a 50MiB reescribiendo ciertos puntos finales HTTP de Java en Rust idiomático. Ahorros como este se acumulan rápidamente cuando los proveedores de la nube cobran precios superiores por una mayor memoria o nodos adicionales.

Sin la necesidad de tener un recolector de basura en funcionamiento continuo, los proyectos de Rust son adecuados para ser utilizados como bibliotecas por otros lenguajes de programación a través de interfaces de funciones externas. Esto permite que los proyectos existentes reemplacen piezas críticas para el rendimiento con un rápido código Rust sin los riesgos de seguridad de la memoria inherentes a otros lenguajes de programación de sistemas. Algunos proyectos incluso se han reescrito gradualmente en Rust utilizando estas técnicas.

Con acceso directo al hardware y la memoria, Rust es un lenguaje ideal para el desarrollo integrado y bare-metal. Puede escribir código de nivel extremadamente bajo, como kernels del sistema operativo o aplicaciones de microcontroladores . Los tipos y funciones principales de Rust, así como el código de biblioteca reutilizable, brillan en estos entornos especialmente desafiantes.

 

Procedente de otros lenguajes de programación de sistemas

Para muchas personas, Rust se ve en gran medida como una alternativa a otros lenguajes de programación de sistemas, como C o C ++. El mayor beneficio que puede proporcionar Rust en comparación con estos idiomas es el comprobador de préstamos . Esta es la parte del compilador responsable de garantizar que las referencias no sobrevivan a los datos a los que hacen referencia, y ayuda a eliminar clases enteras de errores causados ​​por la inseguridad de la memoria.

A diferencia de muchos lenguajes de programación de sistemas existentes, Rust no requiere que pase todo su tiempo atascado en detalles esenciales. Rust se esfuerza por tener tantas abstracciones de costo cero como sea posible, abstracciones que tengan el mismo rendimiento que el código escrito a mano equivalente. En este ejemplo, mostramos cómo los iteradores, una abstracción primaria de Rust, pueden usarse para crear de manera sucinta un vector que contenga los primeros diez números cuadrados.

let squares: Vec<_> = (0..10).map(|i| i * i).collect();

Cuando safe Rust no puede expresar algún concepto, puede usar el inseguro Rust . Esto desbloquea algunos poderes adicionales, pero a cambio, el programador ahora es responsable de garantizar que el código sea realmente seguro. Este código inseguro se puede envolver en abstracciones de nivel superior que garantizan que todos los usos de la abstracción sean seguros.

Usar código inseguro debe ser una decisión calculada, ya que usarlo correctamente requiere tanto pensamiento y cuidado como cualquier otro idioma en el que usted es responsable de evitar comportamientos indefinidos . Minimizar el código inseguro es la mejor manera de minimizar las posibilidades de fallas seguras y vulnerabilidades debido a la inseguridad de la memoria.

Los lenguajes de programación de sistemas tienen la expectativa implícita de que estarán disponibles de manera efectiva para siempre. Si bien algunos desarrollos modernos no requieren esa cantidad de longevidad, muchas empresas quieren saber que su base de código fundamental se podrá utilizar en el futuro previsible. Rust reconoce esto y ha tomado decisiones de diseño conscientes en torno a la compatibilidad y estabilidad con versiones anteriores; es un lenguaje diseñado para los próximos 40 años .

El ecosistema Rust

La experiencia de Rust es más grande que una especificación de lenguaje y un compilador; muchos aspectos de la creación y el mantenimiento de software de calidad de producción se tratan como ciudadanos de primera clase. Se pueden instalar y administrar múltiples cadenas de herramientas Rust concurrentes a través de rustup . Las instalaciones de Rust vienen con Cargo, una herramienta de línea de comandos para administrar dependencias, ejecutar pruebas, generar documentación y más. Debido a que las dependencias, las pruebas y la documentación están disponibles de forma predeterminada, su uso es frecuente. crates.io es el sitio de la comunidad para compartir y descubrir bibliotecas de Rust. Cualquier biblioteca publicada a crates.io tendrá su documentación construido y publicado el docs.rs .

Además de las herramientas integradas, la comunidad de Rust ha creado una gran cantidad de herramientas de desarrollo. La evaluación comparativa, el fuzzing y las pruebas basadas en propiedades son fácilmente accesibles y se utilizan bien en los proyectos. Lints compilador adicionales están disponibles a partir de Clippy y automático de formato idiomática es proporcionada por rustfmt . El soporte de IDE es saludable y cada día es más capaz.

Más allá de los puntos técnicos, Rust tiene una comunidad vibrante y acogedora. Hay varias vías oficiales y no oficiales para que las personas obtengan ayuda, como el chat , el foro del usuario , el subreddit de Rust y, por supuesto, las preguntas y respuestas de Stack Overflow y la sala de chat . Rust tiene un código de conducta aplicado por un increíble equipo de moderación para asegurarse de que los espacios oficiales sean acogedores, y la mayoría de los espacios no oficiales también observan algo similar.

Fuera de línea, Rust tiene múltiples conferencias en todo el mundo, como RustConf , Rust Belt Rust , RustFest , Rust Latam , RustCon Asia y más.

No todo son rosas

El sólido sistema de tipos de Rust y el énfasis en la seguridad de la memoria —todos aplicados en el momento de la compilación— significan que es extremadamente común obtener errores al compilar su código. Esta puede ser una sensación frustrante para los programadores que no están acostumbrados a un lenguaje de programación tan obstinado. Sin embargo, los desarrolladores de Rust han pasado una gran cantidad de tiempo trabajando para mejorar los mensajes de error para asegurarse de que sean claros y procesables. ¡No dejes que tus ojos brillen mientras lees errores de Rust!

Es especialmente común escuchar a alguien quejarse de que ha estado "peleando con el verificador de préstamos". Si bien estos errores pueden ser desalentadores, es importante reconocer que cada una de las ubicaciones identificadas tenía el potencial de introducir errores y vulnerabilidades potenciales en un idioma que no realizaba las mismas comprobaciones.

En este ejemplo, creamos una cadena mutable que contiene un nombre, luego tomamos una referencia a los primeros tres bytes del nombre. Si bien esa referencia es sobresaliente, intentamos mutar la cadena borrándola. Ahora no hay garantía de que los puntos de referencia a datos válidos y desreferenciarlos puedan conducir a un comportamiento indefinido, por lo que el compilador nos detiene:

fn no_mutable_aliasing() {
    let mut name = String::from("Vivian");
    let nickname = &name[..3];
    name.clear();
    println!("Hello there, {}!", nickname);
}

error[E0502]: cannot borrow `name` as mutable because it is also borrowed as immutable
 --> a.rs:4:5
  |
3 |     let nickname = &name[..3];
  |                     ---- immutable borrow occurs here
4 |     name.clear();
  |     ^^^^^^^^^^^^ mutable borrow occurs here
5 |     println!("Hello there, {}!", nickname);
  |                                  -------- immutable borrow later used here

For more information about this error, try `rustc --explain E0502`.

Afortunadamente, el mensaje de error incorpora nuestro código y hace todo lo posible por explicar el problema, señalando las ubicaciones exactas.

La creación de prototipos de soluciones en Rust puede ser un desafío debido a su naturaleza de tipo estático y porque Rust requiere cubrir el 100% de las condiciones, no solo el 99%. Los casos extremos deben tener código aplicable, incluso cuando el programador aún no sabe qué debería hacer la ruta feliz. Durante el desarrollo temprano, estos casos extremos a menudo se pueden abordar haciendo que el programa se bloquee y luego se puede agregar un manejo riguroso de errores en un momento posterior. Este es un flujo de trabajo diferente al de lenguajes como Ruby, donde los desarrolladores a menudo prueban el código en un REPL y luego lo mueven a un prototipo sin considerar los casos de error en absoluto.

Rust es todavía relativamente nuevo, lo que significa que es posible que algunas bibliotecas deseadas aún no estén disponibles. La ventaja es que hay mucho terreno fértil para desarrollar estas bibliotecas necesarias, quizás incluso aprovechando los desarrollos recientes en los campos relevantes de la informática. Debido a esto y a las capacidades de Rust, algunas de las bibliotecas de Rust, como la caja de expresiones regulares , son las mejores en su clase en cualquier idioma.

Si bien Rust tiene un fuerte compromiso con la estabilidad y la compatibilidad con versiones anteriores, eso no implica que el lenguaje esté finalizado. Es posible que un problema específico no tenga acceso a las características del lenguaje que lo harían más simple de expresar o quizás incluso posible de expresar. A modo de ejemplo, Rust ha tenido futuros asíncronos durante más de tres años, pero estable async/await asistencia en el idioma en sí está a sólo unos meses de edad.

El compilador de Rust se basa en LLVM , lo que significa que la cantidad de plataformas de destino será menor que C o C ++.

¡Ven y únete a nosotros!

Independientemente de los lenguajes de programación que te gusten ahora, seguramente habrá algo que te entusiasme o intrigue sobre Rust. Estas son algunas de las razones por las que otros y yo amamos tanto a Rust, y hay muchas más. Si está buscando una estructura adicional en su proyecto, un código más rápido o más eficiente, o la capacidad de escribir código de rendimiento de manera más rápida y segura, ¡es hora de que vea si Rust será su próximo lenguaje favorito!

#rust #programming 

¿Qué es Vue.js y por qué es tan especial?

Vue.js es un framework progresivo de JavaScript que te da la flexibilidad necesaria para trabajar con todo tipo de proyectos (grandes o pequeños), además se integra fácilmente a proyectos ya existentes. Pero, ¿Por qué es tan popular? ¿Qué lo hace tan especial frente a otros frameworks y librerías? En este video te lo contamos.

#vue #vue-js