Injection sicher Aufruf IAxaptaRecord.ExecuteStmt()

Gibt es eine Injektion sichere Weise über das axpata Business Connector zu nennenInjection sicher Aufruf IAxaptaRecord.ExecuteStmt()

string salesId = someObject.Text; 

IAxaptaRecord salesLine = ax.CreateRecord("SalesLine"); 
salesLine.ExecuteStmt("select * from %1 where %1.SalesId == '" + salesId + "'");

Wenn someObject.Text der folgenden gesetzt ist, bin ich dann anfällig für x ++ Code-Injektion :

"SomeSalesOrder' || %1.SalesId == 'SomeOtherOrder"

gibt es eine Möglichkeit, die Abfrage zu parametrisieren, oder wäre es besser, alle Daten, Zugangscode zu schreiben direkt in x ++, und rufen sie dann die von COM?

Quelle

2009-05-18 holz

Es gibt keine Möglichkeit, sicherzustellen, dass Sie auf alle Fälle abgedeckt haben ...

ExecuteStmt Verwendung ist höchstwahrscheinlich der falsche Ansatz. Sie sollten Ihre Auswahl oder was auch immer in einer Axapta-Methode (mit Parametern) schreiben und dann diese Methode aufrufen.

Quelle

2009-05-18 07:13:32

Da Sie keine Literale verwenden, ist das Standardverhalten für einfache Abfragen die Verwendung von Platzhaltern (parametrisierten Abfragen), was als sicher gilt. Für komplexe Abfragen (Joins) kann nur der ForcePlaceholders-Hinweis in Joins verwendet werden. –

-2

Sie sollten einen Austausch auf ' z.

string salesId = someObject.Text.Replace("'", "\\'");

Quelle

2009-05-18 04:14:14

ich für eine Parametrisierung Methode Rahmen behandelt Suche alle Kanten Fälle zu behandeln, nicht nur das Beispiel, das ich – holz

gab Sie könnten eine Erweiterungsmethode für IAxaptaRecord erstellen, die so etwas wie ‚ExecuteParametizedStmt ist (String-Abfrage, Parameter Objekt []) Dies würde die Abfrage in einem Format von String.Format akzeptieren und es auf diese Weise erstellen, nach der erforderlichen Arbeit an den Variablen (z. B. Escaping) –

Das ganze Problem behandelt Escaping korrekt. Wenn die Abfrage "Select * from% 1.Id == {0}" war (wobei {0} ein int sein sollte) und dann "42 || 1 == 1" übergeben wird, wird die Injektion immer noch nach I erfolgen sind mit der Methode, die Sie angegeben haben, entkommen. Ich kenne nicht alle Randfälle von x ++ Injektion, also möchte ich nicht meine eigene Escaping-Methode schreiben. Denn wenn ich es tue, würde ich wahrscheinlich etwas verpassen und ich würde es erst erfahren, wenn es zu spät ist. Dies ist für eine öffentliche Web-App mit vielen vertraulichen Informationen, so dass ich 100% sein muss, dass kein Risiko einer Injektion besteht. – holz

-2

Holz,

können Sie verwenden parametrisierte mit dem forcePlaceholder Schlüsselwort-Anweisungen SELECT. Dies ist das Standardverhalten in X ++. Da dieses Verhalten jedoch für komplexe Joins überschrieben werden kann, empfiehlt es sich, den forcePlaceholder-Hinweis implizit anzugeben.

Da parametrisierte SELECTs zusätzlichen Overhead verursachen und keine Optimierung der tatsächlichen Werte der Parameter zulassen, sollten Sie stattdessen Views oder Axapta-Abfragen in Betracht ziehen.

Grüße, Velislav Marinov

Quelle

2009-05-18 20:36:33

'forceplaceholders' lösen das in der Frage angegebene Problem nicht. Die Verwendung von Literalen in X ++ als Werte stellt kein Problem dar, da Werte vom Kernel angegeben werden. –

Sie liegen falsch. ForcePlaceholders erstellt parametrisierte Abfragen, während ForceLiterals für SQL-Injection anfällig ist. Überprüfen Sie das Sicherheits-Whitepaper von MS. –

Sicherheits-Whitepaper: http://download.microsoft.com/download/b/6/e/b6e77418-cde2-4ed4-a920-60d7f2d17757/Microsoft%20Dynamics%20AX%20Writing%20Secure%20X++%20Code.doc Die Frage war die Verwendung von direktem SQL über den Business Connector, was eine schlechte Sache ist. Die 'forceliterals' /' forceplaceholders' ist ein anderes Thema. Forceliteral ist ein Problem, wenn das Kernel-Quoting umgangen werden kann, was schwer zu widerlegen ist. –

Injection sicher Aufruf IAxaptaRecord.ExecuteStmt()

Antwort

Verwandte Themen