Is het inderdaad veilig of ontbreekt er nog wat?
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 " en < wordt <
- 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!
- Sterkte van de sessie-ID?
- Multi-factor authentication (MFA)?
- Wachtwoordbeleid?
- Frame hijacking?
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
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)
Gewijzigd op 04/06/2014 15:30:05 door Dos Moonen
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?
- 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 - -
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!
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.
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.
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.
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 Mark Hogeveen
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:
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)?
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.
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.
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.
Ward van der Put op 04/06/2014 18:00:08:
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.
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+)
De manier waarop je wachtwoorden hasht is 'snel', vertraag het aub door het bijvoorbeeld 8000 keer te hashen of Bcrypt/Scrypt te gebruiken.