Eso no depende de nosotros, por eso se deja muy en claro en las reglas y post de normas en cada sección que las preguntas deben contener el título lo mas detallado posible.
siempre se ha dicho que un post con un titulo que diga "hola", "ayudaaa" o algo no referente al tema será eliminado, también si te fijas al crear un nuevo post tienes la posibilidad de darle un ícono y entre esos íconos está el de pregunta pero al parecer no todos lo utilizamos y no puedo manejar el mouse por los demás asi que lo único que queda es crear reglas y normas e ir controlando que todo esto se lleve a cabo pero no es porque nosotros queramos que sea así.

En mi caso yo soy moderador de la sección de bugs y exploits a nivel web y no por eso significa que me la paso jodiendo a toda web que se me cruze por delante, claro que no. Todo lo que he aprendido acá sobre seguridad web me ha servido para crear mis propios sistemas de forma segura. Gracias a esto pude aprender php, entender mejor el RFC de html4 y xhtml, manejar el DOM en javascript, mysql y varias cosas mas y no tan solo a utilizarlos sino a crear una programación segura.

Yo se de redes wifi pero no soy tan experto, si algo he podido aprender de ese foro es que por ejemplo no se debe cifrar la red en un tipo de codificacion sino de otra porque una se puede crackear mas facil que la otra, entonces yo con eso puedo tener una red mas segura en mi casa, tambien se sobre ataques smb y accesos comparidos por lo tanto también me cuido de eso.

Pero en resumidas cuentas todo esto significa que lo que he aprendido no me sirve para andar jodiendo a medio mundo tirando paginas webs y desmadrando sistemas, eso es justamente el tipo de gente que queremos evitar, si un dia futuro encuentro un bug que nadie mas conoce yo soy feliz porque es un bug del cual yo me puedo proteger antes de que alguien mas lo descubra e intente joderme a mi.

Saludos y bienvenido al foro!.

jajaja skeletron redescubriste la rueda 

smf no es vulenarble a ese tipo de ataques haciendose pasar por proxy e inyectando codigo arbitrario porque fitra la ip en 4 grupos numéricos tal como indica el standard (RFC).

Ya se enviaron todas las vulnerabilidades encontradas. El dia 30 de noviembre serán publicadas acá lo hayan reparado o no.

alexcof se nota que ni si quiera te has tomado la molestia de leer el post. si buscas automatizacion nunca vas a encontrar la mayoría de los bugs de una web.

escaneadores hay muchos:
http://www.google.com/search?hl=es&site=&q=escaneador+de+vulnerabilidades+web&btnG=Buscar&lr=

los mas conocidos son nstalker, sss, nikito y en fin.

Es el antivirus, lo que sucede es que hay algunos antivirus y cortafuegos que no son muy óptimos en el reconocimiento de webs maliciosas y producen falsos positivos como este. Por lo general pasa de forma automatizada en una base de datos propia del antivirus que viene adjunta a la actualización.

Un sitio web que contenga un enlace hacia un malware no significa que infectamos gente, eso es una estupidez que piensan algunos de los encargados de estos tipos de sistemas y ponen al foro en la lista negra. Si hay enlaces hacia algunos malwares pero para su estudio y comprimidos, si realmente quisieramos infectar gente no creen que el virus o troyano estaría zipeado?.

Hay varios sitios webs que también se dedican al estudio de malwares como por ejemplo el forospyware y milw0rm y no significa que estos sitios infecten gente.

Ese antivirus que utilizas no utiliza un buén criterio en su filtro de sitios webs, eso deja mucho que desear del programa.

Yo te recomendaría utilizar un antivirus de verdad como el nod32 y no porquerias como el panda, mcafee o norton.

http://foro.elhacker.net/seguridad/nueva_encuesta_mejor_antivirus-t178670.0.html
http://foro.elhacker.net/seguridad/nueva_encuesta_mejor_firewall-t178673.0.html

jajaja lo que pasa es que el servidor de seguro utiliza mod_security y en una de sus reglas filtra algún carácter especial que pusiste ahi.

No necesitas insertar un chorro de caracteres al inicio, solo basta con probar con '"<> y ves si se muestra en el código fuente o no y ahi ves si recien puedes inyectar código.

Supongo que como es html inyeccion no podrás inyectar javascript porque seria javascript inyeccion xD

Si es un sistema prefabricado lo primero que hago es descargarme el código fuente e instalarlo en local y despues comienzo a testear.

Yo no veo el codigo fuente al instante sino que comienzo a probar cosas primero y si no va funcionando bien entonces voy comprobando con el codigo fuente y comienzo a debugear.

En el caso de que no sea un sistema publico entonces no queda otra que testear asi nomas.

Yo no uso scanners, antes si los usaba porque no sabia mucho del tema pero los escaneadores muchas veces dan falsos positivos y nunca encuentran todo.

Por ejemplo si el sistema tiene blind inyeccion sql entonces no lo va a encontrar o si tiene una inyección por lo menos un poco fabricada entonces tampoco, por ejemplo el escaneador siempre prueba con comillas y espacios diciendo and 1=1 o or 1=1 etc pero en el caso de que la inyección esté entre parentesis entonces no lo va a encontrar )) and 1=(1
Lo mismo pasa con las xss, si este afecta solamente a una sección que no ves entonces no lo va a encontrar, si hay csrf entonces el escaneador puede que no lo localize.

Un escaneador con suerte te puede encontrar el 15% de las vulnerabilidades aproximadas de un sistema WEB.

Por ejemplo si la web tiene index.php?sección=contacto entonces si no tienes el codigo fuente puedes suponer que se hace haciendo una query a la base de datos, seleccionando una variable del mismo php o si no haciendo un include y eso se puede deducir porque uno ya sabe como programar ese tipo de cosas y por eso siempre digo que para aprender de vulnerabilidades WEBs primero tienes que saber programar en ese lenguaje, entonces pruebas index.php?sección=contacto' or 1='2 y si no resulta pruebas con index.php?sección=contacto' or 1='1 y si tampoco funciona ahi puedes deducir que puede estar utilizando otra forma aunque puede que tenga una inyeccion mas avanzada pero lo dejas para despues y pruebas index.php?sección=index y si ves que te aparece la portada duplicada es porque es LFI, entonces ya sabes que hace un include terminado en .php asi que lo explotas con un null bite index.php?sección=../../../../../../etc/passwd%00 y si funciona entonces despues te pones a buscar de cabeza como poder subir un archivo cualquiera y muchas veces te encuentras con que puedes subir imagenes, le inyectas una shell a la imagen y lo incluyes y ya tienes acceso al servidor.

Despues ves si tiene un panel de adm,in en sitio.com/admin adm robots.txt etc y en lasgunas ocasiones te toparas con varios fallos que te permiten entrar.

Despues vas buscando en algunas variables del sitio, ves el codigo fuente de la web desde firefox y ves si hay alguna variable sospechosa que contenga solo numeros o un archivo con extension, etc y vas testeandolos.

Por ejemplo en una web me toco ver que hacias un index.php?sec=api&tipo=funcionx entonces te mostraba un código en ‭‬javascript que era incluido desde ajax y que contenia la funcion funcionx entonces lo reemplazas y le pones funcionx({}))}alert(documen.cookie) y ves que se ejecuta pero lanza un header de texto plano asi que buscas en el sistema de alguna forma en que pueda llamar a esa función con tu xss inyectado y listo.

Solo es cosa de tener imaginación y saber el lenguaje sobre el que estas auditando. y nunca te apoyes en un scanner porque asi uno nunca aprende y despues vienen al foro diciendo... "el SSS me dijo que x web tiene xss en una variable, que hago ahora?" y ese es el problema.

Actualmente hay una vulnerabilidad en SMF que ningún escaneador pudiera haberlo encontrado y otros mas donde solo puedes ejecutarlos si tienes sesion activa y tebndrias que darle la cookie al escaneador y aun asi faltarian  muchas cosas.

Frikipedia tenía inyeccion sql en el referer y no lo encontré con un escanner.

Hay que tener paciencia, gustarte lo que haces y saber programar por lo menos en html, ‭‬javascript y como secundario puedes aprender el lenguaje que se ejecuta en el servidor que puede ser php, aspx, etc. porque si ves algo que funciona de una forma y no tienes acceso a ver el codigo fuente real puedes deducir como se puede hacer esa función y ves sus posibles puntos debiles y si el programador es precabido se habrá dado cuenta y lo solucionó con algunas lineas extras de código que no puedes ver y eso es lo que vas testeando cosa por cosa.

Yo aprendí bastante de fallas que ni si quiera habia leido en internet tan solo haciendo mis propios sistemas CMS, no es facil pero la gracia es que vas aprendiendo... derrepende dices.... "aah y si alguien hace esto y esto? de seguro va a entrar" y despues te das cuenta que hay sitios webs que funcionan de la misma forma que tu sistema y vas a probar y si funcionan

Yo utilizo el netcat, firefox con los complementos de live headers, ncookies edit, noscript, firebug y un editor de texto que en win es el block de notas y en linux el gedit, nada mas y si se pone dificil uso google.

Utiliza el ida pro, hay un plugin para upx que los desempaca.

Por lo que entendí tu vas a enviar los datos a un sitio web, si es así entonces debes utilizar urlencode ya que el servidor te responderá con un error 400 si intentas enviar carácteres que no sean alfanuméricos sin que estén encodeados a menos que envíes una petición POST como si fueras a enviar un archivo.

Un htmlentities no eviatrá un xss ya que puedes insertar saltos de linea o carácteres nulos. Si por ejemplo tu código está encerrado en un try{} basta con hacer un salto de linea y escribir un }catch(x){alert(document.cookie) ya que el try evitará que se termine la ejecución del script por un error de sintaxis dejando la posibilidad de ejecutar código arbitrario.

Yo te recomendaría que utilizes una función similar a lo que hace escape real string de php pero para js, le haces stripslashses, luego addslashses, eliminas \n \r \01 \00, etc y al final lo pasas por trim o utiliza expresiones regulares con match.

Ahora, si vas a pasar variables que si contienen saltos de linea puedes pasarlos a urlencode y despues lo procesas en urldecode teniendo en cuenta de que si lo vas a imprimir en la página debes tener cuidado de no imprimir todo directamente o si no también tendrás problemas de xss.