---

Jeg arbejder i øjeblikket på et adgangsbeskyttelsesscript, til min
administrationsside, til mine to rimelig store hjemmesider.
Jeg har imidlertid haft gang i lidt dialog på www.eksperten.dk, men det er
gået rimelig meget i stå - ved ikke hvorfor... :/
Men jeg startede altså med at benytte almindelige cookies, til jeg
overbeviste mig selv om at jeg kunne nøjes med sessioncookies, så nu har jeg
ændret mit script til dette:

session_start();
if ($_SESSION['username'] == "$dbbrugernavn" && $_SESSION['password'] ==
"$dbadgangskode") {
} else {
if (isset($_POST['username']) && isset($_POST['password'])) {
if ($_POST['username'] == "$dbbrugernavn" && $_POST['password'] ==
"$dbadgangskode") {
$_SESSION['username'] = "$dbbrugernavn";
$_SESSION['password'] = "$dbadgangskode";
} else {
echo "Log ind informationerne var ugyldige!";
exit;
}
} else {
echo "<form action=\"index.php\" method=\"post\">\n";
echo "Brugernavn: <input type=\"text\" name=\"username\">\n";
echo "Adgangskode: <input type=\"password\" name=\"password\">\n";
echo "<input type=\"submit\" value=\"Log ind\">\n";
echo "</form>\n";
exit;
}
}

På nuværende tidspunkt beskytter jeg administrationssystemet med en blanding
af htaccess og en lidt ældrere udgave af dette script, men vil I mene at jeg
med dette kan droppe htaccess?
Endvidere ville jeg meget gerne have hvis I meget grundigt ville kigge
scriptet igennem for sikkerhedshuller og jeg vil også lige spørge, om I vil
mene jeg skal kryptere dataene som lægges i sessioncookien? - går bare ud
fra at folket bag PHP nok skal sørge for at sikkerheden er i orden - ved
almindelige cookies står man jo selv for dette...

På forhånd tak,

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

"Morten Jørgensen" <admin@startlinket.dk> wrote in
news:3e58b0b4$0$4232$edfadb0f@dread14.news.tele.dk

> Endvidere ville jeg meget gerne have hvis I meget grundigt ville
> kigge scriptet igennem for sikkerhedshuller og jeg vil også lige
> spørge, om I vil mene jeg skal kryptere dataene som lægges i
> sessioncookien? - går bare ud fra at folket bag PHP nok skal
> sørge for at sikkerheden er i orden - ved almindelige cookies
> står man jo selv for dette...

Det er nok smartest at du krypterer dine cookiedata - i hvert fald
passwordet! Brug f.eks. md5() til det.

--
..: Henrik Stidsen - HS235.dk ::...
http://hs235.dk/cracks - http://susie.dk/
http://hs235.dk/billeder :=)

---

Morten Jørgensen wrote in <3e58b0b4$0$4232$edfadb0f@dread14.news.tele.dk>:
> session_start();
> if ($_SESSION['username'] == "$dbbrugernavn" && $_SESSION['password'] ==
> "$dbadgangskode") {

Du fortæller intet om hvor de to variabler kommer fra, der kan godt være
sikkerhedshuller før den første linje du viser.

> $_SESSION['password'] = "$dbadgangskode";

Er der nogen grund til at lagre kodeordet?
Jeg plejer bare at lagre informationen om, at brugere er logget ind.

I din første "if" tjekker du om brugernavn og kodeord er korrekt. Det gør du
tilsyneladende på hver side. Du kunne i stedet nøjes med at tjekke, om der
står i sessionen, at brugeren er logget ind.

> På nuværende tidspunkt beskytter jeg administrationssystemet med en
> blanding af htaccess og en lidt ældrere udgave af dette script, men vil I
> mene at jeg med dette kan droppe htaccess?

Når det er lavet færdigt kan du sikkert godt.

> jeg vil også lige spørge, om I
> vil mene jeg skal kryptere dataene som lægges i sessioncookien?

Sessioncookien skal du slet ikke spekulere på, det klarer PHP selv. Den
indeholder kun sessionsid, og er ikke farlig i sig selv.

Al data der står i variablen $_SESSION kan klienten/brugeren (eller andre)
som udgangspunkt ikke få fat i. Det kræver et sikkerhedshul et eller andet
sted. Derfor behøver du ikke at spekulere på at kryptere sessions-data.

--
Mvh.
Niels Andersen
http://myplace.dk/articles/getpost/?lang=da

---

"Niels Andersen" <niels-usenet@myplace.dk> skrev i en meddelelse
news:1802568.vh39HMgTr7@home.myplace.dk...
> Du fortæller intet om hvor de to variabler kommer fra, der kan godt være
> sikkerhedshuller før den første linje du viser.

De includes fra en anden fil, hvor de er sat ind i en variabel.

> Er der nogen grund til at lagre kodeordet?
> Jeg plejer bare at lagre informationen om, at brugere er logget ind.
>
> I din første "if" tjekker du om brugernavn og kodeord er korrekt. Det gør
du
> tilsyneladende på hver side. Du kunne i stedet nøjes med at tjekke, om der
> står i sessionen, at brugeren er logget ind.

Tja, det har du vel ret i, men på én eller anden måde så synes jeg det
virker alt for "let", men det er jo korrekt at man kun behøver at tjekke når
de logger ind, for efterfølgende kun at tjekke om de har modtaget
sessioncookien... Så det vil du altså anbefale mig, også selvom det skal
beskytte en meget vigtig side?

> Når det er lavet færdigt kan du sikkert godt.

Fint

> Sessioncookien skal du slet ikke spekulere på, det klarer PHP selv. Den
> indeholder kun sessionsid, og er ikke farlig i sig selv.
>
> Al data der står i variablen $_SESSION kan klienten/brugeren (eller andre)
> som udgangspunkt ikke få fat i. Det kræver et sikkerhedshul et eller andet
> sted. Derfor behøver du ikke at spekulere på at kryptere sessions-data.

Helt fint, også det jeg ville mene.

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

Morten Jørgensen wrote in <3e58d8ab$0$4315$edfadb0f@dread14.news.tele.dk>:
>> Du fortæller intet om hvor de to variabler kommer fra, der kan godt være
>> sikkerhedshuller før den første linje du viser.
> De includes fra en anden fil, hvor de er sat ind i en variabel.

Og der har vi så nok kædens svageste led. Kodeordet så som rent tekst i en
fil. Ofte vil det enda være en fil, som er relativt let at få fat i.

Sørg for at filen ligger uden for "webscope". Hvis overhovedet muligt (og
det er det her), så lad være med at opbevare kodeordet som "plaintext". Læg
fx. i stedet en md5sum af kodeordet.
Når du så skal kontrollere kodeord laver du en md5sum af det indtastede
kodeord, og så sammenligner du denne md5sum med den i filen.

Så kan folk læse samtlige dine filer uden at finde kodeordet. Den eneste
måde at finde kodeordet bliver at køre bruteforce på md5summen. Hvis du har
et godt kodeord er det noget der kommer til at tage tid. Dit kodeord og
hackerens udstyr bestemmer hvor lang tid. Måske nogle timer, måske flere
år.

Jeg kender ikke lige hacker-værktøjerne osv. godt nok til at sætte tid på et
bestemt kodeord, men sørg for at have både store og små bogstaver, tal og
specialtegn (som fx. punktum og komma).

>> Er der nogen grund til at lagre kodeordet?
>> Jeg plejer bare at lagre informationen om, at brugere er logget ind.
> Tja, det har du vel ret i, men på én eller anden måde så synes jeg det
> virker alt for "let",

Med din metode kan man se kodeordet både i din includefil og i sessionsdata.
Dvs. hvis først man er kommet ind i din server har man gode chancer.

Man kan så argumentere for at hvis nogen først er kommet ind, så er det ikke
kodeordet der er problemet.

> Så det vil du altså anbefale mig, også selvom det skal
> beskytte en meget vigtig side?

Lige nu (hvor jeg har en masse andre ting i hovedet) har jeg lidt svært ved
at overskue alle detaljerne i de to muligheder. Men den med at huske
kodeordet, og kontrollere det for hvert "klik" synes jeg ikke lyder særlig
smart.

--
Mvh.
Niels Andersen
http://myplace.dk/articles/getpost/?lang=da

---

"Niels Andersen" <niels-usenet@myplace.dk> skrev i en meddelelse
news:1263982.178TDY3bXU@home.myplace.dk...
> Og der har vi så nok kædens svageste led. Kodeordet så som rent tekst i en
> fil. Ofte vil det enda være en fil, som er relativt let at få fat i.
>
> Sørg for at filen ligger uden for "webscope". Hvis overhovedet muligt (og
> det er det her), så lad være med at opbevare kodeordet som "plaintext".
Læg
> fx. i stedet en md5sum af kodeordet.
> Når du så skal kontrollere kodeord laver du en md5sum af det indtastede
> kodeord, og så sammenligner du denne md5sum med den i filen.
>
> Så kan folk læse samtlige dine filer uden at finde kodeordet. Den eneste
> måde at finde kodeordet bliver at køre bruteforce på md5summen. Hvis du
har
> et godt kodeord er det noget der kommer til at tage tid. Dit kodeord og
> hackerens udstyr bestemmer hvor lang tid. Måske nogle timer, måske flere
> år.
>
> Jeg kender ikke lige hacker-værktøjerne osv. godt nok til at sætte tid på
et
> bestemt kodeord, men sørg for at have både store og små bogstaver, tal og
> specialtegn (som fx. punktum og komma).

Det samme kodeord bruges jo af scriptet til at oprette forbindelse til
databasen, så det skal jo være dér, men det kunne jo godt lægges udenfor
webscope.
Men nu er det jo ikke bare sådan at folk vil se indholdet af filen, hvis de
gætter sig til hvilken én det er, for det er jo en .php fil og indholdet af
den er kun variabler. Men det er korrekt, at går PHP ned, så vil man kunne
se indholdet og også korrekt at hvis man får direkte adgang til filen, så
kan man se den - det vil man altid kunne... Så jeg kan ikke rigtig se at det
skulle kunne gøres bedre, andet lige end at lægge det udenfor webscope.

> Med din metode kan man se kodeordet både i din includefil og i
sessionsdata.
> Dvs. hvis først man er kommet ind i din server har man gode chancer.

Ja, det er jo korrekt at det gøres sværrere at komme ind, hvis det ikke
ligger i sessionen. Men det jeg spurgte til, var jo om jeg så bare skulle
lave noget jeg tjekker på i sessionen, om man er logget ind?
Det har garanteret den samme sikkerhed, som hvis jeg lagde brugernavn og
adgangskode derind, men du må kunne følge mig, at det umiddelbart lyder som
tjekkede man kun når man loggede ind - ved godt det ikke har noget at sige.
:)

