07. august 2006 - 20:56Der er
17 kommentarer og 2 løsninger
Danske karakterer med asp
Hej. Jeg har et lille problem med æ, ø og å.
Af sikkerhedshensyn anvender jeg server.htmlencode når jeg skal gemme input fra brugerne til min database. Men når jeg skal hente det frem igen giver det problemer.
Når teksten hives frem i browseren bliver den vist korrekt, medmindre jeg forkorter teksten.
F.eks. er følgende streng sendt til databasen: "Lejlighed søges".
Dette er gemt som "Lejlighed søges", hvilket er helt ok, da det vises korrekt i browseren.
Problemet er, hvis jeg afkorter teksten inden den vises i browseren til f.eks. 12 tegn. Så kommer der ikke til at stå "Lejlighed sø", men "Lejlighed s&".
Det ser jo ikke kønt ud, og det giver også problemer i forbindelse med validering af rss-feeds som jeg roder lidt med.
Er der nogen som har ideer til hvordan man omgås dette problem, uden at man skal lave en alenlang replace-funktion hver gang man skal skrive noget til skærmen eller til et rss-feed?
hvilken sikkerhed forsøger du at opnå med at bruger server.htmlencode når du lægger ind i databasen?
Som udgangspunkt vil jeg mene det er rigeligt at erstatte ' med '' når du lægger ind i databasen - og så første ved udtræk bruge server.htmlencode. På denne måde undgår du også de problemer du står i nu.
Ikke helt forstået? Det er vel stadig først nødvendigt idet du trækker dataene ud igen - hvis du forsøger at undgå "ondsindet" html-kode så vil du opnå den helt samme sikkerhed ved at bruge server.htmlencode ved udtræk fra databasen som idet du sætter det ind.
Det har du nok ret i, men der er to problemer ved det:
1. Input kommer primært fra brugere (forum, linkregistrering osv.) 2. Jeg er ikke helt sikker på konsekvenserne med alle de data der er i databasen nu, hvis jeg laver det om.
en hovedregel med databasearbejdet er aldrig at ændre brugernes input ved indsættelse i database - så er det altid lettere at manipulere med når man trækker det ud. Og dette altså uanset hvor data kommer fra.
Det kan jeg godt se måske er lidt sent nu - så mine to umiddelbare forslag er enten at konvertere dataene i den nuværende database til "rigtige" data (det vil jeg mene er det mest korrekte) eller også på en eller anden måde at replace tegnene direkte i din sql (dette vil gøre det en del tungere fremover og endelig kan det være at der er rigtig rigtig mange tegn der skal erstattes).
nielle > Jo, det er vel løsningen, men hvis jeg kunne undgå en lang replace-sætning ville jeg gerne det.
keysersoze > Håber ikke at du tog det ilde op, jeg synes bare der er mange spørgsmål herinde som bare ender i en lang diskussion om noget andet end det der bliver spurgt om.
helt korrekt, men mange af diskutionerne bunder i religionsforskelle m.m. hvor man altid vil kunne diskutere og ikke alle er lige gode til at stoppe en diskution... specielt måske når man er på eksperten. Her - og det håber jeg ikke du tager det ilde op ;) - skyldes dine problemer decideret forkert håndtering af brugerinput og uheldigvis betyder dette nogle uhensigtsmæssigheder der ikke "bare lige" kan rettes.
Der er ingen modsætning til htmlencode så som skrevet tidligere - og som også nielle skriver - er en masse replace() så vidt jeg kan se eneste mulighed. Og eftersom dette umiddelbart er den eneste ser en konvertering af databaseindholdet klart mest hensigtsmæssigt ud rent performancemæssigt.
Hvordan beskytter man sig så mod f.eks. SQL-injection?
Jeg har tidligere haft et problem med at tilgå min database via phpMyAdmin, fordi der var lagt noget html ned i en tabel (uden htmlencode), så nogle af skærmbillederne i phpMyAdmin gik i kage. Jeg kunne derfor heller ikke slette den record der var årsag til det.
Det var derfor jeg i sin tid begyndte at htmlencode det inden jeg gemte det i databasen.
HtmlEncode beskytter ikke specielt imod SQL-injection, men er snare rettet imod at beskytte imod HTML-kode (hvilket f.eks. beskytter imod XSS angreb).
For at beskytte imod den mest almindelige form for SQL-injection, er det nok at lave en Replace(dinTekst, "'", "''") på inddata før at se sendes i databasen.
Problematikken omkring injectet HTML-kode klares normalt ved at kalde htmlencode når data trækkes ud fra databasen, i stedet for når data sættes ind i databasen.
Når der nu ikke er en htmlDecode-funktion må jeg jo være tilfreds med det jeg har fået, bide i det sure æble og rette min database til.
Tak for indsatsen :)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
