---

Jeg har for nylig haft indbrud på en site, hvor en person fik adgang til en
administrations-side, hvor han lavede diverse hærværk. Det var meget
ubehagelgt og det vil jeg gerne undgå sker igen. Siten var beskyttet med
denne kode øverst:

---------------------
<?php
session_start();
if (!isset($_SESSION[webmaster])) {
header("Location: ikke_logget_ind.php");
}
------------------------

Denne session sættes, når en webmaster (autoriseret person) logger sig ind
og jeg troede at det ville forhindre, at andre kunne se siten, da denne
session ikke sættes, når de logger sig ind.

Jeg forsøger at finde ud af, hvordan dette indbrud er lavet, og derfor vil
jeg godt vide, om der er metoder, hvormed hackere og andre kan "forfalske"
en session og dermed få adgang til et område, som kræver at denne session
eksisterer? Forudsætningen er naturligvis, at man kender URL til filen, men
hvis man gør det, kan man så forfalske en session og dermed få adgang til et
område, som er beskyttet på ovenstående måde?

Formålet, for mig, med at vide dette, er naturligvis at jeg i fremtiden
gerne vil sikre mine portaler bedre for at undgå indbrud og hærværk.

v.h.
Jakob

---

On Mon, 26 Jun 2006 09:53:59 +0200, "Jakob Munck" <jm2@webspeed.dk>
wrote:

>---------------------
><?php
>session_start();
>if (!isset($_SESSION[webmaster])) {
> header("Location: ikke_logget_ind.php");
>}
>------------------------
>
>Denne session sættes, når en webmaster (autoriseret person) logger sig ind
>og jeg troede at det ville forhindre, at andre kunne se siten, da denne
>session ikke sættes, når de logger sig ind.

Der er et par detaljer:

1. Dit output fortsætter stadigvæk, selv om du har sat denne header.
Husk at sætte exit() umiddelbart bagefter, ellers bliver den reelle
webside stadigvæk sendt med (og brugeren kan blot sætte sin browser op
til ikke at følge din redirect til ikke_logget_ind.php). Derfor: Husk
at sørge for at afslutte script-afviklingen efter din viderestilling.

2. Primæsset er rigtigt nok, at en bruger ikke selv kan sætte
session-værdierne, men der kan være et par undtagelser:

2.1: Siden giver mulighed for at brugeren selv sætter session-værdier.
Det kan være, man har en form, der spreder sig over mange sider, og
blot har noget simpelt kode, der smider alle POST-nøgler/værdier over
i $_SESSION. Her kan brugeren så selv sende sine egne værdisæt med.

2.2: Har brugeren et webhotel på samme server, og php-opsætningen ikke
er sat op til at alle webhoteller deler session-mapper. Du kan læse
lidt om dette og se et eksempel på http://stock.ter.dk/session.php .
Her afhænger det så af dit webhotel.

3. Brugeren kan rent faktisk være logget ind som webmasteren:

3.1. Hvis brugeren har gættet et brugernavn og kodeord til
webmasteren, vil han have adgang. Her kan det være relevant at tjekke
logfilerne for om han har været forbi en login-side.

3.2. Hvis brugeren har mulighed for at tilføje HTML på siden (fx hvis
der er et webforum, der tillader HTML), kan han havde lagt et
javascript ind, der sender brugerens cookie (og dermed session-id) til
ham. Hvis en webmaster, der er logget ind, kigger på siden, vil
webmasterens session-id så blive sendt til brugeren, der blot kan gå
ind på siden med dette session-id - og nu være logget ind.


Under alle omstændigheder kan det være relevant at kigge i logfilerne
for at se, hvilke sider, brugeren har været forbi - fx om han har
været forbi en login-side eller ej.

--
- Peter Brodersen
Ugens^WMånedens^WSommerens værktøj - Find vej: www.findvej.dk
Nu med link direkte til en adresse, fx: www.findvej.dk/Nybrogade2,1203

---

Mange tak for dine kommentarer. Jeg har et par spørgsmål:


