PHP/MySQL - Los caracteres seguros para mostrar los nombres/nombres de usuario/contraseñas, con DOP

Question

un poco de PHP/MySQL novato aquí ...

He estado construyendo un sitio basado en PHP que utiliza una base de datos MySQL para almacenar información del usuario, como sus nombres para mostrar, nombres de usuario y contraseñas.

He estado aprendiendo acerca del escape, declaraciones preparadas y similares, y cómo evitar inyecciones SQL como "bobby"); drop table users-- ".

Estoy usando sentencias preparadas de PDO para obtener la entrada del usuario de formularios, con el fin de registrarlos en la base de datos. Sin embargo, necesito saber algunas cosas:

1. Desde que estoy usando comandos preparados, para los nombres de pantalla, nombres de usuario, contraseñas, etc, está bien para mí permitir caracteres especiales como @, #, $, o incluso 'solo' o 'doble' cotizaciones? ¿Y qué hay de espacios, caracteres internacionales, caracteres con acentos o cosas como ♥ ? Y cuando pregunto si está "bien" permitir estos caracteres, estoy preguntándome si existen otros riesgos de seguridad que puedan surgir de permitir comillas o paréntesis en los nombres de usuario de las personas, o cosas como etiquetas html para negrita o cursiva?

2. Si está bien para permitir más caracteres especiales, pero no algunos: son Hay caracteres específicos "peligrosos" (en el ámbito de MySQL) la que tienen una necesidad imperiosa de hacer ilegal? (Me siento como cotizaciones puede encajar esta agenda, pero yo estoy haciendo señales mixtas en eso.)

3. Si tuviera que permitir a los personajes fuera de la típica "alfanumérica y subrayado" rango, ¿hay trampas I puede experimentar más tarde (en MySQL, SQL o PHP) al permitir caracteres extraños? ¿Necesitaré de alguna manera hacer que las etiquetas html aparezcan como cadenas, en lugar de las etiquetas reales , al mostrar los nombres de usuario de las personas? ¿O tendría que escapar de las citas en los nombres de usuario de las personas cada vez que quisiera consultarlas? ¿O nada de esto importa ya que usaré las declaraciones preparadas con PDO?

4. Haz conjuntos de caracteres UTF-8 o como utf16 vienen en cualquier lugar, en lo que es por lo que puede aceptar la más amplia gama de nombres de visualización y nombres de usuario, mientras que todavía asegurándose de esos alfabetos se pueden representar en mi sitio web?

5. Sé que hay algunas letras cirílicas que parecen idénticas a en inglés. Solía ​​copiar estos directamente de MS Word y usar en mis nombres de usuario. Me doy cuenta de que estos pueden usarse para imitar a otros miembros perceptualmente, simplemente cambiando una "a" por una "a" cirílica. Los nombres de usuario con ♥ en ellos pueden ser difíciles para buscar si alguien no está bien versado en alt-code. ¿Debería ser esto una preocupación? ¿Qué opinas de esto?

Gracias de antemano a quien pueda darme una idea de esto.

Answer 1

Primero déjenme decir que me gusta mucho su estilo. Parece que la mayoría de las personas no se toman el tiempo de pensar detenidamente estas cosas, y solo abren consultas sin ningún tipo de sanitización de datos. Así que felicitaciones por ser diligente. :)

Dicho esto, con PDO, no debería tener que preocuparse por las cotizaciones que arruinan sus consultas. Especialmente si vincula sus variables con bindParam, lo que permite un control estricto de los parámetros. Con eso puedes lanzar el tipo de variable y la longitud. Además, los caracteres especiales no arruinarán tu consulta, ya que también se les escapa el DOP. Entonces no hay necesidad de preocuparse por eso.

En cuanto a hacer que HTML aparezca como texto en lugar de HTML real, una función muy útil es htmlspecialchars(), que convertirá el código html en códigos de caracteres. Esta función también se puede usar con el indicador opcional ENT_QUOTES, que convierte este " en este ". htmlspecialchars() también tiene una opción para establecer el resultado a la codificación de su elección.

Answer 2

Este SQL Injection Cheat Sheet tiene varios ejemplos de consultas MySQL que puede probar mientras está en desarrollo.

Es un gran recurso para conocer algunas de sus preguntas sobre lo que es "Aceptable", y debe tener en cuenta todo el ciclo de vida de "un dato".

Normalmente, una pieza de datos podría comenzar en una forma HTML y luego publicado a su script PHP (por lo que, si el usuario desea que sólo puede datos POST directamente sin forma). Entonces su script php (con suerte) desinfecta los datos, entonces es Almacenado.

Mientras que en la base de datos, que podría estar haciendo de copia de seguridad operaciones, guardándolo en un SQLDump, o algún otro tipo de mantenimiento.

Entonces, obviamente, los datos se Leer en algún momento, si se trata de un lenguaje de reducción del precio puede ser que consiga compilado, y finalmente se envía al navegador de alguien, donde es probable que sea inyecta en html y muestra.

Como puede ver, hay un montón de lugares en el ciclo de vida de un dato donde las cosas pueden salir mal. Si no tiene en cuenta todo esto, puede ver algunos errores comunes, como barras invertidas que se acumulan cada vez que guarda/carga los datos ... errores sql, volviéndose vulnerable a ataques, etc.

¿Qué tipo de datos? ¿quieres apoyar? Eso depende de usted. Solo asegúrate de manejarlo correctamente.