Sesiones
Invetigar sobre los siguientes temas:
Leer más: https://sistemasremington.webnode.com/informatica2/progrmacion-web-ii/actividades/sesiones/
Aspectos Básicos de la Seguridad en Aplicaciones Web
En la actualidad el crecimiento de internet ha impactado directamente en la seguridad de la información manejada cotidianamente. Sitios de comercio electrónico, servicios, bancos e incluso redes sociales contienen información sensible que en la mayoría de los casos resulta ser muy importante.
Se puede decir que uno de los puntos más críticos de la seguridad en Internet son las herramientas que interactúan de forma directa con los usuarios, en este caso los servidores web. Es común escuchar sobre fallas en los sistemas de protección de los servidores más frecuentemente utilizados, por ejemplo Apache, NGINX, IIS, etc. (Build With, 2016) O en los lenguajes de programación en que son escritas las aplicaciones. Sin embargo, la mayoría de los problemas detectados en servicios web no son provocados por fallas de ninguna de estas partes, si no que los problemas se generan por malas prácticas de parte de los programadores.
Debemos entender que programar aplicaciones web seguras no es una tarea fácil, ya que requiere por parte del programador, no sólo cumplir con el objetivo funcional básico de la aplicación, sino una concepción general de los riesgos que puede correr la información procesada por el sistema.
1. Problemas principales en la programación de sistemas web
Gran parte de los problemas de seguridad en las aplicaciones web son causados por la falta de seguimiento en dos rubros muy importantes de los que depende cualquier aplicación, las entradas y salidas del sistema. Ver Ilustración 1.
Ilustración 1. Entrada y salida del sistema.
Además de verificar estos 2 rubros, es importante considerar la exposición accidental de datos que pueden ser empleados en un posible ataque sobre el sistema. Los mensajes de error enviados por el servidor, que suelen ser de gran utilidad durante el proceso de desarrollo de la aplicación, pueden ser empleados maliciosamente cuando siguen apareciendo en un entorno de producción, por lo que es necesario deshabilitar todos estos mensajes y editar algunos otros (como los que se envían cuando el servidor no encuentra algún archivo en particular) los cuales también pueden ser utilizados por los atacantes para obtener información sobre nuestro sistema.
2. Prácticas básicas de seguridad web
2.1 Balancear riesgo y usabilidad
Si bien la usabilidad y la seguridad en una aplicación web no son excluyentes una de la otra, alguna medida tomada para incrementar la seguridad con frecuencia afecta la usabilidad. Normalmente siempre se debe pensar en las maneras en que usuarios ilegítimos nos pueden atacar y la facilidad de uso para los usuarios legítimos.
Es conveniente emplear medidas de seguridad que sean transparentes a los usuarios y que no resulten engorrosas en su empleo. Por ejemplo, el uso de un login que solicita el nombre de usuario y contraseña (Ilustración 2.), permite controlar el acceso de los usuarios hacia secciones restringidas de la aplicación. Este paso adicional, es una característica que impacta en la rapidez de acceso a la información por parte del usuario, pero que proporciona un elemento adicional de protección.
A mayor complejidad de nuestro sitio, aumenta el riesgo de que se sufra un ataque debido a sus características más elaboradas, es por eso que deben considerarse opciones de seguridad necesarias y sencillas pero eficientes, que ayuden a mitigar cualquier característica que la haga vulnerable.
Ilustración 2. Login como medida de seguridad.
2.2 Rastrear el paso de los datos
Es muy importante mantener conocimiento de los pasos que ha recorrido la información en todo momento. Conocer de dónde vienen los datos y hacia dónde van. En muchas ocasiones lograr esto puede ser complicado, especialmente sin un conocimiento profundo de cómo funcionan las aplicaciones web.
En las aplicaciones web, existen maneras de distinguir los orígenes de los datos y poder así reconocer cuando los datos pueden ser dignos de confianza y cuando no.
Normalmente existen arreglos globales en la aplicación (por ejemplo en PHP los arreglos $_GET, $_POST, $_COOKIE y $_SESSION entre otros) que sirven para identificar de forma clara las entradas proporcionadas por el usuario. Si esto lo combinamos con una convención estricta para el nombrado de las variables podemos tener un control sobre el origen de los datos usados en el código.
Además de entender los orígenes de la información se debe dar la misma importancia a entender cuáles son las salidas que tiene la aplicación y hacia a donde se devuelven los resultados.
2.3 Filtrar entradas
El filtrado es una de las piedras angulares de la seguridad en aplicaciones web. Es el proceso por el cual se prueba la validez de los datos. Si nos aseguramos que los datos son filtrados apropiadamente al entrar, podemos eliminar el riesgo de que datos contaminados sean usados para provocar funcionamientos no deseados en la aplicación.
Existen muchos puntos de vista diferentes sobre cómo realizar el filtrado o proceso de limpieza. Lo que usualmente se recomienda es ver al filtrado como un proceso de inspección, no debemos tratar de corregir los datos, es mejor forzar a los usuarios a jugar con las reglas válidas.
Al usar listas blancas asumimos que los datos son inválidos a menos que prueben ser validos al encontrarse patrones coincidentes. Una limitante de usar este punto de vista es considerar inválidos datos que debieron considerarse válidos pero que no fueron tomados en cuenta patrones similares al construir la lista blanca.
Si llegamos a utilizar algún framework se debe tener especial cuidado, ya que estos brindan tantas comodidades que muchos desarrolladores inexpertos los utilizan sin preocuparse en entender el código que están observando y por lo tanto implementan medidas de validación en entradas, variables, entre otros, sin entender exactamente el funcionamiento de la solución empleada.
Es importante notar que en los lenguajes de programación existen una buena cantidad de filtros pero evidentemente estos no llegan a cubrir todas las necesidades que puede tener un desarrollador. En este caso, se llegan a utilizar funciones creadas y adaptadas a nuestras necesidades a modo de filtro especial, en la mayoría de estos casos es donde se puede encontrar el uso de expresiones regulares.
En la Ilustración 3 tenemos un ejemplo en PHP de variables GET sanitizadas mediante una función la cual valida que únicamente sean números enteros (FILTER_SANITAZE_NUMBER_INT) y no contengan etiquetas HTML (strip_tags).
Ilustración 3. Filtrado avanzado usando funciones de PHP.
Una vez concluido el paso del filtrado solo resta usar convenciones apropiadas en el nombramiento de las variables para poder distinguir las que ya han sido filtradas.
2.4 Escapado de salidas
Otro punto importante de la seguridad es el proceso de escapado y su contraparte para codificar o decodificar caracteres especiales de tal forma que su significado original sea preservado. Si llegamos a utilizar una codificación en particular es necesario conocer los caracteres reservados los cuales serán necesarios escapar.
El proceso de escapado debe estar compuesto a su vez por los siguientes pasos:
- Identificar las salidas.
- Escapar las salidas.
- Distinguir entre datos escapados y no escapados.
El proceso de escapado debe adecuarse al tipo de salida de que se trate (si es al cliente, a la base de datos, etcétera). Para la mayoría de los destinatarios, existen funciones nativas en los lenguajes de programación para esta finalidad. En alguno de los casos como podría ser el de base de datos es importante incluso observar la codificación en la que son enviados.
Para distinguir entre los datos que han sido escapados de los que no, es recomendable también usar una convención de nombres. Es necesario una función de escapado para cada caso, como ejemplo en PHP se tomarían las siguientes consideraciones para:
- Correo electrónico, se puede usar la función filter_var() con los argumentos de FILTER_VALIDATE_EMAIL.
- Bases de datos SQL, es más recomendable utilizar consultas parametrizadas pero podríamos utilizar mysql_real_escape_string.
- Líneas de comandos, se puede hacer uso de la función escapeshellarg().
- Código en Javascript, PHP no tiene un método incorporado para escaparlo, pero se puede utilizar json_encode() junto con htmlspecialchars() si se quiere mostrar en HTML.
3. Clasificacion de ataques web.
3.1 Ataques URL de tipo semántico
Este tipo de ataques involucran a un usuario modificando la URL a modo de descubrir acciones a realizar que originalmente no están planeadas para ser manejadas correctamente por el servidor. La implementación de cualquier formulario debe contemplar validaciones necesarias para evitar el esas acciones y se deben realizar adecuaciones de acuerdo a nuestras entradas, en la ilustración 5 se muestra un formulario de logincon campos de usuario y contraseña.
Ilustración 4. Formulario con envio de datos por metodo GET
En el ejemplo anterior los parámetros, que son enviados con el método GET, se agregan directamente en la URL, lo que produce que atacantes inexpertos puedan utilizarlos, ya que son solo un poco más fáciles de capturar y modificar que los enviados de forma oculta desde el navegador (POST). Un ejemplo del envío por GET es el de la ilustración 5.
Ilustración 5. URL con parámetros enviados visibles.
3.2 Ataques de Cross-Site Scripting
Cross-Site Scripting (XSS) es un tipo de vulnerabilidad de seguridad informática típicamente encontrada en aplicaciones web que permiten la inyección de código por usuarios maliciosos en páginas web. Los atacantes típicamente se valen de código HTML y de scripts ejecutados en el cliente. (OWASP, 2014)
Ilustración 6. Definición general de los tipos de XSS. (Domínguez, 2015)
3.3 Ataques de Cross-Site Request Forgery
Este tipo de ataque permite al atacante enviar peticiones HTTP a voluntad desde la máquina de la víctima. Es difícil determinar cuándo una petición HTML se ha originado por un ataque de este tipo.
Cuando un atacante conoce el formato que debe tener una URL para lograr la ejecución de una acción en el sistema, ha logrado encontrar la posibilidad de explotar este tipo de ataques. Ahora lo que necesita el atacante es simplemente hacer que una víctima visite la URL.
Un recurso que se utiliza comúnmente para realizar este tipo de ataques suele tener embebida la petición en una imagen. En este caso el atacante sólo necesita crear alguna etiqueta HTML del siguiente tipo:
Existen acciones que podemos tomar para contrarrestar este tipo de ataques, una de estas es preferir el método POST para el procesamiento de formas en lugar del GET, otra posibilidad es solicitar confirmación por parte del solicitante antes de realizar los procesos (a costa de reducir la usabilidad en la aplicación).
3.4 Peticiones HTTP falsificadas
Un ataque más sofisticado que el anterior es enviar peticiones falsas empleando herramientas especiales para este propósito.
Para ello, se emplean herramientas de línea de comandos o plugins agregados a los navegadores, con estos se pone a la escucha de los servicios web que típicamente se conectan a través del puerto 80. En la ilustración 7 podemos observar los campos que pueden modificarse con Tamper Data.
En realidad un atacante puede confeccionar a gusto sus peticiones HTTP, la fortaleza de nuestro sistema será medible por su capacidad de detectar que peticiones recibidas deben ser escuchadas y procesadas de acuerdo a los parámetros y valores que se vayan a recibir.
4. Seguridad de las aplicaciones y su relación con las bases de datos
La mayoría de las aplicaciones web son usadas como un conducto entre fuentes de información y el usuario, esto es, las aplicaciones web son usadas para interactuar con una base de datos.
Muchos programadores no dan importancia al filtrado de datos provenientes de una consulta a la base de datos, debido a que consideran a esta fuente como confiable. Aunque el riesgo a primera vista parecería menor, es una práctica recomendable no confiar en la seguridad de la base de datos e implementar la seguridad a fondo y con redundancia. De esta manera, si algún dato malicioso fue inyectado a la base de datos, nuestra lógica de filtrado puede percatarse de ello.
4.1 Exposición de Credenciales de Acceso
Uno de los asuntos principales a ser cuidados cuando se utiliza una base de datos es el almacenamiento de las credenciales de acceso a ella.
Los datos de usuario y password son considerados sensibles, por lo que deben tener garantizada una atención especial. En archivos de configuración es común encontrar estos datos los cuales se encuentran como texto en claro. Ver ilustración 8.
Ilustración 8. Código PHP con contraseñas de acceso a base de datos.
La intercepción o acceso no autorizado de esta información podría comprometer los servidores de bases de datos o gestores de contenidos en donde estén alojados. Si por alguna razón no fuera posible localizar al archivo que contiene esta información fuera del directorio raíz, es necesario configurar el servidor web para rechazar las peticiones de recursos que no deben ser accesibles.
4.2 SQL Injection
La inyección de código SQL es la vulnerabilidad número uno en el top de OWASP (OWASP, 2015). Para que exista una vulnerabilidad de SQL Injection se requieren dos fallas por parte del programador:
- Fallas en el filtrado de los datos.
- Fallas en el escapado de los datos al enviarlos a la base de datos (escapado de salida).
-
Ilustración 9. Descripción básica de SQL Injection.
Ninguno de estos pasos cruciales debe ser omitido, y los dos pasos requieren especial atención para poder minimizar los errores. Afortunadamente los ataques de SQL Injection son fácilmente evitables, mientras filtremos y escapemos las salidas.
4.3 Exposición de datos
Una de las preocupaciones más comunes relacionadas con las bases de datos es la exposición de datos sensibles. Al almacenar números de tarjetas de crédito, por ejemplo, es preferible asegurarse que los datos almacenados en la base de datos se encuentran seguros e inaccesibles incluso para los administradores de la base.
Para asegurar que no se almacenan datos como texto en claro en la base de datos, se pueden realizar procedimientos de hash a las cadenas almacenadas para que no sea entendible la información a simple vista. Se debe considerar el costo de esta implementación ya que habría que obtener el hash al insertarlo y al extraerlo realizar la operación inversa, lo que conllevaría a que la aplicación tarde un poco más en responder.
5. Páginas privadas y los sistemas de autenticación
La autenticación consiste en verificar la identidad de un usuario. Comúnmente el procedimiento involucra un nombre de usuario y una contraseña a revisar. Muchas aplicaciones tienen recursos que son accesibles sólo para los usuarios autenticados, así como recursos totalmente públicos.
5.1 Ataques de fuerza bruta
Este tipo de ataque es un método de ensayo y error utilizado para obtener información de una contraseña, clave o número de identificación personal, entre otros. Funciona mediante la generación de un gran número de intentos consecutivos para el valor de los datos deseados. Un ataque de este tipo agota todas las posibilidades sin preocuparse por cuales opciones tienen mayor probabilidad de funcionar.
En los términos del control de acceso, generalmente encontramos al atacante intentando ingresar mediante un gran número de pruebas. En algunos casos el atacante puede conocer nombres de usuario válidos y la contraseña es la única parte que se trata de adivinar.
5.2 Espionaje de contraseñas (Password Sniffing)
Cuando un atacante tiene los medios para analizar el tráfico entre los usuarios y el servidor de la aplicación, debemos preocuparnos por la exposición que pueden tener los datos en el trayecto, sobre todo cuando se trata de credenciales de acceso.
Ilustración 10. Captura de tráfico HTTP con contraseña enviada en claro.
En la actualidad debido a la información que se transmite en la web se recomienda establecer el uso del protocolo HTTPS para poder cifrar el canal de comunicación por el que enviaremos nuestra información. (OWASP, 2016)
5.3 Cookies o variables de sesión persistentes
Cuando un usuario permanece en el estado de registrado después de un tiempo no razonable (por ejemplo, cuando no expira la sesión), tenemos un problema de registros persistentes.
Este tipo de problemas disminuyen la seguridad de nuestro mecanismo de autenticación. Generalmente son causados por una cookie persistente, un ticket enviado al usuario o alguna variable de sesión establecida que no se considera como expirado jamás o que no cambia en cada nuevo registro establecido por el usuario.
Las cookies permanentes y variables de sesión ayudan a los sitios web a recordar tu información y ajustes cuando los visitas más adelante. Esto conlleva un acceso más rápido y sencillo ya que, por ejemplo, no tienes que iniciar sesión de nuevo.
6. Conclusiones
La seguridad en aplicaciones Web involucra principalmente al desarrollador, aunque con gran frecuencia se encuentran defectos que pueden ser aprovechados por atacantes en las tecnologías en que se basan los sistemas web (Sistemas Operativos, Servidores Web, Servidor de Base de Datos, etc.) la atención principal debe dirigirse a los defectos propios al desarrollo nuestras aplicaciones.
Todo programador debe estar consciente que el manejo de las peticiones, para aceptarlas o rechazarlas, deben estar los datos o variables recibidas no cumplan con las características esperadas o predefinidas. Todas las entradas del sistema deben pasar por el filtrado de los datos contenidos para confirmar su usabilidad. Además para el programador debe ser claro y fácil de identificar cuando una variable ya ha sido sometida al proceso de limpieza, de esta forma evitaremos tener que confiar en la memorización o tener que hacer un mapa de los procesos ejecutados por cada línea de código ejecutada de manera previa.
Otro aspecto importante a considerar son los procesos de salida de la información del sistema. Es importante siempre considerar el significado que pueda tener la información enviada en su nuevo contexto, y en el caso de poder crear problemas de interpretación de las salidas, escaparlas para preservarlas. Al igual que en el proceso de filtrado, es importante mantener un control sobre la codificación que tienen los datos antes de enviarlos a su nuevo contexto.
Para mayor información y como solucionar los problemas antes mencionados les recomendamos seguir las Sugerencias de Seguridad para Sitios Web (Aguilar & Hernández, 2014)
7. Referencias
Aguilar, A. & Hernández, A. (25 de Abril de 2014). Obtenido de Sugerencias de Seguridad para Sitios Web: https://www.seguridad.unam.mx/documento-id=1143
Built With. (26 de Enero de 2016). Web Server Usage Statistics. Obtenido de https://trends.builtwith.com/Web-Server
Aguilar, A. (21 de Agosto de 2015). Obtenido de ¿Qué es y cómo opera un ataque de Cross-Site Scripting (XSS)-: https://www.seguridad.unam.mx/documento-id=35
OWASP. (3 de Febrero de 2014). Obtenido de Top 10 2013-A3-Cross-Site Scripting (XSS): https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)
OWASP. (21 de Agosto de 2015). Obtenido de Top 10 2013-Top 10: https://www.owasp.org/index.php/Top_10_2013-Top_10
OWASP. (27 de Enero de 2016). Obtenido de Transport Layer Protection Cheat Sheet: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
Extraido de: https://www.seguridad.unam.mx/historico/documento/index.html-id=17
Aporte Personal: La seguridad en las aplicaciones web es un tema muy importantes que debe ser tenido en cuenta a la hora de programar estas aplicaciones, muchos de los problemas y ataques en las plicaciones web es debido a la baja seguridad provocada por los malas practicas a la hora de programar, con base en esto se debe tener en cuenta una serie de facores importantes para la seguridad de la informacion, factores como rastreo de los datos, sesiones, metodos de envio de informacion, entre otros, asi mismo tener un conocimiento sobre los tipos de ataques que podria sufrir nuestra aplicacion para asi reforzar su seguridad y proteger la informacion.
2. Funciones Comunes:
- session_abort — Desecha los cambios en el array de sesión y finaliza la sesión
- session_cache_expire — Devuelve la caducidad de la caché actual
- session_cache_limiter — Obtener y/o establecer el limitador de caché actual
- session_commit — Alias de session_write_close
- session_create_id — Crear un nuevo ID de sesión
- session_decode — Decodifica la información de sesión desde una cadena de sesión codificada
- session_destroy — Destruye toda la información registrada de una sesión
- session_encode — Codifica los datos de la sesión actual como un string codificado de sesión
- session_gc — Realizar una recolección de basura de datos de sesión
- session_get_cookie_params — Obtener los parámetros de la cookie de sesión
- session_id — Obtener y/o establecer el id de sesión actual
- session_is_registered — Averiguar si una variable global está registrada en una sesión
- session_module_name — Obtiene y/o establece el módulo de sesión actual
- session_name — Obtener y/o establecer el nombre de la sesión actual
- session_regenerate_id — Actualiza el id de sesión actual con uno generado más reciente
- session_register_shutdown — Función de cierre de sesiones
- session_register — Registrar una o más variables globales con la sesión actual
- session_reset — Reinicializar el array de sesión con los valores originales
- session_save_path — Obtener y/o establecer la ruta de almacenamiento de la sesión actual
- session_set_cookie_params — Establecer los parámetros de la cookie de sesión
- session_set_save_handler — Establece funciones de almacenamiento de sesiones a nivel de usuario
- session_start — Iniciar una nueva sesión o reanudar la existente
- session_status — Devuelve el estado de la sesión actual
- session_unregister — Deja de registrar una variable global de la sesión actual
- session_unset — Libera todas las variables de sesión
- session_write_close — Escribir información de sesión y finalizar la sesión
- SessionHandler — La clase SessionHandler
- SessionHandler::close — Cerrar la sesión
- SessionHandler::create_sid — Devuelve un nuevo ID de sesión
- SessionHandler::destroy — Destruir una sesión
- SessionHandler::gc — Eliminar las sesiones antiguas
- SessionHandler::open — Inicializar una sesión
- SessionHandler::read — Leer información de la sesión
- SessionHandler::write — Escribir información de sesión
- SessionHandlerInterface — La clase SessionHandlerInterface
- SessionHandlerInterface::close — Cerrar la sesión
- SessionHandlerInterface::destroy — Destruir una sesión
- SessionHandlerInterface::gc — Limpieza de sesiones antiguas
- SessionHandlerInterface::open — Inicializar una sesión
- SessionHandlerInterface::read — Leer información de sesión
- SessionHandlerInterface::write — Escribir información de sesión
Configuración Del Servidor
Puedes usar cualquier servicio de alojamiento web que tenga PHP y MySQL ya instalados (sólo asegúrese de tener la versión PHP 5.3 ó superior y MySQL 4.1.3 ó superior). Para esta guia, se usó Xampp como servidor.
Paso 1 – MySQL
En primer lugar, es necesario que cree la base de datos y la tabla que almacenara todos los registros. Puedes hacer esto de forma manual utilizando la interfaz gráfica de usuario de PhpMyAdmin ó usar SQL para insertar esta información. Si deseas usar SQL, las siguientes lineas te crearan tanto la base de datos como la tabla:
[bash]
/* Create Database */
CREATE DATABASE userlitdb;
/* Create Table */
CREATE TABLE `usertbl` (
`id` int(11) NOT NULL auto_increment,
`full_name` varchar(32) collate utf8_unicode_ci NOT NULL default ”,
`email` varchar(32) collate utf8_unicode_ci NOT NULL default ”,
`username` varchar(20) collate utf8_unicode_ci NOT NULL default ”,
`password` varchar(32) collate utf8_unicode_ci NOT NULL default ”,
PRIMARY KEY (`id`),
UNIQUE KEY `username` (`username`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
[/bash]
Observe que todos ellos son de tipo varchar, incluso la contraseña que se convertirá más tarde en md5 para asegurar la contraseña del usuario. Además, use un AUTO_INCREMENT para asignar automáticamente un ID ó un número de usuarios que se registrarían más tarde.
Ahora que la tabla se ha creado, lo que tienes que hacer es implementar la estructura con HTML y diseño con CSS, luego vendrá el PHP.
Paso 2 – El HTML
Ya que el proceso lo haremos del lado del servidor (por usar solo PHP), usaremos tres archivos PHP en cual se cuenta con las funciones y la estructura con el HTML. En primer lugar, se crea el archivo login.php. Sientete libre de copiar el siguiente código:
[php]
session_start();
?>
if(isset($_SESSION["session_username"])){
// echo "Session is set"; // for testing purposes
header("Location: intropage.php");
}
if(isset($_POST["login"])){
if(!empty($_POST[‘username’]) && !empty($_POST[‘password’])) {
$username=$_POST[‘username’];
$password=$_POST[‘password’];
$query =mysql_query("SELECT * FROM usertbl WHERE username=’".$username."’ AND password=’".$password."’");
$numrows=mysql_num_rows($query);
if($numrows!=0)
{
while($row=mysql_fetch_assoc($query))
{
$dbusername=$row[‘username’];
$dbpassword=$row[‘password’];
}
if($username == $dbusername && $password == $dbpassword)
{
$_SESSION[‘session_username’]=$username;
/* Redirect browser */
header("Location: intropage.php");
}
} else {
$message = "Nombre de usuario ó contraseña invalida!";
}
} else {
$message = "Todos los campos son requeridos!";
}
}
?>
Logueo
" . "MESSAGE: ". $message . "
";} ?>
[/php]
A continuación, creamos el archivo register.php. Copie y pegue el siguiente código:
[php]
if(isset($_POST["register"])){
if(!empty($_POST[‘full_name’]) && !empty($_POST[‘email’]) && !empty($_POST[‘username’]) && !empty($_POST[‘password’])) {
$full_name=$_POST[‘full_name’];
$email=$_POST[‘email’];
$username=$_POST[‘username’];
$password=$_POST[‘password’];
$query=mysql_query("SELECT * FROM usertbl WHERE username=’".$username."’");
$numrows=mysql_num_rows($query);
if($numrows==0)
{
$sql="INSERT INTO usertbl
(full_name, email, username,password)
VALUES(‘$full_name’,’$email’, ‘$username’, ‘$password’)";
$result=mysql_query($sql);
if($result){
$message = "Cuenta Correctamente Creada";
} else {
$message = "Error al ingresar datos de la informacion!";
}
} else {
$message = "El nombre de usuario ya existe! Por favor, intenta con otro!";
}
} else {
$message = "Todos los campos no deben de estar vacios!";
}
}
?>
" . "Mensaje: ". $message . "
";} ?>
Registrar
[/php]
A continuación, se crea la pagina de bienvenida en el archivo intropage.php. Esto servirá como la página principal una vez que un usuario inicia sesión exitosamente.
[php]
session_start();
if(!isset($_SESSION["session_username"])) {
header("location:login.php");
} else {
?>
}
?>
[/php]
Si la estructura se maneja con HTML, ¿por que usar PHP con HTML? Simple, PHP es tan flexible que nos permite usar HTML incrustado, si prefieres y quieres probar a tu modo, puedes separar la estructura del HTML del código PHP Pero bueno, que seria del HTML sin el CSS en estos días?
Paso 3 – El CSS
Para darle un aspecto bien interesante al ejercicio, le daremos un pequeño retoque con CSS, es por esto que se ve bastante llamativo el formulario
[css]
*= GENERAL STYLES
——————————————————–*/
body {
background: #efefef;
font-family: ‘Open Sans’, sans-serif;
color: #777;
}
a {
color: #f58220;
font-weight: 400;
}
span {
font-weight: 300;
color: #f58220;
}
.mlogin {
margin: 170px auto 0;
}
.mregister {
margin: 80px auto 0;
}
.error {
margin: 40px auto 0;
border: 1px solid #777;
padding: 3px;
color: #fff;
text-align: center;
width: 650px;
background: #f58220;
}
.regtext {
font-size: 13px;
margin-top: 26px;
color: #777;
}
/*= CONTAINERS
——————————————————–*/
.container {
padding: 25px 16px 25px 10px;
font-weight: 400;
overflow: hidden;
width: 350px;
height: auto;
background: #fff;
-webkit-box-shadow: 0 1px 3px rgba(0,0,0,.13);
-moz-box-shadow: 0 1px 3px rgba(0,0,0,.13);
box-shadow: 0 1px 3px rgba(0,0,0,.13);
}
#welcome {
width: 500px;
padding: 30px;
background: #fff;
margin: 160px auto 0;
-webkit-box-shadow: 0 1px 3px rgba(0,0,0,.13);
-moz-box-shadow: 0 1px 3px rgba(0,0,0,.13);
box-shadow: 0 1px 3px rgba(0,0,0,.13);
}
.container h1 {
color: #777;
text-align: center;
font-weight: 300;
border: 1px dashed #777;
margin-top: 13px;
}
.container label {
color: #777;
font-size: 14px;
}
#login {
width: 320px;
margin: auto;
padding-bottom: 15px;
}
.container form .input,.container input[type=text],.container input[type=password],.container input[type=e] {
background: #fbfbfb;
font-size: 24px;
line-height: 1;
width: 100%;
padding: 3px;
margin: 0 6px 5px 0;
outline: none;
border: 1px solid #d9d9d9;
}
.container form .input:focus {
border: 1px solid #f58220;
-webkit-box-shadow: 0 0 3px 0 rgba(245,130,32,0.75);
-moz-box-shadow: 0 0 3px 0 rgba(245,130,32,0.75);
box-shadow: 0 0 3px 0 rgba(245,130,32,0.75);
}
/*= BUTTONS
——————————————————–*/
.button{
border: solid 1px #da7c0c;
background: #f78d1d;
background: -webkit-gradient(linear, left top, left bottom, from(#faa51a), to(#f47a20));
background: -moz-linear-gradient(top, #faa51a, #f47a20);
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=’#faa51a’, endColorstr=’#f47a20′);
color: #fff;
padding: 7px 12px;
-webkit-border-radius:4px;
-moz-border-radius:4px;
border-radius:4px;
float: right;
cursor: pointer;
}
.button:hover{
background: #f47c20;
background: -webkit-gradient(linear, left top, left bottom, from(#f88e11), to(#f06015));
background: -moz-linear-gradient(top, #f88e11, #f06015);
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=’#f88e11′, endColorstr=’#f06015′);
}
/*= FOOTER
——————————————————–*/
footer {
color: #777;
font-size: 12px;
text-align: center;
margin-top: 20px;
}
[/css]
Extraido de: www.freepik.es/vector-gratis/plantilla-de-login_1036677.htm
Aporte Personal: Para la creacion de sesiones debemos tener en cuenta todos los factores que acompañen la creacion de nuestra aplicacion web factores como la estructura HTML, el codigo PHP para realizar la creacion, el registro, recuperacion, etc de las sesiones, tambien debe ser tenido en cuenta nuestra implementacion de estilos con CSS esto para darle una mejor pariencia a nuestro aplicativo.
4. METODOS DE ACCESO:
Las sesiones, en aplicaciones web realizadas con PHP y en el desarrollo de páginas web en general, nos sirven para almacenar información que se memorizará durante toda la visita de un usuario a una página web. Dicho de otra forma, un usuario puede ver varias páginas durante su paso por un sitio web y con sesiones podemos almacenar variables que podremos acceder en cualquiera de esas páginas.
Digamos que las sesiones son una manera de guardar información, específica para cada usuario, durante toda su visita. Cada usuario que entra en un sitio abre una sesión, que es independiente de la sesión de otros usuarios. En la sesión de un usuario podemos almacenar todo tipo de datos, como su nombre, productos de un hipotético carrito de la compra, preferencias de visualización o trabajo, páginas por las que ha pasado, etc. Todas estas informaciones se guardan en lo que denominamos variables de sesión.
PHP dispone de un método bastante cómodo de guardar datos en variables de sesión, y de un juego de funciones para el trabajo con sesiones y variables de sesión. Lo veremos en este artículo.
Para cada usuario PHP internamente genera un identificador de sesión único, que sirve para saber las variables de sesión que pertenecen a cada usuario. Para conservar el identificador de sesión durante toda la visita de un usuario a una página PHP almacena la variable de sesión en una cookie, o bien la propaga a través de la URL. Esto se puede configurar desde el archivo php.ini.
Trabajo con sesiones en PHP
Cuando queremos utilizar variables de sesión en una página tenemos que iniciar la sesión con la siguiente función:
session_start ()
Inicia una sesión para el usuario o continúa la sesión que pudiera tener abierta en otras páginas. Al hacer session_start() PHP internamente recibe el identificador de sesión almacenado en la cookie o el que se envíe a través de la URL. Si no existe tal identificador se sesión, simplemente lo crea.
Una vez inicializada la sesión con session_start() podemos a partir de ahora utilizar variables de sesión, es decir, almacenar datos para ese usuario, que se conserven durante toda su visita o recuperar datos almacenados en páginas que haya podido visitar.
La sesión se tiene que inicializar antes de escribir cualquier texto en la página. Esto es importante y de no hacerlo así corremos el riesgo de recibir un error, porque al iniciar la sesión se deben leer las cookies del usuario, algo que no se puede hacer si ya se han enviado las cabeceras del HTTP.
Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at )
Una vez iniciada la sesión podemos utilizar variables de sesión a través de $_SESSION, que es un array asociativo, donde se accede a cada variable a partir de su nombre, de este modo:
$_SESSION["nombre_de_variable"]
Existen otras dos configuraciones del php.ini que afectan al trabajo con variables de sesión, que son track_vars y register_globals. Por defecto track_vars está activado y register_globals está desactivado. Este es el caso normal y el que suponemos tendrá el servidor donde programes, pero si esas variables cambian podría cambiar alguna cosita, como que las variables se tengan que registrar explícitamente con session_register().
Ejemplo de código para definir una variable de sesión
session_start();
?>
<html>
<head>
<title>Generar variable de sesióntitle>
head>
<body>
$_SESSION["mivariabledesesion"] = "Hola este es el valor de la variable de sesión";
?>
body>
html>
Como se puede ver, es importante inicializar la sesión antes de hacer otra cosa en la página. Luego podremos definir variables de sesión en culquier lugar del código PHP de la página.
Para leer una variable de sesión se hace a través del mismo array asociativo $_SESSION. Es tan sencillo como haríamos para utilizar cualquier otra variable, lo único es que tenemos que haber inicializado la sesión previamente. Y por supuesto, que la variable que deseamos acceder exista previamente.
session_start();
?>
<html>
<head>
<title>Leo variable se sesióntitle>
head>
<body>
Muestro esa variable:
echo $_SESSION["mivariabledesesion"];
?>
body>
html>
Como se puede ver, al inicio del código hemos inicializado la sesión y luego en cualquier parte del código podríamos acceder a las variables de sesión que tuviésemos creadas.
Más sobre sesiones en PHP
La siguiente información sobre sesiones de PHP también puede ser de útil lectura. No obstante lo expresado hasta aquí es una información mucho más actualizada. En las próximas líneas se explican mecanismos para sesiones pero todos los que se comentan, aunque son válidos, no son actuales por tratarse de explicaciones para versiones de PHP más antiguas.
Hemos dicho en el capítulo anterior que la variables de sesión se diferencian de las variables clásicas en que éstas residen en el servidor, son especificas de un solo usuario definido por un identificador y pueden ser utilizadas en la globalidad de nuestras páginas.
Para iniciar una sesión podemos hacerlo de dos formas distintas:
-Declaramos abiertamente la apertura de sesión por medio de la función session_start(). Esta función crea una nueva sesión para un nuevo visitante o bien recupera la que está siendo llevada a cabo.
-Declaramos una variable de sesión por medio de la función session_register('variable'). Esta función, además de crear o recuperar la sesión para la página en la que se incluye también sirve para introducir una nueva variable de tipo sesión.
Las sesiones han de ser iniciadas al principio de nuestro script. Antes de abrir cualquier etiqueta o de imprimir cualquier cosa. En caso contrario recibiremos un error.
Con lo visto, vamos a proponer el ejemplo clásico de utilización de una sesión: un contador. Este contador deberá aumentar de una unidad cada vez que recargamos la página o apretamos al enlace:
session_register('contador');
?>
<HTML>
<HEAD>
<TITLE>contador.phpTITLE>
HEAD>
<BODY>
If (isset($contador)==0)
{$contador=0;}
++$contador;
echo "<a href="contador.php">Has recargado esta página $contador vecesa>";
?>
BODY>
HTML>
La condición if tiene en cuenta la posibilidad de que la variable $contador no haya sido todavía inicializada. La función isset se encarga de dar un valor cero cuando una variable no ha sido inicializada.
Otras funciones útiles para la gestión de sesiones son:
Extraido de: desarrolloweb.com/articulos/321.php
Aporte personal: los metodos de acceso a las sesiones en php debe aplicarse siempre al inicio de cualquier otra instancia de lo contrario nuestro codigo nos arrojara error, la sentencia en PHP para el inicio de sesion es session_start(), esta instancio crea una sesion o mantiene la sesion de un usuario previamente logueado, Php tambien utiliza otras importantes fnciones para el manejo de las sesiones como lo son entre otras la Session_id(), session_destroy(), session_unregister(), que nos sirven para identificar la sesion, abandonar la sesion eliminando las variables e identificadores y abandonar la variable session respectivamente.
Extraido de: www.slideshare.net/leowicho/sesiones-y-cookies-en-php
5. CIERRE DE SESION:
session_destroy
(PHP 4, PHP 5, PHP 7)
session_destroy — Destruye toda la información registrada de una sesión
bool session_destroy ( void )
session_destroy() destruye toda la información asociada con la sesión actual. No destruye ninguna de las variables globales asociadas con la sesión, ni destruye la cookie de sesión. Para volver a utilizar las variables de sesión se debe llamar a session_start().
Para destruir la sesión completamente, como desconectar al usuario, el id de sesión también debe ser destruido. Si se usa una cookie para propagar el id de sesión (comportamiento por defecto), entonces la cookie de sesión se debe borrar. setcookie() se puede usar para eso.
Ejemplo #1 Destruir una sesión con $_SESSION
// Inicializar la sesión.
// Si está usando session_name("algo"), ¡no lo olvide ahora!
session_start();
// Destruir todas las variables de sesión.
$_SESSION = array();
// Si se desea destruir la sesión completamente, borre también la cookie de sesión.
// Nota: ¡Esto destruirá la sesión, y no la información de la sesión!
if (ini_get("session.use_cookies")) {
$params = session_get_cookie_params();
setcookie(session_name(), '', time() - 42000,
$params["path"], $params["domain"],
$params["secure"], $params["httponly"]
);
}
// Finalmente, destruir la sesión.
session_destroy();
?>
Extraido de: php.net/manual/es/function.session-destroy.php
Extraido de: specchio.pklin.ru/destruir-session-php-al-cerrar-navegador/
Aporte Personal: Es importante tener en cuenta que en cada inicio de sesion se guardan variables que pertenecen a cada sesion iniciada y de ellos se pueden generar registro, es de importancia para los programadors tener en cuenta que se debe agregar en el codigo del cierre de sesion para no comprometer informacion de los usuarios, para ellos PHP ofrece una comoda funcion para destruir completamente la sesion esta funcion es : session_destoy(), hay que resaltar que esta funcion elimina las variables de la sesion mas no compromete las variables globales.
6. Encriptación de contraseñas:
Modelo de almacenamiento cifrado
SSL/SSH protege los datos que viajan desde el cliente al servidor: SSL/SSH no protege los datos persistentes almacenados en una base de datos. SSL es un protocolo que protege los datos mientras viajan por el cable.
Una vez que un atacante obtiene acceso directo a una base de datos (eludiendo el servidor web), los datos sensibles almacenados podrían ser divulgados o mal utilizados, a menos que la información esté protegida por la base de datos misma. Cifrar los datos es una buena forma de mitigar esta amenaza, pero muy pocas bases de datos ofrecen este tipo de cifrado de datos.
La forma más sencilla para evitar este problema es crear primero un paquete de cifrado propio y utilizarlo en los scripts de PHP. Hay muchas extensiones de PHP que pueden ser de ayuda para esto, tales como Mcrypt y Mhash, cubriendo así una amplia variedad de algoritmos de cifrado. El script cifra los datos antes de insertarlos en la base de datos, y los descifra al obtenerlos. Véanse las referencias para ejemplos adicionales del funcionamiento del cifrado.
'Hashing'
En caso de datos que deban estar realmente ocultos, si no fuera necesaria su representación real, (es decir, que no sean mostrados), quizás convenga utilizar algoritmos hash. El ejemplo más típico del uso del hash es a la hora de almacenar el hash criptográfico de una contraseña en una base de datos, en lugar de almacenar la contraseña en sí.
En PHP 5.5 o posterior las funciones de password proporcionan una forma adecuada de utilizar hash con datos delicados y trabajar con estos hash. En PHP 5.3.7+ se puede utilizar también la biblioteca » password_compat.
password_hash() se emplea para usar un hash con una cadena dada utilizando el algoritmo más fuerte actualmente disponible, mientras que password_verify() comprueba si la contraseña dada coincide con el hash almacenado en la base de datos.
Ejemplo #1 Campo de contraseña con hash
// Almacenar el hash de la contraseña
$consulta = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
pg_escape_string($nombre_usuario),
password_hash($contraseña, PASSWORD_DEFAULT));
$resultado = pg_query($conexión, $consulta);
// Consultar si el usuario envió la contraseña correcta
$consulta = sprintf("SELECT pwd FROM users WHERE name='%s';",
pg_escape_string($nombre_usuario));
$fila = pg_fetch_assoc(pg_query($conexión, $consulta));
if ($fila && password_verify($contraseña, $fila['pwd'])) {
echo 'Bienvenido, ' . htmlspecialchars($nombre_usuario) . '!';
} else {
echo 'La autenticación ha fallado para ' . htmlspecialchars($nombre_usuario) . '.';
}
?>
En versiones anteriores de PHP esto se puede realizar con la función crypt().
Ejemplo #2 Contraseña con hash utilizando crypt()
// Almacenar el hash de la contraseña
// $caracteres_aleatorios se obtuvo, p.ej., utilizando /dev/random
$consulta = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
pg_escape_string($nombre_usuario),
pg_escape_string(crypt($contraseña, '$2a$07$' . $caracteres_aleatorios . '$')));
$resultado = pg_query($conexión, $consulta);
// Consultar si el usuario envió la contraseña correcta
$consulta = sprintf("SELECT pwd FROM users WHERE name='%s';",
pg_escape_string($nombre_usuario));
$fila = pg_fetch_assoc(pg_query($conexión, $consulta));
if ($fila && crypt($contraseña, $fila['pwd']) == $fila['pwd']) {
echo 'Bienvenido, ' . htmlspecialchars($nombre_usuario) . '!';
} else {
echo 'La autenticación ha fallado para ' . htmlspecialchars($nombre_usuario) . '.';
}
?>