Lo del csrf es muy sencillo, mira:

Imaginemos que tienes un enlace como este: http://foro.elhacker.net/borrar_usuario.php?nick=Skeletron que solo puedes ejecutar cuando estas logueado.
Si yo consigo de algún modo que "hagas click" en el enlace conseguiré que borres tu usuario
Para evitarlo la aplicación web tiene que hacer que esa url no sea siempre válida, para ello lo que se hace es que cuando tu accedes a tu perfil y se muestra el enlace "borrarme" se añade al final un valor aleatorio quedando el enlace asi: http://foro.elhacker.net/borrar_usuario.php?nick=Skeletron&token=adsfadsfadfsafdas además se guarda el token en una variable de sesión.
Entonces en borrar_usuario.php se comprueba que el token existe y corresponde con la variable de sesión.
Así un usuario malintencionado necesitaría tu token para que funcionara, pero como éste cambia en cada formulario ya no es posible.

De todos modos es un ejemplo para que se entienda, el token tambien puede pasarse por post (es lo más común y lo mejor) o por cookie claro y como comenta Nakp si no previenes csrf hay muchos modos de que te obliguen a "hacer click".

De nada 

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!

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 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

Lo dejamos en un empate hasta que se demuestre lo contrario xD, porque con el enunciado ese vete a saber
Esque claro si fallas en el diagrama ya el error va a ser de diseño y siempre es más complicado de corregir

Yo también era de empezar a picar código cuanto antes mejor pero en mi último trabajo me lo exigian y creo que cuando le pillas la costumbre merece la pena por lo claro que te queda el concepto de un solo vistazo, además si te piden una mejora en un futuro ves más claro el impacto que tendrá en la aplicación y ya por último los imprevistos que te ahorras porque ya tienes "todo planeado" antes de empezar a picar una sola tecla.
Aunque claro, todo es discutible y hay quien considera que es hacer el trabajo dos veces xDD

Saludos!

Este es mi dibujito, sin dibujito:
Con esto ya es trivial dibujarlo.

Pero ya puestos:


 

La otra opción que comento sería substituyendo la asociativa por entidad normal.


Y el modelo relacional que ya había puesto:Que NO es lo mismo que la estructura de las tablas en sql como se suele confundir

Pues en realidad a mi me gustan bastante, es el modo más claro y cómodo para diseñar una base de datos

Saludos!

En estos problemas lo más importante es el enunciado, y aquí está muy poco claro, pero dado que yo entiendo los mensajes se envian entre amigos creo que sería:

-Entidad persona
-Amistad relación reflexiva simétrica de persona n-m
-Entidad Mensajes
Al añadir esta última se crearía una asociativa de mensajes con amistad 1-n

Siento no poder hacer el dibujito, pero se entiende.

Del modo anterior al pasar al modelo relacional quedaría:

Persona(dni, nombre, blablabla)
Amistad(dni,dni_amigo,donde_se_conocieron)
Mensajes(dni,dni_amigo,mensaje) donde dni,dni_amigo forana hacía Amistad

Sino se podría quitar la asociativa y que amistad fuera entidad, sería un esquema entidad/relación equivalente y el modelo relacional sería el mismo.

Saludos!

Seguramente será algún trabajo de clase para aprender como funcionan los hilos.


A simple vista en tu código:
-La inicialización del hilo está mal, el argumento debe ser un ThreadStart, quedaría: hilo=new Thread(new ThreadStart(ProcHilo));
-ProcHilo no hace nada por lo tanto cuando se ejecute terminará al instante y el .abort, .sleep, .join y demás no tendrán sentido, deberías poner un bucle infinito dentro y hacer el catch de la excepción cuando el hilo principal llame a .abort
-En el hilo principal estas instanciando cHilo1() sin parámetros pero cuando se crea Thread es en el constructor con parámetro nombreHilo, nunca se crea Thread
-public CHilo1() : this(null) { } Hereda de ella misma? :S para que?
-Sobre lo del bucle que recorra todo en orden, el orden a seguir sería:
Start //Inicia el hilo
Sleep //Pausa el hilo durante cierto tiempo
Abort //Provoca excepción en el hilo para finalizarlo
Join //Bloquea el hilo principal hasta que el hilo finaliza

Saludos!

Porque se desperdicia memoria? se utiliza la justa, más algun puntero con la dirección de memória para redimensionar.
De todos modos en c# no puedes declarar cadenas de tamaño fijo, simplemente porque el ahorro de memória es mínimo, apenas algun puntero y puede que algún unsigned para guardar el tamaño.

En los lenguajes en los que se permite string[11] es más por motivos conceptuales y control de excepciones, una cadena que nunca pueda superar ese tamaño como una matricula o lo que sea y en caso contrario tire error.

Puedes explicar eso? como se optimiza la memoria ocupada por un int? :S

Como dicen los compañeros más arriba, lo bueno de los lenguajes de alto nivel como .net y java es que en caso de que quedaran memory leaks está el garbage collector para solucionar el problema.
De todos modos siempre es bueno que no llegue a pasar eso, y que se libere la memoria automáticamente no significa que el código esté optimizado...

Saludos!