veiligheid connectie database

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Carel

Carel

09/01/2008 10:12:00
Quote Anchor link
Ik heb een klein vraagje over database connectie maken. Het onderstaande gebruikt ik als voorbeeld.

mysql_connect('localhost', 'mysql_user', 'mysql_password');

Ik heb deze waarden opgeslagen in een PHP document zodat ik ze niet elke keer hoef in te voeren op elke pagina waar ik connectie wil maken met database. Maar ik vraag me af of dat niet gevaarlijk is, want dan zou iedere gebruiker (indien ze de naam te weten komen van mijn php database connectie PHP document) deze php document kunnen gebruiken om mijn omgeving te vervuilen enz.

Is dit ook zo en zo ja hoe is dit dan op te lossen?
 
PHP hulp

PHP hulp

05/11/2024 14:48:54
 
- wes  -

- wes -

09/01/2008 10:20:00
Quote Anchor link
Nee

Een PHP bestand wordt zeg maar uitgevoerd en de uitkomst daarvan getoond op het scherm. De PHP code zelf is nooit te zien
 
Carel

Carel

09/01/2008 10:26:00
Quote Anchor link
Nee dat bedoel ik niet Wes, ik snap ook dat PHP code nooit te zien is. Maar een hacker kan wel dat PHP document OPVRAGEN zonder die PHP code te hoeven in zien en dan een eigen omgeving creeren om in mijn database te klooien en te doen wat hij wilt. Natuurlijk blijft de vraag hoe hij zijn eigen php document in mijn omgeving zou willen toevoegen, maar goed dat is een ander punt.

Waarschijnlijk is het daarom zo belangrijk om uploads te beveiligen en het niet mogelijk te maken voor gebruikers om PHP documenten te uploaden.
Gewijzigd op 01/01/1970 01:00:00 door Carel
 
Joren de Wit

Joren de Wit

09/01/2008 10:30:00
Quote Anchor link
Allereerst zal in jouw connectie bestandje de hostnaam 'localhost' zijn. De hacker moet dus al een php bestandje op jouw server kunnen uitvoeren.

Verder plaats je dit soort bestandjes altijd buiten je webroot. Op die manier zijn ze alleen vanaf de server zelf en niet van buitenaf te benaderen. Ze kunnen dus ook niet meer geinclude worden in een extern PHP bestand.
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
 
Carel

Carel

09/01/2008 10:44:00
Quote Anchor link
Klink erg interessant Blanche. Ik weet niet zeker of ik je geheel begrijp. Is hier een tutorial ofzo over te vinden?

Is dat eerste punt is dus niet erg positief en het tweede buiten webroot bedoel je buiten public_html. Hoe maak ik dan connectie in mijn public_html met de database als ik het niet meer kan includen?

Wellicht dat ik je verschil tussen intern en extern niet zo goed begrijp....
 
Joren de Wit

Joren de Wit

09/01/2008 10:48:00
Quote Anchor link
Vanaf dezelfde server kun je gewoon bestanden die buiten je public_html staan includen. Voor een script dat in public_html staat, komt dat er dan zo uit te zien:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
include '../includes/db_config.php';
?>

In dit geval zou db_config.php in een map 'include' buiten je public_html map staan...

Het is nu onmogelijk voor iemand vanaf een externe server om dit bestandje te benaderen. Hij heeft enkel toegang tot bestanden en mappen die in jouw webroot (public_html) staan.
 
Hipska BE

Hipska BE

09/01/2008 10:58:00
Quote Anchor link
nog veiliger/beter is het gebruik van de vernieuwe mysql functies van php

mysqli_connect('localhost', 'mysql_user', 'mysql_password');
 
Carel

Carel

09/01/2008 11:01:00
Quote Anchor link
Ok...dat klinkt begrijpelijk. Hoe weet mijn php documenten dat mijn php scripts wel toegestaan zijn om buiten public_html connectie te maken met de db_config.php

Ik denk omdat mijn gegevens (wanneer ik inlog) gekoppeld zijn aan de bestanden die ik upload waardoor mijn php bestanden uniek zijn....

klopt dat of ben ik helemaal gek aan het denken...

Hipska mag ik met die vernieuwde thingie wel mijn database connectie script in public_html zetten?
Gewijzigd op 01/01/1970 01:00:00 door Carel
 
Hipska BE

Hipska BE

09/01/2008 11:09:00
Quote Anchor link
dat mag, maar het is altijd veiliger om erbuiten te zetten...

als je php script in public_html een bestand van daarbuiten wil includen, en het mag niet, dan krijg je een error. Zo weet je of het kan of niet.
(normaal lukt dat altijd)
 
Joren de Wit

Joren de Wit

09/01/2008 11:17:00
Quote Anchor link
@Hipska: bij mysqli_connect() moet je ook al de database opgeven aangezien er geen functie als mysqli_select_db() bestaat.

Maar nog liever zou ik met de object georiënteerde methode werken:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
$mysqli
= new mysqli('host', 'user', 'password', 'database');
?>


Meer informatie kun je vinden in deze MySQLi tutorial.
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
 
Carel

Carel

09/01/2008 11:26:00
Quote Anchor link
Oei bedankt voor de tips, ziet er dusdanig complex uit dat ik nog even op ouderwetse manier werk totdat ik aan een echte website begin. Ik had nog een vraag eerder gesteld en ben nog steeds benieuwd wat het antwoord is:

Hoe weet mijn php documenten dat mijn php scripts wel toegestaan zijn om buiten public_html connectie te maken met de db_config.php

