Tips (PHP): Escribir en la sesión de otro usuario

Mientras desarrollaba una nueva funcionalidad para el framework PHP en el que estoy trabajando, me encontré con la necesidad de realizar una acción no muy común: escribir valores en la sesión de otro usuario.

Como todo desarrollador PHP sabe (o debería...), es posible almacenar valores que persisten entre requests en una misma sesión, utilizando el arreglo súper global $_SESSION. Cada sesión se asocia a un usuario, por lo que los valores almacenados para un dado usuario son accesibles sólo para él. Ahora, y si desde la sesión de un usuario, deseamos acceder valores de la sesión de otro usuario?
Muchos se preguntarán, para qué querría hacer esto? Bueno, en mi caso particular me sirvió para actualizar la configuración de un usuario desde un usuario administrador, sin la necesidad que el primero se loguee nuevamente para ver los cambios. Por ejemplo, si un usuario administrador A cambia el theme de un usuario B que ya está logueado, quiero que B vea los cambios al instante. Podría hacer esto mismo almacenando un valor en la base de datos y chequeando desde la sesión de B el registro en cada acceso, pero esto me pareció muy ineficiente. Mi solución fue escribir un flag en el arreglo de sesión de B, y luego desde B chequear el valor en el arreglo para ver si hay cambios.
Como me resultó una funcionalidad interesante, decidí compartirla.

Para que el siguiente código funcione, es necesario almacenar los IDs de sesión de cada usuario logueado. Lo pueden hacer guardando los IDs en una tabla cada vez que un usuario se loguea en el sistema. Asumo que la función "get_user_session_id($user)" ya está implementada y me permite obtener el ID del usuario que le envío por parámetro; cada uno verá como almacenar y obtener el ID.
Traté de dejar el código lo más genérico posible, con lo que deberán cambiar sólo la línea que asigna el valor en la sesión del otro usuario, la cual marqué con el comentario "CAMBIAR AQUI!".
Espero que les resulte útil!

//guardar el session id actual para poder restaurarlo luego
$current_id = session_id();

if(($sid = user_get_session_id($user)) === FALSE)
{
  throw new Exception("user ID not found");
}

//guardar los valores de la sessión actual antes de cambiar de sessión
session_write_close();

//abrir la sessión del otro usuario
session_id($sid);
session_start();

//almacenar el valor deseado en la sessión del otro usuario
$_SESSION['some_value'] = $value;   // CAMBIAR AQUI!

//guardar los cambios hechos en la sessión del otro usuario
session_write_close();

//volver a la sessión del usuario actual
session_id($current_id);
session_start();

Hardening PHP

PHP es el lenguaje más popular para la creación de Webs, y por lo tanto muy conocido, y a la vez atacado.
Si bien es trabajo del programador (y el mayor responsable de) tomar los recaudos necesarios para que sus aplicaciones no sean vulnerables, un administrador de sistemas puede utilizar varias opciones para que el servidor sea lo más resistente posible. PHP ofrece varias opciones que aumentan la seguridad significativamente, si se encuentran bien configuradas.

La siguiente es una lista de directivas que se pueden configurar en el archivo de configuración de php (/etc/php.ini, o /etc/php5/apache2/php.ini, dependiendo la distribución) para mejorar la seguridad del servidor:

• Restringir el acceso al sistema de archivos. Dado que los sites se alojarán en /var/www, salvo casos excepcionales, los scripts PHP no necesitan acceso al resto del sistema de archivos, a excepción del directorio /tmp que es donde se alojan los archivos cuando el usuario hace un upload. Por ello, es posible restringir los directorios a los que se puede acceder, mediante la opción:
  

  open_basedir = /var/www:/tmp

  Esta configuración se puede cambiar por site en el correspondiente Virtual Host, utilizando la directiva:
  

  php_admin_value open_basedir /var/www/[nombre site]/

• Deshabilitar funciones riesgosas. Hay funciones que deben ser permitidas sólo en casos particulares, debido a que se usan raramente y representan un gran riesgo. Esta configuración se realiza con la directiva disable_functions:
  

  disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

• No revelar información de PHP en los headers. Esto le permitiría a un atacante saber que el servidor posee PHP, además de la versión instalada, y así poder realizar un ataque más específico:
  

  expose_php = Off

• No exponer errores de scripts al cliente. Los errores de programación no deben quedar expuestos a los clientes, sino que deben loggearse en archivos para que el programador los pueda depurar:
  

  display_errors = Off
  display_startup_errors = Off

