Category: Seguridad

Artículos y opiniones sobre seguridad Web, SQL Injection, XSS, etc.

Categories
Provocación Seguridad

¿Las certificaciones sirven para algo?

En mi lectura diaria, encontré una entrada en la que se comenta que SANS creó un instituto de seguridad (Software Security Institute), en el cual se tomará un examen que determina si los candidatos conocen sobre técnicas de seguridad para escribir código seguro (por el momento los lenguages que se mencionan son C/C++, Java/J2EE y próximamente Perl, PHP, .NET y ASP.NET).

Como curioso que soy 🙂 me puse a resolver una prueba gratuita de Java/J2EE -hice esto porque actualmente no existen pruebas para .NET o PHP-, entre las que se incluían algunas preguntas generales y otras específicas con respecto a técnicas de seguridad usando este lenguaje. Esta es la calificación que obtuve:

SANS Software Security Institute Test Results

Ustedes se preguntarán que hay de malo con esta calificación, pues el pequeño detalle es que yo en este momento conozco muy poco de Java y jamás desarrollé una aplicación con J2EE.

Aunque los conceptos de seguridad se pueden aplicar en varios lenguajes, esto dista mucho de los objetivos que SANS -o cualquier empresa que se dedica a certificar gente- desea lograr... si alguien llegara a contratarme basándose solamente en este resultado, es obvio que sería un desastre para el trabajo que me asignen los primeros meses.

No es por desmerecer a las personas que tienen certificaciones -y saben de lo que hablan, pero en mi humilde opinión, éstas solo sirven para adornar el curriculum vitae y casi siempre para convencer a empleadores que sólo se fijan en estas cosas.

Categories
Seguridad

¿Qué hace difícil a la seguridad?

Michael Howard:

I’ve been asked this question numerous times, often in the guise of a question like, "why can't you guys simply fix the security problem?" or "reliability and scalability problems are understood and solvable, why can't you do the same with security?" or my favorite variant, "what the heck keeps you interested in security when it seems you're fighting a 'no-win' battle?"

...

So what is it that makes security hard?

It’s simple:

  • Scalability and reliability issues are man-vs-machine and machines are stupid.
  • Security is man-vs-man and humans are intelligent.

This security stuff is an ongoing arms race and chess game, and each side is constantly trying to outwit the other. We raise the bar, and the attackers then spend time trying to defeat that bar. So we raise the bar again, and so on. With reliability and scalability, we can understand the "adversary" and that’s that. The "enemy" won’t adapt to defeat you!

Cuánta razón tiene al decir que esta es una constante batalla entre los que intentan desarrollar software seguro y aquellos que talvez con más tiempo, dinero de por medio u otras motivaciones se dedican a encontrar vulnerabilidades.

Por tanto, es nuestra responsabilidad como desarrolladores, estar pendiente de aquellos aspectos de seguridad que se pueden presentar en nuestras aplicaciones, caso contrario estaremos en desventaja y probablemente ya hayamos perdido esta lucha sin cuartel 🙂

Categories
CSRF Seguridad Web WordPress XSS

Actualización de seguridad: WP-Cache 2.1.1

Este último fin de semana, Ricardo Galli liberó una nueva versión que corrige unos problemas de seguridad presente en su popular plugin WP-Cache.

Estos problemas se presentaban porque en versiones anteriores no se implementaron ningún tipo de control para evitar ataques del tipo CSRF al momento de guardar las opciones de este plugin, por lo cual alguien podía usar un exploit parecido al de unos días atrás para persistir HTML peligroso en el archivo de configuración.

Si la siguiente prueba de concepto funciona en tu blog, entonces es recomendable actualizar de versión (sólo se hicieron cambios en la página que guarda las preferencias, así que no debería haber problemas):

code:

http://wp/wp-admin/options-general.php?page=wp-cache/wp-cache.php&wp_rejected_user_agent=</textarea><script>alert(/XSS/)</script>

Por otro lado, si tienen algo de experiencia en PHP, les sugiero que revisen los plugins que actualmente usan y guardan sus preferencias en base de datos (presencia de la función update_option); si no encuentran ninguna llamada a las funciones wp_nonce_field, wp_nonce_url, wp_verify_nonce o check_admin_referer, entonces probablemente sus instalaciones de WordPress son vulnerables a este tipo de ataques.