> Man kan så argumentere for at hvis nogen først er kommet ind, så er det
ikke
> kodeordet der er problemet.
>
> Lige nu (hvor jeg har en masse andre ting i hovedet) har jeg lidt svært
ved
> at overskue alle detaljerne i de to muligheder. Men den med at huske
> kodeordet, og kontrollere det for hvert "klik" synes jeg ikke lyder særlig
> smart.

Nej, det er korrekt, så vi må vel drage den konklusion, at jeg "bare" gemmer
noget information, som jeg efterfølgende kan tjekke på? ... og det skulle
der så ikke være nogle sikkerhedshuller i, andet end hvad "PHP-folket" nok
skal rette. :P

---

Morten Jørgensen wrote in <3e58dfab$0$4293$edfadb0f@dread14.news.tele.dk>:
> Det samme kodeord bruges jo af scriptet til at oprette forbindelse til
> databasen, så det skal jo være dér, men det kunne jo godt lægges udenfor
> webscope.

Er det "by design", eller en tilfældighed?

Hvis det er med vilje at de er ens, så slipper du netop for at have
kodeordet stående. I hvert fald hvis databasen kun bruges efter login. :)
Metoden er simpel: Opret forbindelse til databasen med det kodeord brugeren
har angivet. Går det godt, så må kodeordet være rigtigt. Går det ikke godt,
ja så får selv PHP ikke adgang til data. :)

Men det giver selvfølgelig nogle begrænsninger, som ikke er særligt heldige.
Jeg har kun brugt ideen i database-værktøjer, hvor præcis de begrænsinger.

> Men det jeg spurgte til, var jo om jeg så bare skulle
> lave noget jeg tjekker på i sessionen, om man er logget ind?

Yeps. Fx:
if (brugernavn og kodeord er korrekt) {
$_SESSION['loggedin'] = true;
}

> men du må kunne følge mig, at det umiddelbart lyder
> som tjekkede man kun når man loggede ind

Yeps.

Hvis vi skulle tage en analogi: Du bruger kun din husnøgle når du skal ind
ad fordøren. Når du går rundt inde i huset skal du ikke bruge nøglen.

--
Mvh.
Niels Andersen
http://myplace.dk/articles/getpost/?lang=da

---

"Niels Andersen" <niels-usenet@myplace.dk> skrev i en meddelelse
news:23775219.BRJGBbCr80@home.myplace.dk...
> Er det "by design", eller en tilfældighed?
>
> Hvis det er med vilje at de er ens, så slipper du netop for at have
> kodeordet stående. I hvert fald hvis databasen kun bruges efter login. :)
> Metoden er simpel: Opret forbindelse til databasen med det kodeord
brugeren
> har angivet. Går det godt, så må kodeordet være rigtigt. Går det ikke
godt,
> ja så får selv PHP ikke adgang til data. :)
>
> Men det giver selvfølgelig nogle begrænsninger, som ikke er særligt
heldige.
> Jeg har kun brugt ideen i database-værktøjer, hvor præcis de begrænsinger.

Databasen skal jo bruges på mine hjemmesider, hvor folk som ikke kender
brugernavn og adgangskode til databasen, skal kunne surfe rundt og tilmelde
sig mit reklamenetværk og bruge dét... Duer jo ikke hvis alle skal kende
brugernavn og adgangskode for at bruge siden. :P

> Yeps. Fx:
> if (brugernavn og kodeord er korrekt) {
> $_SESSION['loggedin'] = true;
> }

Godt, så gør jeg det, så burde sikkerheden vel være i orden.

> Yeps.
>
> Hvis vi skulle tage en analogi: Du bruger kun din husnøgle når du skal ind
> ad fordøren. Når du går rundt inde i huset skal du ikke bruge nøglen.

Nu er det vel rimelig let lige at smadre en dør eller vindue, hvis det
skulle være dét... Så jeg vil ikke mene et hus er så sikkert endnu, men
noget i dén stil jo :P

Man jeg takker da for hjælpen,

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

"Morten Jørgensen" <admin@startlinket.dk> skrev i en meddelelse
news:3e58b0b4$0$4232$edfadb0f@dread14.news.tele.dk...
> Jeg arbejder i øjeblikket på et adgangsbeskyttelsesscript, til min
> administrationsside, til mine to rimelig store hjemmesider.
> Jeg har imidlertid haft gang i lidt dialog på www.eksperten.dk, men det er
> gået rimelig meget i stå - ved ikke hvorfor... :/
> Men jeg startede altså med at benytte almindelige cookies, til jeg
> overbeviste mig selv om at jeg kunne nøjes med sessioncookies, så nu har
jeg
> ændret mit script til dette:
>
> session_start();
> if ($_SESSION['username'] == "$dbbrugernavn" && $_SESSION['password'] ==
> "$dbadgangskode") {
> } else {
> if (isset($_POST['username']) && isset($_POST['password'])) {
> if ($_POST['username'] == "$dbbrugernavn" && $_POST['password'] ==
> "$dbadgangskode") {
> $_SESSION['username'] = "$dbbrugernavn";
> $_SESSION['password'] = "$dbadgangskode";
> } else {
> echo "Log ind informationerne var ugyldige!";
> exit;
> }
> } else {
> echo "<form action=\"index.php\" method=\"post\">\n";
> echo "Brugernavn: <input type=\"text\" name=\"username\">\n";
> echo "Adgangskode: <input type=\"password\" name=\"password\">\n";
> echo "<input type=\"submit\" value=\"Log ind\">\n";
> echo "</form>\n";
> exit;
> }
> }
>
> På nuværende tidspunkt beskytter jeg administrationssystemet med en
blanding
> af htaccess og en lidt ældrere udgave af dette script, men vil I mene at
jeg
> med dette kan droppe htaccess?
> Endvidere ville jeg meget gerne have hvis I meget grundigt ville kigge
> scriptet igennem for sikkerhedshuller og jeg vil også lige spørge, om I
vil
> mene jeg skal kryptere dataene som lægges i sessioncookien? - går bare ud
> fra at folket bag PHP nok skal sørge for at sikkerheden er i orden - ved
> almindelige cookies står man jo selv for dette...
>
> På forhånd tak,

Nå, så fik jeg kigget lidt på scriptet og er nu endt med dette:

session_start();
if ($_SESSION['loggedin'] != "1") {
if ($_POST['username'] == "$dbbrugernavn" && $_POST['password'] ==
"$dbadgangskode") {
$_SESSION['loggedin'] = "1";
} else {
echo "<form action=\"index.php\" method=\"post\">\n";
echo "Brugernavn: <input type=\"text\" name=\"username\">\n";
echo "Adgangskode: <input type=\"password\" name=\"password\">\n";
echo "<input type=\"submit\" value=\"Log ind\">\n";
echo "</form>\n";
exit;
}
}

Vær venlig og kig lidt på det og sig hvad I synes - altså er der nogen
sikkerhedshuller?
I øvrigt, nu tjekker jeg direkte på variablen, selvom den ikke eksisterer,
men "må" man egentlig det eller skal man først tjekke med isset()?

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

"Morten Jørgensen" <admin@startlinket.dk> skrev i en meddelelse
news:3e58ff89$0$4266$edfadb0f@dread14.news.tele.dk...
> Nå, så fik jeg kigget lidt på scriptet og er nu endt med dette:
>
> session_start();
> if ($_SESSION['loggedin'] != "1") {
> if ($_POST['username'] == "$dbbrugernavn" && $_POST['password'] ==
> "$dbadgangskode") {
> $_SESSION['loggedin'] = "1";
> } else {
> echo "<form action=\"index.php\" method=\"post\">\n";
> echo "Brugernavn: <input type=\"text\" name=\"username\">\n";
> echo "Adgangskode: <input type=\"password\" name=\"password\">\n";
> echo "<input type=\"submit\" value=\"Log ind\">\n";
> echo "</form>\n";
> exit;
> }
> }
>
> Vær venlig og kig lidt på det og sig hvad I synes - altså er der nogen
> sikkerhedshuller?
> I øvrigt, nu tjekker jeg direkte på variablen, selvom den ikke eksisterer,
> men "må" man egentlig det eller skal man først tjekke med isset()?

Kan det virkelig passe at ingen kan hjælpe? Selv ikke engang med det om
isset()?

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

Morten Jørgensen wrote:
> Kan det virkelig passe at ingen kan hjælpe? Selv ikke engang med det om
> isset()?

jeg bruger altid isset eller lignende inden jeg bruger en variabel.

Hvad sikkerheden angår: umiddelbart ser det godt ud for mig at se, især
hvis du har slashes osv-validering af det tekst-input som du har, så man
ikke kan komme igennem med "jesper ' where 1=1 [hostile here]" eller
lignende...

Vi har haft en længere debat om det for nogle måneder siden - søg
tilbage i gruppen på "sikkerhed" med groups.google.com

Ellers kan jeg ikke komme på noget, og det isset-halløj gik jeg ud fra
at du fik svar på når de som ved mere om sikkerhed end mig svarede dig

/Jesper Brunholm

--
Phønix - dansk folk-musik fra unge musikere - <http://www.phonixfolk.dk/>

---

"Jesper Brunholm" <nospam@brunholm-scharff.dk> skrev i en meddelelse
news:3E5A3310.1020009@brunholm-scharff.dk...
> jeg bruger altid isset eller lignende inden jeg bruger en variabel.

Men der er ikke noget galt for ikke at gøre det? Nu tænker jeg på fremtidige
versioner eller noget lignende...

> Hvad sikkerheden angår: umiddelbart ser det godt ud for mig at se, især
> hvis du har slashes osv-validering af det tekst-input som du har, så man
> ikke kan komme igennem med "jesper ' where 1=1 [hostile here]" eller
> lignende...

Hvilken funktion siger du man skal bruge til det? Jeg har faktisk også
forsøgt med lidt, men det lader overhovedet ikke til at det bliver fortolket
som PHP.

> Vi har haft en længere debat om det for nogle måneder siden - søg
> tilbage i gruppen på "sikkerhed" med groups.google.com

Kan jeg ikke lige huske... :)

> Ellers kan jeg ikke komme på noget, og det isset-halløj gik jeg ud fra
> at du fik svar på når de som ved mere om sikkerhed end mig svarede dig

Ja, jeg gik da også ud fra at Niels Andersen fortsatte her i tråden :/

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

"Morten Jørgensen" <admin@startlinket.dk> skrev i en meddelelse
news:3e58ff89$0$4266$edfadb0f@dread14.news.tele.dk...
> Nå, så fik jeg kigget lidt på scriptet og er nu endt med dette:
>
> session_start();
> if ($_SESSION['loggedin'] != "1") {
> if ($_POST['username'] == "$dbbrugernavn" && $_POST['password'] ==
> "$dbadgangskode") {
> $_SESSION['loggedin'] = "1";
> } else {
> echo "<form action=\"index.php\" method=\"post\">\n";
> echo "Brugernavn: <input type=\"text\" name=\"username\">\n";
> echo "Adgangskode: <input type=\"password\" name=\"password\">\n";
> echo "<input type=\"submit\" value=\"Log ind\">\n";
> echo "</form>\n";
> exit;
> }
> }
>
> Vær venlig og kig lidt på det og sig hvad I synes - altså er der nogen
> sikkerhedshuller?
> I øvrigt, nu tjekker jeg direkte på variablen, selvom den ikke eksisterer,
> men "må" man egentlig det eller skal man først tjekke med isset()?

Skal jeg prøve at spørge igen eller oprette endnu et spørgsmål, som kan
fylde endnu mere op?! (Undskyld min opførsel, men det undrer mig vildt meget
at der ingen reaktioner kommer...)

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

Morten Jørgensen wrote:
>
> Skal jeg prøve at spørge igen eller oprette endnu et spørgsmål, som kan
> fylde endnu mere op?! (Undskyld min opførsel, men det undrer mig vildt meget
> at der ingen reaktioner kommer...)


Tjah, det kan du da godt, men det hjælper nok ikke at true med det... ;)
- scriptet er der ikke noget i galt med, men det er jo ikke mere sikkert
end hvis man vil kan man få fat i brugernavn / password.
Dette kan du kun "sikre" ved at bruge ssl krypterede linier, men det
kommer jo også en del an på hvad det er du prøver at beskytte...

Hvis det er en side med familie billeder der ikke er af anstødende
karakter er det nok lige at gå til ekstremer at anvende ssl.

Hvis det er en side med alle dine passwords ville jeg nok se om jeg ikke
kunne få etableret en ssl forbindelse med et 128+ bits krypteret certifikat.



--
>> ulrik - ulrik(@)lazy.dk
excuse of the day : sticky bit has come loose
from bofh : http://www.cs.wisc.edu/~ballard/bofh/

---

"Ulrik Nielsen" <ulrik@lazy.dk> skrev i en meddelelse
news:06M6a.95692$Hl6.9231534@news010.worldonline.dk...
> Tjah, det kan du da godt, men det hjælper nok ikke at true med det... ;)

Nej, selvfølgelig ikke... Men jeg synes bare det er mærkeligt, at man kan
sidde og skrive frem og tilbage om noget og der pludselig ingen respons
kommer mere... :/

> - scriptet er der ikke noget i galt med, men det er jo ikke mere sikkert
> end hvis man vil kan man få fat i brugernavn / password.

Her mener du vel at "sniffe", når der logges ind? Men når man først er
logget ind, så kan det vel ikke laves bedre...
Men det jeg spørger om, er jo om jeg på nogen måde kan lave mit script
bedre, bare ved brug af normalt PHP, uden brug af SSL osv.? (Selv små
detaljer modtager jeg MEGET gerne!)

> Dette kan du kun "sikre" ved at bruge ssl krypterede linier, men det
> kommer jo også en del an på hvad det er du prøver at beskytte...

Igen, SSL og andre eksterne funktioner og metoder er jeg ikke interesseret
i... Er bare interesseret i kun at bruge en normal PHP installation og så
bare få sikkerheden i top, så der ikke findes ting og sager der pludselig
kan melde fejl og give adgang eller noget.

> Hvis det er en side med familie billeder der ikke er af anstødende
> karakter er det nok lige at gå til ekstremer at anvende ssl.
>
> Hvis det er en side med alle dine passwords ville jeg nok se om jeg ikke
> kunne få etableret en ssl forbindelse med et 128+ bits krypteret
certifikat.

Det er et administrationssystem til et
reklamenetværk/bannerbytte/tekstlinkbytte med ca. 200 medlemmer... :P
Og så var der jo lige det jeg jo spurgte om:
- Må man lave en if ($_POST['hurra'] == "bah"), selvom $_POST['hurra']
måske endnu ikke er oprettet, eller skal man altid bruge isset() her? (Ved
godt det er et svært spørgsmål, da folk har det med at komme med egne
erfaringer osv., men der må være et eksakt svar på dette)

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

"Morten Jørgensen" <admin@startlinket.dk> wrote in
news:3e5b974a$0$4212$edfadb0f@dread14.news.tele.dk:

> - Må man lave en if ($_POST['hurra'] == "bah"), selvom
> $_POST['hurra']
> måske endnu ikke er oprettet, eller skal man altid bruge isset() her?
> (Ved godt det er et svært spørgsmål, da folk har det med at komme med
> egne erfaringer osv., men der må være et eksakt svar på dette)

Det her er ikke noget eksakt svar...

Du skal altid spørge på isset($_POST['variabel']) hvis du ikke er 100%
sikker på, at den vil være sat. Det er der minimum to grunde til:

1) Det er pæn kode (syns jeg).

2) Hvis error_reporting bliver ændret engang så PHP begynder at fortælle
dig om NOTICEs, så vil det stadig virke uden at komme med grimme
beskeder. Dvs. du vil ikke komme ud for en situation hvor PHP indtil nu
automagisk har initialiseret en ikke-defineret variabel, men så
pludselig begynder at brokke sig efter at du har skiftet server.

.... og det er så _præcis_ hvad jeg mener om den sag :) - tror jeg.

--
Hyggehej
/Thomas

---

"Thomas Lindgaard" <thomas@it-snedkeren.BLACK_HOLE.dk> skrev i en meddelelse
news:Xns932DE646CEC65thomasitsnedkerendk@62.243.74.162...
> Det her er ikke noget eksakt svar...

Nej, selvfølgelig ikke, men kan jo være det ændrer lidt på mit synspunkt. :P

> Du skal altid spørge på isset($_POST['variabel']) hvis du ikke er 100%
> sikker på, at den vil være sat. Det er der minimum to grunde til:
>
> 1) Det er pæn kode (syns jeg).

Meget muligt, men den bliver jo lidt lidt længere.

> 2) Hvis error_reporting bliver ændret engang så PHP begynder at fortælle
> dig om NOTICEs, så vil det stadig virke uden at komme med grimme
> beskeder. Dvs. du vil ikke komme ud for en situation hvor PHP indtil nu
> automagisk har initialiseret en ikke-defineret variabel, men så
> pludselig begynder at brokke sig efter at du har skiftet server.

Forstod det ikke lige helt... Du mener altså at jeg IKKE vil komme ud for
nogen situation, hvor den vil komme med nogle grimme beskeder, uanset om
error_reporting bliver ændret?

> ... og det er så _præcis_ hvad jeg mener om den sag :) - tror jeg.

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk

---

Morten Jørgensen wrote:
>
> Forstod det ikke lige helt... Du mener altså at jeg IKKE vil komme ud for
> nogen situation, hvor den vil komme med nogle grimme beskeder, uanset om
> error_reporting bliver ændret?
>
>

Det er det Thomas mener.

Altid teste om dine variabler er til stede før du bruger dem.
Det kan godt være at dine scripts bliver lidt længere.

Warnings i din kode er advarsler om at der er noget php fortolkeren ikke
kan finde / finde ud af, så derfor "gætter" den på hvad det er du
mener... Det kan man undgå ved at sikre at de variabler man har tænkt
sig at bruge, faktist findes.


--
>> ulrik - ulrik(@)lazy.dk
excuse of the day : filesystem not big enough for Jumbo Kernel Patch
from bofh : http://www.cs.wisc.edu/~ballard/bofh/

---

"Ulrik Nielsen" <ulrik@lazy.dk> skrev i en meddelelse
news:Tx_6a.97036$Hl6.9321410@news010.worldonline.dk...
> Det er det Thomas mener.

Nåe, okay, fik indtryk af at han mente det modsatte, men bare fik skrevet
det forkert. :(

> Altid teste om dine variabler er til stede før du bruger dem.
> Det kan godt være at dine scripts bliver lidt længere.
>
> Warnings i din kode er advarsler om at der er noget php fortolkeren ikke
> kan finde / finde ud af, så derfor "gætter" den på hvad det er du
> mener... Det kan man undgå ved at sikre at de variabler man har tænkt
> sig at bruge, faktist findes.

Ja, god forklaring, så jeg vil ændre mit script så den tjekker det, selvom
den på nuværende tidspunkt bare tjekker om den indeholder en bestemt værdi.
Men så tror jeg faktisk jeg endelig har fået svar på mine spørgsmål, så skal
jeg bare lige have kigget lidt på det med isset(), så jeg takker for alle
svarene også selvom det desværre tog sin tid...

--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk