Si usas php>=5 y mysql>=4.1 lo mejor es que uses prepared statments
Si no, tienes que escapar los caracteres especiales, utilizando mysql_real_escape_string($_POST['VAR']) o htmlentities($_POST['VAR'],ENT_QUOTES)

De todos modos hay mucha información sobre esto en el foro

Saludos!

pd:y seguramente este hilo debería ir en el subforo de php

Para intentar protegerte de inyecciones SQL tienes softwares como este:

http://www.greensql.net/

Pero si quieres algo mas personalizado, puedes crear dentro del motor de BD procedimientos almacenados y pasarle cierta cantidad de parametros, tambien existen en php creo que magic_quotes... (O no se bien, en Perl se conoce como placeholder) en php no se como se llame esta tecnica, pero tambien se utiliza dentro del lenguaje scripting para intentar evitar las inyecciones SQL.

Que significa que te sigue ingresando perfectamente?
Con mysql_real_escape_string lo que consigues es que los caracteres especiales como las comillas simple se escapen con \', asi te aseguras que no cierran la primera comilla y añaden codigo.
Por lo tanto si a $_POST['mail'] se le pasa: '); drop database bd;-- Puedes estar seguro de que en mails se habrá insertado "'); drop database bd;"-- y no se habrá borrado la base de datos.

Y añadir capas de software para prevenir esto como comenta ^Tifa^ siempre está genial, pero programar bien para evitarlo tampoco cuesta nada y es aún más seguro

Saludos!

Si, hay que hacer lo mismo siempre que construyas sql dinámicamente a partir de la entrada del usuario, en el caso de que construyas el sql con un campo numérico debes comprobar también la entrada con un is_numeric() para que no haya inyección.

Pues si, para evitar xss con htmlspecialchars ya te vale puesto que convierte solo lo peligroso, aunque yo siempre utilizo htmlentities por costumbre, te transforma todos los tags posibles aunque la mayoría no sean necesarios teniendo bien puesto el encoding
Tienes que vigilar siempre todo get, post y cookie. No se que libro que leí hace mucho empezaba con: "La entrada del usuario es siempre incorrecta y peligrosa hasta que se demuestre lo contrario"

Después así sobre seguridad web relacionado también te quedaría prevenir CSRF sin tener en cuenta todo lo más simple: path traversal, rfi, lfi, etc...

Saludos!

cross site request forgery... el ejemplo mas burdo es cuando muestras un link en una imagen (el link de eliminiar algo por ejemplo) pero solo lo puede ejecutar alguien con permisos, sin embargo no pide un token asi que al "ver la imagen" el que tiene permisos, ejecuta alguna accion sin su consentimiento