• Loggear errores permiten detectar cuál fue la falla que causó que el programa no funcione o lo haga de forma imprevisible:
  

  log_errors = On

• No utilizar register_globals. Esta funcionalidad se considera extremadamente peligrosa y por default viene desactivada en toda configuración actual, pero por las dudas se debe checkear que el valor sea el siguiente:
  

  register_globals = 0

• No utilizar magic_quotes. PHP provee, hasta la versión 5, de una utilidad para escapar caracteres peligrosos (', “, \, NULL), antes de ser utilizados por los scripts del servidor. Esto permite evitar algunos ataques de SQL Injection, pero tiene complicaciones con las distintas codificaciones de caracteres y además puede introducir problemas en la programación. Este tipo de controles deben estar implementados en la aplicación y no en el servidor, por lo cual a partir de PHP 5.3 se considera deprecated y en la versión 6 ya no existe.
  

  magic_quotes_gpc = Off
  magic_quotes_runtime = Off
  magic_quotes_sybase = Off

• Para realizar upload de archivos desde el cliente, utilizar el directorio tmp correspondiente al site, es decir /var/www/[nombre site]/tmp. Esta configuración se realiza en el virtual host con la sentencia:
  

  php_admin_value upload_tmp_dir /var/www/[nombre site]/tmp

• No tratar las URLs (como http:// o ftp://) como archivos. En caso de encontrar un error en la programación, un atacante podría realizar remote file inclusion si esto se encuentra activado.
  

  allow_url_fopen = Off
  allow_url_include = Off

• Cambiar el nombre de la variable de sesión. Por defecto esta variable se llama PHPSESSID y demuestra que el servidor ejecuta PHP, y que la página actual está escrita en PHP. Si bien esto agrega poca seguridad, agrega una traba más al atacante.
  

  session.name = SESSION_ID

Como dije, estas opciones ayudan a la seguridad, pero no evitan, por ejemplo, que un programa vulnerable a SQLi permita a un atacante romper la base de datos.
Espero que les sean de utilidad!


Referencias

- Description of core php.ini directives
- Securing PHP: Step-by-Step

Cómo evitar SQL Injection + Prepared Statements en PHP

Luego de escribir la serie de artículos sobre hacking usando SQL Injection, creo que es tiempo de escribir sobre algún método de prevención >=)

Como se puede observar en cualquier bibliografía "decente" sobre SQL Injection, existen básicamente 3 formas de prevenir la inyección, las cuales están muy bien descriptas en el artículo de OWASP SQL Injection Prevention Cheat Sheet. Las opciones son:

- Prepared Statements: Los prepared statements son sentencias pre-compiladas, en las cuales se indica qué parámetros serán ingresados por el usuario. De esta forma podemos indicarle al DBMS cuál es el código a ejecutar y cuáles serán las variables. Esto permite que el motor distinga la sentencia a ejecutar de los datos de entrada y así evitar que el usuario agregue sentencias SQL.
Además de la obvia ventaja de prevenir las inyecciones, éstos permiten mejorar el tiempo de ejecución si la misma sentencia se utiliza más de una vez. Cuando armamos una sentencia SQL, el motor de base de datos analiza, compila y optimiza la forma en que la ejecutará, por ello, si la armamos una sola vez y la ejecutamos varias veces (ya sea utilizando los mismos o diferentes parámetros), el tiempo de ejecución disminuirá considerablemente.

- Stored Procedures: Los stored procedures son más conocidos que los prepared statements entre los desarrolladores debido a su uso extensivo en la programación que interactua con BDs. Se escriben procedimientos en el lenguaje del DBMS (los cuales se almacenan en la base de datos) y desde el código del programa se llaman estos procedimientos con las variables ingresadas por el usuario como los parámetros. De esta forma, el DBMS puede distinguir correctamente variables de código.
Los stored procedures son tan eficaces como los prepared statements, pero hay que tener cuidado de no utilizar los parámetros para armar sentencias, porque estaríamos anulando la defensa.

- Escapar todo dato ingresado por el usuario: probablemente ésta sea la forma más difundida de prevenir SQL Injection y la cual se cita en mucha bibliografía, pero también es la menos recomendada. La idea es que cada vez que el usuario ingrese datos que utilizaremos en una sentencia, escapemos los caracteres especiales (como comillas simples o dobles, barras invertidas "\", o caracteres de comentario "--" o "#", etc) para que el dato sea un solo string y el motor de BD no lo confunda con código a ejecutar. Un ejemplo de función que permite escapar los caracteres especiales, cuando utilizamos php + mysql, es mysql_real_escape_string. Recuerden que esta función no es mágica y se puede evitar como expliqué en el artículo SQL Injection avanzado: consultas simplificadas, file inclusión, ejecución remota y más! en la sección "No puedo usar comillas... no importa!".
Cómo explican en la página de OWASP citada anteriormente, este técnica es frágil y se debe utilizar sólo cuando ya contamos con código inseguro y reescribirlo utilizando prepared statements requeriría un costo inaceptable. Todo desarrollo que se comience de cero debe utilizar prepared statements o stored procedures.


Librería PDO para PHP

Como ya les he mencionado varias veces, soy fan del desarrollo en PHP, por lo cual me expandiré un poco sobre cómo prevenir SQL Injection en este lenguaje. Mi opción favorita para tal caso es utilizar prepared statements, porque mi filosofía es "dejar la base de datos, para almacenar datos", lo cual elimina a los stored procedures como opción. Además de esta forma el código es portable para ser utilizado con distintos motores de base de datos.

En fin, para lograr el objetivo utilizaremos la librería PDO. Como lo describen en la documentación oficial de PHP, PDO (PHP Data Objects) es una interfaz ligera para acceder a bases de datos, la cual permite abstraernos del motor de base de datos, utilizando siempre el mismo conjunto de funciones para acceder a los datos. Esto hace que el código sea portable a cualquiera de las bases de datos soportadas por PDO, entre las que se encuentran las más importantes (MySQL, SQL Server, Postgre, Oracle, SQLite, Informix, Firebird, etc).

PDO no fuerza al usuario a utilizar prepared statements, pero ofrece una serie de funciones para el manejo de los mismos. En ellas se puede utilizar tipado fuerte, lo cual agrega mayor seguridad al especificar el tipo de los datos esperados.


Utilizar los Prepared Statements de PDO

Los prepared statements de PDO son fáciles de utilizar, aunque al principio pueden resultar un poco molestos debido a que se debe escribir un poco más de código al ejecutar consultas.
Veamos una comparación de las funciones que más se utilizan al acceder a la base de datos. Tomo como ejemplo las funciones de MySQL, aunque como saben, PDO funciona con casi cualquier base de datos.

Conexión con la base de datos:

$db = mysq_connect('localhost', 'tester', '123456');
mysql_select_db('test', $db);

Para conectarnos utilizando PDO debemos crear un objeto PDO indicando el tipo de la base de datos a utilizar, el host, el nombre de usuario y el password de la siguiente manera:

$db = new PDO("mysql:host='localhost';dbname='test'", 'tester', '123456');

Consulta a la base de datos:

mysql_query("SELECT * FROM content WHERE id=".$_GET['id'], $db)

Esta es la parte más sensible donde debemos evitar utilizar cualquier parámetro ingresado por el usuario directamente en el string de consulta. Primero preparamos la consulta que debemos ejecutar, indicando con : cuáles son las variables ingresadas por el usuario:

$stmt = $db->prepare("SELECT * FROM content WHERE id= :id");

Luego vinculamos la variable ingresada por el usuario con la utilizada en la consulta, indicamos el tipo, y finalmente ejecutamos la consulta.

$stmt->bindParam(":id", $_GET['id'], PDO::PARAM_INT);
$stmt->execute();

Las 2 llamadas anteriores se pueden unificar en una sola, utilizando un arreglo asociativo en la función execute:

$stmt->execute(array(":id" => $_GET['id']));

La única desventaja de utilizar esta forma de bind es que todos los parámetros son tratados como PDO::PARAM_STR (es decir, strings).

Obtener una fila en un arreglo:

mysql_fetch_array($db);

La forma de obtener filas es muy similar a la llamada anterior, lo que debemos ejecutar es lo siguiente:

$stmt->fetch();

Al igual que mysql_fetch_array, el fetch de PDO obtiene por defecto un arreglo con ambos índices: asociativo y numérico. Si deseamos obtener sólo el arreglo asociativo, podemos utilizar el parámetro PDO::FETCH_ASSOC. En caso de desear uno con índices numéricos el parámetro es PDO::FETCH_NUM:

$stmt->fetch(PDO::FETCH_ASSOC) o $stmt->fetch(PDO::FETCH_NUM);

Además contamos con una función que retorna todas las filas resultantes de la ejecución de la consulta:

$stmt->fetchAll();

Ver errores:

mysql_error($db);

En el caso de prepared statements, los errores se obtienen con errorInfo:

$stmt->errorInfo();

el cual retorna un arreglo que contiene:
0 código de error SQLSTATE
1 código de error
2 mensaje de error

Bueno, con eso cubrimos las funciones básicas de acceso a la base de datos, aunque existen unas cuantas más y las pueden ver en el manual The PDOStatement class.


Conclusión

Prevenir las inyecciones SQL es muy sencillo utilizando prepared statements y es sólo cuestión de ser lo suficientemente responsable (y consciente) a la hora de escribir consultas. Una vez que uno se acostumbra, la escritura del código sale de forma natural y esas "líneas de más" no resultan tan molestas. Recuerden que esto les salvará muchos dolores de cabeza y se sentirán tranquilos de que no los "hackearan" utilizando esta técnica.
Write safely! =)


Referencias

- SQL Injection Prevention Cheat Sheet
- Introduction to PHP PDO
- Prepared statements and stored procedures (Prepared statements and stored procedures)
- PHP manual PDO
- Prepared Statements

Usar o no usar Joomla

En las últimas semanas varias personas me consultaron sobre qué me parecía el uso de Joomla para montar páginas Web. Mi respuesta en todos los casos es "depende". Lo importante a la hora de decidir entre montar un Joomla o hacer un desarrollo de cero es ver cuáles son las ventajas y desventajas de hacer una u otra cosa. Todo varía dependiendo del tipo de página que deseemos, el público al que queremos llegar, la funcionalidad que necesitamos, el grupo que se va a encargar del desarrollo del site, el mantenimiento que le van a dar, el nivel de seguridad, y por supuesto, el presupuesto con el que contamos.
Vale destacar que tomo como base Joomla porque es el CMS (Content Management System) libre más conocido y utilizado, pero que lo dicho se puede utilizar para cualquier otro CMS conocido como drupal, Wordpress, PHP Nuke, etc.
Las recomendaciones que compartiré con ustedes se basan en la experiencia de usar Joomla y de tratar con varios proveedores de software (dolores de cabeza si los hay).
Veamos entonces cuáles son las preguntas que deben hacerse para decidir por un desarrollo de cero o partir de un CMS como Joomla.


Background: qué es un CMS?

Me parece correcto que, antes de ver los puntos mencionados, describa qué es un Content Management System. La mayoría de los que siguen este blog seguramente está recontra familiarizados con este tipo de programas, pero la idea de este artículo es llegar a un público general.

Entonces, qué es un CMS y en qué se diferencia a realizar un desarrollo de cero? un CMS, en la jerga web, es un programa que nos permite montar rápidamente una página a través de una interfaz Web que tiene las herramientas necesarias para administrar contenido (texto, imágenes, multimedia, etc), menús, secciones, usuarios y visualización. Básicamente tenemos una página prearmada y lo único que tenemos que hacer es agregar el contenido, elegir qué deseamos mostrar y cómo. Es un "construir página web for dummies", algo que cualquiera puede hacer.
La diferencia con un desarrollo es que en un CMS no necesitamos programar nada, solamente administrar el contenido desde la sección de administración. Claro que si necesitamos una funcionalidad que el CMS no provee, necesitaremos un programador para que la agregue, pero este trabajo es ínfimo comparado a realizar todo el site desde cero.
En el caso de joomla, es posible extenderlo fácilmente a través de módulos y existen decenas o tal vez cientos de módulos disponibles gracias a los aportes de la comunidad libre.


Con qué presupuesto contamos?

El factor más importante, es el presupuesto. Después de todo, lo que importa es el vil metal. El presupuesto influirá directamente para responder el resto de las preguntas que planteo.
Si el presupuesto es pequeño, deberían decantarse por Joomla casi sin pensarlo. Los beneficios que brinda son muchos frente a un desarrollo hecho a medida con poco dinero.
Si, en cambio, contamos con gran presupuesto, lo mejor es contratar a una empresa con gran experiencia en desarrollo Web y que cree un site desde cero. Esto nos dará ventajas tanto para elegir exactamente qué es lo que queremos, como para mostrar una imagen empresarial importante y asignarle al site la seguridad necesaria. Es decir, si tienen gran presupuesto, no hace falta que sigan leyendo =P
Por otra parte, contando con un presupuesto mediano, revisen el resto de las preguntas y a partir de ellas decidan qué hacer.


Cuál es la imagen que deseamos mostrar?

La segunda pregunta que tenemos que hacernos es "cuál es la apariencia que queremos?". Con esto me refiero al prestigio que quedemos que tenga la página. Es un punto clave para decidir si utilizar un CMS o no.
No es lo mismo mostrar una página que se desarrolló desde cero que mostrar un Joomla. Esto es básico para las empresas, sobre todo empresas medianas para arriba, donde la imagen es muy importante.
Si bien los Joomla son realmente flexibles en cuanto a modificar la visualización de la página, alguien que medianamente conoce del tema se da cuenta que la página está hecha con Joomla. Yo veo una página y casi al instante me doy cuenta de si es un Joomla o no. Y al entrar al site de una empresa hecho con Joomla, lo primero que pienso es "son unos ratas" (i.e. no quisieron gastar mucho, o no les importa el site), lo cual en el mundo de las apariencias (alias marketing), es malo.
Por ello, si necesitamos mostrar una imagen de empresa importante, no lo piensen, realicen un desarrollo de cero.


Joomla es seguro?

Este punto está muy ligado con el anterior. Hoy en día no se puede desestimar la seguridad de un site web publicado a internet, es una locura y falta de sentido común hacerlo. Entonces, siendo tan importante el tema seguridad, pondrían un Joomla?
En este punto Joomla tiene puntos a favor y en contra. El gran punto a favor es que tiene una gran comunidad detrás revisando y corrigiendo errores continuamente y enviando los updates a los usuarios. Tener actualizaciones constantes es algo que casi nunca tenemos con un desarrollo a medida porque en general una empresa de software crea el site, lo pone online, lo cobra y listo, no existe soporte posterior.
El problema grave son los módulos desarrollados por terceros que en general no tienen soporte, abriendo una brecha de seguridad importante. La otra gran desventaja es que donde encuentran un agujero en Joomla o en uno de sus módulos, explotan todos los sites. Esto es, descubren un agujero y se publica en la web, y a partir de allí cualquiera puede explotar nuestro site (en conjunto con los otros cientos de sites hechos en Joomla). Esto nos abre a atacantes no dedicados, es decir, gente que no estuvo intentando hackear nuestro site de forma exclusiva, sino cualquier persona que vea que tenemos un Joomla.
Incluso cuando sale un agujero en Joomla, muchos deportivamente salen a buscar sites hechos con este CMS para hackear tantos como pueda, sin importarle realmente hackear nuestro site por alguna razón. Una búsqueda en google con el parámetro inurl:option=com_content nos traerá todos los sites hechos en Joomla que no cambiaron sus URLs.

Entonces, es seguro usar Joomla? si lo mantenemos actualizado, no usamos módulos de terceros sin soporte y lo configuramos correctamente, si. Incluso diría que es más seguro usar Joomla que un desarrollo a medida sin soporte, o un desarrollo a medida realizado por una empresa que no entiende o no le importa la seguridad (me he topado con tantos...).
A pesar de esto, si la seguridad es muy importante y deseamos que nos hackeen lo menos posible (nunca estaremos libres de la posibilidad de hackeo, eso tenganlo presente), mi recomendación es un site desarrollado de cero teniendo en cuenta las recomendaciones básicas de seguridad.
Si por otra parte deciden utilizar Joomla, lean el checklist de seguridad provisto por la misma comunidad: Security Checklist.


Qué funcionalidad necesitamos?

Otro punto importante es la funcionalidad. Joomla es bastante flexible, amigable y muy extensible, algo que nos permite tener alta funcionalidad. En un desarrollo de cero lograr la funcionalidad que tiene Joomla les costará mucho dinero y probablemente muchas peleas con los desarrolladores por no entender los requerimientos. Obviamente que hay ciertas cosas que están estructuradas de una manera (como la administración de contenidos) que si no les gusta deberán ser modificadas por un desarrollador.
La mayoría de los sites, desarrollados de cero, que contienen una sección de administración, que he visto, son una patada en los huevos. Administrar una página a través de ellos es una tortura, y un Joomla nos habría salvado de tanto sufrimiento.

En resumen, si funcionalidad es lo que buscan, mi recomendación es Joomla, a menos que tengan el tiempo, dinero, dedicación y paciencia necesarias para tratar con un equipo que desarrolle todo de cero.


Qué experiencia tiene la empresa que hará el desarrollo?

Si el presupuesto es mediano o bajo, probablemente deban contratar una empresa de acorde a esto. Es entonces cuando deberían preguntarse: confío lo suficiente en "tal empresa" como para que haga este desarrollo desde cero?
Si están en duda, pongan un Joomla! o bien sigan buscando desarrolladores hasta encontrar uno que parezca cumplir los requerimientos.


Queremos que el site se vea actualizado?

Lo primero que vemos al entrar en un site es su diseño visual, y es lo que importa para mostrar que mantenemos el site actualizado. Es muy importante renovar cada cierto tiempo la visualización para darle frescura y no aburrir.
Joomla, al igual que todos los CMSs importantes, posee un sistema de templates a través del cual es simple renovar la visualización, algo que no he visto en la mayoría de los desarrollos a medida. Además existen muchos templates gratis para descargar de Internet.
Este punto se puede ligar directamente con el de imagen empresarial que plantié anteriormente, pero trato de mostrarlo más abstracto. Tal vez tenga un site que deseo mantener actualizado visualmente, pero que no necesita mostrar una imagen de empresa tan importante. Igualmente este es el punto que menos influirá en la decisión, aunque si es para tener en cuenta. Deben saber que con Joomla será fácil mantener una visualización actualizada, mientras que con un desarrollo a medida deberán pedirlo explícitamente y probablemente aumente el presupuesto.


Conclusión?

Tal vez les dejé más interrogantes que respuestas, pero espero haber cumplido con informarlos lo suficiente como para poder tomar una decisión razonable.
En resumen, si poseen el suficiente dinero, hagan un desarrollo a medida. Lo mismo si esperan que no los hackeen en conjunto con otros 1000 sites, o si desean brindar una cierta imagen. En el resto de los casos, piensenlo bien, probablemente Joomla cumpla perfectamente sus necesidades.

Espero que ustedes puedan darme aportes sobre qué les parece el uso de Joomla en ámbitos empresariales, y tal vez agregar algunas preguntas más a la lista =)

shortcuts: programación PHP

Nunca les pasó que se mezclan los lenguajes de programación y a veces no recuerdan como usar una estructura, o como crear un objeto, o cuáles variables o funciones usar para acceder a ciertos datos? bueno a mi si, y siempre quise tener una referencia rápida con todos estos datos.
Es por eso que se me ocurrió crear un nuevo shortcut, uno donde cuente con la sintaxis básica de los lenguajes que utilizo. La idea comenzó porque me veo forzado a aprender un poco de ASP y ASP.Net, y tener acceso rápido a la sintaxis me ahorraría mucho tiempo de navegación.
Toda la información que posteo la pueden encontrar en cualquier tutorial del correspondiente lenguaje, pero siempre están separados en varias hojas y con explicaciones de para qué sirve cada estructura.
Mi idea es crear un shortcut con ejemplos, pero sin explicaciones (o con explicaciones muy cortas). Osea, si sabes programar no necesitas que te expliquen para qué sirve cada cosa.

En esta entrega les traigo un shortcut de programación PHP. Justamente PHP es el lenguaje que más utilizo y conozco así que escribí casi todo sin necesidad de buscar. Más adelante espero entregar versiones similares de lenguajes que no conozco tanto, como ASP.Net y JSP... vengo a full con la auditoría de aplicaciones Web y necesito aprender bastante.

