/ Forside / Teknologi / Udvikling / PHP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
PHP
#NavnPoint
rfh 3959
natmaden 3372
poul_from 3310
funbreak 2700
stone47 2230
Jin2k 1960
Angband 1743
Bjerner 1249
refi 1185
10  Interkril.. 1146
sikkert login-script
Fra : Anders K.


Dato : 06-07-05 00:57

Hej.

Jeg tænkte lidt på om login-scriptet på hjemmesideskolen er
sikkert..(http://hjemmesideskolen.dk/scripts/phpmysql/default.php
)

Med sikkert mener jeg at man ikke "for sjovt" kan hacke sig ind,
uden at være ekspert..

Men hvis den ikke er sikker? hvad er så?

/Anders

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

 
 
Dan Storm (06-07-2005)
Kommentar
Fra : Dan Storm


Dato : 06-07-05 08:27

I princippet er det jo sikkert nok idet at en uvedkommende skal have
adgang til at lave en session med det rigtige indhold på din server.

Hvis du er paranoid for om folk kan komme ind alligevel, så kan du lave
en kontrol af brugerens login oplysninger.

database: | id | brugernavn | password | control |

Ved login danner du en random nøgle!

$control = md5(uniqid());
$_SESSION['control'] = $control;

Og så lige kontrol funktionen:

function loggedin() {

   if(mysql_query("SELECT * FROM users WHERE
brugernavn='"$_SESSION['brugernavn']."' AND
control='".$_SESSION'[control']."'")) {
      return true;
   }else{
      return false;
   }
}


Når du så vil kontrollere om brugeren må se indholdet skriver du bare:

if(loggedin()) {
//kode hvis brugeren er logget ind
}else{
//kode hvis brugeren IKKE er logget ind
}

På den måde sætter du ikke al din lid til den session der hedder
'logget_ind'. Og det er trods alt lidt svært at gætte en tilfældigt md5
krypteret kontrol kode. Uden den får brugeren ikke adgang.

(Al min kode er utestet, men håber du kan se idéen)


--
Dan Storm

http://err0r.dk
storm@err0r.dk

PGP Public key på http://err0r.dk/pubring.pkr

>>> husk på; en ekspert er en person der har begået alle fejl mulige
inden for et bestemt område

Anders K. (06-07-2005)
Kommentar
Fra : Anders K.


Dato : 06-07-05 10:36

Dan Storm wrote in dk.edb.internet.webdesign.serverside.php:
> I princippet er det jo sikkert nok idet at en uvedkommende skal have
> adgang til at lave en session med det rigtige indhold på din server.
>
> Hvis du er paranoid for om folk kan komme ind alligevel, så kan du lave
> en kontrol af brugerens login oplysninger.
>
> database: id brugernavn password control
>
> Ved login danner du en random nøgle!
>
> $control = md5(uniqid());
> $_SESSION['control'] = $control;
>
> Og så lige kontrol funktionen:
>
> function loggedin() {
>
>    if(mysql_query("SELECT * FROM users WHERE
> brugernavn='"$_SESSION['brugernavn']."' AND
> control='".$_SESSION'[control']."'")) {
>       return true;
>    }else{
>       return false;
>    }
> }
>
>
> Når du så vil kontrollere om brugeren må se indholdet skriver du bare:
>
> if(loggedin()) {
> //kode hvis brugeren er logget ind
> }else{
> //kode hvis brugeren IKKE er logget ind
> }
>
> På den måde sætter du ikke al din lid til den session der hedder
> 'logget_ind'. Og det er trods alt lidt svært at gætte en tilfældigt md5
> krypteret kontrol kode. Uden den får brugeren ikke adgang.
>
> (Al min kode er utestet, men håber du kan se idéen)
>

Okay tak.. :)

skal jeg så sætte al det ind på hver side?
og forstår ikke helt det der med "control"... hva skal man skrive i db'en?

/Anders

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

Dan Storm (06-07-2005)
Kommentar
Fra : Dan Storm


Dato : 06-07-05 14:57

$control variablen skal naturligvis opdateres i den række hvor brugerens
login informationer er og skal sammenlignes mod den session du sætter
med samme indhold.
--
Dan Storm

http://err0r.dk
storm@err0r.dk

PGP Public key på http://err0r.dk/pubring.pkr

>>> husk på; en ekspert er en person der har begået alle fejl mulige
inden for et bestemt område

Jacob Atzen (06-07-2005)
Kommentar
Fra : Jacob Atzen


Dato : 06-07-05 12:16

On 2005-07-06, Dan Storm <shadyz@_REMOVETHIS_err0r.dk> wrote:

[snippet noget MD5 kode]
> På den måde sætter du ikke al din lid til den session der hedder
> 'logget_ind'. Og det er trods alt lidt svært at gætte en tilfældigt md5
> krypteret kontrol kode. Uden den får brugeren ikke adgang.

I hvilke scenarier mener ud, at dette skulle give ekstra sikkerhed? Jeg
har lidt svært ved at gennemskue det.

--
Med venlig hilsen
- Jacob Atzen

Dan Storm (06-07-2005)
Kommentar
Fra : Dan Storm


Dato : 06-07-05 15:04

Generelt er det jo ikke muligt at sætte en session på en server du ikke
har adgang til. Dette giver blot en mental sikkerhed. Dog benyttes denne
metode af chatsystemer for at sikre sig imod overtagelse af aktive
brugere. Så, imho, hvis denne metode bruges korrekt kan du sagtens opnå
en form for bedre sikkerhed.

Man kunne eventuel navngive session'en efter md5(uniqid()) og eventuelt
kontrollere denne mod brugerdatabasen. Det er nok lidt svære at navngive
en session korrekt, hvis den blot bliver navngivet således. Det kunne
være det var endnu bedre end mit første forslag?


--
Dan Storm

http://err0r.dk
storm@err0r.dk

PGP Public key på http://err0r.dk/pubring.pkr

>>> husk på; en ekspert er en person der har begået alle fejl mulige
inden for et bestemt område

Jacob Atzen (06-07-2005)
Kommentar
Fra : Jacob Atzen


Dato : 06-07-05 16:55

On 2005-07-06, Dan Storm <shadyz@_REMOVETHIS_err0r.dk> wrote:
> Generelt er det jo ikke muligt at sætte en session på en server du
> ikke har adgang til. Dette giver blot en mental sikkerhed. Dog
> benyttes denne metode af chatsystemer for at sikre sig imod
> overtagelse af aktive brugere. Så, imho, hvis denne metode bruges
> korrekt kan du sagtens opnå en form for bedre sikkerhed.

Du har stadig ikke svaret på, hvilke angrebsscenarier din løsning virker
mod. Prøv at beskrive, hvordan du vil udføre et konkret angreb på den
oprindelige løsning og dernæst, hvordan dette kan undgås med din
løsning.

--
Med venlig hilsen
- Jacob Atzen

Dan Storm (06-07-2005)
Kommentar
Fra : Dan Storm


Dato : 06-07-05 17:35

Min løsning er baseret på læsning om at sikre et brugersystem bedre.
Hvordan man konkret udfører et angreb ved jeg ikke. Det er ikke det
område jeg ha interesseret mig mest for.
--
Dan Storm

http://err0r.dk
storm@err0r.dk

PGP Public key på http://err0r.dk/pubring.pkr

>>> husk på; en ekspert er en person der har begået alle fejl mulige
inden for et bestemt område

Peter Brodersen (06-07-2005)
Kommentar
Fra : Peter Brodersen


Dato : 06-07-05 15:37

On 06 Jul 2005 11:16:26 GMT, Jacob Atzen <jacob@aub.dk> wrote:

>I hvilke scenarier mener ud, at dette skulle give ekstra sikkerhed? Jeg
>har lidt svært ved at gennemskue det.

På et typisk webhotel har forskellige kunder samme session.save_path,
og deler derfor sessions. Således kan det være muligt at modificere
sine egne session-data, hvis man har webhotel samme sted som det andet
site.

Så PHPs eget session-id kan være let nok at få fat på, og læse fra og
skrive til. Men vores mulighed for at ændre sessionsdataen hjælper os
ikke, idet vi ikke kender den aktuelle login-session

Tjek evt. eksemplet i den gule boks på:
http://stock.ter.dk/session.php

--
- Peter Brodersen

Jacob Atzen (06-07-2005)
Kommentar
Fra : Jacob Atzen


Dato : 06-07-05 16:59

On 2005-07-06, Peter Brodersen <usenet2005@ter.dk> wrote:
> On 06 Jul 2005 11:16:26 GMT, Jacob Atzen <jacob@aub.dk> wrote:
>
>>I hvilke scenarier mener ud, at dette skulle give ekstra sikkerhed? Jeg
>>har lidt svært ved at gennemskue det.
>
> På et typisk webhotel har forskellige kunder samme session.save_path,
> og deler derfor sessions. Således kan det være muligt at modificere
> sine egne session-data, hvis man har webhotel samme sted som det andet
> site.
>
> Så PHPs eget session-id kan være let nok at få fat på, og læse fra og
> skrive til. Men vores mulighed for at ændre sessionsdataen hjælper os
> ikke, idet vi ikke kender den aktuelle login-session

Så ved at tilføje en nøgle til sessionsdataene sikrer vi, at man ikke
bare kan ændre sit brugernavn til et andet. Men kunne man så ikke ligeså
godt lagre passwordet fremfor en vilkårlig nøgle i sessionen?

--
Med venlig hilsen
- Jacob Atzen

Peter Brodersen (06-07-2005)
Kommentar
Fra : Peter Brodersen


Dato : 06-07-05 17:08

On 06 Jul 2005 15:59:23 GMT, Jacob Atzen <jacob@aub.dk> wrote:

>Så ved at tilføje en nøgle til sessionsdataene sikrer vi, at man ikke
>bare kan ændre sit brugernavn til et andet. Men kunne man så ikke ligeså
>godt lagre passwordet fremfor en vilkårlig nøgle i sessionen?

For eksempel, jo. Dog, hvis folk får adgang til session-dataen (igen
forudsætter vi denne mulighed), så er passwordet også tilgængeligt, og
ikke bare en aktuel session.

Normalt kan sessions-informationen bruges til at undgå at man konstant
skal lave database-opslag. Det undgår vi desværre ikke i dette
tilfælde.

En anden mulighed kunne være også at gemme en hash af brugernavnet +
dags dato eller lignende, hvis man vil undgå konstant at skulle lave
database-opslag. Men i det hele taget er databaseopslag på nøgler
næppe dér, flaskehalsen opstår.

--
- Peter Brodersen

Søg
Reklame
Statistik
Spørgsmål : 177552
Tips : 31968
Nyheder : 719565
Indlæg : 6408849
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste