9 svar · 585 visningar · startad av aasah
Jag håller på med ett skript för en liten "gästbok". De senaste dagarna har jag ägnat åt felsökning av diverse skumma saker och tror nu att jag äntligen lyckats lokalisera problemet. Jag har en fil som fungerar och en som bara laddar och laddar och laddar.... Den enda skillnaden mellan dessa filer är att jag i den senare försöker skydda mig mot oönskad input mha funktionerna html_entities och html_entity_decode. Använder PHP version 4.3.1.
Följande skiljer filerna åt: (Anropet sker oavsett hur texten eg ser ut, alltså även på textsträngar där det ej behövs, samt tomma strängen.)
//$to är true när värdena ska till DB:n, annars false.
function secureMe($post, $to) {
echo "$post<BR>";
if ($to)
$tmp = htmlentities($post);
else $tmp = html_entity_decode($post);
return $tmp;
}
//När värdena hämtas från DB, för utskrift
$subj = secureMe($row['Sub'], FALSE);
$comm = secureMe($row['Com'], FALSE);
//På väg in i DB:n
$subj = secureMe($_POST['subj'], TRUE);
$comm = secureMe($_POST['newC'], TRUE);
htmlentities använder du när du vill förhindra att någon skriver HTML- eller Javascript kod som visas i inlägget.
Antingen kör du htmlentities när du sparar till databasen ELLER när du hämtar från databasen.
Varför du överhuvudtaget skulle köra html_entity_decode har jag svårt att förstå, och som du har gjort det blir det dessutom samma resultat som om du använt varken htmlentities eller html_entity_decode.
Ett tips är att aldrig använda htmlentities innan du skriver till fil/databas. Den texten som användaren skriver in bör vara den text som sparas - helt oförändrad.
När du hämtar informationen och presenterar den på en webbsida kör du istället htmlentities på texten innan den skrivs ut.
Jag ser inte heller någon anledning att använda html_entity_decode i ditt fall...
jawbreaker skrev:
Ett tips är att aldrig använda htmlentities innan du skriver till fil/databas. Den texten som användaren skriver in bör vara den text som sparas - helt oförändrad...
Varför är det bättre än tvärtom? :q
Helt oförändrat borde öppna för SQL Injections, om jag har förstått det rätt...
Om man inte skriver decode() blir ju ett inlägg mer eller mindre oläsligt! Alltså, visst, vi som programmerar kan ju deschiffrera det, men för den övriga delen av människosläktet ser det för bedrövligt ut... :(
Kan man inte istället lösa det genom att ersätta:
alla "javascript" med "javas cript" (oavsett "case" alltså) samt
< och/eller > till något annat? Eller tappar man i säkerhet då?
Okej, några kommentarer:
1. Funktionen htmlentities har inget som helst att göra med SQL injections.
2. Visst, man ska alltid skydda sig mot SQL injections.
Har du magicquotes satt till ON, så sköts det automatiskt. Det magicquotes gör är att det lägger till escapetecken på lämpliga ställen i alla texter som tas emot via GET och POST och så vidare. I detta fall kan du skriva en SQL-fråga liknande det här:
$query = "SELECT * FROM MyTable WHERE MyField = '" . $_GET["test"] . "'";
utan att du behöver oroa dig för SQL injections. Har du magicquotes satt till OFF så blir det istället:
$query = "SELECT * FROM MyTable WHERE MyField = '" . mysql_escape_string( $_GET["test"] ) . "'";
för att du ska skydda dig mot SQL injections.
Magicquotes kan också vara ett bekymmer om man ska skriva något som tas emot exempelvis via POST till en textfil eller liknande. Magicquotes lägger som sagt till escapetecken (=backslash) på ställen som anses lämpligt (innan apostrofer, citattecken m.m.). Det fungerar bra så länge du skriver till databas, men om du ska skriva till textfil så kommer även escapetecknen med i filen, om jag inte missminner mig. Och detta vill man ju sällan. För att dessa tecken inte ska komma med i din fil kan du använda funktionen stripslashes på texten innan den skrivs till filen, typ:
$minVariabelMedTextSomSkaSkrivasTillFilen = stripslashes( $_POST["test"] );
Om, och endast om, magicquotes är satt till ON. Annars blir det bara:
$minVariabelMedTextSomSkaSkrivasTillFilen = $_POST["test"];
3. När du ska skriva text till webbläsaren, och du inte vill att eventuell htmlkod ska tolkas som just htmlkod så använder du funktionen htmlentities på texten innan.
Gör man det så kommer även htmlkoden att visas som vanlig text.
Exempel:
print( "<br>" );
kommer att skriva ut en radbrytning, eller hur? Medan
print( htmlentities( "<br>" ) );
kommer att skriva ut texten "<br>" (minus citattecknen då, såklart).
Åh!! :) Jag undrar vad det var för funktion jag testade med i förra veckan när jag fick ut &l t (som ett ord.... :( ) för <, &a ring för å och diverse andra kodbeskrivningar. Uppenbarligen inte htmlentities... Har just provat för säkerhets skull. Tack för förklaringar och råd! :D
jawbreaker - Tack för den utförliga beskrivningen av när magic_quotes är ett bekymmer, jag hade inte klart för mig när strip_slashes var bra förrän nu! :)
Det är inte alltid så lätt att hålla koll på alla inställningarna i PHP, men det var ju skönt att det verkade ordna upp sig den här gången åtminstone :)
Nej nu.... :( Det VAR den funktionen jag testade. :(
Om jag skriver i en testfil endast:
<?php echo htmlentities("Örjan <b>gråter</b>.").""; ?>
Så skriver PHP:
Örjan <b>gråter</b>.
Om jag skriver:
while ($row = mysql_fetch_array($res)) {
echo "<tr><td><center><table bgcolor=#FCFCFC width=\"95%\">";
echo "<tr><th class=\"blueC medium\"><center>Posted by ".$row[1]." at ".$row[2]."</center></th></tr>";
if ($row[3] != "")
echo "<tr><td class=\"medium\"><b>".htmlentities($row[3])."</b></td></tr>";
echo "<tr><td class=\"medium\">".htmlentities($row[4])."</td></tr>";
if ($grantedToPost)
printPostButtons($row);
echo "</table></center></td></tr>";
}
Och en post innehåller
<b>My bold try</b>
så skriver PHP:
<b>My bold try</b>
VARFÖR???? x( :q
Förmodligen har du använt htmlentities på texten även innan du sparade den i databasen?
Du ska endast använda htmlentities när du skriver ut texten till webbläsaren, precis som i ditt kodexempel.
Om du har data i databasen som redan har körts genom htmlentities innan den sparades så kommer det att bli som du skrev...
Åh! Det är ju fullt möjligt att det kom dit medan jag körde det på indata, ja. Tackar! :D