>>---------------------
>><?php
>>session_start();
>>if (!isset($_SESSION[webmaster])) {
>> header("Location: ikke_logget_ind.php");
>>}
>>------------------------
>>
>>Denne session sættes, når en webmaster (autoriseret person) logger sig ind
>>og jeg troede at det ville forhindre, at andre kunne se siten, da denne
>>session ikke sættes, når de logger sig ind.
>
> Der er et par detaljer:
>
> 1. Dit output fortsætter stadigvæk, selv om du har sat denne header.
> Husk at sætte exit() umiddelbart bagefter, ellers bliver den reelle
> webside stadigvæk sendt med (og brugeren kan blot sætte sin browser op
> til ikke at følge din redirect til ikke_logget_ind.php). Derfor: Husk
> at sørge for at afslutte script-afviklingen efter din viderestilling.
>


Kan du forklare det lidt mere tydeligt. Jeg forstår det ikke rigtigt. Hvad
kan en bruger gøre, som jeg ikke ønsker, hvis jeg har glemt at sætte exit()
efter headeren? Hvad er faren, hvad kan der ske?



> 2. Primæsset er rigtigt nok, at en bruger ikke selv kan sætte
> session-værdierne, men der kan være et par undtagelser:
>
> 2.1: Siden giver mulighed for at brugeren selv sætter session-værdier.
> Det kan være, man har en form, der spreder sig over mange sider, og
> blot har noget simpelt kode, der smider alle POST-nøgler/værdier over
> i $_SESSION. Her kan brugeren så selv sende sine egne værdisæt med.
>
> 2.2: Har brugeren et webhotel på samme server, og php-opsætningen ikke
> er sat op til at alle webhoteller deler session-mapper. Du kan læse
> lidt om dette og se et eksempel på http://stock.ter.dk/session.php .
> Her afhænger det så af dit webhotel.
>

Det kan jeg vist ikke gøre noget ved.


>
> 3.2. Hvis brugeren har mulighed for at tilføje HTML på siden (fx hvis
> der er et webforum, der tillader HTML), kan han havde lagt et

Det er ikke muligt.

> javascript ind, der sender brugerens cookie (og dermed session-id) til
> ham. Hvis en webmaster, der er logget ind, kigger på siden, vil
> webmasterens session-id så blive sendt til brugeren, der blot kan gå
> ind på siden med dette session-id - og nu være logget ind.
>
>
> Under alle omstændigheder kan det være relevant at kigge i logfilerne
> for at se, hvilke sider, brugeren har været forbi - fx om han har
> været forbi en login-side eller ej.
>

Ja, det er nok rigtigt.

Tak for hjælpen.

v.h.
Jakob




> --
> - Peter Brodersen
> Ugens^WMånedens^WSommerens værktøj - Find vej: www.findvej.dk
> Nu med link direkte til en adresse, fx: www.findvej.dk/Nybrogade2,1203

---

On Mon, 26 Jun 2006 19:40:10 +0200, "Jakob Munck" <jm2@webspeed.dk>
wrote:

>> 1. Dit output fortsætter stadigvæk, selv om du har sat denne header.
>> Husk at sætte exit() umiddelbart bagefter, ellers bliver den reelle
>> webside stadigvæk sendt med (og brugeren kan blot sætte sin browser op
>> til ikke at følge din redirect til ikke_logget_ind.php). Derfor: Husk
>> at sørge for at afslutte script-afviklingen efter din viderestilling.
>Kan du forklare det lidt mere tydeligt. Jeg forstår det ikke rigtigt. Hvad
>kan en bruger gøre, som jeg ikke ønsker, hvis jeg har glemt at sætte exit()
>efter headeren? Hvad er faren, hvad kan der ske?

Forestil dig at du har kode i stil med:

....
if (!isset($_SESSION['webmaster'])) {
header("Location: ikke_logget_ind.php");
}

if ($_REQUEST['opret']) {
// kode til at oprette en artikel
}


Selv hvis $_SESSION['webmaster'] ikke indeholder noget, så bliver
resten af koden stadigvæk afviklet. Så hvis jeg går ind på den side
med (for dette tilfælde) ...?opret=1, så vil den del af koden
stadigvæk blive afviklet, selv om der længere oppe er blevet sendt en
header.

--
- Peter Brodersen
Ugens^WMånedens^WSommerens værktøj - Find vej: www.findvej.dk
Nu med link direkte til en adresse, fx: www.findvej.dk/Nybrogade2,1203

