#30 Acepto las criticas constructivas, lo que me molesta es que remarquen los fallos una y otra vez. lee #3
Ponte en mi situación, yo vengo aquí con la mejor de las intenciones, par aponer algo de código que no voy a necesitar, por si alguno quiere modificarlo, usarlo, o aprender cosas básicas, desde abajo.
Postear un código de Google que tiene muchos fallos, qué gran aporte, a ninguno se nos habría ocurrido buscar allí.
#32 No voy a seguir el juego a alguien que con 25 años rellena su perfil con las características de su ordenador.
Voy ha dejar el tema desde este punto y responderé solo a comentarios constructivos.
#33 Buena actitud esa, has quedado peor que el chico de 25 años que, en una página gamer, pone su rig en el perfil.
Sinceramente, no sé qué esperabas, estamos en un foro y aquí se critica todo. Puede que no de las mejores maneras, pero es así. Si eres tan maduro como quieres aparentar (aunque con el ataque anterior lo pongo en duda) sabrás pasar de las críticas y responder como un caballero sin entrar al trapo.
#33 jajaja menudos argumentos, ahora me vas a decir que por postear en feda no soy un profesional que hace bien su trabajo xDDD Cuánta molestia te has tomado, de entrar en mi perfil y mirarlo de arriba a abajo, grande!
Vas ha dejar el tema? Qué pena ^^
Ya te digo, que vi el thread por la mañana y pensaba que estaba bien, de hecho no me importó. Me importa una puta mierda tu script o de donde lo hayas sacado, lo que no me ha gustado, te lo vuelvo a repetir, es cómo has tratado a usuarios asiduos a este subforo que han mostrado sus críticas constructivas y tu los has despreciado, diciendo que venga, menos palabrería y más hacer, que si no saben programar porque usan frameworks... etc. Awesome.
:si:
Estaría interesante que alguien explicara o diera unas nociones de como crear una aplicación que contenga PHP para que sea segura de verdad.
#36 creo que intentó hacerse aquí
http://www.mediavida.com/foro/9/seguridad-en-aplicaciones-web-453370
no estoy al corriente del hilo.
por cierto y al respecto, con PDO se soluciona en gran medida SQLinjection?
Me autorespondo http://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection
A mi me vendría muy bien porque los proyectos que hice en PHP en el FP2 no utilice ningún tipo de seguridad sobre inyección SQL, etc. Y la verdad que me gustaría saber de gente que trabaja a diario con ello que nos explicarán un poquillo a los que estamos empezando con esto.
#41 ya te han pasado el enlace al hilo que hice, se han puesto un par de enlaces en este hilo, ¿qué mas quieres? ¿Clases particulares? :S
Hola #1, espero que no te tomes a mal mi comentario, pero tengo que decirte que has tenido un error básico al hacer el thread.
Si has cogido un script y lo has cambiado un poco pero eres consciente de lo que es* ponlo de primeras, no te defiendas después. Siempre se agradecen aportes (aunque a mí no se me pasaría por la cabeza utilizar esto, para eso le coloco un excel o un access al tipo en cuestión), pero ten en cuenta que este tipo de piezas reutilizables deben de hacerse con mucho cuidado.
Eso, te pongas como te pongas, es una aberración. Es la cosilla que saca el que va de autodidacta, aprende las cuatro cosas que le convienen y divierten (aunque para mí esto no es un autodidacta) y se pone a hacer chorradas para motivarse, pero luego todo queda en humo.
Por otra parte me gustaría decirte que no tiene nada de malo utilizar frameworks (aunque mola más hacerlos 
). Eso sí, conviene saber las bases (es posible marcarte un desarrollo MVC sin ningún framework de una forma sencilla). De todas formas, es mejor utilizar un framework sin conocer las bases que hacer esto, porque por lo menos el framework (algunos) te obliga a hacer las cosas medio bien (aunque el que no sabe, no sabe).
Ojo, no cuestiono tus habilidades técnicas, pues no las conozco. Lo que cuestiono es tu criterio a la hora de publicar cosas. Yo nunca contrataría a nadie en mi empresa que crea que eso es digno de publicar, aunque sea gratis y para ayudar a la gente.
- siento decirte que para mí ese "script" es sinónimo de no saber programar en absoluto: cuando vi el php y el html mezclado me dieron ganas de pegarme un tiro, por no hablar de otras cosas como la falta de seguridad (no llegué a fijarme en la tabulación con tablas pero si es así, gl...).
#41: Busca la biblia de eso y bájate el libro.
#46: Tampoco es para tanto, pero creo que al haber leído esto entenderás el por qué de algunas críticas (que dicho sea de paso, algunas fallaron en el tono y en eso tienes razón).
#43 Tienes razón, no tendría que haber subido algo de tan mala calidad, la verdad es que estoy bastante arrepentido, no solo por como ha quedado (que repito que no va con mi estilo), sino xq me deja por los suelos como programador (aunque no sea mi código).
[Por lo que pido que se cierre o bloquee el post]
#40 Has probado lo de ese ejemplo? Yo con PDO he sido capaz de inyectar código, pero soy bastante novato al respecto y no sé si fue por usar PDO o porque simplemente lo programé mal. Pero capaz fuí, eso seguro.
#48 a ver con PDO se puede injectar si no está bien programado, tal y como comentan en stackoverflow xD
me interesa mucho el tema, y aprovecho el desvío de SQLi para solventar una duda;
Ahí va, (y perdonadme si digo alguna burrada).
Hasta hace poco evitaba posibles liadas en las consultas con htmlspecialchars(), de momento todo bien, nunca he tenido problemas (también se ha de decir que han sido aplicaciones muy sencillotas, sistema newsletter, comentarios y mp's a los "admins"). Ahora uso mysql_real_escape_string(). Bien, alguien me puede decir cual de las dos es más correcta. O mejor dicho, htmlspecialchars() me servía de algo??¿ xDD
Quiero añadir que la base de datos se ha montado sobre mysql basándome en el modelo relacional. Otra pregunta, si no recuerdo mal escuché una conversación ajena sobre el desuso de las bbdd basadas en el modelo relacional, si es así, alguien me puede decir que se usa actualmente?
#50 yo uso htmlspecialchars con ENT_QUOTES y de momento 0 problemas con eso puedes librarte de mucha basura incluido tipos de injection
Ambas, pero según la ocasión. htmlspecialchars para eliminar y/o permitir ciertas etiquetas, y la otra para escapar caracteres chungos que puedan petar consultas.
Otro "truco" es ocultar las variables lo máximo posible, no las pases por url, trátalas con htaccess.
pd: todo esto, si os parece, podemos tratarlo mejor en este hilo http://www.mediavida.com/foro/9/seguridad-en-aplicaciones-web-453370 que para eso se creó :si:
#54 en vez de dejar una url así
midominio.com/usuario.php?idUsuario=1 , puede quedar así
midominio.com/usuario/1
quedando transparente la variable.
#55 transparente para la barra de navegador, con cualquier inspector ves los post y get que envias
#51 lo ideal es utilizar el combo, sprintf la cadena del query, mysql_real_escape_string para manejar las comillas como texto y addcslashes para las consultas especialmente peligrosas como Like, revoke, etc.
Si es un programa de gestión interna sin importancia no me complico mucho y uso htmlspecialchars como tu, ya que esto reduce considerablemente el peligro de SQL injection con un código mínimo.