Ik denk omdat mijn gegevens (wanneer ik inlog) gekoppeld zijn aan de bestanden die ik upload waardoor mijn php bestanden uniek zijn....

klopt dat of ben ik helemaal gek aan het denken...
 
Hipska BE

Hipska BE

09/01/2008 11:28:00
Quote Anchor link
@carel: daar had ik al antwoord op gegeven, zie mijn vorige post..

toch raad ik je zeer sterk aan om mysqli te gebruiken, het moet niet volgens de OOP stijl zijn, maar dan kan je overal waar je mysql_... gebruikte vervangen door mysqli_...

verbinden met de DB doe je zo:
mysqli_connect('host', 'user', 'password', 'database');
 
Joren de Wit

Joren de Wit

09/01/2008 11:29:00
Quote Anchor link
Quote:
Ik denk omdat mijn gegevens (wanneer ik inlog) gekoppeld zijn aan de bestanden die ik upload waardoor mijn php bestanden uniek zijn....

Nee, dat komt omdat de bestanden zich binnen hetzelfde filesystem bevinden, ze staan immers op dezelfde server.

Met include kun je alle bestanden includen zolang ze zich binnen hetzelfde filesystem bevinden en zolang je genoeg rechten hebt op de map waarin ze staan...
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
 
Carel

Carel

09/01/2008 11:57:00
Quote Anchor link
Met hetzelfde filesysteem (welke filesysteem?) bedoel je daarmee buiten public_html. Want dan zou ik dus alle php scripts die connectie willen maken met database moeten plaatsen buiten public_html.

Klinkt soms een beetje tegenstrijdig. Eerst moet ik db_connectie buiten public_html zetten voor veiligheid. Vervolgens oproepen in mijn scripts die in public_html staan. MAAR dan wordt hier weer gezegd zolang ze zich binnen hetzelfde filesystem bevinden en zolang je genoeg rechten hebt op de map waarin ze staan. Het 1 spreekt het ander tegen. En dan snap ik nog steeds niet de veiligheidsoplossing want dan kan als iemand ooit achter de locatie met naam php script achterkomt het toch nog steeds op vragen.....Ik bedoel hier worden vaak scripts getoont waarin een databaseconnectie geinclude wordt (en met die gegeven kan je er toch wel in komen?)

Sorry dat ik jullie zo bezig hou maar ik begrijp nog steeds niet de logica. Ik zal die mysql veranderen in mysqli als dat beter is.

En nog iets waarom erbuiten zetten als je ook voor mappen kan cmodden?
 
Joren de Wit

Joren de Wit

09/01/2008 12:02:00
Quote Anchor link
Quote:
Het 1 spreekt het ander tegen.
Nee hoor, alle bestanden en mappen op de server behoren tot het bestandssysteem (filesystem). PHP files die in public_html staan, kunnen in principe in alle mappen op de server komen zolang er genoeg rechten op die map verleend zijn.

Van buitenaf, dus als ik jouw website via internet benader, kan ik alleen bestanden en mappen in je public_html map benaderen. Daarbuiten kan ik nooit komen.

Kortom, includen vanaf dezelfde server gaat wel maar benaderen van buitenaf niet.

ps. Het veranderen naar mysqli is niet enkel het aanpassen van de functienamen. Er zitten nog wel wat andere subtiele verschillen tussen, daar moet je dus wel eerst even naar kijken.
 
Carel

Carel

09/01/2008 12:10:00
Quote Anchor link
wat jij zegt is dus alleen als mensen vanaf binnenaf een php script kunnen plaatsen in mijn public_html gebruik kunnen maken van mijn databaseconnectie.

Dus als ze een php script in 1 van mijn mappen kunnen plaatsen omdat ik daar bijv cmod daar 777 heb staan kunnen ze wel mijn database benaderen. Aan mij de taak om ervoor te zorgen dat gebruikers en anderen geen php documenten kunnen uploaden naar mijn public_html dus....

ik zal nog eens kijken naar die mysqli dan overigens.
 
Joren de Wit

Joren de Wit

09/01/2008 12:13:00
Quote Anchor link
Het mag natuurlijk nooit mogelijk zijn dat anderen op welke plaats dan ook PHP bestanden kunnen plaatsen en uitvoeren. Behalve dat ze dan toegang tot je database kunnen krijgen, hebben ze in ieder geval al toegang tot je bestandssysteem.

En geloof me, daar is al genoeg schade aan te richten, ook al heb je geen toegang tot de database.
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
 
Carel

Carel

09/01/2008 19:07:00
Quote Anchor link
Hey bedankt voor de uitleg en tips. Ik had alleen nog een vraagje voor het plaatsen van mijn database connectie buiten public_html. Wat voor soort chmod nummer ik moet gebruiken voor de map waarin de database connectie in staat.

En nog 1 ding. Je zei "Kortom, includen vanaf dezelfde server gaat wel maar benaderen van buitenaf niet." Wat bedoel je met buitenaf? Is dat buiten mijn public_html bij de mensen zelf of zie buitenaf als in mijn public_html.

Als het bij de mensen zelf is en niet binnen public_html begrijp ik het wel.

Bedankt
 
Joren de Wit

Joren de Wit

09/01/2008 19:11:00
Quote Anchor link
Van buitenaf: niet van de eigen server. Dus door personen/scripts/servers van buiten...

Jouw webroot staat niet bij mensen zelf, ze benaderen jouw website alleen via het internet. Standaard zullen ze dan in de webroot (jouw public_html) uitkomen en benaderen ze jouw server dus van buitenaf.

Welke chmod je die map geeft maakt niet zo heel veel uit, 755 zou prima zijn...
 



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.