1) "Ci sono altri elementi interni che ho perso e che vale la pena notare."
Non sono sicuro di aver capito bene, specialmente nella parte "non vale niente", ma c'è un grande cambiamento nel meccanismo di sandboxing. Secondo una recensione su The Register , Microsoft rimuove una parte della sandboxing per le applicazioni che sono stati scaricati da Application Store (non sono sicuro se questo si applica alle applicazioni di terze parti).
Inoltre, hanno pensato di espandere l'API di Windows in modo che più applicazioni e librerie siano utilizzabili dalle applicazioni utente. Per difendere questa scelta, affermano che dovrebbe essere responsabilità degli utenti ispezionare l'intento delle applicazioni piuttosto che bloccare le funzionalità delle applicazioni.
Infine, Microsoft sta ancora valutando se fosse una buona idea unificare le piattaforme o meno, secondo il link sopra. Se me lo chiedi, questi sono alcuni cambiamenti radicali. Non sono un esperto del tema UWP ma, per quanto ho visto, è solo un modo di confezionare, piuttosto che uno sforzo per implementare una maggiore sicurezza. Un file .appx sembra contenere; un file eseguibile standard, un file di mappa a blocchi che contiene hash di file, una firma di app e il resto dei dati come immagini e così via. Forse prenderanno presto decisioni sempre più radicali, come il ritorno alla vecchia struttura.
2) "Come dovremmo affrontare le app UWP con test delle penne indirizzate alle schede e ai dispositivi Windows 10."
Tipi di test:
-
Debugger: Bene, come con qualsiasi altra applicazione Windows, inizierei con OllyDbg o un debugger equivalente per analizzare il comportamento. Se sai come leggere un output del debugger, puoi ottenere rapidamente molte informazioni.
-
Test Fuzz: Sempre con il debug, sempre una buona scelta da provare. Forzare vari dati verso l'applicazione attraverso i canali di input può rivelare alcune informazioni sull'applicazione.
Ora, per i tipi di attacco:
-
Iniezione DLL: Sembra che funzioni anche con le applicazioni UWP ma solo se le DLL incluse in .appx non sono firmate. Cercando di collegare diverse DLL dannose potrebbe darti un'idea della sicurezza. In qui , in realtà qualcuno ha usato questo metodo come mod di gioco.
-
Escalation di privilegi: Sebbene esista un meccanismo di sandbox, non è una garanzia per l'incapsulamento perfetto. In effetti, il post in questo link afferma che qualcuno ha gestito utilizzare un exploit in un payload di 0 giorni per sfuggire al meccanismo di APPCONTAINER.
-
Sniffer input / output: Supponiamo che la tua applicazione sia protetta come un castello. Tutte le DLL sono firmate, non ci sono exploit nelle DLL che si usano o nelle DLL che appartengono al sistema. I test di fuzzing non hanno riscontrato nemmeno un bug. Anche in questa situazione, potrebbero esserci dei difetti di progettazione nella tua applicazione che dovrai considerare. La tua applicazione mostra informazioni preziose in testo chiaro che possono essere ottenute da uno screenshot? La tua applicazione comunica con una fonte esterna senza una crittografia? Queste domande in realtà non dipendono dal sistema UWP, ma possono rivelare informazioni delicate sull'applicazione o sull'utente. La tua applicazione può essere protetta ma Windows utilizza ancora applicazioni Win32 accanto a quelle UWP, quindi devi stare attento ai difetti di progettazione.
Questo è ciò a cui riesco a pensare ora. Non ho mai usato nessuno di questi metodi su un Windows 10 prima dato che sarebbe più vantaggioso per un hacker utilizzare i metodi di phishing piuttosto che cercare le crepe nel software. Spero che ti aiuti!