Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - Alex

#541
Back-end / Re:Sesiones
Enero 30, 2013, 10:15:52 PM
Javascript también puede manejar cookies

En el ejemplo del código de la pagina1.php anterior teníamos un trozo de código en Javascript que reproducimos otra vez:

Código: text
    ...
    <code id="mi-cookie"></code>
    </p>
    <script>
        var arrayCookies = document.cookie.split(";");
        for (var i=0; i<arrayCookies.length; i++){
            var unaCookie = arrayCookies[i].split("=");
            var nombre = quitaEspacios(unaCookie[0]);
            if (nombre == "PHPSESSID") {
               var contenido = escapaHtml(arrayCookies[i]);
               setInnerText(document.getElementById("mi-cookie"), contenido);
               break;
            }
        }
    </script> 
    ... 

   

Podemos ver que usamos document.cookie que nos devuelve un string con todas las cookies del dominio de esa página almacenadas en el navegador. La colección de cookies de un dominio son parejas nombre=valor separadas por punto y coma (;). Así haciendo un split(";") sobre ese string obtenemos un array de parejas nombre=valor, que luego separamos otra vez para obtener el nombre y buscar el que nos interesa, PHPSESSSID para mostrar el identificador en la página de ejemplo. Así veremos que realmente el identificador se almacenó en una cookie de nuestro navegador.

Las tres funciones señaladas quitaEspacios(), escapaHtml() y setInnerText() las he creado para anular espacios antes y después de una cadena, escapar caracteres reservados e insertar texto dentro de un elemento.

No quiero extenderme ahora mucho sobre el manejo de cookies con JavaScript, pues mi interés está ahora en las que se gestionan desde un servidor para el uso de sesiones basadas en cookies. La única razón de exponerlo es para corroborar que esa cookie de sesión está realmente alojada en nuestro navegador.
#542
Back-end / Re:Sesiones
Enero 30, 2013, 10:15:03 PM
Ejemplo de una sesión PHP basada en cookies

Antes de meternos en un ejemplo para ver cómo trabajan una sesión, no debemos olvidar que las sesiones sirven para mantener información entre accesos a distintas páginas. Esa información, que se almacena en el servidor, estará disponible a través de las variables de sesión pero no de forma permanente. Digo esto porque yo mismo pensaba que las sesiones son para eso del "registro y acceso de usuarios", conocido como proceso de autenticación por el cual un sistema verifica que un usuario es quién dice ser, para entonces permitir o denegar el acceso. Las sesiones sirven para esto, pero su principal objetivo es mantener la información entre accesos.

Supongamos que tenemos un catálogo de productos en un sitio. Se compone de un conjunto grande de páginas, cada página para una línea de productos, que a su vez se desglosa en subpáginas con sublíneas. Nos podría interesar ofrecer al usuario un sistema que le ayude a encontrar lo que necesita. Por ejemplo, si en la primera página elige la línea "electrodomésticos" y en la siguiente "frigoríficos", podríamos ofrecerle todos los productos relacionados en esa sublínea y además un conjunto de enlaces relacionados. Algo así como "quizás le interese también congeladores, hornos, lavadoras, ...". Pero si elige "televisores" podríamos sugerirle "cámaras de video, aparatos música, ...".

Ese es un ejemplo de personalización de páginas. Para que un sistema así funcione es necesario almacenar la información previa del camino que va siguiendo el usuario. Para esto pueden servir las sesiones, pero no es estrictamente necesario que el usuario esté registrado en alguna base de datos.

Usaremos un ejemplo más simple. Sea una primera página (pagina1.php) que abre una sesión para navegar por un conjunto siguiente de páginas (pagina2.php y otras). Supongamos que deseamos abrir la sesión con objeto de personalizar el conjunto de páginas segunda y siguientes. Para simplificar el ejemplo hacemos que la personalización sea sólo para el color del fondo de las páginas. Podemos ya entrar en la pagina1.php que tiene el siguiente código (obviamos con puntos suspensivos el HTML que no es de interés):

<?php
//Lo primero es iniciar la sesión antes de enviar nada, pero
//estableciendo el modo con cookies por si estuviera desactivado

ini_set("session.use_cookies", 1);
ini_set("session.use_only_cookies", 1);
session_start();

//Por defecto asignamos un color para el fondo. Si esta es la
//primera vez que abrimos la sesión, le pone el color amarillo.

if (!isset($_SESSION['color-fondo'])) {
    //Esto evita la fijación de sesión
    session_regenerate_id(true);
    //Ahora asignamos el parámetro de sesión por primera vez
    $_SESSION['color-fondo']  = 'yellow';
}

//Ahora se construye la página
?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login">
<html xmlns="You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login" lang="es" xml:lang="es">
    ...
    <h3>Página 1</h3>
    <p>Esta página ... el color del fondo, que ahora tiene el valor
    <code>
<?php echo htmlspecialchars($_SESSION['color-fondo']); ?></code>,
    color de fondo que se pondrá en las páginas 2 y 3.
    </p>
    <p>Podemos ver la cookie que almacenó PHP en el navegador:<br />
    <code id="mi-cookie"></code>
    </p>
    <script>
        var arrayCookies = document.cookie.split(";");
        for (var i=0; i<arrayCookies.length; i++){
            var unaCookie = arrayCookies.split("=");
            var nombre = quitaEspacios(unaCookie[0]);
            if (nombre == "PHPSESSID") {
               var contenido = escapaHtml(arrayCookies);
               setInnerText(document.getElementById("mi-cookie"), contenido);
               break;
            }
        }
    </script>   
    ...

   

En color marrón está el código PHP y en azul el HTML, incluso el de JavaScript. Los comentarios están en verde. En primer lugar vemos que para iniciar una página con sesión hemos de reconfigurar las opciones de inicio session.use_cookies y session.use_only_cookies para que la sesión sólo use cookies. Es una medida extra de seguridad por si la configuración se hubiera modificado, pues en otro caso se usaría URL para enviar la sesión y esta es una vía que no se aconseja como vimos más arriba. Luego hacemos session_start() antes que se envíe cualquier cosa al navegador. Con esto se inicia la sesión pero no la consideramos activa hasta que guardemos algún parámetro de la sesión como $_SESSION['color-fondo'] = 'yellow'. Para saber si ya la sesión fue iniciada antes miramos con isset() si nuestro parámetro color-fondo está ya registrado. Si no lo estuviera es que es el primer inicio de la sesión y lo registramos con un color de fondo amarillo, por ejemplo.

Entonces el servidor creará un identificador único para esa sesión. Este identificador se mantiene mientras mantengamos abierto el navegador, por lo que cada vez que accedamos a las páginas del ejemplo veremos que se mantiene el color de fondo seleccionado. Este ejemplo se ejecuta en mi servidor Apache + PHP montado en local sólo para aprender. Puede ver más detalles de la instalación en Apache 2.2.15 y PHP 5.2.13 en Windows. Buscando el php.ini encontramos una línea con You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login_path="C:\WINDOWS\Temp", que es el lugar donde se configura para guardar las sesiones. Esta es una carpeta que usa el servidor para almacenar la sesión, cuyo contenido después de ejecutar la primera página es el siguiente:



Crea un archivo con el nombre iniciado con sess_q75n4oq6turdv67uohqkbl7lv5. La ristra después de sess_ es el identificador único de esa sesión. Si abrimos el archivo con un bloc de notas podemos ver que contiene color-fondo|s:6:"yellow";. Se trata del parámetro que le pasamos con el color de fondo. Realmente no tenemos que preocuparnos por esto pues nos basta con crear nuevos parámetros para una sesión simplemente haciendo $_SESSION["parametro"] = $algun_valor. Para recuperar un parámetro bastaría hacer $variable = $_SESSION["parametro"]. (La barra vertical separa el nombre del valor del parámetro y que la s:6: significa que el valor es un string con 6 caracteres).

A continuación el servidor crea el documento pagina1.php que será enviado al navegador del usuario. Lo que se envía incluyendo la cabecera HTTP será algo como esto:

Código: text
HTTP/1.1 200 OK
Date: Sun, 12 Sep 2010 22:46:25 GMT
Server: Apache/2.2.15 (Win32) PHP/5.2.13
X-Powered-By: PHP/5.2.13
Set-Cookie: PHPSESSID=q75n4oq6turdv67uohqkbl7lv5; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 2031
Content-Type: text/html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="es" xml:lang="es">
<head>
    <title>Página 1</title>
    ... continúa el resto de la página ...


Esto lo he obtenido mediante un script PHP que hace algo parecido al Telnet en Windows. Puede ver más detalles en telnet con php. En todo caso lo que nos interesa apreciar es que el servidor envia una orden para que el navegador albergue una cookie. Ésta contiene el identificador de la sesión, el mismo que almacena en la carpeta de sesiones C:/Windows/Temp como vimos antes. El nombre dado a la cookie siempre es PHPSESSID. Este nombre se configura en el php.ini inicialmente por defecto (aunque puede modificarse):
Código: text

; Name of the session (used as cookie name).
; http://php.net/session.name
session.name = PHPSESSID   

   

Un detalle interesante es la fecha de expiración de la cookie. Se observa una fecha anterior, el 19/11/1981, con lo que la cookie que se almacena en el navegador tiene una duración de vida mientras el navegador esté abierto. Por lo tanto sólo va a existir en memoria y no será almacenada en el disco duro. En ese caso y con Windows se grabarían en las carpetas de documentos y configuración, en algún lugar de la carpeta del usuario. Pero creo que no viene al caso saber donde se almacenan, pues todos los navegadores nos dan la posibilidad de consultarlas y, en algún caso, hasta modificarlas.

Podemos ver las cookies en Internet Explorer 8 mediante herramientas de desarrollo, luego en caché y en ver información de cookies. Este navegador construye una página para mostrar todas las cookies almacenadas, por lo que podemos buscar al final del documento, apareciendo algo como esta imagen, donde el identificador es igual que el primero de la lista de la imagen de más arriba:



Es importante ver que Internet Explorer no muestra el dominio del que procede cuando estamos trabajando con localhost, pero que debe ser algún error puesto que para el resto de cookies si se ve el dominio. De todas formas aprovechamos para decir que las cookies de un dominio sólo pueden ser gestionadas por ese dominio, por lo que es un dato de suma importancia que se almacena con la cookie. Observe el tiempo de expiración at the end of the session, al finalizar la sesión. En los siguientes navegadores veremos que se aporta más información.

En Opera 10.61 podemos verlas en herramientas, avanzados, huellas(cookies) con algo como esto. Este navegador es el que me parece más completo al mostrar las cookies (huellas como le llama), pues ofrece además la posibilidad de editarlas. También se puede acceder con el botón derecho del ratón con la opción editar opciones del sitio, huellas, mostrando todas las cookies del dominio de esa página. Se corresponde con el segundo identificador de la lista mencionada.



En Firefox 3.6.8 podemos verlas en opciones, privacidad, mostrar cookies con algo como esto, por supuesto con otro identificador de sesión. También podemos verlas con el botón derecho del ratón en la página, con la opción ver información de la página y luego en seguridad, obteniéndose todas las cookies para el dominio de esa página. El identificador es el mismo que el tercero de la lista del /Temp en el servidor:



En Safari 4.0.5 están las cookies en el botón de ajustes generales, en la opción de preferencias, seguridad. El identificador es el mismo que el último de la lista en el /Temp del servidor:



En cualquier caso la cookie con el identificador de la sesión se almacena en el navegador del usuario. A partir de aquí y siempre dentro de la duración de la sesión, el navegador acompañará esta cookie con las solicitudes de páginas que se hagan a ese mismo servidor. Éste comprueba que el identificador es igual que el que tiene almacenado en la carpeta de sesiones del servidor (en C:/Windows/Temp para mi servidor local), en cuyo caso pone a disposición de uso los parámetros allí almacenados (el color de fondo para nuestro ejemplo).

La importancia de guardar sólo un identificador en el navegador del usuario radica en que es un dato sin valor en sí mismo. Veámos, ¿porqué no guardamos también los parámetros como el color de nuestro ejemplo en la cookie?. Existe la función setcookie() en PHP que permite enviar cookies desde el servidor al navegador. Mientras que con la variable superglobal $_COOKIE podemos verla en el servidor. Podemos argumentar que así no estamos almacenando nada en el servidor. ¿Pero si en lugar de ser un simple color para el fondo de las páginas fuera un dato personal que consideramos privado?. Dónde es más seguro tenerlo, ¿en el servidor o en el navegador?. Por ahora respondemos que en el servidor, siguiendo el criterio general de PHP que es almacenar el identificador en el navegador y el resto de la información en el servidor. Espero que a medida que desarrolle estos temas pueda dar más luz sobre este asunto.
#543
Back-end / Re:Sesiones
Enero 30, 2013, 10:11:06 PM
El proceso de una sesión PHP

Tal como señala el manual de PHP sobre You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, el concepto es preservar cierta información a través de accesos subsiguientes de los usuarios. El proceso en PHP es el siguiente:

    Un usuario entra por primera vez en una página del sitio que usa sesiones para, a partir de esa página, navegar a otras.
    PHP crea un identificador único para esa sesión (designado para abreviar a veces como ID). Digamos de forma sencilla que es una cadena de números y letras creada por PHP que identifica de forma única un usuario en un momento del tiempo. Esta cadena se genera de forma aleatoria y se almacena en el servidor, estando disponible en el navegador del usuario de dos formas posibles:
        El servidor envía una cookie al navegador del usuario con el identificador. Podemos llamarlas sesiones basadas en cookies.
        El servidor propaga el identificador a través de la URL. En este caso podemos denominarlas sesiones basadas en URL.
    Después de recibir la primera respuesta desde el servidor acompañada del identificador, el navegador hace las siguientes peticiones de otras páginas acompañando el identificador, tanto como cookie o por la URL. Así el servidor identifica al navegador.

Código: text
Aparte de usar cookies o enviar por la URL el identificador de sesión, podría haber otra forma usando un formulario con un campo de texto oculto. En el tema V sobre propagar sesiones veremos ejemplos de las distintas formas para propagar el identificador de sesión.


Según se desprende del manual PHP, las sesiones basadas en cookies son más seguras que las basadas en URL. Por defecto en el archivo de configuración php.ini (versión 5.2.13) encontramos los siguientes valores para configuraciones de sesiones que pueden ser modificadas en tiempo de ejecución:

La opción You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, que especifica si PHP usará cookies para propagar las sesiones. Por defecto se establece en 1 (true), tal como se ve en el php.ini:

Código: text
; Whether to use cookies.
; http://php.net/session.use-cookies
session.use_cookies = 1


La opción You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, que especifica si PHP sólo usará cookies para almacenar el identificador de sesión en el navegador del cliente, no permitiendo la otra opción de propagarlo por la URL. El valor predeterminado es 1 (true), recomendando usar cookies para evitar la suplantación de sesiones (hijacking), al menos en parte. Esto es lo que aparece en el php.ini:

Código: text
; This option forces PHP to fetch and use a cookie for storing and maintaining
; the session id. We encourage this operation as it's very helpful in combatting
; session hijacking when not specifying and managing your own session id. It is
; not the end all be all of session hijacking defense, but it's a good start.
; http://php.net/session.use-only-cookies
session.use_only_cookies = 1


La opción You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, que especifica que el identificador sea comunicado a través de URL entre el navegador y el usuario de forma transparente, es decir sin necesidad de incorporar el identificador en cada petición o respuesta. Por defecto es 0 (false). SID es una constante de PHP que contiene el nombre de la sesión y el identificador en la forma "name=ID" o una cadena vacía si se está usando la opción de sesiones basadas en cookies. Para usar sesiones no basadas en cookies sino en URL debemos primero poner la opción session.use_cookies = 0 y luego esta opción a 1. Sin embargo debe tenerse en cuenta el riesgo asumido, tal como se expone en el php.ini:

Código: text
; trans sid support is disabled by default.
; Use of trans sid may risk your users security.
; Use this option with caution.
; - User may send URL contains active session ID
;   to other person via. email/irc/etc.
; - URL that contains active session ID may be stored
;   in publically accessible computer.
; - User may access your site with the same session ID
;   always using URL stored in browser's history or bookmarks.
; http://php.net/session.use-trans-sid
session.use_trans_sid = 0


Código: text
Algunas configuraciones pueden modificarse en tiempo de ejecución con la función ini_set(a, b), donde "a" será el string de la variable de configuración y "b" será el nuevo valor a poner. Por ejemplo, para habilitar sesiones basadas en URL haríamos:

ini_set("session.use_cookies", 0);
ini_set("session.use_trans_sid", 1);
session_start();

Traducción del comentario de esta opción:
El uso de trans sid puede poner en riesgo la seguridad de los usuarios. Use esta opción con precaución.

    Un usuario podría enviar una URL conteniendo un identificador de una sesión activa de otro usuario a través de un email, canales IRC, etc.
    Una URL con una sesión activa podría ser almacenada en ordenadores públicamente accesibles.
    Un usuario podría acceder con el mismo identificador de otro usuario utilizando una URL almacenada en el historial del navegador.

Si PHP recomienda usar sesiones basadas en cookies tendremos que hacerle caso, pues ahora mismo no se mucho más del tema. Pero hay que tener en cuenta que en este caso el navegador tiene que aceptar las cookies, pues el usuario puede tenerlas desactivadas. En cuanto a esto, el estándar You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login sobre el mecanismo de estado de sesiones basadas en cookies, en su punto 2 expone literalmente:

"Neither clients nor servers are required to support cookies. A server MAY refuse to provide content to a client that does not return the cookies it sends.": Ni navegador ni servidor deben estar obligados a soportar cookies. Un servidor podría rehusar servir contenido a un navegador que no le devuelve una cookie que previamente le fue enviada.

Por lo tanto, y para empezar, suponemos que el servidor manejará sesiones basadas en cookies que deberán ser aceptadas por el navegador. En el tema V sobre propagar sesiones veremos con ejemplos otras formas de propagar las sesiones para los casos en que las cookies no estuvieran activadas en el navegador.
#544
Back-end / Re:Sesiones
Enero 30, 2013, 10:07:46 PM
Sesiones y cookies

El término inglés cookie se traduce literalmente por galleta. Fueron introducidas por Lou Montulli en las primeras versiones del navegador Netscape. La razón de su existencia se debe a que el protocolo HTTP no está preparado para el uso de estados. Un estado en informática se define como una configuración de un sistema en un momento dado. Esa configuración viene a ser información que puede almacenarse en algún lugar para uso futuro. Así cuando se cierra una página web no queda ningún rastro de ese proceso. En definitiva las solicitudes HTTP realizadas al servidor son totalmente independientes.

Pero a veces es necesario almacenar ese estado. Por ejemplo, si en nuestro sitio queremos controlar el acceso de usuarios a ciertas páginas, hemos de tener en el servidor una lista de usuarios registrados. Pero en el navegador debe guardarse también la información de registro, pues de otra forma el usuario tiene que identificarse cada vez que pase de una página a otra.

Una cookie es un trozo de texto que un servidor web almacena en el disco duro del ordenador del usuario para recuperarla cuando la necesite. El contenido son parejas de nombre y valor que pueden usarse para almacenar el estado del sistema. Es importante señalar que sólo puede almacenarse texto y con ciertas limitaciones. Por si mismas las cookies no hacen nada, es decir, no son programas ni ninguna otra cosa que puede ejecutar algo no deseado.

Código: text
En la medida de lo posible hay que buscar los términos en español, pero no podemos traducir cookie directamente por galleta en este contexto. Se puede traducir por su definición como registro de identificación o similar, pero quizás es más apropiado traducirlo como huella tal como hace el navegador Opera. Realmente son huellas que el servidor deja en el navegador para poder identificarlo. De todas formas el término en inglés está tan difundido que quizás es mejor usarlo sin traducir.


Como mucha documentación está en inglés, es conveniente conocer estas definiciones:

State (estado):
    En sistemas que procesan la información, un estado es un conjunto de propiedades transmitidas por un objeto a un observador a través de algún canal. Aplicado a HTTP, las propiedades serán transmitidas por el navegador al servidor, de tal forma que éste determina que información servir en base a las propiedades de ese estado.
Stateless (sin estado), stateful (con estado)
    Son adjetivos que se forman con state less y state full. Significa que un sistema de información trabaja sin o con conocimiento del estado del mismo, respectivamente. HTTP es un sistema stateless (sin manejo de estados), pero con el uso de cookies se convierte en un sistema stateful (con manejo de estados).
Session (sesión)
    Una sesión (de comunicación) es un intercambio no permanente de información entre sistemas. Haciendo HTTP con estados mediante el uso de las cookies, una sesión es el proceso de comunicación entre servidor y navegador para intercambiar la información de estado. Es clásico el ejemplo de una tienda web (el "shopping cart"), donde el usuario selecciona productos que va agregando a su "carrito" a medida que navega entre las páginas del sitio. Las sesiones se caracterizan por:

        Cada sesión tiene un inicio y un final.
        Las sesiones no son permanentes.
        Una sesión puede ser finalizada por el servidor o por el navegador.
        Una sesión siempre está implícita cuando se intercambia información de estado.

    El concepto de sesión es independiente de las cookies, por lo que puede haber sesiones que se manejen sin ellas, tal como veremos más adelante. Sin embargo una cookie está normalmente relacionada con una sesión.

Los documentos que sirven de estándar para implantar HTTP con estados son los siguientes:

    RFC2109 del año 1997 donde se describe inicialmente un protocolo para manejos de estado en HTTP (HTTP State Management Mechanism)
    RFC2965 del año 2000, una revisión y mejora del anterior.

Literalmente el objetivo de estos documentos es especificar una forma para crear un sesión con estado en solicitudes y respuestas con el protocolo HTTP.
#545
Back-end / Re:Sesiones
Enero 30, 2013, 10:06:24 PM
Introducción

Cuando decidimos aprender por nuestra cuenta todo lo que podamos sobre el desarrollo web, en algún momento hemos de enfrentarnos con las sesiones. Si el aprendizaje no sigue alguna secuencia temática ordenada, nos encontraremos con problemas que nos obligan a retroceder en ese aprendizaje para retomar cuestiones que habíamos aparcado provisionalmente. Me explico. Quise hacer un sitio web real, como este, pero intentando producir todos los contenidos con el objeto de entenderlos en todos sus entresijos. Y en un momento dado ya tocaba poner un formulario de contacto que remitise los mensajes a un correo electrónico.

Se pone uno manos a la obra y ve que es necesario tener en cuenta el tema de la seguridad con los formularios que remiten datos al servidor. Pues entonces toca estudiarse todo lo que se pueda sobre seguridad. Pero hay algunas técnicas para hacer más seguro un sitio usando sesiones y cookies. Así que no queda más remedio que retroceder un paso y enfrentarse con preguntas como:

    Qué son las sesiones.
    Qué son las cookies.
    Qué relación hay entre ambos conceptos.
    Dónde se almacenan.
    Cómo se crean y destruyen.
    Qué riesgo hay si guardamos datos sensibles en las variables de sesión.
    Cómo se propagan las sesiones.
    Qué es la suplantación de sesión (session hijacking y session fixation).
#546
Back-end / Sesiones
Enero 30, 2013, 10:05:48 PM
Encontré un manual muy interesante de Sessiones de php.

Índice:
    Introducción
   
    Sesiones y cookies
    Sesiones y cookies
    El proceso de una sesión PHP basada en cookies
    Ejemplo de una sesión basada en cookies
    Javascript también puede manejar cookies
    Gestionando una sesión abierta

    Destrucción de sesiones
    Vida de una sesión
    Acceso indebido con sesiones vencidas y no limpiadas
    Destruyendo una sesión
    Destruyendo sesiones inesperadas

    Sesiones expuestas
    Alojamiento compartido en Apache Server
    Un explorador de carpetas con PHP
    Configuración safe_mode en PHP
    Configuración open_basedir en PHP
    Protegiendo las variables de sesión

    Cifrar variables de sesión
    Alojamiento compartido en Apache Server
    Un explorador de carpetas con PHP
    Configuración safe_mode en PHP
    Configuración open_basedir en PHP
    Protegiendo las variables de sesión

    Propagar sesiones
    El identificador de la relación servidor-cliente en una sesión
    Esquema básico para todos los ejemplos
    Propagar SID: Sólo cookies
    Propagar SID: Sólo URL con trans_sid y form=fakeentry
    Propagar SID: Sólo URL con trans_sid y form=action
    Propagar SID: Sólo URL sin trans_sid
    Propagar SID: Cookies o URL con trans_sid
    Propagar SID: Cookies o URL sin trans_sid y usando constante SID
    Propagar SID: POST oculto

    Asegurar sesiones
    Suplantación de sesiones
    Ejemplo de sesión con autenticación
    Fijación de sessión (session fixation)
    Secuestro de sessión (session hijacking)

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#547
Relaciones entre objetos

