2010-01-23 10 views
5

¿Hay alguna razón por la que debería o no debería nombrar los campos de su formulario exactamente igual que los campos HTML?¿Nombra los campos de tu formulario lo mismo que mysql realmente presenta algún riesgo de seguridad?

<input type="text" name="my_field_1" id="my_field_1" /> --> mysql row my_field_1 

o

<input type="text" name="myField1" id="myField1" /> --> mysql row my_field_1 

La única cosa que puedo pensar son, probablemente, las convenciones de nomenclatura para HTML vs MySQL (preferencia personal tal vez), así como una ligera prevención de inyección (obviamente, el nombre del campo tendría que varían más ... pero todos los valores deben validarse primero de todos modos + el uso de la cadena de escape real).

+2

¿Dónde está la diferencia entre el 'o'? ;) –

+0

Olvidó formatear el código. Edité y formateé el código. – BalusC

+0

"cuerda de escape real"? seguramente, quiere decir "consultas parametrizadas". – aib

Respuesta

2

La única forma en que veo que esto podría plantear un problema es cuando el atacante conoce el nombre de una columna protegida en la misma tabla que no se debe cambiar a través del formulario y crea un nuevo elemento de entrada con ese nombre con la intención de "deslizar" el valor ilegalmente en la mesa.

Eso es algo que su programa necesidad filtro de todos modos en el nivel de los programas, así que no hay problema con el nombramiento de los campos de formulario después de que sus nombres de las columnas reales. Solo tiene que tener cuidado de no recorrer nunca cada columna de tabla disponible o el campo de formulario, pero sea exigente con lo que se actualiza.

Un riesgo secundario muy remoto es que está exponiendo nombres de columna en su tabla. Por lo tanto, si es súper paranoico con respecto a la seguridad, es posible que desee asignar a los campos del formulario un nombre diferente de su columna. Pero no puedo ver ninguna necesidad real para eso.

+0

+1, muy buen punto. –

+0

mientras casi todos proporcionan la misma respuesta (que no tiene nada de malo), tu publicación simplemente demuestra que tal vez estoy un poco paranoica :) – jwzk

0

En realidad, nadie sabrá que utilizó los nombres de los campos en lugar de los nombres personalizados (excepto algunos nombres de columnas típicos). ¿Cómo pueden ellos ahora? Tal vez utilizó nombres personalizados, tal vez no;)
Hace que su código sea más fácil de entender si usa los mismos nombres y su código será más fácil de mantener.

Pero lea las otras respuestas para estar al tanto de los problemas que podrían ocurrir.

0

De acuerdo. No hay problema.

De hecho, si nombra los campos igual que los campos de tabla, puede hacer algunos esquemas de bucle geniales que hacen que la actualización o inserción en MySQL sea más automatizada.

+0

Los esquemas de bucle son una mala idea, ya que espero haber ampliado en mi responder. – blowdart

+0

Disculpe, no incluí muchos ejemplos de código, pero lo que hice en el pasado los une a los dos. Por lo general, tengo una matriz de campos "esperados" a través de los cuales realizo un bucle, obteniendo los valores asociados presentes en la matriz POST y la validación. Entonces no es un ciclo cerrado, no ... ya que es solo una mala idea. – jerebear

2

Si está validando, no, pero no limite la validación a lo que espera del formulario. ¿Qué pasa si tiene una tabla de comentarios con una columna de propietario y construye ciegamente una declaración de actualización de SQL de todos los campos en el formulario, porque sabe que no hay un campo de propietario allí? ¿Qué sucede si uso TamperData, una extensión de Firefox que me permite agregar datos a una solicitud y agrego un campo de propietario?

No recorra todos los campos y acéptelos, asegúrese de que solo los campos que espera están allí y no hay extras.

0

No es un riesgo de seguridad, siempre y cuando su sitio web sea 100% seguro para las inyecciones de SQL. Así que preferiría preocuparme por ese hecho, que por elegir/usar nombres de campo.

0

No, porque debe suponer que cualquier atacante tiene acceso a toda su base de código fuente de todos modos, por lo que nombrarlos de otra forma no reduciría su capacidad para atacarlo.

La forma correcta de proteger una aplicación es escribirla correctamente, no ocultar la información que alguien podría necesitar para atacarla (pueden obtenerla de todos modos).

Cuestiones relacionadas