Categories
Seguridad Sql Injection Web WordPress XSS

Más vulnerabilidades: XSS e ¿Inyección de SQL? en WordPress

Esto es de nunca acabar, se siguen reportando más vulnerabilidades XSS en WordPress, el siguiente ejemplo funciona en todas las versiones 2.x de WordPress (incluyendo la versión en desarrollo).

code:

http://wordpress/wp-admin/page-new.php?saved="><script>alert(123)</script>

Para solucionar este problema, apliquen la función attribute_escape a la dirección URL que retorna de get_page_link (línea 13 de wp-admin/page-new.php en 2.1.2).

php:

<?php echo attribute_escape(get_page_link( isset($_GET['posted']) ? $_GET['posted'] : $_GET['saved'] )); ?>

Por otro lado, la persona que reportó esa vulnerabilidad, también me comentó que existe una vulnerabilidad de Inyección de SQL que afecta a todas las versiones de este popular y últimamente bastante inseguro CMS.

La siguiente cita es parte del mail que recibí hoy en la mañana:

But there is another XSS:
wp-admin/page-new.php?saved="><script>alert(123)</script>

There is also an SQL Injection Vulnerability in combination with PHP 4.3.9
It is Possible to spy out any data. The vulnerability exists in all versions, incl. svn trunk

Categories
.NET ASP.NET Seguridad Web XSS

ValidateRequest no es suficiente para protegernos de ataques XSS

En una entrada anterior ya había advertido que la validación que ofrece la propiedad ValidateRequest es muy básica como para sólo confiar en ésta. Para probar esta afirmación tomaremos como ejemplo el siguiente código que seguramente muchos escribimos alguna vez y que otros todavía lo siguen haciendo 🙁

html:

<%@ Page Language="C#" AutoEventWireup="true" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <%= Request.Params["Mensaje"] %>
       
        <a href="<%= Request.Params["Uri"] %>">¡Hola!</a>
    </div>
    </form>
</body>
</html>

Conseguir ejecutar javascript usando el parámetro Mensaje, es un poco fastidioso, porque hay que evitar usar las cadenas <[a-z!] para evitar una excepción del tipo HttpRequestValidationException, por ejemplo para http://aspspider.org/buayacorp/xss.aspx?Mensaje=<script> se produce el siguiente error:

A potentially dangerous Request.QueryString value was detected from the client (Mensaje="<script>").

Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. You can disable request validation by setting validateRequest=false in the Page directive or in the configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case.

Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.QueryString value was detected from the client (Mensaje="<script>").

Revisando uno de los hilos de los foros de sla.ckers.org, uno de los miembros comentó que -para variar- Internet Explorer interpreta los atributos que se ponen en el cierre de algunas etiquetas HTML (</a style=xss:expression(alert(/XSS/))>). Aprovechando este vector de ataque, entonces un ejemplo válido para conseguir ejecutar javascript es http://aspspider.org/buayacorp/xss.aspx?Mensaje=</a style=xss:expression(alert(/XSS/))>.

En el segundo caso que involucra al parámetro Uri es más sencillo, puesto que no se necesita de ningún caracter < para poder ejecutar javascript, para la siguiente dirección http://aspspider.org/buayacorp/xss.aspx?Uri=" style=xss:expression(alert(/XSS/)) " se genera:

html:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>
        Untitled Page
</title></head>
<body>
    <form name="form1" method="post" action="xss.aspx?Uri=%22+style%3dxss%3aexpression(alert(%2fXSS%2f))+%22" id="form1">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEzNDEyMDg2NjZkZCXpsuyzajePI7u8zKPoDxOfXJHy" />
</div>

    <div>
       
       
        <a href="" style=xss:expression(alert(/XSS/)) "">Click</a>

    </div>
    </form>
</body>
</html>

Si entre la audiencia todavía existen desarrolladores que confían en la validación por omisión que trae ASP.NET, es hora de empezar a utilizar los métodos que trae la clase HttpUtility o mejor aún el denominado Microsoft Anti-Cross Site Scripting Library 😉