Usa el input type adecuado solo estás usando text a pesar de soliciar un número y un email.
exp1 y exp2 no las usas, supongo que porque ahí harás la tercera limpieza.
A parte de eso no veo nada más.
No sé como están implementadas las funciones, yo personalmente le hecharía un ojo a la implementación desde la perspectiva de un atacante para ver si hay alguna manera de saltarse la limpieza. Depende que hagas con lo que recibes. Si vas a publicar en el propio sitio, por ejemplo usando un document.write(Texto) si el filtro no es perfecto se pueden hacer cosas tipo:
Ejemplo de filtro inutil solamente buscando < > para evitar inserción de scripts.
Texto = FiltroAntiScripts(Texto);
//Contenido de texto:
var x = 60;
var y = 62;
x = asciiToChar(x);
y = asciiToChar(y);
var texto ="";
texto += x;
texto += "script";
texto += y;
texto += "alert(\"Soy un codigo malicioso xD\")";
texto += x;
texto += "/script"
texto += y;
//Fin contenido de texto.
//Tu código:
document.write(Texto);
Se pueden hacer muchas mierdas así.
Me imagino que la implementación está más que testeada, pero si por ejemplo tienes un decoder en tu código, podrían conseguir llamarlo pasándole como parámetro un script codificado que pase los filtros, pudiendo ejecutar el script desde una url de tu propio sitio. Tras lo cual enviando una url que a simple vista parece segura tipo https://www.elhacker.net/decode="agjw3ben72bfiwb5wk75fjw71637173jlspeb"/post.html
Ya me encontré fallos similares en muchos sitios. Hasta injectando rutas en el nombre de usuario para subir shells a carpetas con permisos o modificar algún archivo para tirar el server cambiándole el contenido a:
I'm an evil atacker, you should be scared. Buuuu.
Hints:
-Validate username serverside.
-Delete the last account created.
-Stop use the same credentials to share your accounts.
Jajaja
CitarThe required attribute works with the following input types: text, search, url, tel, email, password, date pickers, number, checkbox, radio, and file.Usar el tipo de input adecuado aseguro que el usuario no se equivoque al introducir los datos o le de sin querer a enviar y se te envien cosas inútiles al server para evitar que trabaje para nada. También evitas que el usuario envie datos erroneos sin darse cuenta.
exp1 y exp2 no las usas, supongo que porque ahí harás la tercera limpieza.
A parte de eso no veo nada más.
No sé como están implementadas las funciones, yo personalmente le hecharía un ojo a la implementación desde la perspectiva de un atacante para ver si hay alguna manera de saltarse la limpieza. Depende que hagas con lo que recibes. Si vas a publicar en el propio sitio, por ejemplo usando un document.write(Texto) si el filtro no es perfecto se pueden hacer cosas tipo:
Ejemplo de filtro inutil solamente buscando < > para evitar inserción de scripts.
Texto = FiltroAntiScripts(Texto);
//Contenido de texto:
var x = 60;
var y = 62;
x = asciiToChar(x);
y = asciiToChar(y);
var texto ="";
texto += x;
texto += "script";
texto += y;
texto += "alert(\"Soy un codigo malicioso xD\")";
texto += x;
texto += "/script"
texto += y;
//Fin contenido de texto.
//Tu código:
document.write(Texto);
Se pueden hacer muchas mierdas así.
Me imagino que la implementación está más que testeada, pero si por ejemplo tienes un decoder en tu código, podrían conseguir llamarlo pasándole como parámetro un script codificado que pase los filtros, pudiendo ejecutar el script desde una url de tu propio sitio. Tras lo cual enviando una url que a simple vista parece segura tipo https://www.elhacker.net/decode="agjw3ben72bfiwb5wk75fjw71637173jlspeb"/post.html
Ya me encontré fallos similares en muchos sitios. Hasta injectando rutas en el nombre de usuario para subir shells a carpetas con permisos o modificar algún archivo para tirar el server cambiándole el contenido a:
I'm an evil atacker, you should be scared. Buuuu.
Hints:
-Validate username serverside.
-Delete the last account created.
-Stop use the same credentials to share your accounts.
Jajaja
