<meta name='google-adsense-platform-account' content='ca-host-pub-1556223355139109'/> <meta name='google-adsense-platform-domain' content='blogspot.com'/> <!-- --><style type="text/css">@import url(https://www.blogger.com/static/v1/v-css/navbar/3334278262-classic.css); div.b-mobile {display:none;} </style> </head> <body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/platform.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d14600643\x26blogName\x3dcodebits\x26publishMode\x3dPUBLISH_MODE_BLOGSPOT\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttps://codebits.blogspot.com/search\x26blogLocale\x3des_AR\x26v\x3d2\x26homepageUrl\x3dhttp://codebits.blogspot.com/\x26vt\x3d7835190106382237642', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>

jueves, agosto 11, 2005

 

Reacciones desmedidas

Leo hoy varias reacciones desmedidas a un presunto bug en el código de WordPress. Esto me pone a pensar en lo fácil que se malinterpretan las cosas y lo sencillo que puede llegar a ser aprovecharse de situaciones como estas para exparcir problemás aún mayores entre los usuarios de un software.

Comencemos por analizar el "bug", que no es tal cosa, sino que es una vulnerabilidad, producida no por el código de WordPress en sí, sino por un valor de configuración del PHP que no es recomendado ni por la gente de WordPress ni por la mismisima gente de PHP: la directiva register_globals puesta en "on". Esta directiva normalmente es parte del archivo php.ini y determina si PHP debe manejar los parametros que recibe en cada request como variables globales o no.

Donde entra a jugar el código de WordPress? La situación es que en el archivo /wp-includes/functions.php existe una linea que no prevee este tipo de situaciones antes de utilizar una variable. El problema, a nivel técnico, junto con su solución están muy bien explicados en este post de 16-bits.com.ar. El asunto en cuestión es determinar que tan responsable es el código de WordPress de no incluir un control más estricto de la "sanidad" del dato, si la vulnerabilidad sólo se produce al usar una configuración de PHP no recomendada en la propia documentación del lenguaje?

Creo que si bien WordPress trata de cumplir la meta de acercar un software de blogging a todo tipo de usuarios, más allá de su conocimiento técnico, hay cuestiones a nivel configuración que exceden las posibilidades de precaución que pueda tomar este software. Y si bien hoy la víctima es WordPress mañana puede ser cualquier otro software que algún script kiddie se ponga a revisar en busca de un control débil, y el origen del problema va a ser siempre el mismo, una directiva de configuración inadecuada que viene siendo desaconsejada desde hace más de 4 años.

Aqui entra otra cuestión en juego, Debe WordPress proveer un parche para esto o es responsabilidad del administrador de cada sitio utilizar una configuración de php adecuada? Muchos fueron los que en un acto desesperado salieron a recomendar que la gente baje una versión del archivo en cuestión provista por un tercero, sin considerar los potenciales riesgos de seguridad que esto significa, en lugar de modificar una configuración que ni siquiera requiere de acceso al php.ini ya que puede ser modificar desde un .htaccess ... peor el remedio que la enfermedad.

Actualización:
Analizando en detalle el asunto con un amigo, veo que cabe aún más responsabilidad sobre WordPress de la que originalmente pensaba. La cuestión es que incluso con register_globals en off, si no se valida el formato de la cookie puedo editar la cookie antes de enviarla y lograr el mismo resultado que pasandola por parámetro.

Actualización 2:
No hagan caso de lo anterior, eso era en el supuesto caso de reemplazar el uso directo de la variable por su equivalente en el array $_COOKIE.

Comments: Publicar un comentario

<< Home