Is het inderdaad veilig of ontbreekt er nog wat?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Kevin Meeuwisse

Kevin Meeuwisse

04/06/2014 15:08:29
Quote Anchor link
Hallo,

Onlangs heb ik een heel systeem (PHP, MySQL, JavaScript, HTML, CSS) gemaakt waar mensen kunnen inloggen facturen in kunnen zien, tickets kunnen aanmaken etc. echter is mijn vraag; Is hij wel veilig?!

Wat gebruik ik;

- PDO, Incl. Prepared statements
- Special Character filter, alles wordt omgezet VOORDAT het in een Query komt. Bijv. " wordt &quot; en < wordt &lt;
- Aan bijv facturen en berichten geef ik 2 random md5 hashes mee, deze hashes moeten correct zijn in combinatie met het klantnummer.
- Eventuele parameters die in de URL gegeven zijn worden eerst Special Character gefilter VOORDAT het in de Query komt.
- Prepared Statements worden gebruikt.
- Bij het inloggen wordt en een random session_hash gegenereerd, als men uitlogt en weer inlogt heeft men een andere session_hash. Zover ik weet is session hijacking dus niet mogelijk omdat de session ids wisselen.
- IP wordt gelogd tijdens het inloggen, hierin wordt ook aangegeven of de login succesvol was of niet en als er een klant bestaat met het email ook het klantnummer waar de login betrekking op heeft.
- De admin interface wordt gecheckt of het IP juist is, is dit niet het geval dan wordt je naar de error pagina gestuurd.

Voor zover ik weet is hij nu dus enkel vurnirable als je in de server komt omdat;

- Alles eerst gefilterd wordt en geprepared is.
- XSS is niet mogelijk doordat JavaScript niet uitgevoerd wordt dankzei de filtering van onder andere < en >.
- Sessie Hijacking is niet mogelijk doordat de sessie id steeds veranderd.
- Ik heb er met Havij Pro opgezeten, deze gaf naar herhaaldelijk proberen steeds een error terug dat hij niks kon vinden

Mijn vraag is, kloppen mijn veronderstellingen en is hij inderdaad veilig? (Ik weet ook wel dat niks 100% safe is natuurlijk) Maar ik wil gewoon zeker weten dat hij niet makkelijk te hacken is.

Graag hoor ik van jullie!
 
PHP hulp

PHP hulp

11/04/2021 23:59:30
 
Ward van der Put
Moderator

Ward van der Put

04/06/2014 15:24:19
Quote Anchor link
- SSL?
- Sterkte van de sessie-ID?
- Multi-factor authentication (MFA)?
- Wachtwoordbeleid?
- Frame hijacking?
 
Dos Moonen

Dos Moonen

04/06/2014 15:27:07
Quote Anchor link
Quote:
XSS is niet mogelijk doordat JavaScript niet uitgevoerd wordt dankzei de filtering van onder andere < en >.

Er is genoeg XSS mogelijk met iets als
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<a href=<?php echo htmlspecialchars($value, ENT_QUOTES, "UTF-8"); ?> id=miauw>bla</a>


Verder vindt ik het lelijk dat je data VOORDAT het de query in gaat al geschikt maakt voor HTML. Je database is niet HTML, maak de data geschikt voor de database en laat het daarbij. Op het moment dat het is HTML moet komen maak je het geschikt voor HTML!


Heb je een login systeem? Zo ja, hoe sla je het wachtwoord op?

Wat je zou kunnen doen om xss extra moeilijk te maken is de Content-Type op application/xhtml+xml zetten als de browser via de Accept header aangeeft dit te ondersteunen. Het is wel dat je html well-formed moet zijn. Dit zou je als voordeel of als nadeel kunnen beschouwen, dat is een persoonlijke mening.

Toevoeging op 04/06/2014 15:29:18:

Ward van der Put op 04/06/2014 15:24:19:
- Wachtwoordbeleid?

Dat hoort zo simpel te zijn als minimaal 12 tekens. En een maximum van 1KiB ofzo (aantal tekens hangt dan van de encoding af)
http://imgs.xkcd.com/comics/password_strength.png
Gewijzigd op 04/06/2014 15:30:05 door Dos Moonen
 
Kevin Meeuwisse

Kevin Meeuwisse

04/06/2014 15:33:53
Quote Anchor link
Hartelijk dank voor je reactie.

Ik heb inderdaad een login systeem, deze hasht het wachtwoord naad SHA512, daarna wordt er een random hash aangemaakt en die 2 hashes samen worden nog een keer gehasht in SHA512 en dat wordt het wachtwoord voor in de database.
De hash waarmee het wachtwoord wordt gehash sla ik eveneens op in de database omdat je ander nooit zou kunnen inloggen.

-- Edit

Het wachtwoord moet minimaal 6 characters lang zijn waaronder minimaal 1 hoofdletter, 1 kleine letter, 1 cijfer en 1 special character

Toevoeging op 04/06/2014 15:44:41:

Ward van der Put op 04/06/2014 15:24:19:
- SSL?
- Sterkte van de sessie-ID?
- Multi-factor authentication (MFA)?
- Wachtwoordbeleid?
- Frame hijacking?


- SSL Certificaat heb ik nog niet aangeschaft. Geeft dit echt een toegevoegde waarde? Ik had namelijk op een forum gelezen dat het niet zoveel uitmaakt weet 1..2..3.. zo niet welke
- Sessie-ID is 32 characters lang. Cijfers/letters
- MFA Weet ik letterlijk niks van, is dit serverside?
- Wachtwoord beleid; minimaal 6 characters, minimaal 1 hoofdletter, minimaal 1 kleine letter, minimaal 1 cijfer, minimaal 1 special character
- Frame hijacking is een goede! Hier had ik nog niet aan gedacht, als ik de JavaScript(3 codes) om dit te blokkeren toevoeg is dit dan voldoende?
Gewijzigd op 04/06/2014 15:35:52 door Kevin Meeuwisse
 
Dos Moonen

Dos Moonen

04/06/2014 15:48:43
Quote Anchor link
Quote:
Het wachtwoord moet minimaal 6 characters lang zijn waaronder minimaal 1 hoofdletter, 1 kleine letter, 1 cijfer en 1 special character

Bah... maar tenminste geen maximum lengte van 16 tekens zoals die rot policy van Microsoft!
 
Ward van der Put
Moderator

Ward van der Put

04/06/2014 16:17:38
Quote Anchor link
>> SSL Certificaat heb ik nog niet aangeschaft. Geeft dit echt een toegevoegde waarde?

Zonder SSL-verbinding is het vrij eenvoudig voor een derde om gebruikersnaam en wachtwoord af te lezen uit het HTTP-request. Zonder dataverkeer met encryptie kun je een site eigenlijk nauwelijks fatsoenlijk beveiligen.

>> Sessie-ID is 32 characters lang. Cijfers/letters

Met session.hash_function kun je de (standaard) MD5-hash van de sessie-ID vervangen door bijvoorbeeld sha512.

>> MFA Weet ik letterlijk niks van, is dit serverside?

MFA (multi-factor authentication) gebruikt altijd twee of meer verificaties. Bijvoorbeeld bij internetbankieren kun je kritieke handelingen nooit uitsluitend met gebruikersnaam en wachtwoord uitvoeren: er is nog een tweede factor nodig, bijvoorbeeld een sms met een unieke TAN-code of de verificatie van een bankpas met een kaartlezer.

Als je systeem vergelijkbare kritieke onderdelen bevat, is een two-factor authentication wel aan te bevelen.
 
Harry hogeveen

harry hogeveen

04/06/2014 17:38:38
Quote Anchor link
Waarom altijd IP's opslaan? Dat lijkt me alleen nuttig als je het gebruikt om ergens mee te vergelijken, bijvoorbeeld om het maximaal aantal login pogingen bij te houden. Verder zegt een IP toch bijna niks?
 
Obelix Idefix

Obelix Idefix

04/06/2014 17:43:51
Quote Anchor link
IP: schijnt sowieso te kunnen wisselen.
En wat als ik met mijn laptop onderweg ben en eerst inlog op het werk. Daarna 's avonds thuis.
En wat met bv. een bedrijf of school; die zitten doorgaans achter 1 IP adres, maar kunnen vele gebruikers achter schuil gaan.
 
Harry hogeveen

harry hogeveen

04/06/2014 17:47:02
Quote Anchor link
Obelix en Idefix op 04/06/2014 17:43:51:
IP: schijnt sowieso te kunnen wisselen.
En wat als ik met mijn laptop onderweg ben en eerst inlog op het werk. Daarna 's avonds thuis.
En wat met bv. een bedrijf of school; die zitten doorgaans achter 1 IP adres, maar kunnen vele gebruikers achter schuil gaan.

