7
votes

CsharpCodeProvider - Est-ce abusable?

excuses pour l'essoufflement de la question, mais je ne pense pas que cela nécessite beaucoup d'élaboration.

N'y utilisez aucune implication de sécurité causée par l'utilisation du CsharpCodeProvider et pourrait-il ouvrir un serveur pour attaquer?


0 commentaires

3 Réponses :


2
votes

sorte de. Sur la surface, ce n'est pas un risque direct, car vous n'êtes pas courir code, juste compiler it. Cependant, rien ne dit que le compilateur C # ne contient pas une sorte de bogue qui, compte tenu de la bonne entrée malveillante, le ferait de sauter et de commencer à exécuter des commandes directement.

Toutefois, si vous exécutez plus tard le code compilé (et vous le faites probablement - sinon pourquoi le compilez-vous pour commencer?), il fonctionnera au même contexte que vous le souhaitez. De toute évidence, cela a toutes sortes d'implications de sécurité désagréables, tout comme à l'aide de la fonctionnalité quasi-analogue eval () d'autres langues.


2 commentaires

Je ne serais jamais exécutable. L'entrée est simplement utilisée pour assurer une compilation de code. Ainsi, à part le compilateur ayant un bogue, cela signifie-t-il que c'est parfaitement sûr pour l'exemple que je viens de mentionner?


Si vous vérifiez simplement que certains code sont syntaxiquement et compile sans erreurs, je ne peux pas voir le mal.



1
votes

Cela dépend de la source que vous compilez. Si vous avez suffisamment de contrôle sur la source, cela pourrait être un risque acceptable. Si vous autorisez une personne à l'extérieur de votre code d'approvisionnement en fiducie au compilateur, cela pourrait être un risque inacceptable.


0 commentaires

5
votes

Cela dépend de la façon dont vous l'utilisez. Voici un résumé trié à partir de l'utilisation en toute sécurité à une utilisation que vous ne souhaitez certainement pas autoriser (lors de l'exécution du code sur un serveur ou un environnement que vous souhaitez contrôler):

  • si vous utilisez csharpcodeprovider pour générer un code source C #, vous n'avez besoin que d'une autorisation pour enregistrer les fichiers générés dans un répertoire ou pour noter du tout (s'il est possible d'obtenir le code généré dans un flux de mémoire)

  • Si vous l'utilisez pour compiler la source C # générée, vous avez besoin d'une autorisation pour exécuter csc.exe (qui peut ne pas être disponible dans certains environnements limités tels que des hébergements partagés). < / p>

  • Si vous ne générez que des fichiers et les compiler, il ne sera probablement pas nocif (bien que quelqu'un puisse probablement abuser de votre application pour générer de nombreux, nombreux fichiers et attaquer le serveur en utilisant une sorte d'attaque DOS.

  • Si vous chargez et exécutez également le code généré, cela dépend de la façon dont vous le générez. Si vous supposez qu'il n'y a pas de bugs dans C # / CodeDom et que vous pouvez garantir que le code généré est en sécurité, vous devez être bien.

  • Si votre code contient des objets tels que < Code> CodesNippetExpression qui peut être fournie par l'utilisateur (d'une manière ou d'une autre manière) que l'utilisateur peut écrire et exécuter tout ce qu'il veut sur votre serveur, il serait donc potentiellement assez dangereux.


2 commentaires

Faire semblant un instant Ce sera un système ouvert à quiconque, comment utiliserait-ils une codesNippetexpression pour causer des ravages? Je ne comprends pas bien comment c'est utilisé. Le code ne compilera que le code fourni avec les paramètres: générateurExecutable = False; GenerateInmemory = TRUE; et sera alors appelé avec le fournisseur.CompileAssemblyfromsource.


@GenerictyTypea: Le dernier point supposait que la chose précédente est vraie - c'est-à-dire que vous chargez et courez l'assemblage.