---

Peter Brodersen skrev:
>
> Forestil dig at du har kode i stil med:
>
> ...
> if (!isset($_SESSION['webmaster'])) {
> header("Location: ikke_logget_ind.php");
> }
>
> if ($_REQUEST['opret']) {
> // kode til at oprette en artikel
> }
>
>
> Selv hvis $_SESSION['webmaster'] ikke indeholder noget, så bliver
> resten af koden stadigvæk afviklet. Så hvis jeg går ind på den side
> med (for dette tilfælde) ...?opret=1, så vil den del af koden
> stadigvæk blive afviklet, selv om der længere oppe er blevet sendt en
> header.
>

Men det kræver jo så dog at personen ved at der er en variabel som
hedder "opret" på siden, hvilken han ikke kan vide, da den ikke er
synlig. Og derefter skal han så indtaste den manuelt i "adresse-baren"
og give den en værdi som du viser. Men det er et sikkersheds-hul, så ja
husk altid exit;

Men er der egentlig nogen måde at finde ud af hvilke variabler der
ligger på siden? Eller er det bare om at gætte hvis man er fremmed,
indtil man støder på "opret" i dette her tilfælde?

Det er nok sjældent det er muligt at gætte sig frem til så.

Mvh. Lasse Jensen

---

"Lasse Jensen" <kontakt@webweaver.dk> skrev i en meddelelse
news:44a2fcc1$0$15794$14726298@news.sunsite.dk...
> Men er der egentlig nogen måde at finde ud af hvilke variabler der ligger
> på siden? Eller er det bare om at gætte hvis man er fremmed, indtil man
> støder på "opret" i dette her tilfælde?

Personligt navngiver jeg variablerne med navne som giver mening og nogen
gange tager jeg også navne fra de eksempler man ser på nettet. Så det burde
ikke være svært at gætte sig frem, hvis man kender lidt til personen gennem
f.eks. spørgsmål i nyhedsgrupper, hvor man nogle gange linker til de
pågældende scripts som spørgsmålet omhandler.

F.eks. login.php kunne der indgå
user
username
name
pass
password
etc.

Det vil ikke være noget større job for en computer at tage den danske ordbog
eller den engelske og checke alle ordene.

Sikkerhed fås ikke ved at skjule programkode, men kan f.eks. opnås ved at så
mange mennesker som muligt har kigget koden igennem for sikkerhedshuller.

>
> Det er nok sjældent det er muligt at gætte sig frem til så.
>
> Mvh. Lasse Jensen

Mvh.
Rune

---

Rune Christensen skrev:
>
> Sikkerhed fås ikke ved at skjule programkode, men kan f.eks. opnås ved at så
> mange mennesker som muligt har kigget koden igennem for sikkerhedshuller.
>

Naturligvis. Det skal der ikke herske nogen tvivl om!

Mvh. Lasse Jensen

---

Jakob Munck wrote:
> Jeg har for nylig haft indbrud på en site, hvor en person fik adgang til en
> administrations-side, hvor han lavede diverse hærværk. Det var meget
> ubehagelgt og det vil jeg gerne undgå sker igen. Siten var beskyttet med
> denne kode øverst:
>
> ---------------------
> <?php
> session_start();
> if (!isset($_SESSION[webmaster])) {
> header("Location: ikke_logget_ind.php");
> }
> ------------------------
>
> Denne session sættes, når en webmaster (autoriseret person) logger sig ind
> og jeg troede at det ville forhindre, at andre kunne se siten, da denne
> session ikke sættes, når de logger sig ind.
>
> Jeg forsøger at finde ud af, hvordan dette indbrud er lavet, og derfor vil
> jeg godt vide, om der er metoder, hvormed hackere og andre kan "forfalske"
> en session og dermed få adgang til et område, som kræver at denne session
> eksisterer? Forudsætningen er naturligvis, at man kender URL til filen, men
> hvis man gør det, kan man så forfalske en session og dermed få adgang til et
> område, som er beskyttet på ovenstående måde?

Det første jeg ville kigge efter, er om der er mulighed for
SQL-injection-angreb i dit system. Først når det er udelukket, ville jeg
kigge andre steder.