Durante la ejecución de un programa, los diversos objetos que lo componen han de interactuar entre sí para lograr una serie de objetivos comunes.

Existen varios tipos de relaciones que pueden unir a los diferentes objetos, pero entre ellas destacan las relaciones de: asociación, todo/parte, y generalización/especialización.

a.) Relaciones de Asociación

Serían relaciones generales, en las que un objeto realiza llamadas a los servicios (métodos) de otro, interactuando de esta forma con él.

Representan las relaciones con menos riqueza semántica.

b.) Relaciones de Todo/Parte

Muchas veces una determinada entidad existe como conjunción de otras entidades, como un conglomerado de ellas. La orientación al objeto recoge este tipo de relaciones como dos conceptos; la agregación y la composición.

En este tipo de relaciones un objeto componente se integra en un objeto compuesto. La diferencia entre agregación y composición es que mientras que la composición se entiende que dura durante toda la vida del objeto componedor, en la agregación no tiene por qué ser así.

Esto se puede implementar como un objeto (objeto compuesto) que cuenta entre sus atributos con otro objeto distinto (objeto componente).

c.) Relaciones de Generalización/Especialización

A veces sucede que dos clases tiene muchas de sus partes en común, lo que normalmente se abstrae en la creación de una tercera clase (padre de las dos) que reúne todas sus características comunes.

El ejemplo más extendido de este tipo de relaciones es la herencia, propiedad por la que una clase (clase hija) recoge aquellos métodos y atributos que una segunda clase (clase padre) ha especificado como "heredables".

Este tipo de relaciones es característico de la programación orientada a objetos.

En realidad, la generalización y la especialización son diferentes perspectivas del mismo concepto, la generalización es una perspectiva ascendente (bottom-up), mientras que la especialización es una perspectiva descendente (top-down).

Para más información sobre el modelo de objetos en la programación avanzada, y las relaciones entre objetos véase [García, 1998] o para una información más detallada consulte [Booch, 1996].
#548
Modelo de objetos

Existen una serie de principios fundamentales para comprender cómo se modeliza la realidad al crear un programa bajo el paradigma de la orientación a objetos. Estos principios son: la abstracción, el encapsulamiento, la modularidad, la jerarquía, el paso de mensajes y el poliforfismo.

a.) Principio de Abstracción

Mediante la abstracción la mente humana modeliza la realidad en forma de objetos. Para ello busca parecidos entre la realidad y la posible implementación de objetos del programa que simulen el funcionamiento de los objetos reales.

Los seres humanos no pensamos en las cosas como un conjunto de cosas menores; por ejemplo, no vemos un cuerpo humano como un conjunto de células. Los humanos entendemos la realidad como objetos con comportamientos bien definidos. No necesitamos conocer los detalles de porqué ni cómo funcionan las cosas; simplemente solicitamos determinadas acciones en espera de una respuesta; cuando una persona desea desplazarse, su cuerpo le responde comenzando a caminar.

Pero la abstracción humana se gestiona de una manera jerárquica, dividiendo sucesivamente sistemas complejos en conjuntos de subsistemas, para así entender más fácilmente la realidad. Esta es la forma de pensar que la orientación a objeto intenta cubrir.

b.) Principio de Encapsulamiento

El encapsulamiento permite a los objetos elegir qué información es publicada y qué información es ocultada al resto de los objetos. Para ello los objetos suelen presentar sus métodos como interfaces públicas y sus atributos como datos privados e inaccesibles desde otros objetos.

Para permitir que otros objetos consulten o modifiquen los atributos de los objetos, las clases suelen presentar métodos de acceso. De esta manera el acceso a los datos de los objetos es controlado por el programador, evitando efectos laterales no deseados.

Con el encapsulado de los datos se consigue que las personas que utilicen un objeto sólo tengan que comprender su interfaz, olvidándose de cómo está implementada, y en definitiva, reduciendo la complejidad de utilización.

c.) Principio de Modularidad

Mediante la modularidad, se propone al programador dividir su aplicación en varios módulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de ellos con un sentido propio.

Esta fragmentación disminuye el grado de dificultad del problema al que da respuesta el programa, pues se afronta el problema como un conjunto de problemas de menor dificultad, además de facilitar la comprensión del programa.

d.) Principio de Jerarquía

La mayoría de nosotros ve de manera natural nuestro mundo como objetos que se relacionan entre sí de una manera jerárquica. Por ejemplo, un perro es un mamífero, y los mamíferos son animales, y los animales seres vivos...

Del mismo modo, las distintas clases de un programa se organizan mediante la jerarquía. La representación de dicha organización da lugar a los denominados árboles de herencia:


Imagen 1: Ejemplo de árbol de herencia

Mediante la herencia una clase hija puede tomar determinadas propiedades de una clase padre. Así se simplifican los diseños y se evita la duplicación de código al no tener que volver a codificar métodos ya implementados.

Al acto de tomar propiedades de una clase padre se denomina heredar.

e.) Principio del Paso de Mensajes

