¿Qué tipo de entrada es menos vulnerable al ataque?

Question

El tipo de entrada es menos vulnerable a los ataques de secuencias de comandos entre sitios (XSS) y de inyección de SQL.

PHP, HTML, BBCode, etc. Necesito saber para un foro que estoy ayudando a configurar un amigo.

Answer 1

Necesitamos saber más sobre tu situación. Vulnerable como? Algunas cosas que siempre debes hacer:

• Escape las cadenas antes de almacenarlas en una base de datos para protegerse contra las inyecciones de SQL
• Las cadenas de codificación HTML cuando se imprimen de nuevo al usuario desde una fuente desconocida, para evitar el html / javascript malicioso

Nunca ejecutaría php proporcionado por un usuario. BBCode / UBBCode están bien, porque se convierten a html semánticamente correctos, aunque es posible que desee ver las vulnerabilidades de XSS relacionadas con las etiquetas de imagen con formato incorrecto. Si permite la entrada de HTML, puede incluir en la lista blanca ciertos elementos, pero este será un enfoque complicado que es propenso a errores. Por lo tanto, dado todo lo anterior, diría que usar una buena biblioteca BBCode disponible sería su mejor opción.

Answer 2

(Acabo de publicar esto en un comentario, pero parece que algunas personas tienen la impresión de que las listas de selección, los botones de opción, etc. no necesitan ser eliminados).

No cuente con que los botones de radio estén seguros. Todavía debe desinfectar los datos en el servidor. La gente podría crear una página html en su máquina local y hacer un cuadro de texto con el mismo nombre que su botón de opción, y volver a publicar esos datos.

Un usuario más avanzado podría usar un proxy como WebScarab , y solo modifique los parámetros a medida que se publican de nuevo en el servidor.

Una buena regla general es siempre usar sentencias de SQL parametrizadas y siempre escapar de los datos generados por el usuario antes de incluirlos en el HTML.

Answer 3

Ninguno de ellos lo es. Todos los datos que se esperan en el servidor pueden ser manipulados por aquellos con el conocimiento y la motivación. El navegador y el formulario que espera que usen las personas es solo una de las varias formas válidas de enviar datos a su servidor / script.

Familiarícese con el tema de XSS y problemas relacionados

• http://shiflett.org/articles/input-filtering
• http://shiflett.org/blog/2007 / mar / allow-html-and-prevention-xss

Answer 4

Cualquier tipo de booleano.

Incluso puedes filtrar entradas inválidas con bastante facilidad.

;-)

Answer 5

Hay muchos analizadores de código BB que sanean la entrada de HTML, etc. Si no hay uno disponible como paquete, puede consultar uno de los paquetes de software de fuente abierta del foro para obtener orientación.

El código BB tiene sentido ya que es el " estándar " para foros.

Answer 6

La entrada que es la menos vulnerable al ataque es la " no entrada " ;.

¿Estás haciendo la pregunta correcta?

Answer 7

Por el bien de Odin, no desinfecte las entradas. No tenga miedo de que los usuarios ingresen lo que quieran en sus formularios.

La entrada del usuario no es inherentemente insegura. La respuesta aceptada conduce a ese tipo de interfaces web como las de mi banco, donde el Sr. O'Reilly no puede abrir una cuenta, porque tiene un carácter ilegal en su nombre. Lo que no es seguro es siempre cómo se usa la entrada del usuario.

La forma correcta de evitar las inyecciones de SQL es usar declaraciones preparadas. Si la capa de abstracción de su base de datos no le permite usarlas, use las funciones de escape correctas de forma rigurosa (myslq_escape et al). La forma correcta de prevenir los ataques XSS nunca es algo como striptags (). Escapar de todo: en PHP, algo como htmlentities () es lo que está buscando, pero depende de si está enviando la cadena como parte de un texto HTML, un atributo HTML o dentro de Javascript, etc. Use la herramienta correcta para el contexto adecuado. Y NUNCA solo imprima la entrada del usuario directamente a la página.

Finalmente, eche un vistazo a las 10 principales vulnerabilidades de las aplicaciones web y haga lo correcto para evitarlas. http://www.applicure.com/blog/owasp-top-10-2010