5 premiers conseils pour créer des applications sécurisées (Web)

Développer dans un souci de sécurité signifie également que vous devez tenir compte de la manière dont l'application gérera sa sécurité dès le début. -aller. Cela inclut les services d'authentification et d'autorisation, le contrôle d'accès, la liste blanche, la communication entre les projets de la même solution (ou à partir d'autres solutions / fournisseurs), etc. Ne laissez pas cela pour plus tard, cela doit être clair dès le début, pour que tous les éléments de votre application la traitent correctement.

Ne vous y méprenez pas, cela s'applique également aux applications intranet qui ne sont pas disponibles pour le grand public, pas seulement.

Astuce 3 – Surveillez les bases de données CVE

Une recherche en ligne rapide pour quelque chose comme la «vulnérabilité [ ]» vous donnera une liste et des liens vers ces bases de données, vous permettant ainsi de ne pas prendre beaucoup de temps.

Occasionnellement, vous pouvez jeter un coup d’œil aux bases de données sur les vulnérabilités pour voir s’il ya quelque chose qui vous concerne. Certains vous permettent même de créer des flux et de surveiller certaines catégories (par exemple, nvd.nist.gov et cvedetails.com ). Voici également une liste de fournisseurs pour les produits Telerik .

Astuce 4 – Utilisez les dernières versions des packages dont vous dépendez

Je l’ai mentionné ci-dessus, mais je vais répéter les vulnérabilités et les problèmes rencontrés. tout le temps, partout. La manière générale de les réparer est “dans la dernière version” du package / outil correspondant.

Essayez donc de vous tenir au courant des logiciels utilisés par votre application. Il peut s’agir de frameworks (si vous êtes toujours sur .NET 3.5 ou 4.0 – je vous regarde), de packages génériques (tels que la récupération de jQuery ou de Newtonsoft.Json de NuGet) ou d’autres logiciels de fournisseurs comme nous.

La mise à jour vous fournira également de nouvelles fonctionnalités, d’autres corrections et améliorations, et pas seulement une sécurité accrue.

En outre, plus vous mettez à jour souvent, plus ce sera facile. Les vendeurs s’efforcent généralement d’éviter les changements brusques (je sais que nous le faisons), et même quand ils se produisent, ils se produisent assez rarement. Il est préférable de frapper un changement de temps en temps plutôt que d'en frapper cinq à la fois lorsque vous mettez enfin à jour quelque chose d'écrit en 2011. Vous devrez peut-être également envisager d'autres changements de paradigme dans les cadres et les technologies.

Voici également notre guide lors de la mise à niveau de votre interface utilisateur Telerik pour les contrôles ASP.NET AJAX qui indique également comment contrôler les modifications et les outils que nous fournissons, il est donc facile pour vous de maintenir à jour vos bits Telerik.

Astuce 5 – Demander Vos vendeurs

Cela rejoint le point précédent, mais je voulais le garder séparé pour deux raisons.

Raison n ° 1 : Si le vendeur ne le sait pas, cela leur fera au moins réfléchir au concept. Peut-être devraient-ils également adopter certaines meilleures pratiques de sécurité dans leur SDLC, qui sait. Pour ma part, je ne sais pas si vous souhaitez continuer à travailler avec un fournisseur peu soucieux de la sécurité.

Reason 2 : Il est parfois plus facile de demander que de parcourir les ressources en ligne. . La réponse la plus courante est que "la dernière version ne contient pas de vulnérabilités connues", ce qui devrait vous inciter à le mettre à jour.

L'un des éléments clés du paragraphe précédent est le mot "connus". Dites que ce que vous ne savez pas ne peut pas vous faire de mal, mais avec la sécurité, ce n'est pas vraiment le cas. C’est aussi la raison pour laquelle les anciennes versions de logiciels contiennent souvent des vulnérabilités – certaines choses, approches ou codes jugés acceptables au moment de leur rédaction, ne sont plus assez bons et des informations à ce sujet peuvent être découvertes même des années plus tard. [19659004] Par exemple, nous venons de mettre à jour les informations ici pour refléter les nouvelles découvertes, bien que nous ayons corrigé la vulnérabilité d'origine il y a deux ans et demi, et que ces nouvelles découvertes n'affectent pas les versions ultérieures. Pour réitérer l’avis original que nous avions envoyé à l’époque (et ce que j’ai dit dans cet article), la meilleure solution consiste à mettre à niveau vers la version la plus récente (au moment de votre lecture, pas au moment de l’écriture), qui contient encore plus d'améliorations de la sécurité .

Raison 3 : Que faire si vous trouvez une vulnérabilité dans le produit d'un fournisseur qui n'est pas répertoriée en ligne? Peut-être l'avez-vous trouvé en travaillant avec le produit, ou un audit de sécurité / des tests d'intrusion sur votre application l'ont révélé. Dans tous les cas, vous devriez contacter votre fournisseur en privé, car ce sont les seules personnes qui peuvent le réparer, mais ils ne peuvent pas le faire s'ils ne le savent pas.

Une pratique courante pour traiter de tels rapports en Les éditeurs de logiciels sont qualifiés de «divulgation responsable». Les informations relatives à une vulnérabilité ne seront publiées que lorsque le fournisseur aura publié un correctif pour le problème. Cela se produit généralement dans une nouvelle version, mais cela peut varier en fonction du modèle de distribution du produit – par exemple, un système d'exploitation ou un produit massif de bout en bout envoie souvent des correctifs (souvent pour la dernière version uniquement), tandis que De plus petits produits (tels que les paquets NuGet ou les fournisseurs de composants comme nous) publient généralement de nouvelles versions.

Le choix du contenu d'une information devient une question de votre propre discrétion, et vous pouvez faire toute une différence entre donner aux autres développeurs suffisamment d'informations pour la protéger, et en fournissant trop pour que les chapeaux noirs ou même les script kiddies puissent exploiter les problèmes. Ma conviction personnelle est qu’il faut connaître le vecteur d’attaque et ses implications pour que les développeurs puissent comprendre la situation et déterminer s’ils sont affectés, mais les détails de l’exploit ne devraient pas être publics.

Et si vous trouviez une vulnérabilité dans un produit Telerik? Ouvrez avec nous un ticket d'assistance pour le produit concerné afin que nous puissions discuter de la situation. Si vous n'avez pas d'abonnement actif, ouvrez un ticket générique choisissez la catégorie Produits et ajoutez des informations sur la suite de composants dont il s'agit. Si vous êtes testeur de pénétration et que vous n’avez pas de compte chez nous, vous pouvez en créer un gratuitement . Notre système de billetterie est privé et sécurisé et convient à une communication aussi sensible.

En résumé

La communication sur la sécurité va dans les deux sens et, en participant, vous contribuez à améliorer le monde pour tous. Si vous avez quelque chose à ajouter (même de «petites» choses telles que des cours en ligne ou des articles que vous avez aimés), mettez-le dans les commentaires ci-dessous et aidez vos collègues développeurs à créer des applications sécurisées.