---

Jeg vil lige høre om der skulle være nogen grund til at bruge addslashes på
variabler som ikke input'es på en hjemmeside?
Altså med andre ord - Er det ikke kun de variabler som får deres indhold af
en form man giver addslashes?

Er der andre gode sikkerhedsråd til når man programmere i php - sådan
generelt?

Mvh Stig N. Jepsen

---

On Wed, 2 May 2001 13:52:55 +0200, "Stig Nørgaard Jepsen"
<stignj@mail.dk> wrote:

>Jeg vil lige høre om der skulle være nogen grund til at bruge addslashes på
>variabler som ikke input'es på en hjemmeside?
>Altså med andre ord - Er det ikke kun de variabler som får deres indhold af
>en form man giver addslashes?
>
>Er der andre gode sikkerhedsråd til når man programmere i php - sådan
>generelt?

Du bruger svjv kun addslashes når noget skal sættes ind i en database.

--
Mvh. Stefan
Website: http://ghashul.dk/
"I demand the right to keep and arm bears"
"A computer without Windows, is like a fish without a bicycle"

---

Stefan Bruhn <if.you.want.my.e-mail.look@my.message.headers.ghashul.dk> writes:

> Du bruger svjv kun addslashes når noget skal sættes ind i en database.

Det er i hvert fald hvad den er beregnet til.
På http://dk.php.net/manual/en/function.addslashes.php står der:

Returns a string with backslashes before characters that need to be
quoted in database queries etc. These characters are single quote ('),
double quote ("), backslash (\) and NUL (the null byte).

Man kan dog også have glæde af den, hvis man vil outputte PHP-kode (hvor
mærkeligt det end måtte lyde, så sker den slags også :) ...

--
Jacob

---

On Wed, 02 May 2001 13:52:55 +0200, "Stig Nørgaard Jepsen"
<stignj@mail.dk> wrote:

> Jeg vil lige høre om der skulle være nogen grund til at bruge
> addslashes på variabler som ikke input'es på en hjemmeside?
Det kommer an på

1. om din PHP har (den ret irriterende, hvis du spørger mig)
"magic_quotes_gpc" slået til; tjek output fra phpinfo() for
at undersøge det
2. om du benytter SQL, som inddrager pågældende
variable

Hvis din PHP har magic_quotes_gpc slået fra, så skal du huske at benytte
addslashes() på alle udefrakommende data inden du putter dem ind i et
SQL-udtryk.

Generelt:
Udefrakommende data (GET, POST, COOKIES) kan man ikke stole på. Derfor
skal man sikre sig, at data ikke indeholder særlige tegn, der kan
ødelægge SQL-udtryk, HTML-output, osv.

Problemet med SQL udtryk og udefrakommende data kan illustreres på
følgende vis. Lad $x være en variabel, du får udefra (fx. som resultat
af en HTML-formular). Lad $x blive benyttet til at opdatere i en
database, fx:

$SQL="
   update tabelnavn
   set lagerstatus='out'
   where something='$x'
";

Lad os sige, at en person får kringlet det således, at $x indeholder
følgende værdi:
' or 'z'='z

Det resulterende SQL-udtryk bliver nu:

$SQL="
   update tabelnavn
   set lagerstatus='out'
   where something='' or 'z'='z'
";

Bang. Alle tabellens rækker ændres, fordi det altid gør sig gældende, at
tegnet z altid er lig z.

Den rigtige måde at konstruere SQL-sætningen på ville have været:

$SQLx = addslashes($x);
$SQL="
   update tabelnavn
   set lagerstatus='out'
   where something='$SQLx'
";

Hvis du har slået magic_quotes_gpc til, vil PHP modificere alle
indkommende data inden du får adgang til dem, nemlig ved at køre dem
alle gennem addslashes(). Dette lyder umiddelbart bekvemt, men er efter
min mening en pestilens, for så skal man køre stipslashes() på alle
eksterne data, før man kan benytte dem i ikke-SQL sammenhæng.

Bemærk følgende forhold, som ved første øjekast er lidt underligt:
Hvis du har brugt addslashes() på en værdi, som du har indsat i et
SQL-udtryk, så skal man _ikke_ køre stipslashes() på samme data, når man
henter dem ud af databasen igen senere.

Bemærk også, at addslashes() ikke nødvendigvis altid er den smarteste
måde at uskadeliggøre data. Hvis vi fx. taler heltalsdata, vil det ofte
være smartere at køre værdien gennem intval() før den benyttes i et
SQL-udtryk. På den måde sikrer man sig imod, at databasen fødes tekstdata til
en kolonne af typen int.

Mere ang. uskadeliggørelse af eksternt genererede data:
Hvis du skal bruge data med ekstern oprindelse i HTML, er det ofte
vigtigt at sikre sig, at data ikke indeholder HTML-særlige tegn, der kan
resultere i HTML med syntaksfejl. Jeg taler her om tegnene <>&. Hvis
sådanne tegn optræder i HTML eller JavaScript, kan slutresultatet blive
en meget grim side - eller det, der er værre: i JavaScript, der afvikler
farlige handlinger. Man kunne fx. forestille sig et message-board, hvor
en ond post'er for sneget særlige tegn ind, der gør at andre message
board brugeres browsere udfører handlinger, der ikke er rare - og som
udvikleren af message-board'et så vil blive klandret for.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

On Wed, 02 May 2001 19:47:19 +0200, "Troels Arvin" <troels@arvin.dk>
wrote:

>Dette lyder umiddelbart bekvemt, men er efter
>min mening en pestilens, for så skal man køre stipslashes() på alle
>eksterne data, før man kan benytte dem i ikke-SQL sammenhæng.

Endnu et problem er, at man bliver forventningsfuld, når man smider
data ind i databaser, og glemmer at bruge addslashes i andre tilfælde
- fx:

1. Når man henter systemvariabler eller HTTP-headers fra brugeren (fx
$HTTP_USER_AGENT) - har været ude for at et statistik-script fejlede
lidt, fordi en User-Agent hed noget med et '-tegn i sig; heldigvis fik
jeg om ikke andet en e-mail med SQL-fejlen.

2. Når man manuelt flytter data fra en tabel til en anden - fx først
laver en query, der udtrækker nogle felter til variable, og derefter
bruger de variable i en ny query, der indsætter data igen.

Begge af ovenstående situationer er sjældne, og derfor i højere grad
noget, man ikke lige skelner en tanke, når man endelig befinder sig i
dem.

--
- Pede
Professionel nørd