**Los artículos son de Kriptopolis
1ª Parte
2ª Parte


| ||||
Hola trasgukabi, en el mensaje de Biblioteca de Clases,Funciones y Sub-rutinas comentás que sería bueno agregar a una función de Muzztein lo siguiente: Cita: Bueno, y Muzztein en esa función aconseja eliminar los signos =, la comilla doble, el " or ", " and " y otros símbolos. str=replace(str,"--","") str=replace(str,"select","") str=replace(str,"insert","") str=replace(str,"update","") str=replace(str,"delete","") str=replace(str,"drop","") str=replace(str,"-shutdown","") str=replace(str,"--","") http://www.forosdelweb.com/showpost....7&postcount=19 Yo me pregunto... Si ya eliminamos la posibilidad de que coloquen una comilla simple reemplazando ésta por dos de ellas seguidas... ¿igualmente pueden hacerte un SQL Inyection o ya está totalmente descartada la posibilidad?
__________________ ...___... |
| ||||
![]() quizas no, pero porsicaso... De toda maneras. EXCELENTE ARTICULO. Casi de poesia. Lectura recomendada 1000% Gracias al que puso el link, y para el que escribio el articulo va un APLAUSOTE ![]() Me encanto la forma de escribir, buenisimo ![]() |
| ||||
Si, Muzztein, el "por las dudas" no está demás... igualmente es algo que siempre me pregunté. Porque leyendo muchos de esos artículos (que comparto: es excelente) siempre hablan (ejemm... escriben =) sobre controlar el uso del apóstrofe y nunca mencionan nada más. Ahora bien, ya dije que el "por las dudas" nunca está de más... pero me gustaría una respuesta tipo SI/NO a mi anterior pregunta ;) (y mucho mejor si viene acompañada con algún artículo, que reitero, nunca encontré ninguno)
__________________ ...___... |
| ||||
Al: en teoría, cualquier ataque sql injection debe empezar con el apostrofe, ya que hay que cerrar el = o el like de la consulta del servidor. Por consiguiente, si eliminas el apostrofe y las comillas dobles no se podría hacer SQL Injection. Ahora, yo no soy Neo, colega. Lo poco que sé de SQL Injection es lo que he compartido con vosotros y puede ser que algún gurú que haya suelto por ahí te diga otra cosa. Pero en principio la respuesta es NO. Un saludo a todos, monstruos, que sois unos monstruos!!!!! |
| ||||
trasgu, entonces tenemos la misma forma de pensar ante la teoría mencionada. Además compartimos otras cosas: Ninguno de los dos es Neo (xD), por lo menos "algo de lo que sabemos" es porque alguien lo ha compartido con nosotros y... no somos gurúes (o por lo menos "gurúes sueltos" =) Otro saludo para vos, monstruo ![]()
__________________ ...___... |
| ||||
Cita: Pues parecese que SI.
Iniciado por Al Zuwaga ... pero me gustaría una respuesta tipo SI/NO a mi anterior pregunta Cita: (y mucho mejor si viene acompañada con algún artículo, que reitero, nunca encontré ninguno)(Si ya eliminamos la posibilidad de que coloquen una comilla simple reemplazando ésta por dos de ellas seguidas... ¿igualmente pueden hacerte un SQL Inyection ...?) Cita: http://msdn.microsoft.com/msdnmag/is...n/default.aspxThere are two basic approaches to validation: disallow troublesome characters or only allow a small number of required characters. While you can easily disallow a few troublesome characters, such as the hyphen and single quote, this approach is less than optimal for two reasons: first, you might miss a character that is useful to hackers, and second, there is often more than one way to represent a bad character. For example, a hacker may be able to escape a single quote so that your validation code misses it and passes the escaped quote to the database, which treats it the same as a normal single quote character. A better approach is to identify the allowable characters and allow only those characters. This approach requires more work but ensures a much tighter control on input and is more safe. Regardless of which approach you take, you'll also want to limit the length of the entry because some hacks require a large number of characters. Saludos y nunca esta demás prevenir que lamentar ![]() Última edición por Myakire; 26/10/2004 a las 08:50 |
| ||||
El último para complementar: Cita: 8.0 How to avoid SQL Injection? Filter out character like single quote, double quote, slash, back slash, semi colon, extended character like NULL, carry return, new line, etc, in all strings from: - Input from users - Parameters from URL - Values from cookie For numeric value, convert it to an integer before parsing it into SQL statement. Or using ISNUMERIC to make sure it is an integer. Change "Startup and run SQL Server" using low privilege user in SQL Server Security tab. Delete stored procedures that you are not using like: master..Xp_cmdshell, xp_startmail, xp_sendmail, sp_makewebtask 9.0 Where can I get more info? One of the earliest works on SQL Injection we have encountered should be the paper from Rain Forest Puppy about how he hacked PacketStorm. http://www.wiretrip.net/rfp/p/doc.asp?id=42&iface=6 Great article on gathering information from ODBC error messages: http://www.blackhat.com/presentation...Litchfield.doc A good summary of SQL Injection on various SQL Server on http://www.owasp.org/asac/input_validation/sql.shtml Senseport's article on reading SQL Injection: http://www.sensepost.com/misc/SQLinsertion.htm |