Sikkerhed i php script

<ole>

Sorry, men hvis du ikke er virkelig stærk i sikkerhed, bør du ikke arbejde med personfølsomme eller 'meget følsomme' oplysninger.

Jeg ville ikke finde det passende, hvis den kirurg, som skal udføre en operation på mig, føler sig nødt til at rådføre sig i et webforum, primært befolket af brugere, som ingen formel kirurgisk baggrund har.

Sådan har jeg det også med folk, som behandler 'meget følsomme' oplysninger på nettet. Just my two cents ...  =)

/mvh
</bole>

Well be that as it may, så blev jeg jo ikke ligefrem stærkere i sikkerhed efter at have læst dit svar.

Nu kan personfølsomme oplysninger vel også defineres på forskellige måder :P

Men ihvertfald vil jeg jo stadig gerne vide hvorvidt min metode er sikker, eller noget af det nemmeste at bryde :)

Luk

Det mindste du kan gøre, er at på smit noget hash på brugernes passwords - hvis du ikke allerede gør det. Ellers tror jeg sgu vi skal se noget kode, for at afgøre det.

Du kan læse om lidt hash her:
http://dk.php.net/manual/en/function.md5.php
http://dk.php.net/manual/en/function.sha1.php

Jeg bruger md5 på koden :) Men tak ellers.. Jeg kigger lige på dine links :D

Så burde du være dækket ind nogenlunde. Det næste du kan kigge på, er om din kode kan være offer for mysql injections.

http://www.tizag.com/mysqlTutorial/mysql-php-sql-injection.php

Takker for link, der er da en funktion at bruge :-)

Hvis du vil have points, må du lige sige til så opretter jeg et nyt spm :D

Det er vist en gammel artikel. Idag burde SQL-injection under PHP/MySQL kun være et akademisk emne af historisk interesse.

Efter fremkomsten af MySQLI:
    http://dk2.php.net/manual/en/book.mysqli.php

- og prepared statements:
    http://dk2.php.net/manual/en/mysqli-stmt.prepare.php

- er der ingen seriøse kodere, som forsøger manuelt at drible sig ud af injection problemer ... det er guddommelig overflødigt  ;o)

shjort >> Begrebet 'personfølsomme oplysninger' er et veldefineret, juridisk begreb, så på det punkt er der ikke plads til personlige definitioner. Netop fordi det ikke fremgik tydeligt af spørgsmålet, hvad der var tale om, skrev jeg:
    "personfølsomme eller 'meget følsomme' oplysninger."

- hvor 'meget følsomme' var citteret fra spørgsmålet.

Jeg ved godt, min kommentar ikke gjorde dig klogere på sikkerhed - det var heller ikke ambitionen  =)

Sikkerhed er et enormt og meget vigtigt emne. Det kræver adskillige bøger og bunker af erfaring, før man med rette kan kaste sig ud i rollen som beskytter af 'meget følsomme oplysninger'. Ikke mindst, hvis de ikke udelukkende omhandler én selv.

Det var dét, jeg gerne ville udtrykke med kommentaren  ;o)

Selvom nye versioner har højere sikkerhed, synes jeg bestemt ikke man skal se gennem fingrene med det. Især ikke når nogen webhoteller stadig bruger ældre versioner af php/asp osv..
Jeg finder stadig mange sider der er viable for injections.

For lige at svare på det oprindelige spørgsmål, så er din sikkershedsmekanisme så sikker som serveren. Hvis den knækkes, er din info tilgængelig.

Når du bruger sessions til at styre logins, bliver session ID placeret i en cookie på brugerens computer. Sessions er den mest sikre (almindelige) sikkerhedsprocedure.
Og før nogen slagter mig for den kommentar, så mener jeg ikke at kerberos, SSO og andre mere centraliserede teknologier ligger inden for den almindelige programmørs rækkevidde/budget. Session-ID'et er ikke umiddelbart til at forstå. Men læs om "Session Highjacking".
http://en.wikipedia.org/wiki/Session_hijacking


Nogle sikkerhedsregler at huske når du arbejder med "sikre" sites:

- Vær opmærksom på sql-injections og anden forurening af din data, uanset hvilken metode du bruger til dette. Dette gælder også almindelige query string variabler. Alt som brugeren kan ændre bør valideres.

- Hvis din data *er* følsom, så kør al trafik over SSL/https. Ikke kun login.

- Gem *ALDRIG* nogen som helst info i en cookie der kan kan give nogen mening isoleret. Inklusiv brugernavn til "husk mig til næste gang" funktionalitet.

- Set din session timeout til den korteste pratiske periode. Det vil sige at hvis en bruger kommer tilbage efter 5-10 minutter, skal vedkommende logge ind igen. Det der så er vigtigt er at gøre dette så smertefrit som muligt for brugeren. Hvis de var på en underside før de røg af, skal de se den samme side efter de logger ind.

- Log alt. Alt. Alt. Selv når en bruger gemmer noget = F.eks. "2009-04-04 21:23:33 User michael has edited information with ID 55". enten til database eller en text-fil.

Det her var et par guidelines til at starte på.

Paranoid? Hvem mig?

Hvis du laver et normalt website kan du skippe mange af dem, men gå altid ud fra at der er nogen der er nysgerrig nok til at prøve på noget.

Mvh,
Michael