---

Jeg har brygget et login system sammen, hvor jeg benytter session til
at holde styr på brugerne. Det virker tilsyneladende fint, men hvordan
med sikkerheden?

Ved login sættes $_SESSION['personid'] og på alle sider tjekkes om
denne er sat og om denne person har tilladelse til at det ene eller
det andet på den aktuelle side.
Min bekymring går på om det kan lade sig gøre at sende en falsk
$_SESSION ind og derved logge på uden password?

--
med venlig hilsen
Leonard - http://leonard.dk/

---

On Sat, 08 Jan 2005 16:49:59 +0100, Leonard <usenet@leonard.dk> wrote:

>Min bekymring går på om det kan lade sig gøre at sende en falsk
>$_SESSION ind og derved logge på uden password?

En almindelig bruger kan ikke. Men hvis dit domæne ligger på et
webhotel, hvor der ligger andre brugere (med samme session.save_path -
hvilket er default), vil andre webhotel-brugere både kunne læse og
manipulere dine session-data.

Et eksempel på dette kan ses på http://stock.ter.dk/session.php

Desværre er det ikke så ofte, at udbyderne laver individuelle
opsætninger (plus at der stadigvæk er diverse potentielle huller ved
shared hosts).

--
- Peter Brodersen

---

Peter Brodersen <usenet@ter.dk> wrote:

>En almindelig bruger kan ikke. Men hvis dit domæne ligger på et
>webhotel, hvor der ligger andre brugere (med samme session.save_path -
>hvilket er default), vil andre webhotel-brugere både kunne læse og
>manipulere dine session-data.

OK, jeg har nu udført en lille test på min hjemmeserver, med nogle
virtual-host domæner på, og derefter også på den server jeg har "ude i
byen":

test.php:
<?php
session_start();
$_SESSION['test']=1;
?>
<a href="/snyd.php">test</a>
<br /><a href="http://andet_domæne_på_samme_server/snyd.php">test

og på begge domæner:

snyd.php:
<?php
session_start();
print $_SESSION['test'];
?>

og i ingen af tilfældene er $_SESSION['test'] sat på det
andet_domæne_på_samme_server



--
med venlig hilsen
Leonard - http://leonard.dk/

---

On Sat, 08 Jan 2005 17:43:20 +0100, Leonard <usenet@leonard.dk> wrote:

><a href="/snyd.php">test</a>
><br /><a href="http://andet_domæne_på_samme_server/snyd.php">test

I det tilfælde medtager du heller ikke dit session-id over til den
anden server. Når du når over på andet_domæne.. og ikke præsenterer en
session-cookie, så genereres der en ny til dig.

Prøv at rette linket til:
http://andet_domæne/snyd.php?PHPSESSID= print session_id(); ?>

Det forudsætter så tillige, at udbyderen ikke har ændret på
defaultværdien på session.use_only_cookies. Dog, det er ikke nogen
voldsom stor sikkerhed. Det betyder blot, at en angriber skal sende
PHPSESSID'et med som cookie og ikke som en del af URL'en.

--
- Peter Brodersen

---

Peter Brodersen wrote:

> Det forudsætter så tillige, at udbyderen ikke har ændret på
> defaultværdien på session.use_only_cookies. Dog, det er ikke nogen
> voldsom stor sikkerhed. Det betyder blot, at en angriber skal sende
> PHPSESSID'et med som cookie og ikke som en del af URL'en.

nu er jeg nysgerrig, hvad er dit forslag til en løsning?
session.save_path kunne være en lokal uden for webscope ting. Har du
andre forslag?

Og hvis jeg siger SuperBase, hvad siger du så?

mvh
Kim Emax

---

Peter Brodersen <usenet@ter.dk> wrote:

>I det tilfælde medtager du heller ikke dit session-id over til den
>anden server. Når du når over på andet_domæne.. og ikke præsenterer en
>session-cookie, så genereres der en ny til dig.

OK, så kan den snydes.
Men den kan jo kun snydes, når jeg kender variabelnavnet på den
session-variabel jeg vil snyde med, og er det sådan lige at finde ud
af?
POST og GET overføres af browseren, men SESSION er vel noget der
gemmes på serveren og ikke er en del af trafikken mellem server og
client?

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:

> OK, så kan den snydes.
> Men den kan jo kun snydes, når jeg kender variabelnavnet på den
> session-variabel jeg vil snyde med, og er det sådan lige at finde ud
> af?
> POST og GET overføres af browseren, men SESSION er vel noget der
> gemmes på serveren og ikke er en del af trafikken mellem server og
> client?

jow, men bruger man vel ikke ofte "level"(1,10,20,100 mv.), "admin"(=1),
"access" og lignende navne? Det handler jo stadig om at lave signende
variabel navne og alt andet end lige, så gad jeg ikke bruge en udbyder,
der ikke forholdt sig til sikkerheden, men lod det være op til mig og
andre at bruge andre navne end det der var mest forstående for koden.

Jeg har f.eks. for at omgåes google toolbars "fede" hilight feature til
input fields i en form, brugt my-ema-il-post som et input name, for at
undgå at mit stylesheet blev overruled af denne toolbar. Mægtigt
irriterende og ekstra besværligt for kodningen af en site.

Og når man som sysadm kunne sætte _et_ parameter i en VirtualHost blok
og løse problemet den vej rundt, så _er_ det jo lidt fjollet at det ikke
bare bliver gjort... Men når man har udbydere til 9,- pr. md. så kan man
jo ikke forlange at de servere er sat optimalt op :)

mvh
Kim Emax

---

Kim Emax <newsgroups@emax.dk> wrote:

>Og når man som sysadm kunne sætte _et_ parameter i en VirtualHost blok
>og løse problemet den vej rundt, så _er_ det jo lidt fjollet at det ikke
>bare bliver gjort...

Enig, men det løser måske ikke problemet.

>Men når man har udbydere til 9,- pr. md. så kan man
>jo ikke forlange at de servere er sat optimalt op :)

Nej, der kan man forlnage ligeså lidt som når man køber et ugeblad i
samme prisklasse, jeg smider ikke penge ud til nogen af delene, men
betaler en ordentlig pris for et kvalitetswebhotel, som også er
lydhøre for forslag til forbedringer.

--
med venlig hilsen
Leonard - http://leonard.dk/

---

On Sat, 08 Jan 2005 23:22:14 +0100, Leonard <usenet@leonard.dk> wrote:

>Men den kan jo kun snydes, når jeg kender variabelnavnet på den
>session-variabel jeg vil snyde med, og er det sådan lige at finde ud
>af?

$_SESSION er et næsten almindeligt array, så du kan altid udføre:

print_r($_SESSION);
eller
var_dump($_SESSION);

... eller øvrige array-funktioner (each, foreach, etc.)

>POST og GET overføres af browseren, men SESSION er vel noget der
>gemmes på serveren og ikke er en del af trafikken mellem server og
>client?

Helt korrekt - der bliver aldrig transmitteret data om
session-indholdet (medmindre, det sker som en del af koden, fx som i
ovenstående print_r()-eksempel). Adgangen til den egentlige
session-data er således baseret på at man har adgang via et andet
webhotel på samme server.


Jeg er dog godt nok ikke begejstret for PHP på det punkt. Diverse
funktioner kan - selv i safe_mode og med open_basedir-restriction
udnyttes til at få informationer om filstrukturen og filer på systemet
(og dermed session-navne) på grund af uhensigtsmæssige
fejlmeddelelser. Jeg håber, det bliver mere oplagt at rette
session.save_handler til fx en database eller lignende i fremtiden.

--
- Peter Brodersen