La mayoría de desarrolladores
iOS saben que
Apple confina las apps de terceros en sus sandboxes como medida de seguridad y conocen cuáles son los métodos de comunicación entre procesos, más conocido como
IPC (Inter Process Communication) o también
Inter-App Communication. Este mecanismo se basa en el manejo de
esquemas URL personalizados (Custom URL Schemes). El primer paso es registrar el esquema
URL deseado en el fichero
Info.plist, tal y como se muestra en la siguiente captura de un ejercicio de ejemplo:
 |
| Figura 1: Registrando el esquema URL deseado para una app |
Una vez hecho esto, hay que declarar el método application:handleOpenURL, para poder manejar las peticiones URL, tal y como se muestra en el siguiente ejemplo de código:
 |
| Figura 2: Ejemplo de código para manejar peticiones URL |
Este método es el encargado de recoger las peticiones URL, que cumplan con el esquema declarado en el fichero Info.plist. Es decir, si nos encontramos en Safari, y se escribe la siguiente petición URL, tal y como se aprecia en la siguientes capturas, se pasarían datos a la aplicación, que tenga declarado el esquema URL “i64URL”.
 |
| Figura 3: Escribiendo una petición URL en Safari |
Y, acorde al ejemplo de código mostrado, en el que se presenta una alerta con los datos recibidos en la petición URL, se presenta la captura de lo que ocurre:
 |
| Figura 4: App recibiendo datos a través de una petición URL |
Hasta aquí todo bien. Pero hay que tener en cuenta varias cosillas en cuanto a seguridad. La primera es, que este método va a ser "
deprecado" en cualquier momento, con lo que desde ya conviene utilizar
el siguiente método:
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
La ventaja de utilizar este método es que permite validar la aplicación de origen que instanció la petición URL. Además se podría especificar, que sólo determinadas apps puedan invocar a nuestra app. A continuación, se presenta un ejemplo, en el que se autoriza sólo a Safari:
 |
| Figura 5: Ejemplo de código autorizando a Safari para realizar peticiones URL a nuestra app |
Otro concepto básico en cuanto a seguridad sería aplicar unos buenos filtros de validación de los datos recibidos a través de la petición
URL, antes de que ésta sea procesada. En el código de ejemplo, se muestra un filtro por longitud de la petición - extraído del ejemplo
LaunchMe de la sección SampleCode de Apple Developer -, pero evidentemente habrá que aplicar una expresión regular o un filtro personalizado según la criticidad de los datos pasados, o según aplicación. Hay muchas aplicaciones que utilizan este sistema, como por ejemplo
Credit Card Terminal:
 |
| Figura 6: Web de Innerfence presentando su app Credit Card Terminal |
La
compañía declara, que por temas de seguridad, utiliza
APIs licenciadas por el
MIT, que seguramente hagan las cosas bien aunque, como siempre, habría que hacer una auditoría de la app, debido a la criticidad de sus datos. Un ejemplo de de petición
URL de esta app:
 |
| Figura 7: Petición URL de la app de Innerfence |
Innerfence tiene publicada la API para que los desarrolladores puedan integrar
Credit Card Terminal en sus apps. Si se descarga, se puede ver el código, y por ejemplo, como aplican sus expresiones regulares:
 |
| Figura 8: Expresiones regulares para filtrar datos recibidos en peticiones de URL |
Por último cabe comentar un detalle, no de seguridad, sino en cuanto a usabilidad, y que comenta
Innerfence en su blog. Es habitual, encontrar muchas apps que utilizan el sistema de esquemas
URL, y en la mayoría de los casos, cuando desde una aplicación se lanza otra, el usuario se queda
“aislado” en la otra aplicación, teniendo esto un pequeño impacto negativo, en la experiencia de usuario.
Lo ideal es que cuando una app lance a otra, una vez se haya terminado la tarea, desde la app destino, se pueda volver a la app inicial, y en el punto en que el usuario se encontraba. Para ello, Innerfence envía en la petición URL, una URL de retorno - tal como se aprecia en la figura 7 -, indicando con un parámetro, en este caso llamado record_id, a que punto de la app debe regresar. Dicha información, puede ser utilizada por la app destino, para poder realizar una nueva petición URL a la app inicial, y que le proporciona al usuario un plus en su experiencia con la app. A continuación, la petición URL, que haría la app destino, para regresar a la app origen:
 |
| Figura 9: Petición URL para volver a la app origen |
Como conclusión, se va a recapitular los puntos principales de los URL schemes:
- Hay que tener mucho cuidado al utilizarlos. No siendo conveniente utilizarlos para pasar datos sensibles o críticos, ni contraseñas - ya que para eso hay otros métodos, como el keychain -.
- No deben utilizarse para realizar cambios en las configuraciones.
Hay que utilizar el método no deprecado, que además permite validar el origen de las invocaciones.
- Es muy importante realizar una validación exhaustiva, de los datos recibidos a través de las peticiones URL, antes de que estos sean procesados.
- Tener cuidado a la hora de declarar el esquema URL, ya que si es igual al de otra app, el comportamiento es impredecible.
