Pour la plupart, vous avez raison. Les applications avec un système de type sécurisé (pas seulement .NET ou Java) ne permettent pas à l'application de violer ces contraintes.
Des débordements de tampon et de nombreuses autres failles de code à distance se produisent car les contraintes dans ces langages et runtimes ne fournissent aucune vérification et ne peuvent pas garantir que le programme n'exécutera pas de code arbitraire en mémoire. Les systèmes sécurisés vérifient que le code est exempt de ces effets.
(Comme une note de côté, C# peut encore effectuer des actions dangereuses et se mettre en place pour exécuter du code arbitraire. Il est juste assez lourd et peu susceptible d'être utilisé dans une application réelle.)
Les trous de sécurité que vous verriez dans un navigateur géré serait si il a laissé le code arbitraire être chargé, en utilisant le CLR comme un environnement sûr. Bien que le code généré par CLR (c'est-à-dire le code JIT de votre application) soit sûr, le chargeur et le vérificateur sont généralement écrits dans une langue inférieure. Il y a eu quelques trous de sécurité (je pense 2 pour .NET?) Où un assembly mal formé pourrait forcer le CLR réel à exécuter du code arbitraire. Cependant, ce sont des problèmes relativement rares, et la superficie est bien inférieure à ce qu'elle serait autrement. Donc, oui, un navigateur entièrement sécurisé, géré lui-même ne serait pas la proie de ces exploits spécifiques. Mais cela signifie également que vous devriez avoir vos plugins écrits et exécutés de la même manière (Flash?). Enfin, il existe d'autres failles de sécurité qui peuvent être ciblées, mais elles seront généralement moins sévères que celles que vous obtiendriez avec une application non gérée. Les scripts inter-sites, par exemple, resteraient toujours un problème. Mais au moins vous n'auriez pas de problèmes de type "voir un document peut exécuter un code arbitraire".