Discussion :

[Dokare]

Bonjour...

J'utilise l'Entity Framework avec une base de données locale Slq Server et une application en C#.
Je souhaite, dans un proche futur, migrer cette base sur un serveur extérieur.

Je lis un tas de choses concernant la sécurité et les attaques sur les bases de données et je commence à m'y perdre.
Est-il nécessaire de passer par un service Web, Json ou REST (et je ne sais quoi d'autres) pour écrire et lire les données ou l'EF suffit-il largement ? En terme de sécurité j'entends...

Question simple...

Merci pour vos réponses...

Cdlt

[Romka]

Salut,

en termes de sécurité pure, ajouter une couche exprès pour ça peut au contraire ajouter de nouvelles failles.
C'est assez vaste comme sujet. Si tu parles d'SQL Injection, tu t'interdis d'utiliser des requêtes directes en mode text où tu parserais des champs à la main et en principe c'est bon.
Après la sécurité de tes données implique beaucoup de choses qui n'ont rien à voir avec leur stockage proprement dit (CSS, vol de session, forgery de formulaires...)
C'est un tout. SI tu suis les "good practices" des technos que tu utilises, et que tu ne fais de trop "exotique", en égénral tu as au final une sécurité "standard" (c'est-à-dire une bonne sécurité).
Et il n'y a pas qu'au niveau de la prog que ça se joue. Je pense à un projet que je viens de terminer, pour lequel j'étais audité au niveau sécurité, tout était blindé et j'ai failli tomber en syncope quand le client a envoyé les credentials administrateur du serveur web par mail, cerise sur le gâteau avec 12 personnes en copie...

[Dokare]

Bonjour...

Donc si j'ai bien compris, on va favoriser les procédures stockées de la base de données pour éviter le SQL Injection...
On limite l'application pour la lecture et/ou l'envoi d'informations mais pas le traitement et le contrôle (enfin, je me comprend ).

Merci pour ce retour... Et bonne journée

[Romka]

Oui, les procédures stockées sont pas mal pour ça (elles ont aussi leur travers, par ex. il faut éviter de mettre de la logique métier dans ta bdd, etc.).
Avec EF les paramètres dans les requêtes sont échappés, donc en théorie pas d'SQL injection directe.
Souvent les failles viennent d'ailleurs dans la solution. A chaque projet c'est différent. Qu'est-ce que la sécurité pour mon projet ? Parfois il s'agit de limiter l'accès en lecture par compte utilisateur, parfois c'est d'interdire la modification, etc.

Merci, bonne journée également