[PHP/(My)SQL] voor dummies - Deel 44

quote:

Op donderdag 31 mei 2007 14:23 schreef Hmail het volgende:

[..]

Wat voor type user is het? Dat kun je in PHPMyAdmin checken onder Database->Privileges. In mijn geval is het een Database-specific user. Check dat even

Bij database specifieke rechten stond alleen de tabel die de gebruiker 'pietje' ook daadwerkelijk mag gebruiken. Deze heb ik voor te testen even weggehaald, met als resultaat dat wanneer je als 'pietje' inlogt, nu alléén maar database information_schema ziet. Verder staat er bij database specifieke rechten niets.

EDIT: Ook al geprobeerd de gebruiker te verwijderen en opnieuw toe te voegen, met alleen hetzelfde resultaat. :/

Nog een edit: Als ik bij databases ga kijken bij het schermpje Gebruikers die toegang hebben tot "information_schema" dan staat gebruiker 'pietje' hier ook echt niet bij, zoals bij de rest van de tabellen die wél netjes verborgen worden, wel het geval is.

[ Bericht 10% gewijzigd door Tuvai.net op 31-05-2007 14:57:54 ]

In mijn geval ziet het database-privleges scherm er zo uit. Het gaat om de gemaskeerde naam:

quote:

Op donderdag 31 mei 2007 15:07 schreef Hmail het volgende:
In mijn geval ziet het database-privleges scherm er zo uit. Het gaat om de gemaskeerde naam:
[afbeelding]

Dat heb ik ook staan bij de betreffende database waar de betreffende user wél toegang toe moet hebben. Maar bij 'information_schema' staat niks verdachts, toch is deze gewoon toegankelijk door de betreffende user terwijl dat niet de bedoeling zou moeten zijn.

Het beheerscherm van de user-privileges op de mysql-server. Misschien dat daar iets anders is?

INFORMATION_SCHEMA is een speciale database waarvan de inhoud verandert aan de hand van de rechten die de gebruiker heeft. Die blijf je dus altijd zien, is sinds MySQL 5 als ik me niet vergis

Wat is dan de functie van die database als je die toch (niet kan) gebruik(t/en)...

verdorie, je hebt gelijk
Inderdaad, ik heb ook een information_schema, sorry

quote:

Op donderdag 31 mei 2007 15:51 schreef JeRa het volgende:
INFORMATION_SCHEMA is een speciale database waarvan de inhoud verandert aan de hand van de rechten die de gebruiker heeft. Die blijf je dus altijd zien, is sinds MySQL 5 als ik me niet vergis

Verrek, dat heb ik ook nog gelezen ook nog. Ik bleef het toch proberen omdat mijn webhost die database niet doet weergeven, maar ik zie nu pas dat die nog op een MySQL 4.x.x versie draait.

Nou ja, in ieder geval draait alles nu. Ik zal uiteraard nog wat gaan spelen met de configuratie zodat ik ook zie hoe PHP vanaf de serverkant werkt. Ben in ieder geval blij dat 't nu loopt.

quote:

Op donderdag 31 mei 2007 16:05 schreef Chandler het volgende:
Wat is dan de functie van die database als je die toch (niet kan) gebruik(t/en)...

Je kunt hem wel gebruiken, en INFORMATION_SCHEMA geeft informatie over je rechten, databases, tabellen, etcetera het is een alternatief voor de niet-standaard SHOW-syntax.

Vandaag ben ik verder met een usersysteem gegaan, en vroeg mij af of de volgende methode veilig is:

De user probeert in te loggen. Ik vang de $_POST op, encrypt het password direct naar md5, en stuur het naar de functie checkLogin.

checkLogin():
Als de username en het password matchen met de database:
-De sessie variabele UsernameSession en PasswordSession aanmaken en invullen.
-Een cookie met een random string wordt gezet.
-Dezelfde random string en het IP-adres van de gebruiker in de database zetten.
-Inloggen.

--------------

Of: De user komt terug, en heeft een cookie meegenomen:

checkCookie()
Als de random string in de cookie en het IP-adres van de gebruiker matchen met de database:
-De sessie variabele UsernameSession en PasswordSession aanmaken en invullen.
-Inloggen.

--------------

De user opent een pagina, de functie checkCredentials wordt aangeroepen.

checkCredentials()
Kijkt of de username en password uit de sessie gecombineerd met het IP-adres van de gebruiker in de database aanwezig is, zo ja:
-UserID en Userlevel teruggeven

