Diskussion zur Artikelserie "Parameter von SQL Befehlen"

Dieser Thread dient zur Diskussion rund um die
[Artikelserie] Parameter von SQL Befehlen

Es gibt einen extra Diskussionthread da die Artikelserie zusammengehörig in einem einzelnen Thread bleiben wird und keine Antworten darauf möglich sind.

Hallo herbivore,

also für mich gibt es da nicht viel zu diskutieren .....
Wer keine Parameter benutzt geht halt einfach ein erhöhtes Risiko ein,
das hier und da mal ein Statement nicht funktioniert.
Was wiederum zu Folgefehlern im Programm und System führen kann.

Um es mal etwas böser auszudrücken:
"Anfangs ist es etwas Mehraufwand weil man diese Technologie auch erstmal
verinnerlichen muss. Wer diesen Aufwand jedoch scheut,
geht nicht verantwortungsvoll mit seinem Code um.
Solange man alleine für sich programmiert ist es ja nicht so tragisch.
In der Firma, oder im Team finde Ich das schon recht strange."

@Khalid:
Sauberer Artikel, hast dir viel Mühe gegeben 👍

Sauberer Artikel, hast dir viel Mühe gegeben

Danke, ich reich das mal an juetho weiter. Von mir selber stammt nur der 2. Artikel in der Serie. Der Rest kommt von juetho.

Ausführlich, nicht langweilig, auch anfängerfreundlich - sehr schöne Serie, danke.

Eventuell sollte nochmal darauf hingewiesen werden, dass auch parametrisierte SQL-Abfragen nicht davon befreien, Usereingaben zu überprüfen 😃.

Wen ein Beispiel für SQL-Injection, das wirklich eingesetzt wird, interessiert:

http://isc.sans.org/diary.html?storyid=4565

Zeigt ganz gut, dass man von potentiellen Angreifern ein bisschen mehr Grips als ';DROP TABLE USERS;-- erwarten darf 😉.

Gruß,

LaTino

@Khalid:
Sauberer Artikel, hast dir viel Mühe gegeben 👍

Ist die Artikelserie denn von Khalid? Irgendwie verwirren mich folgende Ausschnitte:

Ein herzliches Dankeschön gilt Khalid, FZelle und allen anderen Datenbank-Experten, deren vielfältige Hinweise über die Forumssuche zu dieser Artikelserie beigetragen haben.

Gutes Gelingen!

Khalid (für die ausführliche Lösung)
**Jürgen (für die Artikel insgesamt) **

Besonderer Dank gilt FZelle, der mir mit seinen Antworten im Forum bei dieser Aufstellung sehr geholfen hat! Jürgen

Das verstehe ich nicht. Hat juetho die Artikel geschrieben? Wieso postet Khalid sie dann? Erklärung bitte! 😉

Danke, ich reich das mal an juetho weiter. Von mir selber stammt nur der 2. Artikel in der Serie. Der Rest kommt von juetho.

Na dann auch ein Danke und 👍 an juetho und alle die daran gearbeitet haben. 😁

Edit:
@LaTino:

Ups, hab Ich vorhin das quasi erschlagende Argument mit SQL - Injection vergessen 👅

huhu,

Danke! Endlich keine Comments mehr schreiben und sich 3-8 mal "rechtfetigen" oder andere verbessern müssen, nur noch verlinken 😁

Noch was zum wirklichen Diskutieren:

Mir fehlt irgendwie der Verweis, dass man beim Programmieren immer CODE von DATEN trennt - dasselbe gilt natürlich auch bei SQL.

🙂

Xynratron

Danke! Endlich keine Comments mehr schreiben und sich 3-8 mal "rechtfetigen" oder andere verbessern müssen, nur noch verlinken 😄

Genau das war meine Intention.

Mir fehlt irgendwie der Verweis, dass man beim Programmieren immer CODE von DATEN trennt - dasselbe gilt natürlich auch bei SQL.

Tut mir leid, aber wie Du das meinst bzw. worauf Du Dich beziehst, ist mir hier überhaupt nicht klar. Kannst Du das an einem Beispiel (z.B. mit Zitat aus einem der Artikel) verdeutlichen?

Danke! Jürgen

huhu,

naja, ich mein das eher allgemein.

Prinzipiell macht ja jeder automatisch beim Programmieren folgendes:

a) er schreibt Programmcode.
b) man benutzt konkrete Objekte/Daten im Programm

Dabei ist der Programm-CODE immer unabhängig von den Programm-DATEN. Das zieht sich irgendwie überall durch, bei jeder Kommunikation, auf jedem Chip in jedem Programm. (naja, etwas überspitzt^^)

Nur bei SQL ignorieren es einfach alle. Aber genau das ist ja der Sinn von Parametern: CODE (SQL) wird von DATEN getrennt.

Mehr wollt ich eigentlich nicht ausdrücken.

😃

Xynratron

Eventuell sollte nochmal darauf hingewiesen werden, dass auch parametrisierte SQL-Abfragen nicht davon befreien, Usereingaben zu überprüfen 😃.

die parameter verbieten ja eben semikolons und sql-spezifische schlüsselwörter.

Verbieten sie auch XSS? Unabsichtliche Falscheingaben? Absichtliche Falscheingaben, um das Programm zu bestimmten Verhaltensweisen zu zwingen?

Gruß,

LaTino

huhu,

Das ist für mich hier nicht die Frage. DB-Parameter haben ja im ersten Step nichts mit Benutzereingaben zu tun. Eine Validierung der eingegebennen Daten ist vollkommen unabhängig zu sehen, da dies nichts mit dem speichern der Daten zu tun hat.

Man kann zwar eine Daten-Validierung in die DB verlegen (constraints, trigger was auch immer) diese aber genausogut in einem Businesslayer oder durch bestimmte Steuerelmente (z.B: Masked-Edit, Dropdowns) abhandeln.

😃

Xynratron

Datenvalidierung im Datenlayer funktioniert nur für syntaktische, nicht für semantische Validierungen. Insofern ab damit in den Businesslayer.

LaTino

validieren tut er in erster linie den typen und die gültigkeit. somit verhindert man schon mal all die bufferoverflows am sql-server. zudem verhindert ein verlangter typ integer oder datetime jegliche syntax-eingabe (ist schlecht aus einem datetime ein select zu bekommen 😃 ). wie es allerdings mit strings aussieht, muss ich leider passen. ausprobieren dürfte aber meine wissenslücke stopfen. leider habe ich aber aktuell keinen sql-server zum ausprobieren in reichweite.....

Meine Antwort bezog sich nicht auf dich, sondern auf Jack - der sich wieder auf meine Antwort bezogen hat.

Das war mir bekannt. Deswegen meine Aussage dass eine Prüfung der Benutzereingaben nichts mit DB-Parametern zu tun hat.

😃

Xynratron

Parameter sind auch eine Prüfung von Benutzereingaben.

Okay, ich muss wohl etwas ausführlicher werden, sonst gibt's nur Missverständnisse.

Im Prinzip berührt meine Anmerkung auch das, was Xynratron gesagt hat. Die Parametrisierung ist eine der besten Methoden, SQL Injections zu vermeiden - eine Überprüfung der Syntax, die direkt durch den SQL-Server/Datenprovider vorgenommen wird und den Programmierer von der Last befreit, zu prüfen, ob eine Eingabe sich in den erwarteten Datentyp umformen lässt.

Es ist allerdings ein Trugschluß zu glauben, dass das an Validierung reicht. Kein Parameter der Welt hindert mich daran, in einen Eintrag eines Gästebuchs "<script>doSomethingEvil()</script>" zu schreiben: immerhin ist es Text, und der kommt auch in der Datenbank in ein Textfeld.

Dasselbe gilt für die anderen Szenarien, die ich genannt habe (gewollte und ungewollte Falscheingaben). Die Parametrisierung sorgt für eine gewisse Prüfung der Daten durch die Datenzugriffsschicht. Naturgemäßt hat diese Schicht keinen Schimmer von der Bedeutung der Daten - daher MUSS in jedem Fall eine Validierung auch in der Logikschicht erfolgen.

Meine Anmerkung bezog sich nur darauf: es wäre fatal zu glauben, rein validierungstechnisch hätte man mit dem Einsatz parametrisierter SQL-Abfragen alle Probleme gelöst. Sie helfen in einem Bereich der Validierungen. Es gibt sowohl weitere syntaktische als auch weitere semantische Prüfungen, die vorgenommen werden müssen, auch wenn man Parameter benutzt. Die Artikel laufen Gefahr, durch einen Neuling so verstanden zu werden, dass er alle Sicherheitsprobleme mit Parametern gelöst hätte - darum ging's mir 🙂.

Gruß,

LaTino

sehr ausführlich und sehr nützlich: Protect From SQL Injection in ASP.NET

das meiste davon gilt auch für winforms.

also solche eingaben wie ' oder ; werden auch aus einem string korrekt "unterbunden". aber wenn man anfängt html einzutippen, dann ist das natürlich eine asp.net spezifische problematik.

Ist mir zu kurz gedacht.

Was ist mit "legalen" Werten in einer Anwendung, die dafür sorgen, dass sich die Anwendung nicht so verhält, wie sie sollte? Unter diese Kategorie fallen webspezifische Sachen wie das Beispiel mit dem XSS, aber lass in einer Faktura beim Erfassen eines Belegs mal eine negative/zu große/zu kleine Menge eines Artikels zu - grundsätzlich nicht mit Parametern zu erschlagen, sondern nur mit zusätzlicher Behandlung der Benutzereingaben. Und auf die sollte man eben nie verzichten.

Nicht falsch verstehen, ich finde die Artikel großartig. Hatte diese Problematik nur erst vor kurzem mit dem mir zugeteilten Azubi (Fachinf. Anwendungsentwicklung), der von injectionanfälligen SQL-Anfragen-Zusammenbasteln voller Begeisterung auf Stored Procs (also parametrisierte Abfragen) umstieg, weil er meinte, sich Validierungen sparen zu können. Nix da 👅.

LaTino

Nur Businessvaldation hat nichts mit dem Übertragen/Lesen der Daten von/zu einer DB zu tun.

Auch wenn Porsche alles getan hat, um einem 911 die bestmögliche Strassenlage,
den bestmöglichen Motor usw. zu implementieren, erspart das dem Fahrer nicht das denken.
Das man einen Porsche nicht mit 280 in eine Haarnadelkurwe fährt ist dann die aufgabe
des Fahrers.

Hier ging es ums Autobauen, nicht ums fahren.

Nicht alles, was hinkt, ist ein Vergleich 😁

Ich hätte doch nur gern einen Satz gehabt:

"Auch wenn ihr Porsche mit ABS viel sicherer fährt, denken Sie bitte daran, den Sicherheitsabstand einzuhalten."

Meine Erfahrung ist, dass man auf parametrisierte Abfragen umsteigt, den alten Validierungscode entsorgt, und sich wundert, dass man in Teufels Küche gerät.

'nuff said.

LaTino

wollte hier mal ein "herzliches dankeschön" an alle beteiligten verfasser der serie loswerden! hat mir sehr geholfen 👍