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.
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:
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
Para los interesados, el título hace referencia a un libro gratuito de unas 147 páginas, en el que se habla de Microsoft Atlas (antiguo nombre para el ahora denominado Microsoft Ajax) para el desarrollo de aplicaciones Web.
El libro está basado en el CTP de Julio de 2006, dividido en 4 capítulos:
- Building Blocks of AJAX-Style Web Applications
- The Paradigm Shift
- The XmlHttpRequest Object
- Existing AJAX Frameworks in .NET
- Conclusion
- Building Blocks of the Atlas Application Framework
- The Atlas Architecture
- The Programming Model of Atlas
- A Sample Atlas Page
- Conclusion
- Updatable Page Fragments
- Atlas Server Controls
- Enabling Page Partial Rendering
- Taking Control of Page Updates
- Providing User Feedback During Updates
- Conclusion
- Atlas Controls and Extenders
- The Atlas Control Toolkit
- The Accordion Control
- The Rating Control
- The ReorderList Control
- Atlas Server Extenders
- Conclusion
Pueden descargarlo desde la siguiente dirección.
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 😉