Despues de unos cuantos años ya auditando paginas web he de decir que las paginas que siempre me dan mas dolores de cabezas (de primeras, luego hay algunas que…) son las paginas en ASP.Net. Cuando veo una tengo que respirar hondo, concienciarme y armarme de paciencia.
Por defecto ASP.Net tiene algunas caracteristicas de seguridad que haran nuestros primeros ataques infructuosos, empezando por el codigo HTML que genera. El primer paso de toda auditoria que hago es leer el codigo HTML e intentar pensar como el desarrollador ha generado aquello. Ni que decir tiene que comentarios e indentaciones ayudan a la imaginacion 
Pero es que con ASP.Net se le quitan a uno las ganas… Nombres de variables como ctl00$divPrincipal$TextLabel1 y multitud de llamadas a WebResource.axd hacen que sea un poco mas coñazo analizarlas con un un proxy local.
Ademas esta el “problema” del VIEWSTATE y sus amigos EVENTTARGET, EVENTARGUMENT, etc. Cuando se ponen de acuerdo para salir a paseo por tu proxy puedes olvidarte de muchas cosas (CSRF) pero sobre todo de limpieza en las peticiones. Lidiar con un campo oculto que a veces me ha llegado a ocupar mas de 500 Kb en cada peticion (auditamos seguridad, no rendimiento, pero se les podrian decir un par de cosas…) es algo poco agradable, por no decir algo peor.
Luego claro esta olvidate de base de los ataques XSS. Si se te ocurre meter algo que parezca una etiqueta HTML la aplicacion lo va a parar. Aqui solo tienes dos esperanzas:
- La aplicacion no tiene controlados los errores y muestra un bonito mensaje de debug con algo de informacion y una captura para añadir al informe.
- Encuentras un texto que se incluye dentro de una etiqueta HTML por lo que no necesitas añadir los simbolos > y <
Pero aun con esas si la aplicacion usa autenticacion por formulario tenemos que todas las cookies van a estar marcadas como httpOnly por defecto, asi que nos olvidamos del robo de sesion 
Y hablando de formularios! ASP.Net proporciona una serie de componentes para autenticacion, recuperacion de contraseña y registro donde, no hace falta decirlo, no hay manera de inyectar. No podeis dejar a los desarrolladores que se hagan sus propios formularios de login?
Para terminar con las cosas que Microsoft hace bien en ASP.Net es el tema de los privilegios y roles de usuarios. Si los programadores son cuidadosos (en las ultimas he encontrado un par de sitios donde no lo habian sido ) y hacen uso de las funciones de ASP.Net, podemos estar seguros de que las fugas de informacion o escaladas de privilegios van a ser las minimas.
En fin, que estoy deseando que la proxima auditoria sea un PHP……….. se nota mucho? 
Alguna vez me he encontrado yo petes en ASP.NET con campos donde dejan escribir “algunos” tag HTML. Ahi normalmente desactivan “las no comillas” y demás filtrado sospechoso.
Eso y las querystring no correctamente detectadas y parseadas con TryParse().
Pero si, en el curro me llaman talibán pero sólo por estar tipado ya añade una capa adicional de seguridad respecto de PHP por ejemplo
Comment by Kartones — 2010/05/13 @ 1:13 PM
Bueno, si dejan “algunos” tag HTML estan perdidos…
Luego el tipado, que no he comentado por obvio, pero el parseo a Int hace que cualquier parametro sea imposible de usar para meter un 1=1
Taliban no se, pero donde este un PHP desarrollado desde 0 que se quite cualquier cosa para auditar
Comment by Pedro Laguna — 2010/05/13 @ 1:19 PM
http://blog.skeptikal.org/2010/04/5-reasons-httponly-wont-save-you.html
Comment by palako — 2010/05/13 @ 3:25 PM
@palako Si, si, quizas me he pasado un poco con lo de olvidarse del robo de sesion, no debi de haber sido tan drastico, pero de las 5 razones que ahi se exponen, ninguna se podia aplicar a la aplicacion en cuestion. Bueno si, la ultima, y esa se elimina por la imposiblidad de incluir Javascript en ningun lado.
Y ya que te pasas escribe algo mas!
Comment by Pedro Laguna — 2010/05/13 @ 3:35 PM
mirate el comentario que puse en ese enlace, que es el XST, es el mas interesante de todos (asi que son 6 razones)
Birras? Hoy voy a estar por el intrepid fox….
Comment by palako — 2010/05/13 @ 3:57 PM
Vale, lo del XST, toda la razon, pero nunca he visto un IIS 6 respondiendo a TRACE… Tu conoces alguno?
Lo del intrepid fox imposible hoy, que mañana vuelo temprano
Comment by Pedro Laguna — 2010/05/13 @ 4:26 PM
ehhhh…. no has mirao mucho, no? porque viene activado por defecto
http://www.shodanhq.com/?q=IIS
coje cualquiera y prueba:
$ nc -vv 98.131.182.35 80
Connection to 98.131.182.35 80 port [tcp/http] succeeded!
OPTIONS / HTTP/1.1
Host: something.com
HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD
Content-Length: 0
Server: Microsoft-IIS/6.0
Public: OPTIONS, TRACE, GET, HEAD, POST
X-Powered-By: ASP.NET
Date: Fri, 14 May 2010 14:35:38 GMT
Comment by palako — 2010/05/14 @ 2:40 PM
Bueno, eso si que lo probe, estuve mirando un poco antes de contestarte… Pero, ademas del OPTIONS, tambien intente hacer el TRACE:
Que bueno, ya sabes que es Microsoft y nunca hay que fiarse de lo que dicen
Comment by Pedro Laguna — 2010/05/17 @ 8:25 AM
Couldn’t agree more. Give me a PHP over an ASP, ASPX or JSP any day. (my Spanish was good enough to read the post but not good enough to write my comment)
Comment by ethicalhack3r — 2010/05/31 @ 12:28 AM