Det er teoretisk muligt at stjæle en session, men det er meget
kompliceret, så med mindre der er en meget god grudn til at hacke lige
præcis din hjemmeside, tror jeg ikke at det er derigennem vedkommende
har fået adgang.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

>
> Det første jeg ville kigge efter, er om der er mulighed for
> SQL-injection-angreb i dit system. Først når det er udelukket, ville jeg
> kigge andre steder.
>

Alle mine forme indsættes i db med kode af denne type:

----------------------------------------

$indhold = $_POST["indhold"];
$indhold = strip_tags($indhold);

if(!get_magic_quotes_gpc()){
$indhold = addslashes($indhold);
}

$dato_tid = date("Y-m-d G:i:s", time());
$unixtid = date("U", time());
mysql_query("INSERT INTO semeddelelser (afsender_id, indhold, dato_tid,
unixtid) VALUES ('$indhold', '$dato_tid', '$unixtid')");

header("Location: medd_list.php");
---------------------------------------

Jeg har ikke meget begreb om FQL-injection, men har fået at vide, at
ovenstående kode skulle være ok og ikke gøre denne form for hacking mulig. I
øvrigt var hackeren så fræk, at udsende interne medlemsmails til sitens
medlemmer med vores post-system, og det tyder vel ikke på, at der er tale om
sql-incektion. Snarere på, at han er trængt "fysisk" ind i vores
Webmaster-område.

Er koden ok, eller hvad?

v.h.
Jakob

---

Jakob Munck wrote:
>>Det første jeg ville kigge efter, er om der er mulighed for
>>SQL-injection-angreb i dit system. Først når det er udelukket, ville jeg
>>kigge andre steder.
>
> Alle mine forme indsættes i db med kode af denne type:
>
> ----------------------------------------
>
> $indhold = $_POST["indhold"];
> $indhold = strip_tags($indhold);
>
> if(!get_magic_quotes_gpc()){
> $indhold = addslashes($indhold);
> }
>
> $dato_tid = date("Y-m-d G:i:s", time());
> $unixtid = date("U", time());
> mysql_query("INSERT INTO semeddelelser (afsender_id, indhold, dato_tid,
> unixtid) VALUES ('$indhold', '$dato_tid', '$unixtid')");
>
> header("Location: medd_list.php");
> ---------------------------------------
>
> Jeg har ikke meget begreb om FQL-injection, men har fået at vide, at
> ovenstående kode skulle være ok og ikke gøre denne form for hacking mulig.

Det er ikke længere nok til at man automatisk kan vide sig sikker. Se
dokumentationen på http://dk2.php.net/manual/en/function.addslashes.php

> I øvrigt var hackeren så fræk, at udsende interne medlemsmails til sitens
> medlemmer med vores post-system, og det tyder vel ikke på, at der er tale om
> sql-incektion. Snarere på, at han er trængt "fysisk" ind i vores
> Webmaster-område.

"Fysisk"? Hvis der er nogen som har pillet ved din server, er det nok en
låsesmed og en politimand, du skal have fat i

Med SQL-injection kan du sagtens logge ind som en anden bruger, givet at
systemet er sårbart. Er det hvad du hentyder til med "fysisk"?

> Er koden ok, eller hvad?

Jeg kan hverken sige ja eller nej. Jeg mener ikke at det er en god idé
overhovedet at bruge addslashes og alle disse dersens besværgelser over
inputstrenge, som er blevet så moderne i LAMP-miljøer. I virkeligheden
kan man undgå stort set alle disse problemer ved at bruge prepared
statements. Se http://dk2.php.net/manual/en/function.mysqli-prepare.php

Det rare ved prepared statements er, at man helt slipper for at skulle
escape de værdier, som man bruger.

Desværre er prepared statements ikke specielt udbredte, så jeg ved ikke
om der - trods de gode muligheder for det modsatte - er nogle lignende
sikkerhedsproblemer med dem. Endelig skal det siges at prepared
statements oprindeligt blev indført for at give bedre performance,
hvilket ikke ligefrem er formålet med at bruge dem i det, jeg beskriver
ovenfor.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

"Jakob Munck" <jm2@webspeed.dk> skrev i en meddelelse
news:449f92aa$0$140$edfadb0f@dread11.news.tele.dk...

> <?php
> session_start();
> if (!isset($_SESSION[webmaster])) {
> header("Location: ikke_logget_ind.php");
> }

Jeg ville lave det på en anden måde.

Først ville jeg søge i DB om brugern har ret til at logge ind..

Hvis han har det - altså hvis DB retunerer mere end 0 records (1 record) på
brugernavn og password i db-søgning, så kan du sætte session på brugernavn
og password (evt. kan du lave en md5 på password).

Samtidig skal du lave en if ($num_rows_fra_db > 0){$login =
"ok";}else{$login="ikkeok";}

Rundt om alt den kode du vil have beskyttet laver du:

if ($login == "ok"){

beskyttet kode

}else{

print "du skal logge ind";

}

Håber du forstår.

Mvh Thomas

---

"ThomasB" <usenet*fjern*@*SKAL FJERNES*2ma2.dk> skrev i melding
news:44a03571$0$15788$14726298@news.sunsite.dk...
> "Jakob Munck" <jm2@webspeed.dk> skrev i en meddelelse
> news:449f92aa$0$140$edfadb0f@dread11.news.tele.dk...


> Samtidig skal du lave en if ($num_rows_fra_db > 0){$login =
> "ok";}else{$login="ikkeok";}

Bare det at søk i database ikke er "casesesitive" så jeg ville kjørt en test
i php på om brukernavn==intastet_brukernavn og pw==intastet_pw

ellers vil ove/hus bli godkjent selv om ove/Hus er den korekte
kombinasjonen.

-Ove

---

On Mon, 26 Jun 2006 21:36:14 +0200, "Ove Lie" <Ove.Ed.Lie@c2i.net>
wrote:

>Bare det at søk i database ikke er "casesesitive" så jeg ville kjørt en test
>i php på om brukernavn==intastet_brukernavn og pw==intastet_pw
>
>ellers vil ove/hus bli godkjent selv om ove/Hus er den korekte
>kombinasjonen.

Det afhænger så sandelig af ens felt-type og collation. Normalt
angiver man password-feltet som en binary-collation i tabelstrukturen
(eller alternativt i selve forespørgslen, hvis man ikke kan slippe af
sted med andet).

--
- Peter Brodersen
Ugens^WMånedens^WSommerens værktøj - Find vej: www.findvej.dk
Nu med link direkte til en adresse, fx: www.findvej.dk/Nybrogade2,1203

---

"Peter Brodersen" <usenet2006@ter.dk> skrev i melding
news:e7pd74$cgh$1@news.klen.dk...
> On Mon, 26 Jun 2006 21:36:14 +0200, "Ove Lie" <Ove.Ed.Lie@c2i.net>
> wrote:
>
> >Bare det at søk i database ikke er "casesesitive" så jeg ville kjørt en
test
> >i php på om brukernavn==intastet_brukernavn og pw==intastet_pw
> >
> >ellers vil ove/hus bli godkjent selv om ove/Hus er den korekte
> >kombinasjonen.
>
> Det afhænger så sandelig af ens felt-type og collation. Normalt
> angiver man password-feltet som en binary-collation i tabelstrukturen
> (eller alternativt i selve forespørgslen, hvis man ikke kan slippe af
> sted med andet).

Jo du har rett, men det er ofte at "noen" plages med dette, og det var det
jeg ønsket å poengtere/rette oppmerksomheten mot.

-Ove

---

Ove Lie wrote:
> "ThomasB" <usenet*fjern*@*SKAL FJERNES*2ma2.dk> skrev i melding
> news:44a03571$0$15788$14726298@news.sunsite.dk...
>> "Jakob Munck" <jm2@webspeed.dk> skrev i en meddelelse
>> news:449f92aa$0$140$edfadb0f@dread11.news.tele.dk...
>
>
>> Samtidig skal du lave en if ($num_rows_fra_db > 0){$login =
>> "ok";}else{$login="ikkeok";}
>
> Bare det at søk i database ikke er "casesesitive" så jeg ville kjørt en test
> i php på om brukernavn==intastet_brukernavn og pw==intastet_pw

Jeg laver altid en lille strtolower() på alle brugernavne og kodeord når
det sættes ind i databasen, og det samme med passwords, inden det ryger
ind igennem en md5() - så er man ude over det problem.

>
> ellers vil ove/hus bli godkjent selv om ove/Hus er den korekte
> kombinasjonen.
>
> -Ove
>
>

---

"Ove Lie" <Ove.Ed.Lie@c2i.net> skrev i en meddelelse
news:WsCdnQEsiYmyqj3Z4p2dnA@telenor.com...
>> Samtidig skal du lave en if ($num_rows_fra_db > 0){$login =
>> "ok";}else{$login="ikkeok";}
>
> Bare det at søk i database ikke er "casesesitive" så jeg ville kjørt en
> test
> i php på om brukernavn==intastet_brukernavn og pw==intastet_pw
>
> ellers vil ove/hus bli godkjent selv om ove/Hus er den korekte
> kombinasjonen.

Hvis du ikke vil have det casesensitive, kan du bare vælge f.eks "longtext"
til dit brugernavn og password i databasen.

---

On Tue, 27 Jun 2006 10:27:41 +0200, "ThomasB" <usenet*fjern*@*SKAL
FJERNES*2ma2.dk> wrote:

>Hvis du ikke vil have det casesensitive, kan du bare vælge f.eks "longtext"
>til dit brugernavn og password i databasen.

Det ændrer ikke noget. Longtext vil stadigvæk som udgangspunkt have en
almindelig charset-collation:

mysql> create table foo (bar longtext);
mysql> insert into foo values ('BaZ');
mysql> select COUNT(*) from foo where bar = 'bAZ'\G
*************************** 1. row ***************************
COUNT(*): 1

Men:

mysql> create table foo (bar longtext binary);
mysql> insert into foo values ('BaZ');
mysql> select COUNT(*) from foo where bar = 'bAZ'\G
*************************** 1. row ***************************
COUNT(*): 0

--
- Peter Brodersen
Ugens^WMånedens^WSommerens værktøj - Find vej: www.findvej.dk
Nu med link direkte til en adresse, fx: www.findvej.dk/Nybrogade2,1203

---

"Peter Brodersen" <usenet2006@ter.dk> skrev i en meddelelse
news:e7qrr7$jae$1@news.klen.dk...
>>Hvis du ikke vil have det casesensitive, kan du bare vælge f.eks
>>"longtext"
>>til dit brugernavn og password i databasen.

> mysql> create table foo (bar longtext);
> mysql> insert into foo values ('BaZ');
> mysql> select COUNT(*) from foo where bar = 'bAZ'\G
> *************************** 1. row ***************************
> COUNT(*): 1

Den finder en - så den er caseINsensitive med longtext. (som jeg skrev)

> mysql> create table foo (bar longtext binary);
> mysql> insert into foo values ('BaZ');
> mysql> select COUNT(*) from foo where bar = 'bAZ'\G
> *************************** 1. row ***************************
> COUNT(*): 0

Aha, så den bliver casesensitive når longtext gøres binær?

---

On Tue, 27 Jun 2006 13:10:53 +0200, "ThomasB" <usenet*fjern*@*SKAL
FJERNES*2ma2.dk> wrote:

>>>Hvis du ikke vil have det casesensitive, kan du bare vælge f.eks
>>>"longtext"
>>>til dit brugernavn og password i databasen.
>
>Den finder en - så den er caseINsensitive med longtext. (som jeg skrev)

Jeg missede dit "ikke"

>> mysql> create table foo (bar longtext binary);
>> mysql> insert into foo values ('BaZ');
>> mysql> select COUNT(*) from foo where bar = 'bAZ'\G
>> *************************** 1. row ***************************
>> COUNT(*): 0
>
>Aha, så den bliver casesensitive når longtext gøres binær?

Ja - eller rettere, binary er blot en shortcut for "collate
latin1_bin" (hvis man bruger latin1 som character set)

--
- Peter Brodersen
Ugens^WMånedens^WSommerens værktøj - Find vej: www.findvej.dk
Nu med link direkte til en adresse, fx: www.findvej.dk/Nybrogade2,1203

---

"Peter Brodersen" <usenet2006@ter.dk> skrev i en meddelelse
news:e7r4fl$put$1@news.klen.dk...
>>Den finder en - så den er caseINsensitive med longtext. (som jeg skrev)
>
> Jeg missede dit "ikke"

Tænkte det nok.