Ja, daarom.

Maar als iemand met het verkeerde IP op het admin gedeelte komt, wordt hij dus naar een error pagina gestuurd. Wordt je dan alleen geredirect, of wordt echt de output/input geblokkeerd (zoals het zou moeten)?
Gewijzigd op 04/06/2014 17:47:15 door harry hogeveen
 
Kevin Meeuwisse

Kevin Meeuwisse

04/06/2014 17:58:24
Quote Anchor link
Harry hogeveen op 04/06/2014 17:38:38:
Waarom altijd IP's opslaan? Dat lijkt me alleen nuttig als je het gebruikt om ergens mee te vergelijken, bijvoorbeeld om het maximaal aantal login pogingen bij te houden. Verder zegt een IP toch bijna niks?


Mocht iemand anders inloggen op een account met user level dan krijgt deze persoon direct een email naar zijn telefoon dat er iemand op zijn/haar account is ingelogd vanaf een ander IP. Vervolgens kunnen ze kiezen of dit klopt of dat daadwerkelijk iemand anders erop inlogt en dan wordt het account geblokkeerd

Toevoeging op 04/06/2014 17:59:43:

Harry hogeveen op 04/06/2014 17:47:02:
Obelix en Idefix op 04/06/2014 17:43:51:
IP: schijnt sowieso te kunnen wisselen.
En wat als ik met mijn laptop onderweg ben en eerst inlog op het werk. Daarna 's avonds thuis.
En wat met bv. een bedrijf of school; die zitten doorgaans achter 1 IP adres, maar kunnen vele gebruikers achter schuil gaan.

Ja, daarom.

Maar als iemand met het verkeerde IP op het admin gedeelte komt, wordt hij dus naar een error pagina gestuurd. Wordt je dan alleen geredirect, of wordt echt de output/input geblokkeerd (zoals het zou moeten)?


De user met Admin level kan zelf IP adressen instellen die toegang krijgen tot de admin functies. Als een admin vooraf geen toestemming heeft gegeven om dit IP adres toe te staan dan zijn de input/output automatisch geblokkeerd en wordt er een error pagina ingeladen.
 
Ward van der Put
Moderator

Ward van der Put

04/06/2014 18:00:08
Quote Anchor link
Harry hogeveen op 04/06/2014 17:38:38:
Waarom altijd IP's opslaan? Dat lijkt me alleen nuttig als je het gebruikt om ergens mee te vergelijken, bijvoorbeeld om het maximaal aantal login pogingen bij te houden. Verder zegt een IP toch bijna niks?

Als je achteraf patronen wilt kunnen vinden in hackpogingen en andere soorten misbruik, is het wel verstandig ook IP-adressen op te slaan in een activiteitenlog. Bij onderzoek naar bijvoorbeeld oplichting is de recherche je erg dankbaar als je zo'n log kunt overleggen.
 
Kevin Meeuwisse

Kevin Meeuwisse

04/06/2014 18:03:43
Quote Anchor link
Ward van der Put op 04/06/2014 18:00:08:
Harry hogeveen op 04/06/2014 17:38:38:
Waarom altijd IP's opslaan? Dat lijkt me alleen nuttig als je het gebruikt om ergens mee te vergelijken, bijvoorbeeld om het maximaal aantal login pogingen bij te houden. Verder zegt een IP toch bijna niks?

Als je achteraf patronen wilt kunnen vinden in hackpogingen en andere soorten misbruik, is het wel verstandig ook IP-adressen op te slaan in een activiteitenlog. Bij onderzoek naar bijvoorbeeld oplichting is de recherche je erg dankbaar als je zo'n log kunt overleggen.


Inderdaad, de user met Admin level krijgt een overzicht met login pogingen en als er herhaaldelijk op het zelfde account is ingelogd met het zelfde IP dan worden er stappen ondernomen als de user geregistreerd is, als dit niet het geval is wordt het IP adres geweerd van de website. (Met herhaaldelijk foutief inloggen heb ik het over 20+)
 
Dos Moonen

Dos Moonen

05/06/2014 08:30:10
Quote Anchor link
Oh, vreemd dat ik dit eerder niet gemeld hebt:
De manier waarop je wachtwoorden hasht is 'snel', vertraag het aub door het bijvoorbeeld 8000 keer te hashen of Bcrypt/Scrypt te gebruiken.
 



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.