Die meisten, wenn nicht alle Mainstream-ORMs verwenden parametrisiertes SQL, das Sie vor einem direkten SQL-Injection-Angriff schützt. Durch das parametrisierte SQL auf der Anwendungsebene werden Sie jedoch nicht vor latenten SQL-Injection-Angriffen geschützt. Diese treten auf, wenn eine andere Zeile als ORM direkt Benutzereingaben in einer SQL-Anweisung verkettet (z. B. eine gespeicherte Stapelprozedur, die Benutzereingaben verkettet, um eine nicht parametrisierte dynamische Abfrage zu erstellen). Beachten Sie, dass dies überhaupt kein ORM-Problem ist, aber ich dachte, ich würde darauf hinweisen, dass parametrisiertes SQL Sie nur vor Injektionen schützt, wenn es überall verwendet wird, nicht nur im ORM.
ORMs verwenden normalerweise viel dynamisches SQL, das unsicher ist, weil es Benutzern der Anwendungs- und / oder Dienstkonten die Möglichkeit gibt, Ad-hoc-SQL-Abfragen auszuführen. Die richtige Lösung ist, dass nur Programmierer und DB-Admins DataReader / DataWriter und alle Programme, die die Datenbank berühren, verwenden, außer parametrisierte gespeicherte Prozeduren immer ohne DataReader / DataWriter-Zugriff, der dem Programm zugeordnet ist. Sie können nur auf die SPs zugreifen, von denen ich sage, dass sie es können. Nur die DB-Admins und -Programmierer sollten Ad-hoc-SQL-Abfragen ausführen können.
ORMs sind so konzipiert, dass sie in den Grundkonzepten sicher sind. Meistens müssen Sie sich keine Gedanken darüber machen, aber wenn Sie denken, dass Sie einem echten Crack ausgesetzt sind, sollten Sie ein paar individuelle Einstellungen vornehmen.
Für einfache Anwendungen, einfache SQL-Injection werden Sie decken. Kein Körper (ernsthaft, kein Körper jemals) wird Ihnen eine silberne Kugel in Sachen Sicherheit und SQL Injection geben. Das ist mein Rat.
Tags und Links entity-framework orm nhibernate sql-injection