Saturday, 23 December 2017

OONIPROBE: una herramienta que detecta vigilancia digital y censura en un país o red

El OONI (Open Observatory of Network Interference) es un proyecto de un  software gratis bajo “TheTor Project” que apunta a fortalecer los esfuerzos descentralizados en el aumento de la censura del internet al rededor del mundo.
Desarrollamos un software gratis y de  origen abierto, llamado ooniprobe, que puedes correrlo para examinar lo siguiente:


·         Bloqueo de sitos web
·         bloqueo de aplicaciones con mensajes instantáneos (como por ejemplo WhatsApp y Messenger de Facebook).
·         bloqueo herramientas de evasión de censura(como Tor);
·         Presencia de sistemas (“middleboxes”) en la red que puede ser la razón de la censura y/o vigilancia.
·         Velocidad y rendimiento de su red.

Al correr el software Ooniprobe, puedes recolectar data que pueda servir como evidencia de la censura del internet. ya que enseña, cómo, cuándo, dónde y quién está implementado, mencionó Jim Gil, un experto de seguridad informática de International Institute of Cyber Security (IICS).

Gracias a los miles de usuarios de Ooniprobe alrededor del mundo, millones de medidas de la red han sido recolectadas de más de 100 ciudades desde el 2012. Todas las metadata de la red son publicadas en OONI Explorer, la fuente pública acerca de la censura en internet más grande a la fecha.


OONI, (Open Observatory of Network Interference), es una red de observación global cuyo objetivo es recolectar datos de excelente calidad usando metodologías abiertas, utilizando Free y Open Source Software (FL/OSS) para compartir observaciones e información acerca de varios tipos, metros y cantidades de redes manipulando en el mundo.

OOMIPROBE es el primer programa que los usuarios utilizan para indagar su red y recolectar datos para el proyecto OONI. ¿Estás interesado en realizar pruebas en tu red para encontrar si es vigilada y censurada? ¿Quieres recolectar información para compartirla con otros, para que así todos tengan mejor entendimiento del red? Si es así, por favor lee este documento; esperamos que OONIPROBE  te ayude a reunir información de tu red y te ayude con futuros proyectos.


Lee esto antes de correr el programa de OONIPROBE

Hacer uso de este programa es una actividad con un posible riesgo. esto depende en gran manera de la jurisdicción en la que estes y que tipo de prueba quieras ejecutar. es técnicamente posible para una persona que esta observando tu conexiones a internet estar al tanto del hecho de que estas ejecutando OONIPROBE. esto significa que si este tipo de pruebas es ilegal en tu país, pueden detectarlo.

además, OONIPROBE no tiene precauciones en cuanto a la protección del análisis forense de la instalación en la máquina en la que se está instalando. si el hecho de que hayas instalado o usado OONIPROBE es una obligación, favor de estar al tanto del riesgo.

OONI en 5 minutos
La más reciente versión de OONIPROBE para Debian y Ubuntu puede ser encontrada en el repositorio de paquetes en deb.torproject.org

En Debian estable (jessie):

gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
echo 'deb http://deb.torproject.org/torproject.org jessie main' | sudo tee /etc/apt/sources.list.d/ooniprobe.list
sudo apt-get update
sudo apt-get install ooniprobe deb.torproject.org-keyring


En pruebas de Debian:
gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
echo 'deb http://deb.torproject.org/torproject.org testing main' | sudo tee /etc/apt/sources.list.d/ooniprobe.list
sudo apt-get update
sudo apt-get install ooniprobe deb.torproject.org-keyring

En Debian inestable:

gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
echo 'deb http://deb.torproject.org/torproject.org unstable main' | sudo tee /etc/apt/sources.list.d/ooniprobe.list
sudo apt-get update
sudo apt-get install ooniprobe deb.torproject.org-keyring


En Ubuntu 16.10 (yakkety), 16.04 (xenial) or 14.04 (trusty):

gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
echo 'deb http://deb.torproject.org/torproject.org $RELEASE main' | sudo tee /etc/apt/sources.list.d/ooniprobe.list
sudo apt-get update
sudo apt-get install ooniprobe deb.torproject.org-keyring

