Laden...

MSSQL: Parameter validieren

Erstellt von peterfarge vor 9 Jahren Letzter Beitrag vor 9 Jahren 1.551 Views
P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren
MSSQL: Parameter validieren

Hallo Forum,

ich möchte in C# SQL Parameter bereinigen, ohne sie auf irgendein Datenbanksystem loszuschicken. Kann ich da bereits vorhandene Klassen verwenden oder muß ich selber basteln?

Vielen Dank

Peter

T
314 Beiträge seit 2013
vor 9 Jahren

Also ich verstehe deine Frage nicht.

Hast Du ein Statement mit Parametern und willst nicht alle davon nutzen?

2.207 Beiträge seit 2011
vor 9 Jahren

Hallo peterfarge und willkommen im Forum,

was meinst du mit "bereinigen"?

Gruss

Coffeebean

P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren
Parameter bereinigen

Ich habe Textboxen mit Inhalt, bei den meistens sind es Strings, manchmal auch Date, Int, Double.
Diese sollen später als SQL Parameter verwendet werden. Ich möchte die Klassen des SQL Servers oder von MySQL, etc zu benutzen um aus einem String schädliche Sachen heraus zu filtern und zu überprüfen ob ein String-Date wirklich ein Date ist.

Wenn es nicht geht, dann werde ich in einer Schleife solange alle -- durch - ersetzen bis keine -- mehr im String sind. Und dann diese drei Zeichen ; ' " komplett heraus filtern. Danach sollte SQL Injection nicht mehr funktionieren.

Ich haber ein bißchen mit den MSSQL Klassen herumgebastelt, an die bereinigten Parameter scheint man jedoch nicht zu kommen.

2.207 Beiträge seit 2011
vor 9 Jahren

Hallo peterfarge,

[Artikelserie] SQL: Parameter von Befehlen hilft dir vielleicht weiter. Damit hast du auch SQL-Injection vermieden.

Ansonsten hast du ja noch Parse und TryParse. So kannst du Strings auf ihr korrektes (Datums)Format prüfen.

Gruss

Coffeebean

P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren

Der DB-Server übernimmt zuerst den Befehl selbst und bereitet ihn vor, dann fügt er die Parameter-Werte ein. In dem unter "Problem" genannten Beispiel würde eine einzelne Adresse den Namen "Unsinn; DROP TABLE Kunden;" erhalten; aber weiterer Schaden könnte nicht entstehen. Dann kann ich die Klassen nicht zum Bereinigen benutzen, weil das Bereinigen gar nicht in dem Sinne statt findet. Die Parameter werden dann in das kompilierte SQL Stmnt eingesetzt.

Dann bastele ich selber was.

2.207 Beiträge seit 2011
vor 9 Jahren

Hallo peterfarge,

wenn Parameter keine Lösung für dich sind, dann versteh das Problem immernoch nicht um ehrlich zu sein...

Gruss

Coffeebean

P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren

Ich bekomme diesen String von der GUI "123;Delete * FROM Customer;--" und ich möchte ich entschärft abspeichern bzw in der GUI eine Fehlermeldung anzeigen lassen. Ich kann das Command Object auch mit null erstellen:

SqlCommand command = new SqlCommand(strSQL, null);

Bloß ich kann nicht an die bereinigten Parameter kommen:

command.Parameters.Add(new SqlParameter("@MyValue", strParameter)); 
command.Parameters.Add("@MyValue", System.Data.SqlDbType.Text); 
command.Parameters["@MyValue"].Value = strParameter; 
SqlParameter X = new SqlParameter("@MyValue", strParameter);

Der Erklärung nach werden sie gar nicht bereinigt sondern in dem kompilieren Ablaufplan des SQL Servers eingesetzt. Dann kann ich die Klassen wohl nicht benutzen und muß selber was basteln.

2.207 Beiträge seit 2011
vor 9 Jahren

Hallo peterfarge,

erstmal wird da nichts in einen "Ablaufplan vom SQL-Server" eingesetzt. Alles, was passiert, ist, dass man ein SQL-Query mit Parametern versieht, was einem Hochkommatas abnimmt und SQL-Injection vermeidet. Weitere Vorteile siehe in dem Thread. Am Ende ist das genau das, was du willst. Das sollte man, wenn man SQL-Queries im Code hat, möglichst immer so machen.

Was das Parsen der Parameter vorher angeht, da kannst du auf die, ebenfalls bereits erwähnten, Parse und Tryparse-Sachen zurückgreifen und die sauber im UI behandeln. Das liegt aber an dir.

Das Framework beitet dir die bereits genannten Funktionen dazu an.

Gruss

Coffeebean

16.807 Beiträge seit 2008
vor 9 Jahren

Les doch einfach den Beitrag über die Parameter komplett durch....
Was Du willst ist das Vermeiden des sogenannten SQL Injection; und genau dafür sind die Parameter da. Da muss man nichts (oft fehlerhaft) selbst implementieren.

P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren

Mein Modul speichert aber nicht in die Datenbank (hier liegt das Missverständnis), es gibt die Daten nur weiter. Ich habe keine direkte Verbindung zur Datenbank. Ich weiß das ganz am Ende ein MSSQL Server 2012 steht.

TryParse ist eine gute Idee.

16.807 Beiträge seit 2008
vor 9 Jahren

Du wirst das Händisch nicht alles abdecken können.
Theoretisch ist immer der DAL für den SQL Injection Schutz zuständig; nicht die Business-Logik oder gar die View.

P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren

Abseits der reinen Lehre: Es ist doch besser hinter der GUI schon die meisten Fehler abzufangen. Wenn der User eine Textbox verläßt, dann schaut die GUI Logik nach ob sich in dem Textfeld wirklich ein Datum befindet. Und in dem Suchfeld Nachname wird der String um Zeichen bereinigt die für SQL Injection notwendig sind.

//Ich denke hiermit wird SQL Injection wirksam verhindert:
public static string GetString(string StringSqlParameter) {
	string Result;

	Result = StringSqlParameter;
	Result = Result.Replace(";", "").Replace("'", "").Replace("\\", "").Replace("\"", "");
	while (0 < Result.IndexOf("--")) {
		Result = Result.Replace("--" , "-");
	}

	return Result;
}

Und wenn dann ab jetzt Matz's Futterkiste bei Name nicht mehr erlaubt ist, dann müssen sie einen Bug Report schreiben und ich ersetze dann ' durch einen selbst definierten Tag.

T
314 Beiträge seit 2013
vor 9 Jahren

Und dann hätte man das erreicht was man z.B. gefrickel nennt 😉

' ist halt erlaubtes Zeichen, welches auch sauber behandelt wird. Aber wenn Du dir lieber Steine in den Weg legen willst, tue da das.

Es hat niemand etwas dagegen gesagt, dass eine Validierung des Inputs unnötig ist. Allerdings eben erstmal nur den Typ und nicht den Wert.

16.807 Beiträge seit 2008
vor 9 Jahren

Ich prophezeie Dir jetzt schon, dass Du mit der Variante bald Kopfschmerzen haben wirst.
Die GUI ist nicht dafür verantwortlich die Logik der DB-Schicht zu übernehmen. Es hat die GUI nicht zu interessieren, wie die Datenhaltung erfolgt.

Wenn Du von MSSQL auf mySQL switchst, dann musst Du in Deiner Logik im dümmsten Fall die "unerlaubte Eingabe" anpassen, da einfach bei mySQL das Escapen anders funktioniert als bei MSSQL.
Von einer potenziellen XML-DB wollen wir mal gar nicht sprechen.

Das hier ist definitiv eine Schichtverletzung, eine Verletzung Separation of concerns und eine Bitte an die Leser: macht das nicht nach!

P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren

Ich bin frisch gebackender AddOn Entwickler von SAP Business One. Ich weiß das bei einer unserer Anwendungen SQL Injection möglich ist, das Modul das in die Datenbank schreibt haben wir jedoch zugekauft und keinen Zugriff auf den Source. Im Moment sehe ich keine andere Möglichkeit das Problem zu fixen.

Laut dieser Quelle ist auch bei mySQL der Backslash der Escape Character.

16.807 Beiträge seit 2008
vor 9 Jahren

Herzlichen Glückwunsch soweit.
Wenn Du aber keinen Rat vom Forum bzw. dessen Helfen annehmen oder hören willst, dann frag ich mich schon, was Dein Ziel ist 😉

P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren

Ich kann diesen Rat aber nicht umsetzen.

16.807 Beiträge seit 2008
vor 9 Jahren

Natürlich hast Du das, indem Du die Fremdkomponende entkoppelst und über Deinen DAL eine Abstraktionsschicht baust.
Du bist doch nun frisch gebackener AddOn Entwickler von SAP Business One; das sollte doch kein Problem darstellen 😉

P
peterfarge Themenstarter:in
20 Beiträge seit 2014
vor 9 Jahren

Das wäre eine Menge Arbeit und ich muß mich erstmal weiter einarbeiten. Das ist eine Sache mit geringer Priorität...

16.807 Beiträge seit 2008
vor 9 Jahren

Ich will nicht hoffen, dass das eine wichtige Software ist, denn mit Datenlecks spaßt man nicht.
SQL Injection und der sichere Umgang mit Daten sollte nie eine niedrige Priorität haben.

Eine menge Arbeit hast Du dann, wenn das Leck aufreisst und man sich nicht nur um das Leck, sondern auch um die rechtlichen Konsequenzen und das Image kümmern muss.
Damit will ich nur sagen: geht mit sowas nicht leichtfertig um.

Und wenn das AddOn aus Böblingen ist, dann kenne ich die eigentlich so, dass die sehr bewusst mit sowas umgehen 😉