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.



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.



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.



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.



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



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



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"])){



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



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.



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.



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>



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



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



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:



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.

ut6.- desarrollo de aplicaciones web utilizando código embebido

Documents