NOTA: necesitarás cambiar $RELEASE  para yakkety, xenial o trusty. Esto no pasará de manera automática. Tendrás también que asegurarte de tener el “universerepository” habilitado. El “universerepository” está habilitado por default en la instalación del Ubuntu estándar, pero puede ser que no lo esté en algunas no estándar.

Instalación

macOS
Puedes instalar OONIPROBE en macOS si tienes instalado el homebrew (http://brew.sh/) con:

brew install ooniprobe

Sistema Unix (con pip)
Asegúrate de haber instalado las siguientes dependencias:


•     build-essential
•     python (>=2.7)
•     python-dev
•     pip
•     libgeoip-dev
•     libdumbnet-dev
•     libpcap-dev
•     libssl-dev
•     libffi-dev
•     tor (>=0.2.5.1 torunallthetorrelatedtests)
Dependencias opcionales:
•     obfs4proxy


En los sistemas basados en Debian, se puede generalmente realizar al ejecutar:

sudo apt-get install -y build-essential libdumbnet-devlibpcap-devlibgeoip-devlibffi-dev python-dev python-pip tor libssl-dev obfs4proxy

En seguida podrás instalar OONIPROBE ejecutando:

sudo pip install ooniprobe

o instalar OONIPROBE como usuario:

pipinstallooniprobe

Utilizar OONIPROBE
Pruebas de red son medidas que evalúan el tipo de censura que está sucediendo en el internet.
Decksson colecciones de pruebas de red de OONIPROBE con inputs especiales.
Collectores un servicio utilizado para reportar los resultados de las mediciones.
Test Helper es un servicio utilizado por un investigador para llevar acabo exitosamente las mediciones
Bouncer es un servicio utilizado para descubrir las direcciones de los ayudantes en la prueba y los recolectores (collectors).

Configurando OONIPROBE

Después de haber instalado exitosamente OONIPROBE, debes de tener acceso al UI de la red en tu máquina principal en <http://localhost:8842/> después de ejecutar:
ooniprobe -w
o iniciando el daemon.

Se te dará la configuración wizard del UI de la red en donde podrás leer los riesGos que involucra el ejecutar OONIPROBE. Posterior a haber contestado el quiz correctamente, puedes habilitar o des-habilitar las pruebas de OONIPROBE, ajustar la conexión a las medidas del collector y finalmente configurar tus ajustes de privacidad.

Por default, OONIPROBE no incluye información de identificación personal en sus resultados de las pruebas, ni crea un archivo pcap de acuerdo a los expertos de seguridad informática de webimprints. Esto se puede personalizar.

Ejecuta OONIPROBE como un servicio (systemd)
A partir de de la versión de OONIPROBE 2.0.0 no hay necesidad de cronjobs ya que los agentes de OONIPROBE son responsables de agendar los tasks.
Puedes asegurarte de que un agente de OONIPROBE esta siempre corriendo el programa mediante la instalación y habilitación del systemdunitooniprobe.service:
wget https://raw.githubusercontent.com/TheTorProject/ooni-probe/master/scripts/systemd/ooniprobe.service --directory-prefix=/etc/systemd/system
systemctl enable ooniprobe
systemctl start ooniprobe

Debes de ver un output similar si el OONIPROBE (systemd) service está activo y descargado ejecutando el estatus de systemctlooniprobe
ooniprobe.service - ooniprobe.service, network interference detection tool
   Loaded: loaded (/etc/systemd/system/ooniprobe.service; enabled)
   Active: active (running) since Thu 2016-10-20 09:17:42 UTC; 16s ago
   Process: 311 ExecStart=/usr/local/bin/ooniprobe-agent start (code=exited, status=0/SUCCESS)
   Main PID: 390 (ooniprobe-agent)
CGroup: /system.slice/ooniprobe.service
           └─390 /usr/bin/python /usr/local/bin/ooniprobe-agent start

Instalando las capacidades en tu virtualenvpythonbinary
si tu distribución suporta capacidades puedes evitar necesitar e correr OONI como root:
setcapcap_net_admin,cap_net_raw+eip /path/to/your/virtualenv's/python2

Reporte de bugs
Puedes reportar los bugs o problemas que encuentres de seguridad informática en TheTor Project issuetracker llenando la información en el componente "Ooni"
https://trac.torproject.org/projects/tor/newticket?component=Ooni.
ya sea que registres una cuenta o uses la cuenta del grupo “cypherpunks” con la contraseña “writecode”

Establece un ambiente de desarrollo
En un sistema a base de Debian un ambiente de desarrollo se puede configurar de la siguiente manera:
(requisitos previos incluyen estructuras fundamentales python-dev, y tor; para tor ver https://www.torproject.org/docs/debian.html.en):
sudo apt-get install python-pip python-virtualenvvirtualenv
sudo apt-get install libgeoip-devlibffi-devlibdumbnet-devlibssl-devlibpcap-dev
git clone https://github.com/TheTorProject/ooni-probe
cd ooni-probe
virtualenvvenv

Virtualenvvenv creará un folder en el directorio actual que contendrá los archivos ejecutables de Python, así como una copia de la biblioteca pip que se puede utilizar para instalas otros paquetes.
Para comenzar a utilizar el ambiente virtual, éste necesita estar activado:

sourcevenv/bin/activate
pip install -r requirements.txt
pip install -r requirements-dev.txt
python setup.py install
Posteriormente puedes revisar la seguridad informáticadela instalación se realiza de manera correcta:
ooniprobe -s
Esto te explicará los riesgos de OONIPROBE y se asegurará de que los hayas entendido, después te enseñará las pruebas disponibles.
Para ejecutar la unidad de pruebas, escribe:
coveragerun $(which trial) ooni


Friday, 22 December 2017

Reglas de neutralidad de la red debilitadas por el regulador de Estados Unidos

Restricciones en la capacidad de proveedores estadounidenses de banda ancha para priorizar los datos de un servicio sobre el otro deben ser reducidas después de un voto por un regulador.

La “Federal CommunicationsCommission”, votó tres a dos para cambiar la manera en la que la “neutralidad de la red” es gobernada.

Los proveedores del servicio de internet (ISPs) no tendrán derecho de acelerar o frenar la información de compañías, y cobrar a los consumidores de acuerdo a los servicios a los que accedan; pero deben revelar dichas prácticas.



Previo al voto, protestantes se reunieron fuera del edifico de la FCC para oponerse al cambio.

Muchos discuten acerca de la inversión de reglas introducidas durante el gobierno del Presidente Barack Obama, ¿Como harán que el internet sea menos abierto y más accesible? Deacuerdo a los expertos de seguridad informática de Webimprints, la decisión está teniendo desafíos legales, con el fiscal de Nueva York, Eric Schneiderman, anunciando que el llevará a cabo una demanda en contra de la decisión de la FCC.
Mr. Schneiderman  acusó al guardián de haber fallado en investigar un posible abuso del proceso de comentario público. Dijo que al menos dos millones de personas muertas de Nueva York, fueron utilizadas sus identidades para poner comentarios en el sitio web de la FCC comentó Jim Gil, un experto de seguridad informáticade International Institute of Cyber Security (IICS)

Durante la audiencia, el comisionarlo de la FCC Mr. Michael O’Rielly respondió a esos reclamos argumentando que el staff ha podido determinar y descartar comentarios que fueran ilegítimos.

Las actas del jueves en Washington fueron paradas durante aproximadamente 15 minutos después de que una alarma de seguridad forzó una evacuación de la cámara de la FCC, un final diferente para un debate amargo y vitriólico.


El Presidente de la FCC, AjitPai, argumenta que los cambios fomentarán innovación y promoverá a que ISPs invierta en conexiones más rápidas para las personas que vivan en zonas rurales.

Él se refiere al cambio como “restaurar la libertad del Internet”.
Técnicamente, el voto fue para re clasificar la broadband de Internet como un servicio de información en lugar de telecomunicaciones.

La consecuencia es que la FCC no regulará directamente la ISPs explica Jim Gil, un experto de seguridad informáticade International Institute of Cyber Security (IICS).

En cambio, la jurisdicción pasará a otro regulador, la Federal TradeCommission (FTC). Su responsabilidad primordial será revisar que las compañías divulguen si han bloqueado información, la aceleren u ofrezcan priorizar el tráfico en lugar de detener este comportamiento.

Una de las críticas es que los consumidores estadounidenses tienen pocas o nulas opciones de ISPs para escoger.  Además, los opositores al cambio argumentan que podría tomar años cambiar esta mala conducta mencionó Jim Gil, un experto de seguridad informática de International Institute of Cyber Security (IICS)

“Disiento a esta ley de peso ligero que daña al consumidor, otorga permisos al corporativo, y destruye la libertad del Internet,” dijo el demócrata comisionado MignonClyburn antes del voto. 


Pero su colega, el comisionado Mr. O'Rielly, un republicano, dijo que el temor acerca del fin de la neutralidad de la red eran “cuentos para dormir de terror para los geeks de las telecomunicaciones.”

Wednesday, 3 August 2016

BENEFICIOS Y DESAFÍOS DE LAS PRUEBAS AUTOMATIZADAS DE SOFTWARE

La agenda de software parecen siempre “realizable” en su comienzo, pero a medida que progresan lo deslizamiento ocurren típicamente. Una razón fundamental de esto es que la prueba de software esencial, incluyendo los requisitos de prueba, no comienza de forma simultánea con el desarrollo de código. Esta situación lleva a encontrar errores SHOWSTOPPER en el código o en el diseño final del ciclo de desarrollo acuerdo empresa de pruebas automatizadas de software. Éstos toman más tiempo para rectificar que si se hubieran encontrado más tempranamente.

PRUEBA TEMPRANA Y A MENUDO, DE FORMA AUTOMÁTICA

Empujar un producto inadecuadamente con el fin de cumplir con el programa no es una opción viable, ya sea que. Una percepción de mala calidad en el mercado va a permanecer mucho más tiempo que la decepción de una versión tarde que sea de una calidad decente.
Por lo tanto, las pruebas de software a fondo es un requisito clave para cualquier proyecto de software. Se deben comenzar temprano, y para asegurar la eficacia y eficiencia, deben ser pruebas automatizadas de software tanto como sea posible.

¿QUÉ SE PUEDE AUTOMATIZAR?

La automatización puede ser aplicada eficazmente a casi todos los aspectos del proceso de QA:
§  Unit tests dentro de los desarrolladores.
§  Control de funcionamiento de los componentes de software.
§  Las pruebas de software negativas que intentan forzar errores a través de las entradas no válidas.
§  Las pruebas de software de estrés para determinar la capacidad funcional del software y la plataforma.
§  Las pruebas de rendimiento para medir el cumplimiento de los requisitos del producto.
§  Las pruebas de UI / UX o la instrumentación para determinar el uso del software.
§  Las pruebas de regresión para detectar nuevos defectos en el código existente en cada nueva construcción.
§  Generación de casos y de script de pruebas de software para mejorar la cobertura de la prueba.

BENEFICIOS DE LAS PRUEBAS AUTOMATIZADAS DE SOFTWARE

Con respecto a la agenda de software, las pruebas automatizadas tienen una ventaja fundamental: se ahorra tiempo, lo que significa que reduce el riesgo de deslizamiento de lo programado, mejora la calidad y reduce los costos de corto y largo plazo. Cuanto mayor es el esfuerzo de automatización, las mayores las ventajas que se obtienen.

MÁS RÁPIDA GENERACIÓN DE CASOS DE PRUEBA Y UNA MEJOR COBERTURA

El desarrollo de casos de prueba es a menudo un proceso que consume tiempo se hace manualmente mediante la traducción de los requisitos de diseño y de código en scripts de prueba. La mayoría de casos de prueba pueden ser generados por las herramientas que utilizan anotaciones de código, análisis de ruta de ejecución, la aleatorización de las entradas o de generación de secuencia de comandos desde la grabación de las interacciones del usuario. Todos los métodos de generación de casos de prueba aumentan la cobertura de las pruebas de software.

MEJORA DE LA FIABILIDAD Y REPETITIVIDAD

Las pruebas automatizadas de software eliminan los errores que surgen de las pruebas de software que se ejecutan manualmente, tales como omisiones intencionales o no en los pasos de prueba, que pierden errores o que producen los que en realidad no existen. Cuando se detectan errores, por el bien de los desarrolladores, deben ser confiablemente repetibles.

HABILITACIÓN DE METODOLOGÍAS AGILE

La reducción de retardo temporal a lo largo del proceso de desarrollo de software es una característica esencial de la metodología agile. Cuanto más próximo en el tiempo que pueden existir los requisitos de, diseño, codificación y las pruebas, más rápido el desarrollo iterativo podrá tener lugar. Esto conduce a una mayor eficiencia en el trabajo entre todos los equipos que participan en la producción de software.

AHORRANDO DE TIEMPO EN EL PRÓXIMO PROYECTO

La capacidad de almacenar las pruebas en scripts o un código es no sólo un ahorro de tiempo para el proyecto actual. Estos se pueden reutilizar para la próxima revisión del producto o incluso para diferentes pero similares productos realizados más tarde.

LOS RETOS DE LA AUTOMATIZACIÓN DE PRUEBAS

La automatización no es ciertamente un sustituto de las prácticas de prueba pobres dentro de la organización. No se garantiza la inexistencia de fallos ni tampoco es una garantía de una versión la calidad del producto.
Si la automatización de pruebas de software es nueva para una organización, el departamento de QA tendrá obstáculos para aclarar:
§  Las expectativas poco realistas probable que existan con respecto a cuánto tiempo se guardará en el calendario de pruebas.
§  No cuesta tiempo y dinero para analizar, adquirir, aprender, utilizar y mantener las herramientas de pruebas automatizadas de software.
§  Un nuevo nivel de experiencia puede ser necesaria dentro del equipo de QA para escribir código de automatización.
§  El software de prueba es como cualquier software, eso tiene fallos y éstos deben ser tratados.
La automatización de pruebas puede requerir cálculo adicional e infraestructura de red.
La respuesta simple en apoyo de las pruebas automatizadas de software es que se ahorra tiempo. A pesar de los costos iníciales, una vez establecido, el retorno de la inversión es rápida. El personal y los desarrolladores se vuelven más eficaces y conscientes de la calidad en un entorno en el que ambos son capaces de colaborar de manera eficiente.



Tuesday, 5 July 2016

METODOLOGÍA DE LAS PRUEBAS AUTOMATIZADAS DE LAS APLICACIONES

Los directores de proyectos de software y desarrolladores de software que crean aplicaciones de hoy en día se enfrentan al reto de hacerlo dentro de una agenda cada vez más pequeña y con recursos mínimos. Como parte de su intento de hacer más con menos, las organizaciones quieren probar el software adecuado, pero lo más rápido y detenidamente posible. Para lograr este objetivo, las organizaciones están recurriendo a las pruebas automatizadas.
Frente a esta realidad y al darse cuenta de que muchas pruebas de software no se pueden ejecutar de forma manual, como la simulación de 1.000 usuarios virtuales para las pruebas de volumen, los profesionales de software son la introducción de las pruebas automatizadas para sus proyectos. Sin embargo, estos profesionales de software no saben lo que implica en la introducción de una herramienta de prueba automatizada para un proyecto de software, y no pueden estar familiarizados con la amplitud de aplicación que las herramientas de pruebas automatizadas tienen hoy en día.

LA METODOLOGÍA DE PRUEBA AUTOMATIZADA (ATLM)/ THE AUTOMATED TEST LIFECYCLE METHODOLOGY (ATLM).

Al utilizar el enfoque sistemático descrito en el ATLM, las organizaciones pueden organizar y ejecutar las actividades de prueba de tal manera que se maximice la cobertura de la prueba dentro de los límites de los recursos de prueba de software. Esta metodología de ensayo estructurado implica un proceso de múltiples etapas, apoyando actividades detalladas e interrelacionadas que se requieren para introducir y utilizar una herramienta de prueba automatizada:
§  Desarrollar el diseño de pruebas de software.
§  Desarrollar y ejecutar los casos de pruebas de software.
§  Desarrollar y gestionar los datos de pruebas y el entorno de pruebas de software.
§  Documentar, rastrear y conseguir un archivo acerca de emisión/ informes de problemas.
Claramente, el énfasis en las pruebas automatizadas representa un cambio de paradigma para la industria del software. Este cambio no se trata simplemente de la aplicación de herramientas y el rendimiento de la automatización de pruebas. Más bien, eso envuelve todo el ciclo de vida de prueba y el ciclo de vida de desarrollo del sistema. La implementación de ATLM se lleva a cabo en paralelo con el ciclo de vida de desarrollo del sistema. Para los profesionales de software hacer un salto con éxito a las pruebas automatizadas, deben adoptar enfoques estructurados de la pruebas de software. El ATLM es revolucionario en el hecho de que se promulga un nuevo enfoque estructurado, construyendo bloques para todo el ciclo de pruebas de software, lo que permite a los profesionales de la prueba de software abordar las pruebas de software de una manera metódica y repetible.
El crecimiento de la capacidad de prueba automatizado se ha debido en gran parte a la creciente popularidad del ciclo de vida de desarrollo iterativo e incremental, una metodología de desarrollo de software que se centra en minimizar el calendario de desarrollo al tiempo que proporciona frecuencia, e incrementa construcciones de software. El objetivo de este desarrollo incremental e iterativa es involucrar al usuario y el equipo de pruebas de software en todo el diseño y el desarrollo de cada generación con el fin de perfeccionar el software; asegurando con ello que refleje más de cerca las necesidades y preferencias del usuario y resolviendo los aspectos de mayor riesgo de desarrollo en poco tiempo.

En este entorno de cambios continuos y adiciones al software a través de cada una de las versiones de software, pruebas de software, el mismo adquiere un carácter iterativo. Cada nuevo desarrollo se acompaña de un número considerable de nuevas pruebas de software, así como la reanudación de scripts de prueba existentes, al igual que existe la modificación relativa a los módulos de software publicados anteriormente. Dados los continuos cambios y adiciones a las aplicaciones de software, especialmente las aplicaciones Web, las pruebas de software automatizadas se convierten en un importante mecanismo de control para garantizar la precisión y la estabilidad del software a través de cada versión.
El ATLM, invocado para apoyar los esfuerzos de la prueba que requieren herramientas de pruebas automatizadas, e incorporan un proceso de varias etapas. La metodología es compatible con las actividades detalladas e interrelacionadas que son necesarias para decidir si adquirir una herramienta de prueba automatizada. La metodología incluye el proceso de cómo introducir y utilizar una herramienta de prueba automatizada, abarca el desarrollo de pruebas y diseño de la prueba, las direcciones de prueba de ejecución y la gestión. La metodología ATLM representa un enfoque estructurado, que representa un proceso con la cual se acerca y ejecuta la prueba. Este enfoque estructurado es necesario para ayudar a dirigir el equipo de pruebas a distancia a los errores comunes del programa de prueba:
§  Implementación del uso de una herramienta de prueba automatizada sin un proceso de pruebas de software en el lugar, lo que resulta en un no-repetible programa ad hoc y no medible programa de pruebas de software.
§  La implementación de un diseño de prueba de software sin seguir ningún estándar de diseño, lo que resulta en la creación de scripts de prueba de software que no son repetibles y por tanto no reutilizable para las creaciones incrementales de software.
§  El intento de automatizar el 100% de los requisitos de las pruebas de software, cuando los equipos de pruebas automatizadas desarrolladas internamente no son compatibles con la automatización de todas las pruebas requeridas.
§  Con la herramienta equivocada o el desarrollo de un demasiado elaborado instrumento de prueba.
§  Iniciando implementación de la herramienta de prueba demasiado tarde en el ciclo de vida de desarrollo de aplicaciones, no dejando tiempo suficiente para la configuración de la herramienta y el proceso de introducción a las herramientas de prueba (curva de aprendizaje).
El proceso de pruebas automatizadas comprende seis procesos o componentes primarios:
1.    Decisión para automatizar las pruebas
2.    Adquisición de herramienta de prueba
3.    Introducción de proceso de prueba automatizada de
4.    Planificación de prueba, Diseño y Desarrollo
5.    Ejecución y Gestión de las Pruebas.
6.    Revisión y Evaluación de Programas de Prueba.
Vamos a cubrir más acerca de estos componentes en el próximo artículo.


Thursday, 3 March 2016

Errores comunes de seguridad en el desarrollo de aplicaciones web

¿Qué errores de seguridad no deben hacer nunca durante desarrollo de aplicaciones web? Para ayudar a responder esta pregunta, estamos recopilando consejos de algunos expertos de empresa de seguridad informática y una lista de todas las cosas a continuación.


  1. Desarrollo de sus propios métodos de seguridad

    Algunos desarrolladores hacen suposición errónea de que un algoritmo de cosecha propia para el método de autenticación en realidad hará más seguro. Después de todo, los hackers nunca lo han visto antes, así que tendrían más problemas en romperlo. Esto es incorrecto.
    Desarrollar su propio método de autenticación o métodos de entrada es un error porque usted hará errores que hacker descubrirá dice James Keley, un experto de pruebas de penetración.
    ¿Por qué son las librarías existentes son más seguras? Porque se ponen a pruebas de penetración constantemente por la comunidad de seguridad. Como tales, son menos propensos a incluir grandes agujeros de seguridad que una persona pueda pasar por alto.
  2. El acceso a la base de datos directamente con la información suministrada por el usuario
Al desarrollo de aplicaciones, en particular una aplicación web muchos desarrolladores no adecuadamente validan los datos que reciben de los usuarios. Este es un problema de sanidad de datos, ya que podría invalidar toda su base de datos, pero aún tiene mayores implicaciones de seguridad. Según consultores de empresa de seguridad informática, si no validen las entradas, los ataques de cross site scripting, inyección de SQL, desbordamiento de búfer y otros ataques comunes puedan suceder. Este es uno de los errores más comunes que se encuentran en cualquier aplicación web como los hackers pueden utilizar campos de entrada para inyectar código malicioso en su aplicación y acceder base de datos. Por supuesto, la mayoría de los usuarios nunca va a intentar nada malicioso, pero hay que acercarse a la entrada de datos con una mentalidad defensiva.
  1. Centrarse en los componentes y no el sistema completo
    Con grandes proyectos de desarrollo, donde varios desarrolladores trabajan en diferentes partes de una aplicación, hay una tendencia a centrarse en los componentes individuales en lugar de en el sistema completo. Cada parte puede ser segura, pero qué tan seguras estén juntas. Por lo tanto es importante comprobar la seguridad del sistema completo.
  2. Adición de seguridad en el desarrollo final
    Adición de seguridad en la fase final de su desarrollo de aplicaciones podría ser un problema. No es algo que simplemente puede añadir al término de desarrollo. Es una función de toda la arquitectura de aplicación según experiencia de expertos de servicios de pruebas de penetración.
  3. Permitiendo a los usuarios a crear contraseñas débiles
    Cada vez los hackers hackean una aplicación web y exponen las contraseñas de usuario, una cosa inmediatamente claro que los usuarios tienen horribles hábitos respecto a la seguridad. La contraseña más popular en la mayoría de instancias es 12345. Como desarrollador de aplicaciones web, no se puede permitir que los usuarios crean contraseñas débiles.

  4. El almacenamiento de contraseñas en texto plano
    El error más común los desarrolladores de aplicaciones web es no almacenar las credenciales de autenticación de forma cifrada en bases de datos. Las credenciales de autenticación deben ser almacenados de forma cifrada según consejos de expertos de pruebas de penetración.

¿Necesita ayuda para seguridad de aplicaciones web? Póngase en contacto con Webimprints, una empresa de seguridad informática para saber cómo podemos ayudarle.