Trop souvent, une base de donnée contient des données avec des caractères blancs complètement inutiles. Par exemple un nom, au lieu de “Gabriel” on se retrouve avec “Gabriel “ ou “ Gabriel”. C’est très facile pallier à ce problème en effectuant un .Trim() tout bête juste avant la persistance des données. Cependant, ça devient vite facile de l’oublier.
C’est pourquoi un custom model binder peut pallier à cette problématique très rapidemment, et ce pour l’ensemble de l’application.
Finalement, il suffit d’aller ajouter le code suivant dans votre Startup.cs pour ajouter votre model binder à la liste des ModelBinderProviders du framework. Je le place à la première position, car je veux qu’il soit éxécuté le plus rapidemment possible.
Dans le cadre d’un projet d’amélioration de la sécurité d’une application, j’ai du notamment passer l’ensemble des champs VARCHAR d’une base de donnée vers NVARCHAR. La raison est bien simple: protéger le contenu des injections XSS.
Il faut en outre que:
Le caractère “>” devienne “>”
Le caractère “<” devienne “<”
Le caractère ” devienne "
Pour ce faire, il suffit de générer une série d’instructions “ALTER TABLE” à partir de cette requête SQL:
Finalement, ce n’est qu’une partie des éléments à mettre en place pour sécuriser une application convenablement d’une possible faille XSS.
Les applications .NET Core agissent différemment des applications traditionnelles ASP .NET sur la stack Windows / IIS. En effet, l’application lorsque démarée, procède à des locks sur l’ensemble des fichiers utilisés.
J’entends par là:
les .DLL
Les .EXE
Les fichiers de logs
Cela rend donc impossible le déploiement. Si vous essayez, vous aurez sans doute cette problématique:
Pour résoudre le problème, il faut créer un fichier “before-deploy.ps1” directement dans le root du projet Web et mettre le code suivant:
Pas de craintes, Restart-WebAppPool termine les requêtes courantes avant de redémarrer l’application pool.
Finalement, ne surtout pas oublier de l’inclure dans votre project.json: