1) "¿Hay algún otro elemento interno que haya omitido y que valga la pena mencionar?"
No estoy seguro de haberlo entendido correctamente, especialmente en la parte de "no valer nada", pero hay un gran cambio en el mecanismo de la caja de arena. Según una revisión en The Register , Microsoft elimina una parte del recinto de arena para las aplicaciones que se han descargado de la tienda de aplicaciones (no estoy seguro de si esto se aplica a las aplicaciones de terceros).
También, han estado pensando en expandir la API de Windows para que las aplicaciones de usuario puedan utilizar más funciones y bibliotecas. Para defender esta elección, afirman que debería ser responsabilidad de los usuarios inspeccionar la intención de las aplicaciones en lugar de bloquear las capacidades de las aplicaciones.
Finalmente, Microsoft aún está considerando si fue una buena idea unificar las plataformas o no, según el enlace anterior. Si me preguntas, estos son algunos cambios radicales. No soy un experto en el tema de UWP pero, por lo que he visto, es solo una forma de empaquetar en lugar de un esfuerzo para implementar una mayor seguridad. Un archivo .appx parece contener; un archivo de mapa de bloque ejecutable estándar que contiene hashes de archivos, una firma de aplicación y el resto de los datos, como imágenes, etc. Tal vez tomarán decisiones cada vez más radicales, como volver a la estructura anterior.
2) "¿Cómo abordaríamos las aplicaciones UWP de prueba de lápiz dirigidas a las pestañas y dispositivos de Windows 10?"
Tipos de prueba:
Depurador: Bueno, como con cualquier otra aplicación de Windows, empezaría con OllyDbg o un depurador equivalente para analizar el comportamiento. Si sabe cómo leer una salida del depurador, puede obtener mucha información rápidamente.
Fuzz Testing: De nuevo, lo mismo con la depuración, siempre es una buena opción para probar. Forzar diversos datos hacia la aplicación a través de canales de entrada puede revelar cierta información sobre la aplicación.
Ahora, para los tipos de ataque:
Inyección de DLL: Parece que también funciona con las aplicaciones UWP, pero solo si las DLL incluidas en el archivo .appx no están firmadas. Tratar de enganchar diferentes DLL maliciosos puede darle una idea del lado de la seguridad. En aquí , alguien usó este método como un juego de mod.
Escalamiento de privilegios: Aunque existe un mecanismo de caja de arena, no es una garantía de encapsulación perfecta. De hecho, la publicación en este enlace afirma que alguien ha administrado utilizar un exploit en una carga útil de 0 días para escapar del mecanismo APPCONTAINER.
Detección de entrada / salida: Supongamos que tu aplicación es segura como un castillo. Todas las DLL están firmadas, no hay ninguna vulnerabilidad en las DLL que usa o en las DLL que pertenecen al sistema. Las pruebas de fuzzing no han encontrado ni el más mínimo error. Incluso en esta situación, podría haber fallas de diseño en su aplicación que deberá considerar. ¿Su aplicación muestra información valiosa en texto claro que se puede obtener mediante una captura de pantalla? ¿Su aplicación se comunica con una fuente externa sin un cifrado? Estas preguntas en realidad no dependen del sistema UWP, pero nuevamente pueden revelar información delicada sobre la aplicación o el usuario. Su aplicación puede ser segura, pero Windows todavía usa aplicaciones Win32 junto a las UWP, por lo que debe tener cuidado con los defectos de diseño.
Eso es lo que puedo pensar ahora. Nunca he usado ninguno de estos métodos en un Windows 10 antes, ya que sería más beneficioso para un pirata informático utilizar métodos de phishing en lugar de buscar grietas en el software. Espero que ayude!