En fin, espero que les resulte de utilidad... algo para tener a mano cada vez que van a programar =)

- Tag indicador de código php:

<?php ... codigo ... ?>

- imprimir mensajes:

print "mensaje";
echo "mensaje";

- concatenador de strings: . (punto)

- condiciones:

or: ||
and: &&
not: !
igual: ==
distinto: !=
menor: <
menor igual: <=
mayor: >
mayor igual: >=

- if-then-else

if( condicion )
{
//si es true hacer esto
}
elseif( condicion2 )
{
//hacer esto otro
}
else
{
//hacer esto ultimo
}

- switch:

switch( $variable )
{
case valor1:
//hacer algo
break;

case valor2:
//hacer otra cosa
break;
...
...
default:
//hacer esto en el caso de que no coincida nada de lo anterior
break;
}

- funciones/procedimientos:

function ejemplo($par1, $par3, ... $parn)
{
//codigo
...
...
}

//llamar a la funcion
ejemplo($par1, $par2, ..., $par3);

- formas de incluir otros scripts:

include("other.php");
include_once("other.php"); //si el archivo ya se incluyó en una llamada anterior, no se vuelve a incluir

require("other.php"); //igual a include, pero arroja un error FATAL si no encuentra el archivo
require_once("other.php"); //si el archivo ya se incluyó en una llamada anterior, no se vuelve a incluir

- arreglos:

- crear arreglo:

$miarreglo = array();

- obtener/setear valores:

$miarreglo[0] = "demasiadovivo";
$name = miarreglo[0];

- agregar elemento:

$miarreglo[] = "d3m4s1@d0v1v0";

- arreglos asociativos:

$miarreglo["name"] = "demasiadovivo";
$name = $miarreglo["name"];

- loops:

- while:

while ( condicion )
{
//hacer algo
}

- for:

for ( valor-inicial; condicion; incremento)
{
//hacer algo
}

ejemplo:

for ($i=0; $i<100; $i++)
{
//hacer algo
}

- para recorrer arreglos asociativos, usamos foreach

foreach ($miarreglo as $key => $value)
{
//$key almacena el valor la posición del arreglo y $value el valor
}

otra forma:

foreach ($miarreglo as $value)
{
//obtenemos cada valor almacenado en el arreglo
}

- do..while (siempre se ejecuta al menos una vez)

do
{
//hacer algo
} while ( condicion );

- obtener parámetros GET (usar el arreglo $_GET):

$name = $_GET['name']

- obtener parámetros POST (usar el arreglo $_POST):

$name = $_POST['name']

- cookies:

- setear cookie:

setcookie("name", "demasiadovivo", $ttl);

- obtener cookie:

$name = $_COOKIE['name'];

- sesiones:

- iniciar una sesión:

session_start();

- obtener/setear variable de sesión (usar arreglo $_SESSION - acordarse de incluir la llamada a función session_start() al principio del script):

$_SESSION['name'] = "demasiadovivo";
$name = $_SESSION['name'];

- terminar sesión:

session_destroy();

- archivos:

- abrir archivo:

$f = fopen("archivo.txt", $modo);
donde $modo puede ser
"r" solo lectura
"w" solo escritura
"a" append
"r+" lectura y escritura. Cuando abrimos el archivo el puntero está al inicio de éste.
"w+" igual a r+ pero borra el contenido del archivo cuando lo abre
"a+" igual a r+ excepto que deja el puntero al final del archivo

- leer desde el archivo:

$dato = fread($f, $size);
donde $size indica la cantidad de caracteres a leer.

$dato = fgets($f);
lee de a una linea. Lee caracteres hasta encontrar un enter.

- escribir en archivo:

$dato = "cualquier dato";
fwrite($f, $dato);

- cerrar archivo:

fclose($f);

- clases y objetos:

class ejemplo
{
//constructor
function __construct($par1, $par2, ..., $parn)
{
}

//destructor
function __destruct($par1, $par2, ..., $parn)
{
}
}

- crear clase

$ex = new ejemplo($par1, $par2, ..., $parn)

- setear/acceder atributo

$ex->name = "demasiadovivo";
$name = $ex->name;

- llamar función

$ex->algunafuncion($par1, $par2, ..., $parn);

- visibilidad:

public - visible por todos
protected - visible para los objetos que heredan el atributo o la función
private - visible solamente para la clase

- acceder a métodos estáticos/constantes

$name = $ex::name_estatico;
$ex::algunafuncionestatica($par1, $par2, ..., $parn);

- herencia:

class ejemplo extends ejemplito

donde ejemplo hereda de ejemplito

- comparaciones entre objetos:

obj1 == obj2 //verifica que ambos objetos tengan tengan los mismos atributos, los mismos valores y son instancia de la misma clase.
obj1 === obj2 //verifica que ambos sean el mismo objeto, osea, que ambas variables referencien a la misma instancia de la misma clase.

- clases/funciones abstractas:

abstract class ejemplo_abstracto
{
abstract function funcion_abstracta();
}

- interfaces:

interface ejemplo_interfaz
{
...
...
}

class ejemplo_implementador implements ejemplo_interfaz
{
//la clase debe implementar todos los métodos de la interfaz
}

Referencias

- PHP Manual
- PHP Tutorial (tizag)