Beveiliging

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Specialist Informatiebeveiliging

Waar een linked-data-omgeving, 500 licenties op databanken en digitale tijdschriften en ISO 27001/27002 en de BIO samenkomen. Dat is de KB in Den Haag. En het is de plek waar jij als specialist informatiebeveiliging waardevol digitaal erfgoed, maar ook informatie van en voor miljoenen bibliotheekbezoekers, beschermt tegen cybercriminaliteit. Stilstaan is geen optie. Als onze specialist informatiebeveiliging werk je in ons complexe IT-landschap met eindgebruikersdiensten, landelijke netwerkdiensten en diensten die ons nationaal erfgoed duurzaam opslaan. We ondersteunen de informatiebeveiliging vanuit een afdeling overstijgend team waarin de strategische, tactische en operationele rollen vertegenwoordigd zijn met één CISO, één ISM (information security manager)

Bekijk vacature »

Jan DS

Jan DS

02/07/2010 18:44:45
Quote Anchor link
Ik wil mijn site zeer streng beveiligen.
Welke technieken gebruik ik het best? Waar moet ik op letten?
 
PHP hulp

PHP hulp

13/06/2021 22:27:53
 
Pim -

Pim -

02/07/2010 19:06:02
Quote Anchor link
User input is evil
Elke variabele die op een of andere manier van een gebruiker kan komen, moet worden gechecked. Zelfs $_SERVER['PHP_SELF'] is niet veilig! Cookies zijn niet veilig!

Pas op voor Remote File Inclusion: pas heel erg op met variabelen in include.

Escape elke data die je in een database stopt, of gebruik een typecast naar integer: (int) voor id's. Dus mysql_real_escape_string of, mooier, prepared statements.

Escape alle user data in je output: htmlentities($str, ENT_QUOTES);

Valideer data. Zie ctype_*() of filter_var().

Valideer je sessies.
Zorg dat je sessie data niet in een gedeelde map staat.

Voorkom CSRF (google maar) en geef alle belangrijke forms een extra hidden veld met een random waarde die je opslaat in de sessie.

Dat was het nodige, nu voor de paranoia-lijers: gebruik een intrusion detection system (bijv. PHP-IDS), dit check alle input (en evt output) op mogelijke hacks, maar verandert deze niet. Zo heb je een extra beveiliging voor zowel SQL injection als XSS.

Iemand nog iets toe te voegen?

EDIT: En als je toch bezig bent: koop een SSL certificaat ;)
Gewijzigd op 02/07/2010 20:26:45 door Pim -
 
Jan DS

Jan DS

02/07/2010 20:16:02
Quote Anchor link
Wat bedoel je juist met:
"Elke variabele die op een of andere manier van een gebruiken kan komen, moet worden gechecked."
 
Pim -

Pim -

02/07/2010 20:27:05
Quote Anchor link
Typefout ;)
Gebruiken moet gebruiker zijn
 
Mark L

Mark L

02/07/2010 21:38:11
Quote Anchor link
Sessies aan IP koppelen en deze keer op keer controleren, zodat Session-Hijacking erg moeilijk word.
Ook nooit betrouwbare informatie (bijvoorbeeld wachtwoord) in een sessie/cookie zetten. Zelfs niet geëncrypt!

Wachtwoorden altijd ge-hashed in de database voeren.

Edit:
http://www.phphulp.nl/php/tutorial/beveiliging/online-php-spel-beveiligen/489/

Staan ook dingen bij die voor een gewone site goed zijn om te onthouden!
Gewijzigd op 02/07/2010 21:42:06 door Mark L
 
Pim -

Pim -

02/07/2010 21:57:06
Quote Anchor link
Dat eerste is niet per se een goed idee: ip's kunnen wisselen tijdens de sessie... Beter kan je het met $_SERVER['HTTP_USER_AGENT'], doen. Wel een goed idee is, als je echt goede beveiliging wil hebben, een beperkte sessieduur. Dus 15 min inactief = uitgelogd.
Ook kan je bij elke request het sessie id verversen.

