logo El código abierto
y su importancia
en la empresa
Javascript, Criptografía, Seguridad La seguridad en internet, un tema de todos los días

Volumen 1, #8, Viernes 29 de febrero de 2008

Javascript

¿Qué hace Javascript, un lenguaje de programación, en medio de conceptos de seguridad?

Primero que nada, Javascript se llamaba antes LiveScript, pero por razones propagandísticas, moda y negocios entre Sun Microsystems y Netscape Communications, fue renombrado a Javascript, pues Java, un lenguaje más bien bastante diferente a Javascript, era la sensación en esos días (aunque ambos tienen similitudes con C) .

Javascript es un lenguaje hecho para operar sólo en navegadores, mientras que Java tiene aplicaciones más amplias. Debido a esta particularidad, un programa hecho en Javascript que sea descargado vía Internet y que se ejecute en un navegador, puede realizar un buen número de tareas directamente en la computadora de tal usuario, lo cual puede poner en riesgo la información sensible de éste, si no se comprende bien qué permisos estén dados a tales procesos realizados por las rutinas hechas en Javascript. Los navegadores tienen un selector para desactivar tales rutinas. Algo parecido a lo que en las hojas de cálculo se denomina "Desactivar Macros", ya que tales macros crean riesgos similares.

Un uso muy ingenuo para el Javascript es adornar y mover imágenes en una página web (en el documento descargado desde un sitio web). Otro uso muy útil y menos ingenuo es pre-procesar información en el mismo navegador o "Cliente", antes de transmitir la información hacia el "Servidor" Web que esté atendiendo a ese usuario.

En general los procesos maliciosos hechos en Javascript, suceden en sitios no formales, sitios para adultos, sitios con spam, etc. Por ello procura visitar solo sitios recomendados de buena fuente para mantenerte al márgen de los peligros del "mal uso" de javascript.

Criptografia

La criptografía es el mecanismo para transformar información mediante algoritmos, llaves o claves, para así prevenir que esta pueda ser leída o interpretada por gente no autorizada

La criptografía SIMETRICA, es aquella en la que ambas partes involucradas en la transmisión y recepción, comparten la misma llave. La criptografía ASIMETRICA es aquella en la que cada cual tiene un par de llaves. La llave pública, que se da a conocer a todos y la llave privada que conserva en secreto el dueño del par de llaves.

Es mucho más conveniente manejar la criptografía asimétrica pues por regla general una llave que se publica o que sale del control de uno, debe considerarse PUBLICA. Si hablamos de la criptografía Simetrica, la llave que tengo en mi poder y dejo que otro la vea, ya es pública para efectos prácticos, pues no puedo controlar qué haga la otra persona con esa llave. Mientras que en la criptografía Asimétrica, la llave privada siempre queda privada, mientras uno sepa dónde está y quién realmente tiene acceso a ella.

Además cuando alguien transmite un mensaje encriptado en forma asimétrica, lo hace con la llave pública del destinatario, para que así, sólo el destinatario pueda abrirlo o desencriptarlo.

Seguridad

Son 4 las metas en la transmisión de datos de manera segura, en su concepto más amplio y de acuerdo al standard RFC-4130, conocido como Applicability Statement 2 (AS2), usando HTTP:

  • Confidencialidad de Datos,
  • Integridad y/o Autenticidad,
  • No repudiación del origen de datos y
  • No repudiación del recibo de datos

Una vez más, el OpenSource en acción; el AS2 es un Standard OpenSource (como la mayoría -si no es que todos-) que de no estar alertas podemos pensar que cualquier Standard OpenSource o ISO, es una patente privada o un copyright de alguien como Microsoft.

La confidencialidad.- será posible transmitiendo los datos de manera encriptada.

La integridad.- será posible transmitiendo los datos firmados. La firma es un ensamble del certificado digital del emisor + los datos transmitidos. Si los datos son alterados, no habrá concordancia de estos con la firma, lo cual indicaría que el mensaje fue alterado durante la transmisión.

La no repudiación del origen.- lo garantiza la firma del emisor.

La no repudiación del recibo.- lo garantiza la firma del destinatario sobre el recibo enviado de regreso al emisor, más un elemento (MIC=message integrity check) que confirma que el destinatario recibió el mensaje íntegro.

Por lo cual, cuando tú o tu empresa tengan interés e intención de intercambiar información de manera segura (segura en el sentido descrito arriba), deberás incorporar algo que al final es OpenSource: certificados, firmas digitales y procesos de firmado y encriptado, pero además establecer un canal HTTP o HTTPS (hypertext transfer protocol - "S"ecured) para que la información viaje.

HTTPS

Los mensajes podrían muy bien ir por e-mail, pero más allá de razones de automatización que también son posibles en los servidores de correo, la razón principal de que no se usa el e-mail para transmisión de datos SEGUROS o AS2 -dicho en forma breve-, es que originalmente el protocolo para email y los clientes o programas de e-mail no contemplaban datos binarios, sino sólo texto. Hoy en día, prácticamente todo puede viajar por email igual que por http.

El standard AS2 usa el HTTP, que es la manera en que el Web funciona. Pero también permite el HTTPS, que en general, involucra un encriptado de datos en el servidor de origen y luego un desencriptado en la máquina de destino.

El HTTP y el HTTPS pueden hacer 2 operaciones,

  • Extraer datos (GET)
  • Enviar datos (POST)

El AS2 utiliza el POST pues los servidores envían su información y el servidor de destino responde sea vía GET o vía POST. Si responde vía GET, se dice que el recibo es síncrono y si lo hace vía POST, entonces, el recibo es asíncrono, dado que la segunda forma podría ser llevada a cabo -hablando en términos generales- horas o días más tarde, aunque usualmente se realiza en cosa de fracciones de segundo.

Bajo AS2, tampoco se acostumbra que los servidores encripten y desencripten (esto al final lo hace o no, el programa para AS2, pues el paquete enviado puede ir encriptado y firmado, que es la intención principal del criterio de seguridad de 4 elementos revisado en el apartado anterior). En tal caso, si no se va a encriptar por cuenta de los servidores, pierde sentido usar HTTPS y debería usarse HTTP que es -en general-, más rápido.

En resumen, los pasos de seguridad son más o menos laboriosos de realizar manualmente y siempre requieren de un "filtro" o programa que se encargue de interpretar una gran cantidad de factores que indican cómo debe de procesarse la información. Tales factores vienen "avisados" en los encabezados del mensaje, pero en todo caso, la manera de procesarse YA ES STANDARD y es OPEN SOURCE, lo que significa que no es un secreto o una patente privada y reservada para los que "puedan pagarla".


En la siguiente edición #9: Lenguajes para Programación


Apdo. Postal 321, C.P. 76800. San Juan del Río, Qro. México. (427)-271-2003
ESH Powered by Energia SH