UT6.- Desarrollo de Aplicaciones Web Utilizando Código Embebido
description
Transcript of UT6.- Desarrollo de Aplicaciones Web Utilizando Código Embebido
DESARROLLO WEB EN
ENTORNO SERVIDOR
UT6.- Desarrollo de aplicaciones Web utilizando código embebido
Departamento de Informática y Comunicaciones
CFGS Desarrollo de Aplicaciones Web
Segundo Curso
IES Virrey Morcillo
Villarrobledo (Albacete)
Índice
1. Introducción ....................................................................................................................................................................................................... 1
2. Mantenimiento del estado ........................................................................................................................................................................... 1
2.1. Administración de estado basada en cliente ............................................................................................................................. 2
2.2. Administración de estado basada en servidor ......................................................................................................................... 3
3. Manejo de cookies ........................................................................................................................................................................................... 4
3.1. Configuración de cookies desde HTTP ......................................................................................................................................... 5
3.2. Ejemplo de uso de cookies ................................................................................................................................................................ 7
4. Seguimiento de sesión de un cliente web ............................................................................................................................................. 9
4.1. Funcionalidad de sesión básica ....................................................................................................................................................... 9
4.2. Uso de cookies con sesiones .......................................................................................................................................................... 10
4.3. Almacenamiento del identificador de sesión ......................................................................................................................... 10
4.4. Inicio de sesión .................................................................................................................................................................................... 10
4.5. Registro de variables de sesión .................................................................................................................................................... 11
4.6. Uso de variables de sesión.............................................................................................................................................................. 11
4.7. Anulación del registro de variables y eliminar la sesión .................................................................................................. 11
4.8. Ejemplo de uso de variables de sesión ..................................................................................................................................... 11
5. Seguridad en aplicaciones Web .............................................................................................................................................................. 13
5.1. Implementar tecnología de seguridad ...................................................................................................................................... 13
5.2. Modelo de amenazas ......................................................................................................................................................................... 13
5.3. Recomendaciones de seguridad para aplicaciones Web .................................................................................................. 14
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 1
1. Introducción
Las aplicaciones Web fueron concebidas para mostrar contenidos estáticos, es decir, información no
cambiante en función del tiempo, lo que equivale a decir que ante diversas peticiones del mismo recurso,
siempre se obtiene como respuesta el mismo contenido. Por este motivo, no existía la necesidad de almacenar el
estado de las aplicaciones Web, pues las acciones realizadas y los datos introducidos de forma previa a la
petición de un recurso eran irrelevantes.
En este sentido, el protocolo HTTP, que es el protocolo sobre el que se basa la comunicación de
contenidos Web, se diseñó sin estado. Esta carencia no debería tildarse de defecto, pues el hecho de no tener que
reservar recursos para almacenar el estado proporciona una elevada escalabilidad para compartir información,
ya que los requisitos de memoria necesarios son mucho más reducidos. De hecho, esta elevada escalabilidad ha
permitido, entre otras cosas, la rápida extensión de contenidos Web. Por otra parte, dado que los contenidos de
las aplicaciones Web han ido cambiando con el paso del tiempo, ya sea incluyendo información dinámica
dependiente del usuario conectado o incluyendo contenidos multimedia, aparece la necesidad de almacenar
acciones realizadas o datos introducidos previamente, es decir, se requiere almacenar el estado de la aplicación.
Ante esta necesidad, el primer objetivo que se plantea es la elección de un mecanismo apropiado para el
almacenamiento del estado. De hecho, existe una propuesta (RFC2109), comúnmente conocida como cookies,
que pretende dotar de un mecanismo estándar para manejar el estado.
No obstante, a pesar de que la mayoría de los navegadores permiten el uso de cookies, no se ha
convertido en el único mecanismo utilizado para almacenar el estado, sino que coexiste con otros, como pueden
ser los campos ocultos, el ViewState o las variables de sesión. Gracias a que existen diferentes alternativas a la
hora de almacenar la información de estado, es necesario identificar los factores más relevantes que
determinarán la elección del mecanismo apropiado para la gestión del estado, que son, entre otros: el tamaño y
tipo de la información a almacenar, la duración temporal de la información, la velocidad de almacenado y
recuperación y los factores de seguridad.
2. Mantenimiento del estado
Cada vez que la página se envía al servidor, se crea una nueva instancia de la clase de la página Web. En
la programación Web tradicional, esto se traduce en que toda la información asociada a la página y sus controles
se pierden con cada recorrido de ida y vuelta. Por ejemplo, si un usuario escribe información en un cuadro de
texto, dicha información se perderá en el recorrido de ida y vuelta desde el explorador o dispositivo cliente al
servidor.
Para superar esta limitación inherente de la programación Web tradicional, los lenguajes del lado del
servidor incluyen varias opciones que ayudan a preservar los datos en cada página y en toda la aplicación. Estas
características son las siguientes:
Estado de vista
Estado de control
Campos ocultos
Cookies
Cadenas de consulta
Estado de aplicación
Estado de sesión
Propiedades de perfiles
Las características de estado de vista, estado de control, campos ocultos, cookies y cadenas de consulta
almacenan todas ellas datos en el cliente de formas distintas, mientras que las características de estado de
aplicación, estado de sesión y propiedades de perfil almacenan los datos en la memoria del servidor. Cada opción
tiene ventajas y desventajas, dependiendo del escenario.
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 2
2.1. Administración de estado basada en cliente
Los siguientes apartados describen opciones para administrar el estado que almacenan la información
en la página o en el equipo cliente. En estas opciones, la información no se conserva en el servidor entre acciones
de ida y vuelta, y son las siguientes:
a) Estado de vista:
La propiedad ViewState proporciona un objeto de diccionario para conservar valores entre las distintas
solicitudes de una misma página. Éste es el método predeterminado que la página utiliza para conservar
los valores de las propiedades de la propia página y sus controles entre recorridos de ida y vuelta.
Cuando se procesa la página, se calcula el valor de hash del estado actual de la página y de los controles
en una cadena y se guarda en la página como campo oculto o varios campos ocultos si el volumen de los
datos almacenados en la propiedad ViewState sobrepasa un valor especificado. Cuando se vuelve a
enviar la página al servidor, ésta analiza la cadena de estado de vista durante su inicialización y la
información de las propiedades se restablece en ella.
En un estado de vista se puede también almacenar valores.
b) Estado de control:
En ocasiones es necesario almacenar los datos del estado de control para que un control funcione
correctamente. Por ejemplo, si ha escrito un control personalizado con varias fichas que muestran
distintos tipos de información, el control debe saber la ficha que se selecciona en los recorridos de ida y
vuelta para que funcione tal y como se espera. La propiedad ViewState se puede utilizar para este
propósito, pero los desarrolladores pueden desactivar el estado de vista en el nivel de página,
interrumpiendo su control eficazmente. Para resolver este problema, el marco de trabajo de la página
cuenta con una característica denominada "estado de control".
La propiedad ControlState permite mantener la información de las propiedades que es específica de un
control y que no se puede desactivar como ocurre con la propiedad ViewState.
c) Campos ocultos:
Algunos lenguajes del lado del servidor permiten almacenar información en un control HiddenField, que
se representa como campo oculto estándar HTML. Un campo oculto no está visible en el explorador,
pero se pueden configurar sus propiedades igual que las de un control estándar. Cuando se envía una
página al servidor, el contenido del campo oculto se envía en la colección Form de HTTP junto con los
valores de otros controles. Un campo oculto actúa como repositorio de cualquier información específica
de página que desee almacenar directamente en la página.
Un control HiddenField almacena una única variable en su propiedad Value y se debe agregar en la
página de forma explícita.
Para que los valores de los campos ocultos estén disponibles durante el procesamiento de la página,
debe enviarla mediante el método POST de HTTP. Si utiliza campos ocultos y una página se procesa
como respuesta a un vínculo o a un comando GET de HTTP, los campos ocultos no estarán disponibles.
d) Cookies:
Una cookie es una cantidad pequeña de datos que se almacena en un archivo de texto en el sistema de
archivos del cliente o que se mantiene en la memoria durante la sesión del explorador cliente. Contiene
información específica del sitio que el servidor envía al cliente junto con el resultado de la página. Las
cookies pueden ser temporales (con fechas y horas de caducidad específicas) o permanentes.
Las cookies se pueden utilizar para almacenar información acerca de un cliente, sesión o aplicación
específicos. Las cookies se guardan en el dispositivo cliente y, cuando el explorador solicita una página,
el cliente envía la información de la cookie junto con la información de la solicitud. El servidor puede
leer la cookie y extraer su valor. Uno de los usos típicos es almacenar un símbolo (puede que cifrado)
que indica que el usuario ya se ha autenticado en la aplicación.
El explorador sólo puede devolver los datos al servidor que creó la cookie. Sin embargo, algunos
usuarios malintencionados cuentan con medios para tener acceso a las cookies y leer su contenido. Se
recomienda no almacenar información confidencial, como el nombre de usuario o la contraseña, en una
cookie. En su lugar, se almacena un símbolo en la cookie que identifique al usuario y, a continuación, se
utiliza el símbolo para buscar la información confidencial en el servidor.
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 3
e) Cadenas de consulta:
Una cadena de consulta es información que se anexa al final de la dirección URL de una página. Un
ejemplo típico de cadena de consulta podría tener el siguiente aspecto:
http://www.contoso.com/listwidgets.aspx?category=basic&price=100
En la ruta URL indicada, la cadena de consulta empieza por un signo de interrogación (?) e incluye dos
pares de atributo-valor, uno de ellos se denomina "category" y el otro, "price".
Las cadenas de consulta proporcionan una manera sencilla pero limitada de mantener la información de
estado. Por ejemplo, es una manera sencilla de pasar información de una página a otra, por ejemplo,
pasar un código de producto de una página a otra donde se procesará. Sin embargo, en algunos
exploradores y dispositivos de cliente la longitud de la dirección URL tiene una limitación de 2083
caracteres.
Para que los valores de las cadenas de consulta estén disponibles durante el procesamiento de la página,
debe enviar la página utilizando el método GET de HTTP. Es decir, no puede utilizar las cadenas de
consulta si la página se procesa como respuesta a un método POST de HTTP.
2.2. Administración de estado basada en servidor
Los lenguajes de programación Web del lado del servidor proporcionan una serie de medios para
mantener la información de estado en el servidor, en lugar de conservarla en el cliente. Con la administración de
estados basada en servidor, se puede reducir la cantidad de información que se envía al cliente para conservar el
estado, sin embargo, puede suponer un uso excesivo de los recursos del servidor. En los apartados siguientes se
describen tres características de la administración de estados basada en servidor:
a) Estado de aplicación:
Se permite guardar valores utilizando el estado de sesión de cada aplicación Web activa. El estado de
aplicación es un mecanismo de almacenamiento global al que se puede obtener acceso desde todas las
páginas de la aplicación Web. Por tanto, el estado de aplicación resulta útil para almacenar la
información que se debe mantener en los recorridos de ida y vuelta del servidor y entre las solicitudes
de las páginas.
El estado de aplicación se almacena en un diccionario de tipo clave-valor que se crea cada vez que se
envía una solicitud a una dirección URL específica. Se puede agregar información específica de la
aplicación a esta estructura para almacenarla entre las peticiones de página. Después de agregar la
información específica de la aplicación a estado de aplicación, el servidor se encarga de administrarla.
b) Estado de sesión:
Se permite guardar valores utilizando el estado de sesión de cada sesión de una aplicación Web activa. El
estado de sesión es similar a estado de aplicación, con la diferencia de que el ámbito es la actual sesión
del explorador. Si hay varios usuarios utilizando la aplicación, cada uno de ellos tendrá un estado de
sesión distinto. Asimismo, si un usuario sale de la aplicación y vuelve más tarde, el segundo usuario
tendrá un estado de sesión distinto al del primero.
El estado de sesión tiene la estructura de un diccionario de tipo clave-valor para almacenar información
específica de cada sesión que se debe conservar en recorridos de ida y vuelta del servidor, así como
entre solicitudes de páginas.
Se puede utilizar el estado de sesión para llevar a cabo las tareas siguientes:
‒ Identificar unívocamente las peticiones del explorador o del dispositivo de cliente y asignarlas a
una instancia de sesión individual en el servidor.
‒ Almacenar en el servidor datos específicos de la sesión para utilizarlos a través de múltiples
peticiones del explorador o dispositivo dentro de la misma sesión.
‒ Producir eventos de administración de sesión adecuados. Adicionalmente, puede escribir código
de aplicación para aprovechar estos eventos.
Después de agregar la información específica de la aplicación a estado de sesión, el servidor se encarga
de administrar dicho objeto. En función de las opciones especificadas, la información de la sesión se
puede almacenar en cookies, en un servidor que no forme parte del proceso, o en un equipo que ejecute
el Sistema Gestor de Bases de Datos.
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 4
c) Propiedades de perfiles:
Se permite almacenar datos específicos del usuario. Esta característica es similar al estado de sesión,
salvo que los datos del perfil no se pierden cuando caduca la sesión de un usuario. La característica
propiedades de perfiles utiliza un perfil, que se guarda en un formato persistente y que se asocia con un
usuario específico. El perfil permite administrar con facilidad la información sobre el usuario sin que sea
necesario crear y mantener una base de datos propia. Además, el perfil hace que la información del
usuario esté disponible mediante una API con establecimiento inflexible de tipos a la que puede obtener
acceso desde cualquier punto de la aplicación. Se pueden almacenar objetos de cualquier tipo en el
perfil. La característica de perfil proporciona un sistema de almacenamiento genérico que permite
definir y mantener casi cualquier tipo de datos mientras éstos sigan estando disponibles en un modo de
seguridad de tipos.
3. Manejo de cookies
Las cookies proporcionan un medio para almacenar información específica del usuario en las
aplicaciones Web. Por ejemplo, cuando un usuario visita un sitio, las cookies pueden emplearse para almacenar
las preferencias del usuario u otra información. Cuando el usuario visite el sitio Web de nuevo, la aplicación
podrá recuperar la información que almacenó previamente.
Una cookie es un pequeño fragmento de texto que acompaña a las solicitudes y a las páginas mientras
éstas se transmiten del servidor Web al explorador y viceversa. La cookie contiene información que la aplicación
Web puede leer cada vez que el usuario visita el sitio. Por ejemplo, si un usuario solicita una página de un sitio y
la aplicación no solo envía una página, sino también una cookie que contiene la fecha y la hora, cuando el
explorador del usuario obtenga la página, también obtendrá la cookie, que se almacenará en una carpeta en el
disco duro del usuario. Más adelante, si el usuario solicita de nuevo una página del mismo sitio, cuando
introduzca la dirección URL, el explorador buscará en el disco duro local una cookie asociada a dicha dirección. Si
la cookie existe, el explorador la enviará al sitio junto con la solicitud de la página. A continuación, la aplicación
podrá determinar la fecha y hora en que el usuario visitó el sitio por última vez. Podría utilizar dicha información
para mostrar un mensaje al usuario o comprobar una fecha de caducidad.
Las cookies están asociadas a un sitio Web, no a una página específica, por lo que el explorador y el
servidor intercambiarán información de cookies independientemente de la página que el usuario solicite en su
sitio. Todos los sitios que visita el usuario pueden enviar una cookie al explorador del usuario; éste las
almacenará independientemente.
Las cookies permiten a los sitios Web almacenar información sobre los visitantes. De forma más general,
las cookies son una manera de mantener la continuidad en una aplicación Web, es decir, de realizar la
administración de estados. Excepto durante los breves momentos en los que están realmente intercambiando
información, el explorador y el servidor Web están desconectados. Las solicitudes que realiza un usuario a un
servidor Web se tratan por separado unas de las otras. Sin embargo, muchas veces, es útil para el servidor Web
reconocer a los usuarios cuando solicitan una página. Por ejemplo, el servidor Web de un sitio de compras
efectúa el seguimiento de cada uno de los compradores para poder administrar los carros de la compra y la
información específica del usuario. Por consiguiente, una cookie actúa como una especie de tarjeta de llamada,
que presenta la identificación necesaria para que la aplicación sepa cómo continuar.
Las cookies se utilizan para muchos propósitos, todos ellos destinados a facilitar al sitio Web el
reconocimiento de los usuarios. Por ejemplo, un sitio que lleva a cabo un sondeo podría utilizar una cookie
simplemente como un valor booleano para indicar si el explorador del usuario ya ha participado en la votación, a
fin de evitar que el usuario vote dos veces. Un sitio que solicita a un usuario que inicie una sesión podría utilizar
una cookie para registrar dicho inicio de sesión a fin de que el usuario no tenga que seguir proporcionando sus
credenciales.
La mayoría de los exploradores admiten cookies de un tamaño máximo de 4096 bytes. Debido a este
límite, es recomendable utilizar las cookies para almacenar pequeñas cantidades de datos, o mejor aún, un
identificador como un id. de usuario. Este id. se puede utilizar para identificar al usuario y leer información
relativa a éste de una base de datos u otro almacén de datos.
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 5
Los exploradores también imponen limitaciones respecto al número de cookies que cada sitio puede
almacenar en el equipo del usuario. La mayoría de los exploradores sólo permiten 20 cookies por sitio; si se
intenta almacenar más, las cookies más antiguas se descartan. Algunos exploradores también definen un límite
absoluto, normalmente 300, en cuanto al número de cookies que aceptan desde todos los sitios en conjunto.
Una limitación de las cookies con la que podría encontrarse es que los usuarios pueden configurar sus
exploradores para rechazarlas.
También se puede establecer la fecha y hora de caducidad de una cookie. El explorador elimina las
cookies caducadas cuando un usuario visita el sitio que las escribió. La caducidad de una cookie debería
establecerse en función del tiempo que su aplicación considere que el valor de la misma seguirá siendo válido.
Para que una cookie no caduque nunca, se puede establecer la fecha de caducidad en 50 años a partir de ahora.
Si no se establece la caducidad de la cookie, ésta se crea pero no se almacena en el disco duro del
usuario. En su lugar, la cookie se mantiene como parte de la información de sesión del usuario. Cuando el usuario
cierra el explorador, la cookie se descarta. Una cookie no persistente de este tipo resulta útil para la información
que se debe almacenar durante períodos cortos de tiempo o que, por motivos de seguridad, no se debería
escribir en el disco del equipo cliente. Por ejemplo, las cookies no persistentes son útiles si el usuario está
trabajando en un equipo público en cuyo disco no desea que se escriba la cookie.
Se puede definir una cookie en el equipo de un usuario si envía un encabezado HTTP que contenga datos
con el siguiente formato:
Set-Cookie: NOMBRE=VALOR; [expires=FECHA;] [path=RUTA;] [domain=DOMINIO;] [secure]
De esta forma se crea una cookie con el nombre NOMBRE y con el valor VALOR. El resto de parámetros
son opcionales. El campo expires establece la fecha hasta la cual será válida la cookie. Si no se establece una fecha
de caducidad, la cookie será permanente a menos que la eliminemos manualmente. Los campos path y domain se
pueden utilizar de forma conjunta para especificar el o los URL para los que se utiliza la cookie. La palabra
reservada secure indica que la cookie no se enviará a través de una conexión HTTP.
Cuando un navegador se conecta a un URL, primero busca las cookies almacenadas localmente. Si
ninguna de ellas es relevante para el URL al que se ha conectado, se devuelven al servidor.
3.1. Configuración de cookies desde HTTP
Se pueden configurar cookies manualmente en PHP por medio de la función setcookie(). Su sintaxis es la
siguiente:
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string
$domain [, bool $secure = false [, bool $httponly = false ]]]]]] )
Los parámetros se corresponden exactamente a los del encabezado Set-Cookie mencionado
anteriormente, es decir:
name
El nombre de la cookie.
value
El valor de la cookie. Este valor se guarda en el computador del cliente; no almacene información
sensible. Asumiendo que el name es 'cookiename', este valor se obtiene con $_COOKIE['cookiename'].
expire
El tiempo en el que expira la cookie. Es una fecha Unix por tanto está en número de segundos a partir
de la presente época. En otras palabras, probablemente utilizará la función time() más el número de
segundos que quiere que dure la cookie. También se podría utilizar la función mktime().
time()+60*60*24*30 configurará la cookie para expirar en 30 días. Si se pone 0, o se omite, la cookie
expirará al final de la sesión (al cerrarse el navegador).
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 6
El parámetro expire recibe una fecha Unix, por oposición al formato de fecha Wdy, DD-Mon-YYYY
HH:MM:SS GMT, esto se debe a que PHP realiza esta conversión internamente.
path
La ruta dentro del servidor en la que la cookie estará disponible. Si se utiliza '/', la cookie estará
disponible en la totalidad del domain. Si se configura como '/prueba/', la cookie sólo estará
disponible dentro del directorio /prueba/ y todos sus sub-directorios en el domain, tales como
/prueba/bar/. El valor por defecto es el directorio actual en donde se está configurando la cookie.
domain
El dominio para el cual la cookie está disponible. Establecer el dominio a 'www.example.com' hará
que la cookie esté disponible en el subdominio www y subdominios superiores. Las cookies
disponibles en un dominio inferior, como 'example.com', estarán disponibles en dominios superiores,
como 'www.example.com'.
secure
Indica que la cookie sólo debiera transmitirse por una conexión segura HTTPS desde el cliente.
Cuando se configura como TRUE, la cookie sólo se creará si es que existe una conexión segura. Del
lado del servidor, depende del programador el enviar este tipo de cookies solamente a través de
conexiones seguras (por ejemplo, con $_SERVER["HTTPS"]).
httponly
Cuando es TRUE la cookie será accesible sólo a través del protocolo HTTP. Esto significa que la
cookie no será accesible por lenguajes de scripting, como JavaScript. Se ha indicado que esta
configuración ayuda efectivamente a reducir el robo de identidad a través de ataques XSS (aunque no
es soportada por todos los navegadores), pero esa afirmación no se comparte a menudo. Agregado en
PHP 5.2.0. puede ser TRUE o FALSE.
Si existe algún tipo de salida anterior a la llamada de esta función, setcookie() fallará y retornará FALSE.
Si se ejecuta satisfactoriamente, retornará TRUE. Esto no indica si es que el usuario ha aceptado la cookie o no.
Si se define una cookie como:
setcookie('micookie', 'valor');
Cuando el usuario visite la siguiente página del sitio, o vuelva a cargar la página actual, se podrá acceder
a la cookie a través de $_COOKIE['micookie'] o de $HTTP_COOKIE_VARS["micookie"] o, si se ha activado
register_globals directamente como $micookie.
Se puede eliminar una cookie si se llama a la función setcookie() de nuevo con el mismo nombre de
cookie y una fecha de caducidad pasada. También se puede definir manualmente una cookie con ayuda de la
función header(), que es usada para enviar encabezados HTTP sin formato, y la sintaxis de cookie que se mostró
anteriormente. Es preciso enviar los encabezados de cookie antes que ningún otro encabezado o no funcionarán,
esto es una limitación de las propias cookie más que una limitación del propio lenguaje PHP. La sintaxis de
función header() es la siguiente:
void header ( string $string [, bool $replace = true [, int $http_response_code ]] )
Los parámetros de esta función son los siguientes:
string
El encabezado en formato cadena. Existen dos casos especiales en el uso de header. El primero el
encabezado que empieza con la cadena "HTTP/" (las mayúsculas no son importantes), es utilizado
para averiguar el código de status HTTP a enviar. Por ejemplo, si se tiene Apache configurado para
usar un script en PHP para controlar las peticiones a ficheros no encontrados (usando la directiva
ErrorDocument), querrá asegurarse de que el script genera el código de status que corresponde.
<?php
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 7
header("HTTP/1.0 404 Not Found");
?>
Para el uso de FastCGI debe usarse la siguiente respuesta para un 404:
<?php
header("Status: 404 Not Found");
?>
El segundo caso especial es el encabezado "Location:" No solamente envía el encabezado al
navegador, sino que también devuelve el código de status (302) REDIRECT al navegador a no ser que
el código de status 201 o 3xx ya haya sido enviado.
<?php
header("Location: http://www.example.com/"); /* Redirección del navegador */
/* Asegurándonos de que el código interior no será ejecutado cuando se realiza la
redirección. */
exit;
?>
replace
El parámetro opcional replace indica cuando el encabezado debe reemplazar un encabezado previo
similar o añadir un segundo encabezado del mismo tipo. Por defecto lo reemplazará, pero si se pasa
FALSE como segundo argumento se puede forzar múltiples encabezados del mismo tipo. Por ejemplo:
<?php
header('WWW-Authenticate: Negotiate');
header('WWW-Authenticate: NTLM', false);
?>
http_response_code
Fuerza el código de respuesta HTTP a un valor específico. Observa que este parámetro solamente
tiene efecto si string no está vacío.
La función no devuelve ningún valor.
Hay que tener en cuenta que header() debe ser llamada antes de mostrar nada por pantalla, etiquetas
HTML, líneas en blanco desde un fichero o desde PHP. Es un error muy común leer código con funciones como
include() o require(), u otro tipo de funciones de acceso de ficheros que incluyen espacios o líneas en blanco que
se muestran antes de llamar a la función header(). Sucede el mismo problema cuando se utiliza un solo fichero
PHP/HTML. Por ejemplo:
<?php
/* Esto producirá un error. Fíjate en el html
que se muestra antes que la llamada a header() */
header('Location: http://www.example.com/');
?>
3.2. Ejemplo de uso de cookies
Ejemplo de uso de cookies en PHP para almacenar la hoja de estilos CSS que queremos utilizar para
definir el aspecto de la página:
<?php
// Veo si recibo datos del formulario
if(isset($_POST["estilo"])){
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 8
// Es que estoy recibiendo un estilo nuevo, lo tengo que meter en las cookies
$estilo = $_POST["estilo"];
// Meto el estilo en una cookie
setcookie("estilo", $estilo, time() + (60 * 60 * 24 * 90));
}
else {
// Si no he recibido el estilo que desea el usuario en la página,
// miro si hay una cookie creada
if (isset($_COOKIE["estilo"])){
// Es que tengo la cookie
$estilo = $_COOKIE["estilo"];
}
}
?>
<html>
<head>
<title>Cookies en PHP</title>
<?php
// Miro si he tengo un estilo definido, porque entonces tengo que cargar la
// correspondiente hoja de estilos
if (isset($estilo)){
echo '<link rel="STYLESHEET" type="text/css" href="' . $estilo . '.css">';
}
?>
</head>
<body>
Ejemplo de uso de cookies en PHP para almacenar la hoja de estilos CSS
que queremos utilizar para definir el aspecto de la página.
<form action="cookies-php.php" method="post">
Aquí puedes seleccionar el estilo que prefieres en la página:
<br>
<select name="estilo">
<option value="verde">Verde
<option value="rosa">Rosa
<option value="negro">Negro
</select>
<input type="submit" value="Actualizar el estilo">
</form>
</body>
</html>
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 9
4. Seguimiento de sesión de un cliente web
Los lenguajes del lado del servidor proporcionan la infraestructura de información del estado de una
solicitud a otra (carritos de la compra, desplazamiento de datos, etc.) que necesitan las aplicaciones Web, con
una funcionalidad integrada de estado de sesión que permite realizar las siguientes acciones:
Identificar y clasificar automáticamente solicitudes provenientes de un solo cliente explorador en una
sesión lógica de aplicación en el servidor.
Almacenar datos del ámbito de una sesión en el servidor para utilizarlos en diversas solicitudes de
explorador.
Provocar eventos adecuados de administración del tiempo de vida de la sesión que se pueden controlar
con código de aplicación.
Liberar automáticamente datos de las sesiones si el explorador no vuelve a visitar una aplicación dentro
del período de espera que se haya especificado.
El estado de sesión permite almacenar y recuperar los valores de un usuario cuando el usuario explora
diferentes páginas que conforman una aplicación Web. HTTP es un protocolo sin estado, lo que significa que el
servidor Web trata cada solicitud HTTP de una página como una solicitud independiente; el servidor no retiene
información alguna sobre los valores de las variables que se utilizan durante las solicitudes anteriores. El estado
de sesión identifica las solicitudes recibidas desde el mismo explorador durante un período limitado de tiempo
como una sesión y proporciona la capacidad de conservar los valores de las variables durante la duración de esa
sesión.
HTTP es un protocolo sin estado, es decir, que no indica automáticamente si una secuencia de solicitudes
proviene del mismo cliente ni si una sola instancia de explorador sigue viendo activamente una página o un sitio.
En consecuencia, la creación de aplicaciones Web que necesitan mantener información del estado de una
solicitud a otra puede resultar sumamente complicada sin la ayuda adicional de una infraestructura.
El estado de sesión, sin embargo, no se conserva entre los límites de las aplicaciones Web. Si se pasa de
una aplicación Web a otra durante una ejecución, la información de sesión no está disponible en la nueva
aplicación.
4.1. Funcionalidad de sesión básica
Las sesiones son una forma sencilla de almacenar datos para usuarios de manera individual usando un
ID de sesión único. Esto se puede usar para hacer persistente la información de estado entre peticiones de
páginas. Los ID de sesiones normalmente son enviados al navegador mediante cookies de sesión, y el ID se usa
para recuperar los datos de sesión existente. La ausencia de un ID o una cookie de sesión permite saber a PHP
para crear una nueva sesión y generar un nuevo ID de sesión.
Los pasos básicos de la utilización de sesiones son los siguientes:
1) Iniciar una sesión.
2) Registrar variables de sesión.
3) Utilizar variables de sesión.
4) Anular las variables registradas y eliminar la sesión.
Las sesiones siguen un flujo de trabajo sencillo. Cuando una sesión se inicia, PHP recuperará una sesión
existente usando el ID pasado (normalmente desde una cookie de sesión) o, si no se pasa una sesión, se creará
una sesión nueva. PHP rellenará la variable superglobal $_SESSION con cualesquiera datos de sesión de que se
inicie la sesión. Cuando PHP se cierra, automáticamente toma el contenido de la variable superglobal $_SESSION,
la serializa, y la envía para almacenarla usando el gestor de almacenamiento de sesiones.
Por omisión, PHP usa el gestor interno de almacenamiento files, el cual se establece mediante
session.save_handler. Éste guarda los datos de sesión en el servidor en la ubicación especificada por la directiva
de configuración session.save_path.
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 10
Las sesiones se puede iniciar manualmente usando la función session_start(), y si la directiva
session.auto_start se establece a 1, una sesión se iniciará automáticamente en el momento en que PHP envíe
cualquier salida al buffer de salida.
Las sesiones normalmente se cierran automáticamente cuando PHP termina de ejecutar un script, pero
se pueden cerrar manualmente usando la función session_write_close().
4.2. Uso de cookies con sesiones
Las cookies tienen algunos problemas asociados como por ejemplo que algunos navegadores no las
aceptan o que algunos usuarios pueden desactivarlas en sus navegadores. Esta es una de las razones por las que
las sesiones PHP utilizan un método cookie/URL dual. Al utilizar sesiones PHP, no se tendrán que definir las
cookies manualmente. Las funciones de sesión se encargan de ello.
Se puede utilizar la función session_get_cookie_params() para ver los contenidos de una cookie definida
por el control de sesión. Devuelve una matriz asociativa que contiene los elementos lifetime, path y domain.
También se puede utilizar:
session_set_cookie_params($lifetime $path, $domain [, $secure]);
Para definir los parámetros de la cookie de sesión.
4.3. Almacenamiento del identificador de sesión
De forma predeterminada, PHP utiliza cookies con sesiones. Si existe la posibilidad, se definirá una
cookie para almacenar el identificador de sesión.
El otro método que se puede utilizar consiste en añadir el identificador de sesión al URL. Es posible
indicar que se realice automáticamente si se configura la directiva session.use_trans_sid en el archivo php.ini, que
de forma predeterminada está desactivada.
También se puede incrustar manualmente el identificador de sesión en los enlaces para que se pase de
esta forma. El identificador de sesión se almacena en la constate SID. Para pasarlo manualmente, se debe añadir
al final de un enlace similar a un parámetro GET:
<A HREF="link.php?<?php echo strip_tags(SID); ?>">
En este caso se utiliza la función strip_tags() para evitar ataques de secuencias de comandos entre sitios
web.
Normalmente resulta más sencillo compilar con --enable-trans-sid, siempre que sea posible.
4.4. Inicio de sesión
Antes de poder utilizar la funcionalidad de las sesiones, es necesario iniciar una sesión. Existen dos
formas de hacerlo:
a) La primera y más sencilla consiste en iniciar una secuencia de comandos con una llamada a la función
session_start(), es decir:
session_start();
Esta función comprueba si ya hay un identificador de sesión actual, En caso contrario, creará uno para
tal fin. Si ya existe el identificador de sesión, básicamente carga las variables de sesión registradas
para que se puedan utilizar. Es aconsejable llamar a la función session_start() al inicio de todas las
secuencias de comandos que utilicen sesiones.
b) La segunda forma de iniciar una sesión consiste en configurar PHP para que lo haga automáticamente
cuando alguien visite el sitio web. Esto se puede hacer por medio de la opción session.auto_start
incluida en el archivo php.ini.
Este método presenta el inconveniente de que al activar auto_start no es posible utilizar objetos como
variables de sesión.
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 11
4.5. Registro de variables de sesión
El registro de variables de sesión ha cambiado últimamente en PHP. En PHP 4, las variables de sesión se
almacenaban en la matriz superglobal $_SESSION y también en la antigua $HTTP_SESSION_VARS. Se recomienda
que se utilice $_SESSION. Para poder crear una variable de sesión, basta con definir un elemento en esta matriz,
como se indica a continuación:
$_SESSION['miVariable'] = 5;
Se realizará el seguimiento de la variable que se acaba de crear hasta que finalice la sesión o hasta que la
anule manualmente.
4.6. Uso de variables de sesión
Para poder introducir una variable de sesión en ámbito y utilizarla, primero se debe iniciar una sesión
por medio de la función session_start(). Tras ello se podrá acceder a la variable a través de la matriz superglobal
$_SESSION, como por ejemplo $_SESSION['miVariable'].
Si se utiliza un objeto como variable de sesión, se debe incluir la definición de clase antes de invocar a la
función session_start() para volver a cargar las variables de sesión. De esta forma PHP sabe cómo reconstruir el
objeto de sesión.
Si se ha activado register_globlas, se podrá acceder a las variables de sesión utilizando sus nombres
cortos, como por ejemplo $miVariable, aunque no es una práctica recomendable.
Por otra parte, se tendrá que prestar especial atención cuando se compruebe si se han configurado las
variables de sesión, por ejemplo a través de isset() o empty(). Se debe recordar que las variables de sesión las
puede configurar el usuario a través de GET o POST. Se puede comprobar una variable para ver si se trata de una
variable de sesión registrada por medio de $_SESSION. Por ejemplo, se podría tener:
if (isset($_SESSION['miVariable'])) ...
4.7. Anulación del registro de variables y eliminar la sesión
Cuando se haya terminado con una variable de sesión, se puede anular su registro. Para ello, se puede
hacer directamente si se anula el registro del correspondiente elemento de la matriz $_SESSION, como se indica a
continuación:
unset($_SESSION['miVariable']);
Se ha de tener en cuenta que el uso de session_unregister() y session_unset() ya no es necesario ni
recomendable. Estas funciones se han quedado obsoletas.
No se debe intentar anular la matriz $_SESSION completamente, ya que si se hace se podrían deshabilitar
las sesiones. Para anular el registro de todas las variables se debe utilizar:
$_SESSION = array();
Cuando se haya terminado con la sesión, primero se debería anular el registro de todas las variables y,
tras ello, llamar a la función session_destroy() para borrar el identificador de sesión.
4.8. Ejemplo de uso de variables de sesión
Ejemplo de código para definir una variable de sesión:
<?php
session_start();
?>
<html>
<head>
<title>Generar variable de sesión</title>
</head>
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 12
<body>
<?php
$_SESSION["miVariableSesion "] = "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 cualquier 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.
<?php
session_start();
?>
<html>
<head>
<title>Leo variable de sesión</title>
</head>
<body>
Muestro esa variable:
<?php
echo $_SESSION["miVariableSesion"];
?>
</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.
Un ejemplo clásico de utilización de una sesión es un contador. Este contador deberá aumentar de una
unidad cada vez que recargamos la página o abramos el enlace:
<?php
session_start();
if (!isset($_SESSION["cuenta_paginas"])){
$_SESSION["cuenta_paginas"] = 1;
}
else{
$_SESSION["cuenta_paginas"]++;
}
?>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Contar páginas vistas por un usuario en toda su sesión</title>
</head>
<body>
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 13
<?php
echo "Desde que entraste has visto " . $_SESSION["cuenta_paginas"] . " páginas";
?>
<br>
<br>
<a href="otracuenta.php">Ver otra vez la página</a>
</body>
</html>
5. Seguridad en aplicaciones Web
La seguridad combina varias disciplinas y determina a menudo si una aplicación Web tiene éxito. Una
aplicación Web segura identifica de forma precisa a los usuarios por medio de la autenticación, ayuda a
garantizar que esos usuarios sólo tienen acceso al contenido que necesitan mediante una autorización,
contribuye a proteger los datos confidenciales por medio de la comunicación y el almacenamiento cifrados, y
sigue los procedimientos de seguridad recomendados en la escritura de código con el fin de evitar la
creación de riesgos para la seguridad en la propia lógica de la aplicación.
Si a una aplicación Web tienen acceso usuarios desconocidos, existen muchas probabilidades de que
algún usuario malintencionado intente también obtener acceso. Normalmente, los servidores de Internet
accesibles al público se sondean a diario para descartar vulnerabilidades. Por consiguiente, se recomienda que se
tomen precauciones y adopten medidas de seguridad en todas sus aplicaciones Web.
5.1. Implementar tecnología de seguridad
Implementar tecnología de seguridad es sólo parte de la solución. Otra parte consiste en la vigilancia.
Aunque el sistema cuente con numerosos elementos de seguridad, es preciso vigilarlo de cerca de los modos
siguientes:
a) Supervisando los registros de eventos del sistema. Observando si se producen intentos repetidos de
iniciar sesión en su sistema o si el servidor Web recibe un número excesivo de solicitudes.
b) Manteniendo continuamente actualizado el servidor de la aplicación con las últimas revisiones de
seguridad del Sistema Operativo y de los Servidores Web, así como cualquier revisión del Sistema
Gestor de Bases de Datos o de otros orígenes de datos que pueda utilizar su aplicación.
5.2. Modelo de amenazas
Una fase importante en el proceso de programación de aplicaciones más seguras consiste en ser capaz
de anticipar las amenazas que se puede sufrir. Por ejemplo, Microsoft ha elaborado el siguiente sistema de
clasificación de las amenazas en distintas categorías:
a. Suplantación:
Suplantar es utilizar los datos de identificación de otro usuario o proceso de forma no autorizada. En su
versión más simple, la suplantación consistiría en especificar las credenciales de un usuario diferente.
Un usuario malintencionado podría también cambiar el contenido de una cookie para fingir que es otra
persona o que la cookie proviene de un servidor diferente.
En general, es posible contribuir a evitar la suplantación mediante una autenticación estricta. Siempre
que alguien solicita acceso a información privada, es preciso asegurarse de que es quien dice ser.
También se puede contribuir a la defensa contra la suplantación manteniendo la información de
credenciales a salvo. Por ejemplo, no se debe guardar nunca una contraseña ni otro tipo de datos
confidenciales o privados en una cookie, donde un usuario malintencionado podría encontrarlos y
modificarlos fácilmente.
b. Manipulación:
Manipular significa cambiar o eliminar un recurso sin autorización. El ejemplo típico consiste en
desfigurar una página Web, para lo cual, el usuario malintencionado logra acceso al sitio y cambia
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 14
algunos archivos. Un modo indirecto de manipulación son los ataques mediante secuencias de
comandos. en los que el usuario malintencionado consigue que se ejecute código (secuencia de
comandos) enmascarándolo como la entrada de datos de un usuario en un formulario o como un
vínculo.
Una defensa fundamental contra la manipulación consiste en usar la seguridad del Sistema Operativo
para bloquear los archivos, directorios y otros recursos de mismo. La aplicación también debería
ejecutarse con privilegios mínimos. Para ayudar a evitar los ataques mediante secuencias de comandos,
no se debe confiar de la información que proceda de un usuario, ni de una base de datos. Siempre que se
obtenga información de una fuente que no sea de confianza, hay que procesarla y asegúrese de que no
contiene código ejecutable.
c. Repudio:
Una amenaza de repudio implica llevar a cabo una transacción de manera que no haya pruebas
fehacientes de los actores principales de la transacción. En una aplicación Web, esto puede significar que
se está suplantando a un usuario inocente usando sus credenciales. Contribuir a la protección contra el
repudio es posible, de nuevo, aplicando una autenticación estricta. Además, se deben usar las funciones
de inicio de sesión del Sistema Operativo para mantener un registro de auditoría de cualquier actividad
en el servidor.
d. Revelación de información:
Revelación de información significa simplemente robar o desvelar información que se supone que es
confidencial. Un ejemplo clásico es robar contraseñas, pero puede implicar el acceso a cualquier archivo
o recurso del servidor.
La mejor protección contra la revelación de información es no tener información que revelar. Por
ejemplo, si se evita el almacenamiento de contraseñas, ningún usuario malintencionado podrá robarlas.
Una alternativa al almacenamiento de las contraseñas consiste en guardar sólo un valor hash de éstas.
De este modo, cuando un usuario presenta sus credenciales, se puede extraer el valor hash de su
contraseña y compararlo con el almacenado.
Si, aún así, se almacena información confidencial, se debe utilizar la seguridad del propio sistema para
ayudar a protegerla. Como en todos los casos anteriores, se debería utilizar la autenticación para
contribuir a garantizar que sólo los usuarios autorizados pueden tener acceso a la información
restringida. Si se tiene que exponer información confidencial, es recomendable que se cifre cuando se
almacene y que se utilice SSL (Secure Sockets Layer) para cifrar la información cuando se envíe al
explorador o se reciba de éste.
e. Denegación de servicio:
Un ataque de denegación de servicio consiste en hacer deliberadamente que una aplicación esté menos
disponible de lo que debería. Un ejemplo típico es sobrecargar una aplicación Web de forma que no
pueda servir a los usuarios normales. Como alternativa, los usuarios malintencionados pueden intentar
simplemente bloquear el servidor.
Los Servidores Web permiten limitar las aplicaciones de forma que sólo sirvan un número determinado
de solicitudes, lo que podría resultar útil para negar el acceso a usuarios o direcciones IP que se sabe que
son malintencionados. Para mantener las aplicaciones en línea, es esencial ejecutar código sólido. Se
debe probar exhaustivamente la aplicación y responder apropiadamente a los errores siempre que sea
posible.
f. Concesión de privilegio:
Un ataque de concesión de privilegio consiste en usar medios malintencionados para obtener más
permisos de los asignados normalmente. Por ejemplo, en un ataque de concesión de privilegio que tenga
éxito, un usuario malintencionado consigue obtener privilegios administrativos para el Servidor Web, lo
que le proporciona acceso a todos los datos del servidor, así como el control de las funciones de éste.
5.3. Recomendaciones de seguridad para aplicaciones Web
Incluso los métodos de seguridad de aplicaciones más elaborados pueden verse comprometidos si un
usuario malintencionado logra obtener acceso a los equipos usando medios simples. Entre las recomendaciones
generales de seguridad para aplicaciones Web se encuentran:
Desarrollo Web en Entorno Servidor. UT6.- Desarrollo de aplicaciones Web utilizando código embebido.
© IES Virrey Morcillo. Departamento de Informática y Comunicaciones. 15
Realizar copias de seguridad de los datos con asiduidad y guardarlos en un lugar seguro.
Mantener el servidor Web en un lugar físico seguro, de forma que los usuarios no autorizados no puedan
tener acceso a él, apagarlo, llevárselo, etc.
Utilizar el sistema de archivos apropiado, por ejemplo NTFS, Ext4, etc.
Proteger el servidor Web y todos los equipos de la misma red con contraseñas seguras.
Seguir los procedimientos recomendados para asegurar los servicios Web.
Cerrar los puertos que no se utilicen y desactivar los servicios que no se estén en uso.
Ejecutar un programa antivirus que supervise el tráfico.
Usar un firewall.
Mantenerse informado sobre las actualizaciones de seguridad más recientes del Sistema Operativo y
otros fabricantes, e instalarlas.
Usar las funciones de registro de eventos del sistema y examinar los registros con frecuencia para
detectar actividades sospechosas. Esto incluye los intentos repetidos de iniciar sesión en el sistema y un
exceso de solicitudes en el servidor Web.
Ejecutar las aplicaciones con el mínimo de privilegios.
Conocer a los usuarios.
Protegerse contra entradas malintencionadas.
Tener acceso seguro a bases de datos.
Crear mensajes de error seguros.
Mantener segura la información confidencial.
Usar cookies de forma segura.
Protegerse contra amenazas de denegación de servicio.