Wer oder Was ist Sql injection und was hat das mit dem Dreamweaver zu tun?
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
arbeiten
code
eingabe
email
fehler
feld
funktion
hervorhebung
jemand
leute
muster
nutzen
sagen
sicherheit
string
syntax
team
vergessen
zahl
zeichen
-
Wer oder Was ist Sql injection? und wie funktioniert Sql injection?
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Eine SQL Injection ist das manipulieren eines SQl querys.
Bsp:
Query:
SELECT
*
FROM
test
WHERE
name = $name
Wenn man jetzt aber beim $name solgendes angibt:
hahaha;
DELETE
*
FROM
test;
Kommt folgender Query raus:
SELECT
*
FROM
test
WHERE
name = hahaha;
DELETE
*
FROM
test;
Und der hat halt ein nicht ganz wünschenswertes Ergebnis. -
Und noch mal, falls du noch nicht so viel Ahnung von SQL hast:
Wenn ein Angreifer versucht, deine SQL-Datenbank zu löschen o.ä., nennt man das 'SQL-Injection'. -
lgorse schrieb:
Und noch mal, falls du noch nicht so viel Ahnung von SQL hast:
Wenn ein Angreifer versucht, deine SQL-Datenbank zu löschen o.ä., nennt man das 'SQL-Injection'.
Falsch.
Eine SQL-Injektion ist, wie dragestellt, wenn bei schlecht gescripteten PHP-Code Jemand ein SQL-Query manipuliert, sodass es was ganz anderes macht, indem er SQL-Steuercode einschleust. Das Ziel muss alos nicht unbedingt das löschen der DB sein, und man kann die DB auch auf anderem Wege als ner SQL-Injection löschen ^^ -
Gleich noch ien Tipp wie dus behebst:
statt $name schreibst du html_specialchars($name) oder mysql_real_escape_string($name). -
mal ne frage von mir.
wie schützt html_specialchars()
vor so einer manipulation?
html_specialchars entfernt doch nur alle html elemente aus einem string bzw wandelt die zeichen die für html wichtig sind in entities um!?
Beitrag zuletzt geändert: 21.3.2009 20:30:26 von stevestyxx -
stevestyxx schrieb:
mal ne frage von mir.
wie schützt html_specialchars()
vor so einer manipulation?
html_specialchars entfernt doch nur alle html elemente aus einem string bzw wandelt die zeichen die für html wichtig sind in entities um!?
Richtig. Die wesentliche Funktion ist mysql_real_escape_string() - Die maskiert alle MySql-relevanten Zeichen, sodass sie harmlos sind. html_specialchars() schützt wohl eher vor crosssite-scripting, denn damit werden die Zeichen, die für HTML-Tags relevant sind maskiert, damit ein angreifer beispielsweise nicht <script></script> einbinden kann. -
Eigentlich braucht man sich beim PHP coden nur eins merken: "Traue keiner Eingabe die nicht von Dir persönlich kommt!"
Checke jeden String der von Außen kommt. Sprich Einträge in einem Gästebuch, etc.. Nur so kannst Du wirklich sicher sein, das keine ungewollten Sachen passieren. Aber auch hier muss man leider sagen das es keinen 100%igen Schutz gibt. -
aldistammkunde schrieb:
Richtig. Die wesentliche Funktion ist mysql_real_escape_string() - Die maskiert alle MySql-relevanten Zeichen, sodass sie harmlos sind. html_specialchars() schützt wohl eher vor crosssite-scripting, denn damit werden die Zeichen, die für HTML-Tags relevant sind maskiert, damit ein angreifer beispielsweise nicht <script></script> einbinden kann.
lol, man lern immer wieder was neues. Ich hab die ganze Zeit über geglaubt, dass html_specialchars sowohl einfache als auch doppelte Anführungszeichen maskiert. Und dann findet man heraus, dass die einfachen nur maskiert werden, wenn ENT_QUOTES gesetzt ist. Oh man... alle Script durchgehen und beheben *schäm*
"Traue keiner Eingabe die nicht von Dir persönlich kommt!"
:D
Richtig :D Das was du sagst ist richtig, alles andere ist falsch :D
Warum denn nicht einfach ganz am Anfang ein jeder Seite das $_GET und das $_POST Array durchlaufen und alles einmal mysql_real_escape_string()en. Könnte man sich die ganze Arbeit sparen und man könnte es auch nie vergessen :D
Beitrag zuletzt geändert: 21.3.2009 22:59:49 von nikic -
Weil man dadurch eventuel unnötig Rechenzeit verschwendet. Es ist besser selectiv einen String zu Escapen, statt pauschal erst einmal alles was überhaupt rein kommt. Jetzt nehmen wir an das Du ein Formular mit 30 Feldern hast, davon aber nur 10 in die DB schreibst. Dann werden 20 Felder völlig unnötig bearbeitet.
Ok das ist jetzt nen extrem Beispiel, aber die Masse machts, wenn Du jetzt eine Seite wie Lima hast und dort jede Eingabe, ob sie nun in die DB geschrieben wird oder nicht mit mysql_real_excape_string(); bearbeitest, kostet das auf die Masse an Hits einen ganz schönen Haufen an Rechenzeit. -
strange schrieb:
Weil man dadurch eventuel unnötig Rechenzeit verschwendet. Es ist besser selectiv einen String zu Escapen, statt pauschal erst einmal alles was überhaupt rein kommt. Jetzt nehmen wir an das Du ein Formular mit 30 Feldern hast, davon aber nur 10 in die DB schreibst. Dann werden 20 Felder völlig unnötig bearbeitet.
Ok das ist jetzt nen extrem Beispiel, aber die Masse machts, wenn Du jetzt eine Seite wie Lima hast und dort jede Eingabe, ob sie nun in die DB geschrieben wird oder nicht mit mysql_real_excape_string(); bearbeitest, kostet das auf die Masse an Hits einen ganz schönen Haufen an Rechenzeit.
Vor allem kann dir das escapen auch was putt machen. Die Funktion ist halt dazu da, genau die Zeichen zu maskieren, die SQL-Steuerzeichen sind. Wenn du mit dem Stirng was ganz andres machen willst, wenns z.B. n Passwort ist oder weiss der Teufel, dann macht das Escapen nicht nur keinen Sinn, sondern es macht alles kaputt. Aber es ist tatsächlich am sinnvollsten, alle Überprüfungen ganz oben zu machen, direkt, wenn sie reinkommen, man weiss ja shcon, wozu die da sind. Dann vergisst man's später nicht... -
cooles thema,
mal wieder was gelernt =)
da muss ich bei mir wohl auch nochmal die sql relevanten variablen überarbeiten^^
immer her mit solchen themen mit sachen sicherheit, davon kann ich net genug kriegen vorallem so ausführlich erläutert
-
Aber auch hier muss man leider sagen das es keinen 100%igen Schutz gibt.
und was ist mit
preg_match("/\A[A-Za-z0-9]*\z/", $zu_pruefen);
?
Ich will da mal sehen wie da irgendein Schadcode reinkommt, sofern der Programmierer die Prüfung bei keiner Variable vergisst... -
und was ist mit
preg_match("/\A[A-Za-z0-9]*\z/", $zu_pruefen);
?
Ich will da mal sehen wie da irgendein Schadcode reinkommt, sofern der Programmierer die Prüfung bei keiner Variable vergisst...
Naja, macht auch nur Sinn, wenn nur Alphanumerische Variablen übergeben werden ;)
Wie gesagt, man muss je nach Zweck der Variablen überprüfen, was man tut. Bei Sachen, die in ein SQL-Query gehen halt die SQL-Steuerzeichen maskieren, bei Sachen, die später per "echo" in ne HTML ausgegeben werden halt HTML-Entitis maskieren. Bei Dateipfaden irgendwas mit basename oder ähnlichem...
Wie gesagt, wenn es so einfach wäre, absolut sichere Systeme zu entwickeln, dann gäbs nicht täglich neue Nachrichten von Exploits ovn Webseiten und CMS ;) -
CMS und sonstige fertigsysteme haben den nachteil das sie nicht "speziell zugeschnitten" sind. es wird etwas ermöglicht, was einer der endbenutzer vlt gar nicht will, und das hat ne sicherheitslücke.
real programmers machen das alles selber, und zwar in vim/notepad
-
desaster-productions schrieb:
Aber auch hier muss man leider sagen das es keinen 100%igen Schutz gibt.
und was ist mit
preg_match("/\A[A-Za-z0-9]*\z/", $zu_pruefen);
?
Ich will da mal sehen wie da irgendein Schadcode reinkommt, sofern der Programmierer die Prüfung bei keiner Variable vergisst...
Stell dir vor, du hastn Feld wo die Website eingegeben wird, oder die Email.
Da geht das nicht. Das wäre nur etwas für trivialsteingaben wie texte.
Natürlich gibt es immer möglichkeiten sich vor xss, sqli, evalh zu schützen, aber das problem ist eher, dass man es manchmal einfach vergisst. Wenn du ständig mit irgendwelchen querys jonglierst kannste schon irgendwo das escapen vergessen...
desaster-productions schrieb: CMS und sonstige fertigsysteme haben den nachteil das sie nicht "speziell zugeschnitten" sind. es wird etwas ermöglicht, was einer der endbenutzer vlt gar nicht will, und das hat ne sicherheitslücke.
real programmers machen das alles selber, und zwar in vim/notepad
$aussage[0] = true;
$aussage[1] = false;
Bitte abändern in: ",und zwar in (Adobe)|(Macromedia) Dreamweaver [1-9]|(CS[1-4)"
(PS: Bis wohin hat macromedia den dw eig gemacht?) -
nikic schrieb:
(PS: Bis wohin hat macromedia den dw eig gemacht?)
CS4 ist die neueste Version -
merovius schrieb:
nikic schrieb:
(PS: Bis wohin hat macromedia den dw eig gemacht?)
CS4 ist die neueste Version
Das weiß ich, aber bis zu welche Version hatte Mocromedia den Dreamweaver? -
nikic schrieb:
merovius schrieb:
nikic schrieb:
(PS: Bis wohin hat macromedia den dw eig gemacht?)
CS4 ist die neueste Version
Das weiß ich, aber bis zu welche Version hatte Mocromedia den Dreamweaver?
Afaik bis zum bitteren Ende. Von Macromedia. Wurde afaik von Adobe aufgekauft....
[edit] Jupp, Macromedia wurde Im Dezember 05 von Adobe Systems aufgekauft, Dreamweaver lief noch bis zur Version 8 als "Macromedia Dreamweaver", dann wurde er in die Creative Suite 3 integriert.
Beitrag zuletzt geändert: 23.3.2009 18:41:47 von merovius -
nikic schrieb:
$aussage[0] = true;
$aussage[1] = false;
Bitte abändern in: ",und zwar in (Adobe)|(Macromedia) Dreamweaver [1-9]|(CS[1-4)"
(PS: Bis wohin hat macromedia den dw eig gemacht?)
Ach so, deswegen sind auch so viele, die ich kenne, der Meinung, dass Dreamweaver der größte mist ist und das sind mit Sicherheit keine Anfänger!
Entweder wirklich nur mit Notepad bzw. etwas vergleichbarem oder man benutzt etwas mit Syntaxhighliting und evtl. noch Autovervollständigung wie Notepad++ und für den Professionellen Bereich empfiehlt sich dann noch Zend Studio oder das neue Zend Studio for Eclipse. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