http://stackoverflow.com/questions/328/php-session-security
 
Jan DS

Jan DS

04/07/2010 18:46:13
Quote Anchor link
Ik lees dat md5 niet veilig is. Wat moet ik dan gebruiken?
 
Mark L

Mark L

04/07/2010 18:52:05
Quote Anchor link
Naast md5 heb je ook nog sha1 (en vast nog wel meer)

Waarom is md5 niet veilig? Welke bron?
 
Erwin Geen

Erwin Geen

04/07/2010 18:53:06
Quote Anchor link
Pim de Haan op 02/07/2010 21:57:06:
... Beter kan je het met $_SERVER['HTTP_USER_AGENT'], doen...

User agent kan de client aanpassen.

MD5 is waarschijnlijk niet veilig omdat er veel programma's zijn die dat d.m.v. brute-force kunnen achterhalen.
Gewijzigd op 04/07/2010 18:54:42 door Erwin Geen
 
Jan DS

Jan DS

04/07/2010 18:53:46
 

04/07/2010 18:54:35
Quote Anchor link
Och, met een salt is het wel oké. En anders sha1 + salt. Altijd een salt.
En zeker niet twee keer een functie over elkaar gooien (md5(md5() dat zorgt er juist voor dat er minder uitkomsten zijn, aangezien er voor meerdere dingen dezelfde hash kan komen.
Gewijzigd op 04/07/2010 18:56:52 door
 
Wesley Overdijk

wesley Overdijk

04/07/2010 23:42:41
Quote Anchor link
Ja of je vernieuwd gewoon de sessie id om de 15 minuten.
 

04/07/2010 23:59:32
Quote Anchor link
Wesley Overdijk op 04/07/2010 23:42:41:
Ja of je vernieuwd gewoon de sessie id om de 15 minuten.


En dat helpt tegen wat?
Binnen vijftien minuten kan er zo ingebroken zijn, das lang hoor.
 
Johan Dam

Johan Dam

05/07/2010 13:47:30
Quote Anchor link
NOOIT je sessie aan een IP adres koppelen,
IP addressen zijn makkelijk te faken, dus het beschermd een stuk minder goed als je zou denken.

Ook zijn hosting bedrijven die van IP-farms gebruik maken, wat betekend dat een gebruiker iedere request een ander IP heeft. als je sessie aan IP bind dan kan zo'n persoon dus nooit inloggen bv,

hoe je sessie-hijacking dan wel oplost? laat de gebruiker zijn wachtwoord invoeren elke keer dat er iets belangrijks gebeurd (gegevens wijzigen bijvoorbeeld) op die manier kan een aanvaller niks doen als hij een sessie gestolen heeft.

Wat sessie-hijacking betreft is het belangrijker dat je ervoor zorgt dat een aanvaller niks schadelijks kan doen als hij eenmaal binnen is,
Wil je een bankrekening nummer laten zien? laat dan alleen de laatste 4 cijfers zijn en de rest sterretjes, dat soort dingen,

md5 is met bruteforce te kraken ja, net zoals ieder andere hash, een regulatie op het aantal inlog-pogingen is daarom ook handig, maar gezien een bruteforce aanval vanaf meerdere ip's kan komen is het moeilijk om dit effectief tegen te gaan.
 
P Lekensteyn

P Lekensteyn

05/07/2010 17:01:25
Quote Anchor link
error_reporting 30719 (= E_ALL)
display_errors Off
error_log /pad/naar/error_log

Het bestand error_log buiten de webroot plaatsen, en chmod 600, de owner root.
Let op: $_SERVER['HTTP_USER_AGENT'] hoeft niet te bestaan!
Alle HTTP_* headers zijn door de bezoeker aan te passen.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.