Mediante el denominado paso de mensajes, un objeto puede solicitar de otro objeto que realice una acción determinada o que modifique su estado. El paso de mensajes se suele implementar como llamadas a los métodos de otros objetos.

Desde el punto de vista de la programación estructurada, esto correspondería con la llamada a funciones.

f.) Principio de Polimorfismo

Polimorfismo quiere decir "un objeto y muchas formas". Esta propiedad permite que un objeto presente diferentes comportamientos en función del contexto en que se encuentre. Por ejemplo un método puede presentar diferentes implementaciones en función de los argumentos que recibe, recibir diferentes números de parámetros para realizar una misma operación, y realizar diferentes acciones dependiendo del nivel de abstracción en que sea llamado.
#549
Las clases

Las clases son abstracciones que representan a un conjunto de objetos con un comportamiento e interfaz común.

Podemos definir una clase como "un conjunto de cosas (físicas o abstractas) que tienen el mismo comportamiento y características... Es la implementación de un tipo de objeto (considerando los objetos como instancias de las clases)". [Piattini et al., 1996].

Una clase no es más que una plantilla para la creación de objetos. Cuando se crea un objeto (instanciación) se ha de especificar de qué clase es el objeto instanciado, para que el compilador comprenda las características del objeto.

Las clases presentan el estado de los objetos a los que representan mediante variables denominadas atributos. Cuando se instancia un objeto el compilador crea en la memoria dinámica un espacio para tantas variables como atributos tenga la clase a la que pertenece el objeto.

Los métodos son las funciones mediante las que las clases representan el comportamiento de los objetos. En dichos métodos se modifican los valores de los atributos del objeto, y representan las capacidades del objeto (en muchos textos se les denomina servicios).

Desde el punto de vista de la programación estructurada, una clase se asemejaría a un módulo, los atributos a las variables globales de dicho módulo, y los métodos a las funciones del módulo.
#550
Los objetos

Podemos definir objeto como el "encapsulamiento de un conjunto de operaciones (métodos) que pueden ser invocados externamente, y de un estado que recuerda el efecto de los servicios". [Piattini et al., 1996].

Un objeto además de un estado interno, presenta una interfaz para poder interactuar con el exterior. Es por esto por lo que se dice que en la programación orientada a objetos "se unen datos y procesos", y no como en su predecesora, la programación estructurada, en la que estaban separados en forma de variables y funciones.

Un objeto consta de:

    Tiempo de vida: La duración de un objeto en un programa siempre está limitada en el tiempo. La mayoría de los objetos sólo existen durante una parte de la ejecución del programa. Los objetos son creados mediante un mecanismo denominado instanciación, y cuando dejan de existir se dice que son destruidos.

    Estado: Todo objeto posee un estado, definido por sus atributos. Con él se definen las propiedades del objeto, y el estado en que se encuentra en un momento determinado de su existencia.

    Comportamiento: Todo objeto ha de presentar una interfaz, definida por sus métodos, para que el resto de objetos que componen los programas puedan interactuar con él.

El equivalente de un objeto en el paradigma estructurado sería una variable. Así mismo la instanciación de objetos equivaldría a la declaración de variables, y el tiempo de vida de un objeto al ámbito de una variable.
#551
Antes de empezar quiero aclarar que este texto está orientado a java, pero es aplicable en programación general, por eso lo posteo aquí.

Fue extraido de You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Recomiendo la lectura para todos aquellos que quieran aprender los conceptos minimos. Un saludo... [H]arkonnen.

Programación Orientada a Objetos

La orientación a objetos es un paradigma de programación que facilita la creación de software de calidad por sus factores que potencian el mantenimiento, la extensión y la reutilización del software generado bajo este paradigma.

La programación orientada a objetos trata de amoldarse al modo de pensar del hombre y no al de la máquina. Esto es posible gracias a la forma racional con la que se manejan las abstracciones que representan las entidades del dominio del problema, y a propiedades como la jerarquía o el encapsulamiento.

El elemento básico de este paradigma no es la función (elemento básico de la programación estructurada), sino un ente denominado objeto. Un objeto es la representación de un concepto para un programa, y contiene toda la información necesaria para abstraer dicho concepto: los datos que describen su estado y las operaciones que pueden modificar dicho estado, y determinan las capacidades del objeto.

Java incorpora el uso de la orientación a objetos como uno de los pilares básicos de su lenguaje.
#552
Back-end / ¿Que es un framework?
Enero 30, 2013, 09:24:35 PM
En principio quiero aclarar que éste post fue escrito por WHK para WHK Security, puedes ver el post original haciendo You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login.

aclarado esto, dejo textualmente el post:




Según wikipedia:

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
CitarEn el desarrollo de software, un framework es una estructura conceptual y tecnológica de soporte definida, normalmente con artefactos o módulos de software concretos, en base a la cual otro proyecto de software  puede ser organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado  entre otros programas para ayudar a desarrollar y unir los diferentes componentes de un proyecto.

Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio.


Ahora en otras palabras un framework cuando nos referimos al desarrollo web se describe a un conjunto de funciones y clases estructuradas por un solo sistema.
Es similar a un sistema CMS con la diferencia de que aca no hay secciones finales desarrolladas.

Me explico. Un sistema CMS lo instalas y tiene un sistema completo llegar y llenar de contenidos, por algo es un CMS gestor de contenidos. Un framework no es un sistema hecho, es solo una base para construir tu propio sistema WEB. Algunos ejemplos son estos:

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#553
Android / Re:Paquetes de GNU/Linux en tu Android
Enero 30, 2013, 08:28:16 PM
se ve muy interesante, se te agradece que lo postees por estos lares.

un saludo mi buen amigo y si ves a xianur0 mandale saludos de mi parte.
#554
Python / Re:[Source] Funcion Download
Enero 30, 2013, 08:22:58 PM
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
¿Te has pasado al Python? Una vez que empiezas no podrás parar...

a este paso solo existirán desarrolladores que utilizen py.

saludos!
#555
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Las colisiones que encontro Psymera no es nada del otro mundo. Digo porque dices que el algoritmo de cifrado que usaste es muy sencillo y facil de descubrir, pero no he visto a nadie que lo haya decifrado, a modo de hacer un keygen o algo. Sin codigo, intentando a mano viendo los cambios en las salidas, esta medio dificil para mi encontrar su algoritmo.

Porque no hacer que pida una key para encriptar y desencriptar, la cual tendran solo los usuarios del foro?
O solo habilitar el ucodificador para los usuarios, asi nadie podra ponerse a hacer pruebas para sacar el algoritmo.

es publico porque la idea es que se use por ejemplo para encriptar una password para descargar un crypter, y que si se publica en otra comunidad, los usuarios vengan a la nuestra a desencriptar, y de ese modo quizá se interesen por nuestra comunidad nuevos usuarios.

saludos!
#556
Presentaciones y cumpleaños / Re:Hola a Todos
Enero 30, 2013, 08:19:33 PM
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Bueno pues hoy recibí el privado de [H]arkonnen y decidí hacerle caso, pues mi nombre es Jesús, alguno me dicen Jester soy Colombiano, bachiller tengo 16  años y me uní a esta comunidad con el fin de aprender, conocer gente con los mismos intereses y pasarla bien aprendiendo ya que me apasiona mucho la informatica, este año estudiaré Diseño gráfico, aunque soy muy novato en lo que sé, pero de todo se un poco  ;D y un Saludo a Antrax también estoy en su comu jeje (Parece buen tío xD) , bueno eso seria todo gracias.  ;)

Jejejee me alegra que te decidieras a presentarte, eres bienvenido y esperamos que estés comodo :D

saludos!
#557
Presentaciones y cumpleaños / Re:Hola
Enero 30, 2013, 05:03:06 PM
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Buenas gente!
Soy nuevo en el foro. Como todos aquí, soy un interesado en los temas que en esta comunidad se presentan aunque soy muy novato en casi todos ellos...XD... Tengo algo de experiencia en Java... pero espero seguir creciendo con la ayuda de esta comunidad.
Saludos a todos!

Bienvenido!!! me alegro que te presentaras, espero que te sientas en casa y creo que hablo por todos aquí cuando digo que lo que necesites puedes consultarnos a nosotros dudas y aportar las cosas que encuentres interesantes.

Un saludo! y sientete como en casa :D
#558
Presentaciones y cumpleaños / Re:Buenas...
Enero 30, 2013, 04:28:12 PM
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Hola mi nombre es Rodolfo y soy de Curuzú Cuatiá (Ctes.). Actualmente soy estudiante de infraestructura informática y trabajo como desarrollador web y tecnico en pc y redes. Estoy muy agradecido de formar parte de esta comunidad, un saludos a todos!

bienvenido, siempre es un gusto recivir y conocer nuevas personas que les guste la informática como a nosotros.

me alegro que hallas decidio publicar tu presentación.

saludos!
#559
Underc0de / Re:UCodificator Servicio Online
Enero 30, 2013, 04:01:44 PM
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Pero tambien se podria ayudar, estarai bueno compartir el codigo con la comunidad

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

saludos!
#560
Verán todo comenzó cuando hicimos el Encriptador/Desencriptador de underc0de, con un algoritmo propio

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login <-- ese servicio.

Siendo mi primer algoritmo es muy sencillo y fácil de descubrir (reto a todos los que descubran el algoritmo, tomenlo como un wargame).

mientras tanto con antrax, y psymera hablabamos de como poder mejorar el algoritmo, cuando se nos ocurrieron ideas como

sacar cuentas en base a la hora y dejar un numero que la represente en el hash para su desencriptación.

Encriptar con una semilla generada al azar, creando una lista de semillas base en un arreglo y con un número al azar seleccionar una de ellas, y encryptar, y dejar en el hash el número.

entre otras cosas.

asique este post es para que todos comenten que ideas se les ocurren para un algoritmo de encriptación.

saludos! (recuerden que no nos podemos basar en md5 salvo para cosas que no se necesiten regresar, ya que nuestro algoritmo debe tener una forma de desencriptar).