Tussentijdse passwordwijzigingen, of een wijziging in userlevel, wordt hier mee opgevangen.

--------------


Misschien ga ik de unieke key in de cookie nog een timeout geven (databaseveld), om het extra hufterproof te maken. Dit systeem lijkt mij aardig veilig?

Waarom sla je de username/password op in de sessie? Het lijkt mij dat alleen een userID voldoende is. Daarnaast lijkt het mij verstandig om het IP uit de cookie te laten, die kun je opvragen met $_SERVER['REMOTE_ADDR']. Zo voorkom je dat een cookie gestolen word, en vanaf een ander IP aangepast en misbruikt word

Het IP adres haal ik uiteraard uit REMOTE_ADDR, daar had ik aan gedacht.

Wat het userid betreft, daar had ik eigenlijk totaal nog niet aan gedacht. Meer vanuit een menselijke denkwijze dacht ik er zelf meer aan het username / password te laten onthouden, zoals je dat zelf ook zou doen. Een goede tip, bedankt

je kunt wel een hash maken waarbij je de username + ip + id hasht.. deze controlleer je dan weer met de usernaam + $_SERVER['REMOTE_ADDR'] + id oid..

Zat mogelijkheden

quote:

Op donderdag 31 mei 2007 20:46 schreef Chandler het volgende:
je kunt wel een hash maken waarbij je de username + ip + id hasht.. deze controlleer je dan weer met de usernaam + $_SERVER['REMOTE_ADDR'] + id oid..

Zat mogelijkheden

Ik ben niet bekend met hashen, maar je zet deze vijf variabelen tot een lange string tekst om, wat je vervolgens weer terugdecodeerd naar vijf losse variabelen?

quote:

Op donderdag 31 mei 2007 20:46 schreef Chandler het volgende:
je kunt wel een hash maken waarbij je de username + ip + id hasht.. deze controlleer je dan weer met de usernaam + $_SERVER['REMOTE_ADDR'] + id oid..

Zat mogelijkheden

Waarna de "hacker" vervolgens een hash maakt van de username + ip + id van "het slachtoffer" hasht, en vervolgens dus niet eens de moeite hoeft te doen voor het stelen van een cookie

Serieus, je moet geen gegevens die te achterhalen zijn gaan achterlaten in een hash, of je moet er een hash overheen halen met een willekeurig iets. Zo'n hash moet altijd random zijn, en niet na te maken door de user. Je moet er eigenlijk van uit gaan dat de potentiële hacker alles al weet. Van jou weet ik bijvoorbeeld al je username en id. Ik zet mijn ip in de var, en hebbes, ik heb adminrechten. You see?
Je kunt het wel een beetje afdekken door die var in de database te zetten, maar dan ben je dus het ene lek met het andere aan het dichten. Random is the keyword.

quote:

Op donderdag 31 mei 2007 20:51 schreef Geqxon het volgende:

[..]

Ik ben niet bekend met hashen, maar je zet deze vijf variabelen tot een lange string tekst om, wat je vervolgens weer terugdecodeerd naar vijf losse variabelen?

Exact. Iets a la:

Je krijgt dat een variabele waar de meeste users geen kaas van hebben gegeten, en gokken hoe het word opgebouwd is lastig. Maar daar moet je niet op vertrouwen, want als ik dit weet, zet ik gewoon md5('Chandler'.'6897'.'127.0.0.1') (waarbij we dan even aannemen dat dat mijn ip is), en dat zet ik in mijn cookie neer. Voila, adminrechten

[ Bericht 39% gewijzigd door Hmail op 31-05-2007 21:32:14 ]

quote:

Op donderdag 31 mei 2007 20:51 schreef Geqxon het volgende:

[..]

Ik ben niet bekend met hashen, maar je zet deze vijf variabelen tot een lange string tekst om, wat je vervolgens weer terugdecodeerd naar vijf losse variabelen?

Nee, een hash is one-way. Terugcoderen vanuit een hash naar de losse variabelen is nagenoeg niet mogelijk; terugcoderen naar een wachtwoord is soms wel mogelijk met behulp van reverse lookup tables

Maar goed, naast het hashen, als ik mijn methode aanpas zodat in de PHP-sessie enkel het user-id doorgegeven wordt, is het voor een website a 1000 leden dan veilig genoeg?


_{P.s.: REPLACE in MySQL zuigt. Just so you know.}

Ik hash altijd het wachtwoord in combinatie met een secret word, wat per website wisselt uiteraard
Heb er zelf nog wel eens last van wanneer ik via PMA het wachtwoord wil aanpassen en het secret word niet meer wist

Heb weinig ervaring met inloggen via cookies, de meeste systemen die ik bouw hebben dat niet nodig of het is niet wenselijk dat er automatisch ingelogd wordt Ik vertrouw het ook niet heel erg moet ik zeggen, niet vanwege het onderscheppen van de info, maar meer dat iemand die bij die computer loopt gewoon in het systeem kan...

Weet iemand het volgende:

Wanneer ik drie stringen heb in php

dag = 2
maand = 4
jaar = 1971

Hoe kan ik deze dan inserten in MySql in een veld gedecrlareerd als datetime?


-edit-
Gevonden, gewoon met 1971-4-2

[ Bericht 12% gewijzigd door Skorpija op 03-06-2007 16:38:42 ]

quote:

Op zondag 3 juni 2007 16:18 schreef Skorpija het volgende:
Weet iemand het volgende:

Wanneer ik drie stringen heb in php

dag = 2
maand = 4
jaar = 1971

Hoe kan ik deze dan inserten in MySql in een veld gedecrlareerd als datetime?


-edit-
Gevonden, gewoon met 1971-4-2

Of gewoon mktime() gebruiken zodat je mooi een UNIX timestamp krijgt.

quote:

Op zondag 3 juni 2007 19:53 schreef Tuvai.net het volgende:

[..]

Of gewoon mktime() gebruiken zodat je mooi een UNIX timestamp krijgt.

Maar dat past niet in een datetime (of date) veld in MySQL.

Ordinaire terug vind post

Het valt een beetje dood hier, en zag net al twee verdwaalde PHP-topics in DIG staan. Dus bij deze een kick.

PHP 6 gaat ruig worden. Clean-slate style, rotzooiscripts van de PHP4 tijd gaan dus mooi niet werken. Niks te ge register-globals, of safe-mode.

Nice!

quote:

Op zondag 10 juni 2007 01:24 schreef Geqxon het volgende:
PHP 6 gaat ruig worden. Clean-slate style, rotzooiscripts van de PHP4 tijd gaan dus mooi niet werken. Niks te ge register-globals, of safe-mode.

Nice!

Naast de overduidelijk positieve dingen zijn er mijns inziens ook wat negatieve:

Ze proberen meer OOP in PHP te brengen maar houden tegelijkertijd de lowlevel functies met een compleet gebrek aan naming guidelines (ala strlen(), count(), etc) in het pakket - het ene uiterste versus het andere uiterste

De meeste mensen/providers hadden al moeite om naar PHP5 over te schakelen, terwijl de backwards compatibility optimaal was (op één of twee dingetjes na). Ik vrees ervoor dat het een lange tijd gaat duren voordat men overschakelt op PHP6, nog langer dan PHP5 (wat nog steeds niet helemaal doorgedrongen is).

De afwezigheid van de mogelijkheid om platformafhankelijke binairies te maken; doordat encryptie/compilatie van PHP-files vrijwel altijd gelimiteerd blijft tot opcodes is een goede beveiliging nog steeds erg lastig in te bouwen.

Wat OOP betreft zijn de functies als strlen() en count() vrij "achterlijk", aangezien dat naar mijn mening methodes moeten zijn die bij een string/int/array horen. Dus de string "$filename", de length daarvan moet op te vragen zijn door "$filename.getLength()".

Goed, dat is tenminste hoe ik met Java werk, en wat ik in PHP erg fijn zou vinden. Het enige nadeel hiervan is dat het in zijn totaliteit minder flexibel wordt, maar qua structuur een stuk strakker.

Omdat je ook wel een de grootte van een array of string wil berekenen, die je niet uit mysql haalt?

quote:

Op zondag 10 juni 2007 01:36 schreef Geqxon het volgende:
Wat OOP betreft zijn de functies als strlen() en count() vrij "achterlijk", aangezien dat naar mijn mening methodes moeten zijn die bij een string/int/array horen. Dus de string "$filename", de length daarvan moet op te vragen zijn door "$filename.getLength()".

Goed, dat is tenminste hoe ik met Java werk, en wat ik in PHP erg fijn zou vinden. Het enige nadeel hiervan is dat het in zijn totaliteit minder flexibel wordt, maar qua structuur een stuk strakker.

Java is dan ook OO. Op een handjevol uitzonderingen na is het altijd nodig om een object te maken. Dan kun je dus in de class van het object ook de bijbehorende functies zetten. Of het daardoor minder flexibel wordt, weet ik zo niet.