>>> mysql> create table foo (bar longtext binary);
>>> mysql> insert into foo values ('BaZ');
>>> mysql> select COUNT(*) from foo where bar = 'bAZ'\G
>>> *************************** 1. row ***************************
>>> COUNT(*): 0
>>
>>Aha, så den bliver casesensitive når longtext gøres binær?
>
> Ja - eller rettere, binary er blot en shortcut for "collate
> latin1_bin" (hvis man bruger latin1 som character set)

Det var jeg ikke klar over. I det hele taget tror jeg godt at jeg kunne
bruge en time eller to, på at sætte mig lidt mere ind i de forskellige
datatyper i mysql..

---

Jakob Munck wrote:
> ---------------------
> <?php
> session_start();
> if (!isset($_SESSION[webmaster])) {
> header("Location: ikke_logget_ind.php");
> }
> ------------------------

Som Peter siger, så er det ALTID en god idé at afslutte en
header("location..."); af med en exit; ligeefter.
Fx

<?php
session_start();
if (!isset($_SESSION[webmaster])) {
header("Location: ikke_logget_ind.php");
exit;
}

så STOPPER php parseren der og vil ikke afvikle noget andet kode, det
vil den faktisk gøre hvis du fx bare skriver echo "Hej"; nedenunder.
Du kan selv prøve at slå "automatisk redirects" fra i din browser (under
sikkerheds indstillinger svjh)

En anden god ting, det er ALTID at tjekke op imod databasen hver eneste
gang.

Lav fx. en funktion til det - den kunne se således ud.

function adminLogin($user,$pass) {
$sql = mysql_query("
SELECT COUNT(*)
FROM tabel
WHERE user = '".$user."'
AND pass = '".$pass."'
");
if(mysql_result($sql,0)==1) return true;
else return false;
}

Så sætter du bare $_SESSION["login"] $_SESSION["pass"] efter din html form.

Så på hver eneste administrator side, kaldes i starten
<?php
session_start();
if(adminLogin($_SESSION["login"],$_SESSION["pass"])===FALSE) {
header("location: ikkeloggetind.php");
exit;
}
// beskyttet kode
?>

En anden ting, er at ALLE passwords i din database bliver krypteret med
MD5, det har den fordel, at det er umuligt (kun nogle forskere har endnu
brudt koden) at få den rigtige kode, da det er 1-vejs kryptering.
Bagdelen er at du ikke kan lige skrive til Hr.Olsen hans password, så
skal du ind og rette manuelt i databasen (eller bruge et
administrationsmodul til at ændre hans kodeord).

Du har måske undret dig over at når du trykkede "glemt kodeord" på nogen
sider at du så får en meget underlig kode tilsendt i din mailbox, det er
netop pga at man ikke kan dekryptere kodeordet i databasen.

En anden ting er at tekst i $_SESSION bliver gemt som rå tekst - dvs
100% letlæselig, og kan sagtens læses af en anden der sidder på det
samme trådløse netværk (fx TDC Hotspot eller lign.) - så kodeordet i
$_SESSION["pass"] skal allerede DER krypteres.

En anden ting der kan være sket med din webmaster, er at han har siddet
på en offentlig computer (bibliotek eller lign.) og har ændret på det
han nu skulle, lukket browseren, men har ikke lukket det andet browser
vindue, så lever $_SESSION nemlig endnu, også er det bare for den
"nysgerrige" at trykke på history og snuppe linket til dit
administrationsmodul, og bummelum free access :)

Der er ikke rigtig nogen metode at komme udenom ovenstående (svjv),
andet end man skal opfordre brugeren til at bruge logud knappen
HVERGANG, eller lave noget javascript der selv sørger for at slette
sessionen, med noget ala <body onUnload="sletsession.php">, men så er
det jo at mange offentlige computere, ikke har slået javascript til -
også er man lige vidt.

Nå, det blev sku en lille roman, kan jeg se, håber du har fået lidt
indblik i en der har for et årstid siden haft samme problem, og måtte
gennemgå hele $_SESSION miljøet :)

---

jeg takker hermed jer alle for ovenstående kommentarer, som jeg læser
grundigt og ser i hvilken udstrækning jeg kan forstå og bruge i min kode.

v.h.
Jakob