Du bist nicht eingeloggt.

Login

Pass

Registrieren

Community
Szene & News
Locations
Impressum

Forum / Bits und Bytes

Datenbankeintrag sicher?

<<< zurück   -1- -2-  
Der666Diablo
Champion (offline)

Dabei seit 04.2006
23736 Beiträge

Geschrieben am: 14.05.2009 um 11:29 Uhr

Zitat von solid-:

Zitat von Der666Diablo:

naja ich sags mal so, wenn ejtzt jmd einen iframe in deinen gb speichert (ausmaß:0) und der zwar verschlüsselt eingegeben und ausgegebn wird, dem besucherbrowser dann aber verleitet auf ne verseuchte webseite mit dem iframe zu gehen, dann kannst die seite ganz schnell vergessen, so n fehler dann nachträglich aus der db auszumerzen ist nicht gerade trivial...

Stimmt...mal ein einfaches undkindisches beispiel wäre:

User gibt
"<font color='red'>haha ich habs rot</font>"

wird das zwar der datenbank nichts ausmachen aber der der browser gibt den text ja dann so wieder aus -> echo "<font color='red'>haha ich habs rot</font>" dadurch wäre meine schrift ja rot oder nicht??


eben...und das wäre noch das ungefährlichste beispiel für deine user...

Bei Geld, Sex und Kunst gibt es keinen abnehmenden Grenznutzen. http://shortlinks.de/oee9

solid- - 35
Halbprofi (offline)

Dabei seit 01.2008
371 Beiträge

Geschrieben am: 14.05.2009 um 11:31 Uhr

Zitat von Der666Diablo:

Zitat von solid-:

Zitat von Der666Diablo:

naja ich sags mal so, wenn ejtzt jmd einen iframe in deinen gb speichert (ausmaß:0) und der zwar verschlüsselt eingegeben und ausgegebn wird, dem besucherbrowser dann aber verleitet auf ne verseuchte webseite mit dem iframe zu gehen, dann kannst die seite ganz schnell vergessen, so n fehler dann nachträglich aus der db auszumerzen ist nicht gerade trivial...

Stimmt...mal ein einfaches undkindisches beispiel wäre:

User gibt
"<font color='red'>haha ich habs rot</font>"

wird das zwar der datenbank nichts ausmachen aber der der browser gibt den text ja dann so wieder aus -> echo "<font color='red'>haha ich habs rot</font>" dadurch wäre meine schrift ja rot oder nicht??


eben...und das wäre noch das ungefährlichste beispiel für deine user...

Oke ich weiß nun auf was ich speziell achten muss und werd mich dementsprechend schlau machen danke =)

´o_O`

solid- - 35
Halbprofi (offline)

Dabei seit 01.2008
371 Beiträge

Geschrieben am: 14.05.2009 um 11:41 Uhr
Zuletzt editiert am: 14.05.2009 um 11:41 Uhr

Zitat von Der666Diablo:

Zitat von solid-:

Zitat von Der666Diablo:

naja ich sags mal so, wenn ejtzt jmd einen iframe in deinen gb speichert (ausmaß:0) und der zwar verschlüsselt eingegeben und ausgegebn wird, dem besucherbrowser dann aber verleitet auf ne verseuchte webseite mit dem iframe zu gehen, dann kannst die seite ganz schnell vergessen, so n fehler dann nachträglich aus der db auszumerzen ist nicht gerade trivial...

Stimmt...mal ein einfaches undkindisches beispiel wäre:

User gibt
"<font color='red'>haha ich habs rot</font>"

wird das zwar der datenbank nichts ausmachen aber der der browser gibt den text ja dann so wieder aus -> echo "<font color='red'>haha ich habs rot</font>" dadurch wäre meine schrift ja rot oder nicht??


eben...und das wäre noch das ungefährlichste beispiel für deine user...


Hierfür hab ich allerdings sehr schnell eine lösung gefunden
htmlentities

wandelt html gedöns in unicodes um ;)

´o_O`

McPommes - 51
Experte (offline)

Dabei seit 09.2006
1422 Beiträge
Geschrieben am: 14.05.2009 um 16:56 Uhr

Vielleicht sollte man mal was zur "Verschlüsselung" sagen die du ansprichst. Base64 ist eine Kodierung, aber alles andere als Verschlüsselung. Verschlüsseln heißt dass der Inhalt nicht von jedem gelesen werden kann. Kodiert heißt, die Daten werden so umgewandelt dass man sie problemlos speichern oder irgendwie verschicken kann.

DIe DB schaut sich bestimmt nicht an was hinter der Kodierung steckt. Wenn du nur sicher sein willst dass kein Blödsinn dir die Statements zerschießt, dann passt die Codierung. Aber mit den genannten Funktionen hast du mehr Glück, denn dann siehst du auch auf Anhieb was in den Feldern drin steht, ohne es wieder zurückwandeln zu müssen.


*** diese Fusszeile verschwendet 45 Bytes ***

solid- - 35
Halbprofi (offline)

Dabei seit 01.2008
371 Beiträge

Geschrieben am: 14.05.2009 um 21:37 Uhr

Zitat von McPommes:

Vielleicht sollte man mal was zur "Verschlüsselung" sagen die du ansprichst. Base64 ist eine Kodierung, aber alles andere als Verschlüsselung. Verschlüsseln heißt dass der Inhalt nicht von jedem gelesen werden kann. Kodiert heißt, die Daten werden so umgewandelt dass man sie problemlos speichern oder irgendwie verschicken kann.

DIe DB schaut sich bestimmt nicht an was hinter der Kodierung steckt. Wenn du nur sicher sein willst dass kein Blödsinn dir die Statements zerschießt, dann passt die Codierung. Aber mit den genannten Funktionen hast du mehr Glück, denn dann siehst du auch auf Anhieb was in den Feldern drin steht, ohne es wieder zurückwandeln zu müssen.

danke nochmals =)
aber da ich sie so oder so ausgeb auf der page und ich per einen klick die id mitausgeben kann wäre das auch kein problem eine message die auf der seite ausgegben wird schnell in der db zu finden, klar ist ein bisschen mehr aufwand aber ich belass es nun erst einmal so und werd mich später damit nochmals befassen wenn das gesamte grundprinzip der seite steht ;)
Es ist ja eine Lösung nur vllt nicht gerade eine handlich praktische ;)

trotzdem danke =)

´o_O`

McPommes - 51
Experte (offline)

Dabei seit 09.2006
1422 Beiträge
Geschrieben am: 14.05.2009 um 22:56 Uhr

Zitat von solid-:

aber da ich sie so oder so ausgeb auf der page und ich per einen klick die id mitausgeben kann wäre das auch kein problem eine message die auf der seite ausgegben wird schnell in der db zu finden

Doch schon, weil du mit Base64 praktisch aus 3 Bytes 4 Bytes machst. Du kannst nicht sagen wie ein Stück Klartext in codierter Form aussieht. Oder genauer gesagt, es gibt 3 Möglichkeiten dafür.
Von daher wär die Variante mit dem escape_string schon sinnvoller.


*** diese Fusszeile verschwendet 45 Bytes ***

<<< zurück
 
-1- -2- [Antwort schreiben]

Forum / Bits und Bytes

(c) 1999 - 2026 team-ulm.de - all rights reserved - hosted by ibTEC Team-Ulm

- Presse - Blog - Historie - Partner - Nutzungsbedingungen - Datenschutzerklärung - Jugendschutz -