En ce qui concerne le Web, C# (et plus généralement ASP.NET) est généralement vulnérable aux éléments suivants (énumérés par ordre alphabétique) OWASP Top 10 2013 ). Je me rends compte que vous étiez principalement intéressé par les fonctions d'évier, dont je couvre certaines, mais vous avez demandé comment les gens font accidentellement du code C# dangereux, alors j'espère que j'ai fourni un aperçu ici.
Injection d'A1
Injection SQL
Génération de requêtes par concaténation de chaînes de caractères.
var sql = "SELECT * FROM UserAccount WHERE Username = '" + username "'";
SqlCommand command = new SqlCommand(sql , connection);
SqlDataReader reader = command.ExecuteReader();
Ce problème peut souvent être résolu en les requêtes paramétrées mais si vous utilisez un IN le conditionner actuellement, ce n'est pas possible sans concaténation de chaînes de caractères.
Injection LDAP
Un code tel que
searcher.Filter = string.Format("(sAMAccountName={1})", loginName);
peut rendre l'application vulnérable. Plus d'informations aquí .
Injection de commande OS
Ce code est vulnérable à l'injection de commandes car le deuxième paramètre de la commande Process.Start peut se voir passer des commandes supplémentaires à l'aide de l'option & caractère pour grouper plusieurs commandes
string strCmdText= @"/C dir c:\files\" + Request.QueryString["dir"];
ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText);
Process.Start(info);
par exemple foldername && ipconfig
A2-Bris d'authentification et de gestion de session
Se déconnecter
L'authentification par défaut des formulaires SignOut ne met rien à jour côté serveur, ce qui permet de continuer à utiliser un jeton d'authentification capturé.
L'appel de la méthode SignOut supprime uniquement le cookie d'authentification des formulaires. Le serveur Web ne stocke pas les tickets d'authentification valides et expirés pour une comparaison ultérieure. Cela rend votre site vulnérable à une attaque par rejeu si un utilisateur malveillant obtient un cookie d'authentification de formulaires valide.
Utilisation de l'état de la session pour l'authentification
A fixation de la session La vulnérabilité pourrait être présente si un utilisateur a utilisé état de la session pour l'authentification .
A3-Scripting intersite (XSS)
Response.Write (et le raccourci <%= => ) vulnérables par défaut, à moins que le développeur n'ait pensé à coder le résultat en HTML. Le raccourci plus récent <%: Le code HTML est codé par défaut, mais certains développeurs peuvent l'utiliser pour insérer des valeurs dans le JavaScript où elles peuvent encore être échappées par un attaquant. Même en utilisant la version moderne de Moteur de rasoir il est difficile de bien faire les choses :
var name = '@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';
ASP.NET permet par défaut Validation de la demande qui bloque toute entrée provenant des cookies, de la chaîne de requête et des données POST potentiellement malveillantes (par exemple, les balises HTML). Cela semble bien fonctionner avec les entrées provenant de l'application en question, mais si le contenu de la base de données est inséré à partir d'autres sources, par exemple à partir d'une application écrite à l'aide d'autres technologies, il est possible qu'un code script malveillant puisse tout de même être émis.
Dans les anciennes versions de .NET, c'était un peu une champ de mines pour un développeur de s'assurer que sa production était correctement encodée en utilisant certains des contrôles web par défaut.
Malheureusement, la syntaxe de liaison de données ne contient pas encore de syntaxe d'encodage intégrée ; elle sera disponible dans la prochaine version d'ASP.NET.
par exemple, non vulnérable :
<asp:Repeater ID="Repeater1" runat="server">
<ItemTemplate>
<asp:TextBox ID="txtYourField" Text='<%# Bind("YourField") %>'
runat="server"></asp:TextBox>
</ItemTemplate>
</asp:Repeater>
vulnérables :
<asp:Repeater ID="Repeater2" runat="server">
<ItemTemplate>
<%# Eval("YourField") %>
</ItemTemplate>
</asp:Repeater>
A4-Références directes à des objets non sécurisés
La liaison de modèle MVC peut permettre paramètres ajoutés aux données POST à mettre en correspondance avec le modèle de données. Cela peut être involontaire, car le développeur n'a pas réalisé qu'un utilisateur malveillant pouvait modifier les paramètres de cette manière. Le site Bind peut être utilisé pour empêcher cela .
A5-Mauvaise configuration de la sécurité
Il existe de nombreuses options de configuration qui peuvent affaiblir la sécurité d'une application. Par exemple, la configuration customErrors a On ou en activant la trace.
Les scanners tels que ASafaWeb peut vérifier ces erreurs de configuration courantes.
A6-Exposition des données sensibles
Hachage par défaut
Les méthodes de hachage de mot de passe par défaut dans ASP.NET ne sont parfois pas les meilleures.
A7-Contrôle d'accès au niveau des fonctions manquantes
Absence de restriction de l'accès aux URL
En mode pipeline intégré, .NET peut voir chaque demande et les gestionnaires peuvent autoriser chaque demande, même vers des ressources qui ne sont pas .NET (par ex. .js et des images). Cependant, si l'application s'exécute en mode classique, .NET ne voit que les requêtes de fichiers tels que .aspx donc d'autres fichiers peuvent être accidentellement non sécurisés. Voir cette réponse pour plus de détails sur les différences.
par exemple www.example.com/images/private_photograph_user1.jpg est plus susceptible d'être vulnérable dans une application qui s'exécute en mode classique, bien qu'il y ait des solutions de contournement .
A8-Forces de requêtes intersites (CSRF)
Bien que les applications de formulaires Web traditionnelles soient généralement plus sûres contre CSRF, car elles obligent l'attaquant à falsifier l'état de la vue et l'adresse de l'utilisateur. Validation des événements les applications MVC les plus récentes peuvent être vulnérables, à moins que le développeur n'ait implémenté manuellement les valeurs suivantes jetons anti-falsification . Notez que je ne dis pas que les formulaires web ne sont pas vulnérables, mais que c'est plus difficile que de simplement passer quelques paramètres de base - il y a cependant des solutions, telles que intégrer la clé utilisateur dans la valeur View State.
Lorsque la propriété EnableEventValidation est définie sur true, ASP.NET valide qu'un événement de contrôle provient de l'interface utilisateur qui a été rendue par ce contrôle. Un contrôle enregistre ses événements pendant le rendu, puis valide les événements pendant le traitement du postback ou du callback. Par exemple, si un contrôle de liste comprend des options numérotées 1, 2 ou 3 lors du rendu de la page, et si une demande de postback est reçue en spécifiant l'option numéro 4, ASP.NET lève une exception. Tous les contrôles événementiels d'ASP.NET utilisent cette fonctionnalité par défaut.
La fonction [EnableEventValidation] réduit le risque de requêtes et de callbacks postback non autorisés ou malveillants. Il est fortement recommandé de ne pas désactiver la validation des événements.
A10-Non validé - Réacheminements et renvois
L'ajout d'un code tel que
Response.Redirect(Request.QueryString["Url"]);
rendra votre site vulnérable. L'attaque peut être lancée par l'envoi à un utilisateur d'un courriel de phishing contenant un lien. Si l'utilisateur est vigilant, il peut avoir vérifié le domaine de l'URL avant de cliquer. Cependant, comme le domaine correspond à votre domaine auquel l'utilisateur fait confiance, il cliquera sur le lien sans savoir que la page redirigera l'utilisateur vers le domaine de l'attaquant.
La validation doit avoir lieu sur Url pour s'assurer qu'il s'agit d'une URL relative autorisée ou d'une URL absolue vers l'un de vos domaines et pages autorisés. Vous voudrez peut-être vérifier que quelqu'un ne redirige pas vos utilisateurs vers /Logout.aspx par exemple. Bien que rien n'empêche un attaquant de créer directement un lien vers http://www.example.com/Logout.aspx ils pourraient utiliser la redirection pour masquer l'URL afin qu'il soit plus difficile pour un utilisateur de comprendre quelle page est consultée ( http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78 ).
Autres
Les autres catégories de l'OWASP sont :
- A9-Utilisation de composants présentant des vulnérabilités connues
dont aucune ne me vient à l'esprit qui soit spécifique à C#/ASP.NET. Je mettrai à jour ma réponse si j'en trouve (si vous pensez qu'elles sont pertinentes pour votre question).
