Sikkerhed i mine posts?

$string = addslashes($string);
$string = stripslashes($string);

ehmmm ' -> \' -> ' saa er du da tilbage hvor du startede

hvad type data er din $string ?

normalt vil en

function ren($string) {
  return trim(addslashes($string));
}

fange det meste

Ahh :)

Jeg slettede lige stripslashes. Men det er tekst..
Når jeg vil bruge ren, så er det til tekster :)

Men jeg er nu stadig på udkig efter, om man kan få mere sikkerhed, og undgå hacker angreb?

hehe du garderer dig ihvertfald rigeligt, hvis du fjerner stripslashes.. hvad gør du af strengen bagefter? Hvis du f.eks. smider den i en mysql-db (hvilket du sikkert gør), kunne du overveje at skrive nogle stored procedures.. så er du også rigtig godt garderet imod sql-injections den vej igennem, og du optimerer din performance.. men umiddelbart vil addslashes gøre langt størstedelen af arbejdet for dig.

Med mindre nogen finder en svaghed i mysql_real_escape_string og htmlentities, så er du sikret ret godt mod både sql og html sjov

den logiske opbygning er dog lidt forkert, mysql funktionen er den sidste man kalder

Ved indsættelse er mysql_real_escape_string det eneste du behøver (når nu du bruger mysql_*-funktionerne). Du skal aldrig bruge addslashes (aht. tegnsæt), og hvis magic quotes er slået til, bør du enten slå dem fra, eller fjerne det ved start af dine scripts.

Optimal sikkerhed kommer udelukkende ved brug af parameterized queries (brug af stored procedures er irrelevant for sikkerheden, men giver bedre performance), men det kræver du bruger mysqli_*-funktionerne i stedet. Hvis du har mulighed for det, så gør det, men kan du ikke det, må du nøjes med real_escape_string (og tilsvarende for andre databaser).

Ved output er htmlspecialchars den rigtige funktion at bruge, fremfor htmlentities. Det sparer båndbredde og tid, da du kun har behov for at konvertere de "farlige" tegn, <, >, &, og evt. " og '. Den eneste grund der er til at køre dette ved indsættelse, er for at spare CPU-tid ved output, men det besværliggør en del ting, fordi visse tegn pludselig kræver meget mere plads i databasen (så hvis du har et felt med plads til 30 tegn, kan brugere opleve at der beskæres inden da).

trim() er *generelt* ikke nødvendig, men kan være rar i en del situationer, f.eks. hvor feltet egentligt skal være unikt. Dog bør du i de situationer samtidigt erstatte alle forekomster af 2 eller flere mellemrum efter hinanden med et enkelt.

Gammelhat: Der HAR faktisk været fejl i mysql_real_escape_string, hvor der kunne opstå problemer hvis man kørte med et fler-byte tegnsæt. Både MySQL og PostgreSQL har været udsat for denne form for fejl.

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-2753 er MySQL's CVE-indlæg. Jeg kan ikke lige finde den for PostgreSQL nu.

Altså.. Pidgeot.. du siger at jeg burde skifte htmlentities ud med htmlspecialchars eller hvordan? :-)

        $string = addslashes($string);
        $string = htmlentities($string);
        $string = trim($string);
        $string = mysql_real_escape_string($string);

Efter jeres råd, har jeg byttet om på det hele..
Håber at jeg har fattet rigtigt..

Btw. nu jeg har jer, hvorfor udskriver min side så ikke følgende;
while($viser = mysql_fetch_assoc($henter)) {
echo '<a href="genabn.php?abn='. $viser[id] .'">'. $viser[overskrift] .'</a>
'; }

Ja, du bør skifte htmlentities ud med htmlspecialchars, og du bør køre funktionen når du skriver UD, ikke når du sætter IND - for det bliver lidt svært at forklare en bruger hvorfor han lige pludselig har 4 tegn mindre til rådighed når han bruger & til et felt med en begrænset længde.

Du skal ikke bruge addslashes, så væk med den - det er det vi har mysql_real_escape_string til.

Okay.. Pidgeot, læg et svar :)

btw. hvordan mener du, når jeg udskriver??
Og hvordan det?

Ja, du sætter vel ikke bare noget ind i din database for aldrig at kigge på det igen - et eller andet sted henter du det ud igen og viser det på en side.

Med andre ord, du har forskellige steder i din kode der minder om dette:

$query=mysql_query('SELECT noget FROM tabel');
while($row=mysql_fetch_assoc($query))
{
  echo $row['noget'].'<br>';
}

Det er først på dette tidspunkt du bør bruge htmlspecialchars, og ikke ved indsættelse:

$query=mysql_query('SELECT noget FROM tabel');
while($row=mysql_fetch_assoc($query))
{
  echo htmlspecialchars($row['noget']).'<br>';
}

Grunden er simpel: Hvis vi siger det felt er et varchar(10), så vil du ikke kunne gemme teksten "123 & 678", fordi htmlspecialchars/htmlentities ville lave det om til "123 &amp; 678" - og det er længere end de 10 tegn der er plads til, hvilket kan være svært at forklare overfor en bruger der lige har valgt det som brugernavn (for ham at se er det jo kun 9 tegn). Når der så oven i købet ikke er den store grund til at gøre det på den måde (&-tegnet er komplet ufarligt for databasens vedkommende), så er det bedre at tage det lille performance-hit og gøre det så sent som muligt. Det kræver selvfølgelig lidt disciplin, så man ikke lige pludselig har en situation hvor en eller anden har fået sat noget HTML ind, men det er bedre fra en brugers synspunkt.

Jeg vil i øvrigt godt gentage at så længe du ikke bruger mysqli_-funktionerne til at lave parameterized queries, så kan du ikke sikre dig 100% mod injections.

Tak pidgoet.. Du har været til en KÆMPE hjælp:) tusinde tak