Y at-il moyen d'éviter l'application d'être analysé ou injecté? (C #)

Question

Il y a des tas de profileurs et code statique analyseurs là pour les ensembles C #.

Il suffit de se demander s'il y a des méthodes pour éviter d'être analysé, car il ne m'a pas fait sentir un peu nerveux lorsqu'il est dépouillé.

Je l'ai cherché partout sur Internet et stackoverflow. Il semble pas pour mon émerveillement.

Ce que j'ai ne sont que quelques titres encore plus effrayant comme ceux-ci (désolé, nouvel utilisateur ne peut pas poster des liens hyper, s'il vous plaît les google):

"Manipulation Assemblée et C # / code VB.NET Injection"

"Comment Injecter une Managed .NET Assembly (DLL) dans un autre processus"

Est-ce juste moi d'être trop inquiet ou quoi?

BTW, avec C #, nous construisons un nouveau client WinForm pour les clients d'une banque d'effectuer des transactions en ligne. Devrions-nous pas le faire de la manière Winform ou devrions-nous utiliser une autre langue comme Delphi, C ++? À l'heure actuelle, nous avons un client WinForm construit avec C ++ Builder.

Answer 1

Juste au sujet de toute application peut être « analysée et injecté ». Certains plus que d'autres. Voilà pourquoi vous ne faites jamais confiance l'entrée utilisateur. Vous validez pleinement les demandes de vos utilisateurs sur la fin du serveur, en vous assurant que vous n'êtes pas vulnérable à des dépassements de tampon, injection sql et d'autres vecteurs d'attaque.

Obfuscators peuvent faire des assemblages .NET plus difficiles à analyser. En utilisant une clé sécurisée pour nom fort vos assemblées peuvent le rendre beaucoup plus difficile de modifier votre code. Mais, comme tout le reste dans le monde numérique, quelqu'un peut exploiter une vulnérabilité et de contourner ce que les garanties que vous mettez en place.

Answer 2

Si par une analyse que vous voulez dire quelqu'un décompilation du code et regardant, puis le Dotfucstor livré avec VS Pro et au-dessus est un outil simple (gratuit) pour aider ici. Il y a une fonctionnalité plus complète (mais payé) version qui peut faire plus.

Pour éviter que quelqu'un trifouiller votre assmebliles déployées, utilisez Les noms forts .

Answer 3

Là où il y a une volonté, il y a un moyen, que ce soit le code managé ou assembleur natif. La clé est de garder les informations importantes sur la fin du serveur et de maintenir le contrôle de cela.

Answer 4

La première chose que vous devez décider contre ce que vous essayez de protéger? Obfuscators ne sont utiles que pour protéger les algorithmes de « sauce secrète », mais l'attaquant peut simplement extraire le code et l'utiliser comme boîte noire. Dans 99% des cas sont obfuscators gaspillage d'argent. Si l'attaquant a un accès physique il n'y a pas grand-chose que vous pouvez faire.

Answer 5

Si l'utilisateur final est en cours d'exécution avec des privilèges administratifs alors ils seront en mesure de joindre un débogueur et modifier votre code, y compris les détails du compte cible. Ma banque amicale locale m'a donné un lecteur de puce avec NIP que je dois entrer dans les derniers chiffres n du compte cible, qu'il hash / avec encrypte de ma carte bancaire à puce; puis-je entrer le code de l'appareil dans l'application Web de la banque qui peut vérifier à la fin de la banque ainsi. Ce pallie "man in the middle" attaques de type ...

Answer 6

La sécurité est uniquement possible sur les systèmes que vous contrôlez physiquement l'accès à, et même alors pas garanti, seulement réalisable. Vous devez prendre tout code ne pas exécuter sur un système que vous contrôlez peut et sera compromise. Comme Rowland Shaw a déclaré, le meilleur pari pour une institution financière est une sorte de jeton physique qui ajoute effectivement une composante hors ligne unique pour toutes les transactions qui ne peuvent pas être (facilement) connues à l'avance par un attaquant d'exploitation d'un système compromis. Même alors, vous devez être conscient du fait que si l'ordinateur des utilisateurs a été compromise et il se connecte avec son jeton sécurisé à partir de ce moment jusqu'à ce que la session se termine l'attaquant est libre d'effectuer toutes les actions que l'utilisateur a l'autorisation, mais au moins dans ce cas, l'utilisateur est plus susceptible de remarquer l'activité frauduleuse.