Hej Jakob
Jakob Munck skrev:
> >Lad os se på nogle af linierne i dit kode, og finde ud af hvor
> >problemet opstår:
>
> [snip noget kode]
> > $add="img_store/$userfile_name"; // the path with the file name where the
> > file will be stored, upload is the directory name.
> > if(move_uploaded_file ($userfile, $add)){
> [snip]
> >Læg mærke til at her mangler variablerne $userfile_name og $userfile
> >at blive defineret. Jeg gætter på, at du har dem til at stå i
> >adresselinien, noget i retning af:
> >dit_script.php?userfile_name=et-eller-andet&userfile=et-eller-andet-2
> >I så fald er det GET-variable. Muligvis kan de også komme som
> >POST-variable, f.eks. hvis du på en tidligere side har en form hvor
> >method er POST. Uanset hvilken metode der bruges, vil userfile_name og
> >userfile komme ind direkte som variable, uden at du verificerer at de
> >ikke er blevet fusket med.
>
>
> Ja, de kommer fra en upload-form. Hvordan mener du at der skulle blive
> "fusket" med dem?
Det du mangler er givetvis noget i retning af
$userfile_name = $_FILES['userfile']['name'];
Se eventuelt:
http://dk.php.net/manual/en/features.file-upload.php#features.file-upload.post-method
En uploadform, og såmænd alle andre forme, virker på den måde, at
de kalder et script på serveren og i selve kaldet inkluderer selve de
variable, der er blevet fyldt ind i formen. Eksempel:
<form method="get" action="et-andet-script.php">
<input name="alder" type=text maxlength=3>
<input type=submit value="Send min alder">
</form>
Når brugeren her trykker submit, vil følgende adresse blive kaldt:
et-andet-script.php?alder=37 (fiktiv værdi)
og når du har register_globals 1, vil der i et-andet-script.php så
helt automatisk opstå variablen $alder=37
Og det er her, problemet opstår. For hvad skulle forhindre en
ondsindet bruger eller script i at kalde et-andet-script.php med en
anden værdi? Hvis $alder f.eks. straks bliver brugt i et sql-query, er
der stor risiko for SQL-injection, selvom $alder kun er tiltænkt en
uskyldig heltalsværdi.
Som det siges så smukt på
http://en.wikibooks.org/wiki/Programming:PHP:SQL_Injection
"Never trust user provided data, process this data only after
validation." Jeg ved du allerede har været lidt inde at kigge på
SQL-injection, prøv eventuelt at kigge på dette link. Der er et par
eksempler på, hvad man kunne finde på at putte ind i
et-andet-script.php?alder=***HER***
> Af hvem?
Folk og scripts med skumle intentioner har der aldrig været mangel
på.
> Og hvordan mener du at jeg skulle "verificere" at
> de ikke er blevet fusket med?
Der er mange måder at gøre det på, det kommer helt an på hvilke
typer data, man har med at gøre. Typisk kigger man på det, man ved om
de data, man ønsker brugeren skal skrive. F.eks. ved alder-eksemplet:
En alder består typisk af 1, 2, eller måske endda 3 tal, og intet
mere. Man kunne så teste hvorvidt den returnerede værdi opfylder
dette kriterium:
<?PHP
if (preg_match('/^[0-9]{1,3}$/',$_GET['alder']))
{
// Hvis betingelsen ovenfor er opfyldt, består alder kun af et til
tre tal mellem 0 og 9.
$alder = intval($_GET['alder']);
// Er man stadig en smule paranoid, kan man gøre som ovenfor, hvor
man sætter $alder til at være en heltalsværdi af $_GET['alder'].
Dette skal man naturligvis ikke gøre ved tekst-felter.
}
else
{
die('Hacker attempt.');
}
Man kunne måske ydermere kigge på, om hvorvidt $alder er indenfor
nogle realistiske grænser, f.eks. 0-150 år.
Ved f.eks. navne kan man måske også gætte på, at alle navne burde
kunne skrives vha. a-z, A-Z, æøå, ÆØÅ, eventuelt et par kommaer
og punktummer og bindestreger. Men intet mere. På samme måde kan man
bygge en regular expression op, som kan bruges i preg_match som vist
før.
Mht. f.eks. file-type (som du bruger) kan du verificere at den kun
indeholder bogstaver fra a-z, evt. tal (ærligt, kender ikke filetype
så godt), bindestreger og skråstreger. Men ikke mere, ikke noget med
linieskift, og andet skidt
> [snip]
> > if (!($userfile_type =="image/pjpeg" OR $userfile_type=="image/gif")){echo
> > "Filen skal være i .jpg eller .gif format!<BR>";
> > exit;}
> [snip]
> >Her er det igen. $userfile_type er ikke defineret (i alt fald ikke i
> >det, du har sendt).
>
> >Jeg vil foreslå at du gennemgår dit script linie for linie og kigger
> >på, hvorfor det ikke virker med register_globals 0. Der er meget
> >nyttigt at lære, og samtidig øger du sikkerheden markant, efter min
>
>
> Det har jeg gjort adskillige gange allerede, men jeg finder ikke - med min
> begrænsede viden - nogle fejl.
Sandt nok, man kan bruge lang tid på at finde ud af, hvor fejlen
ligger. Men øvelse gør mester
> >man ikke altid bare kan få svaret serveret. Men til en anden gang
> >ville det måske være udbytterigt og, om ikke andet, høfligt at læse
> >eller i alt fald skimme den litteratur, man bliver henvist til, i
>
>
> Er også sket, men jeg blev ikke meget klogere, ud over at jeg - som vist -
> fandt en (uperfekt) løsning. Desværre giver læsning ikke altid det ønskede
> resultat, især hvis læserens forudsætningerne er for svage. I princippet kan
> ethvert spørgsmål her i NG jo besvares med en henvisning til de uendelige
> masser af information, som er tilgængelige på nettet. Men problemer er ikke
> mange på information, men derimode mangel på KORT, PRÆCIS OG FORSTÅELIG
> information. Og det er noget helt andet.
Det er rigtigt.
> >stedet for at forvente et færdigt facit uden at skulle tænke sig om.
>
> Ja, du har ret i at man skal tænke sig om..
>
>
> Jeg siger tak for kommentaren.
>
> v.h.
> Jakob
Jeg håber du kigger lidt mere på verifikation af brugerinput, tro
mig, det er MEGET brugbart.
--
Mvh Jesper,
http://fdf.dk/landsdel1/