PHP en MYSQL – Hoe wachtwoord in de broncode vermijden?

Ik heb een kleine PHP-applicatie die gegevens opslaan in een MySQL -database. Momenteel zijn gebruikersnaam / wachtwoord moeilijk gecodeerd in de PHP-code. Een situatie die ik niet echt leuk vind, bijvoorbeeld, omdat de code ook beschikbaar is in een repository.

Het beste idee dat ik heb, is om de gegevens uit de code naar een configuratiebestand te verplaatsen (uitgesloten van de repository), en op de een of andere manier coderen het, dus is niet direct leesbaar (obfuscation). Is er een beter en gemakkelijk te gebruiken manier om het probleem op te lossen?

$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
if (!$link) { 
    die('Could not connect: ' . mysql_error());
}
mysql_select_db('mydb');

Scope: Ik wil een robuuste, maar ook eenvoudig te gebruiken oplossing vestigen. Ik wil redelijke veiligheid, maar ik heb hier niet om hier zeer vertrouwelijke gegevens.

Opmerking: het wordt niet langer aanbevolen om de mysql_connectFuncties te gebruiken, zie Stack Overloop Vraag Waarom zou ik MySQL_ niet gebruiken Functies in PHP? *. Ik had het Code-voorbeeld kunnen hebben veranderd, maar aangezien sommige opmerkingen hierop noemen, deed ik dat niet. De oorspronkelijke aard van de vraag blijft echter geldig.

Antwoord 1, Autoriteit 100%

De eenvoudigste manier is, zoals u zei, om een ​​configuratiebestand te gebruiken.

Veel frameworks gebruiken dit (zend , Cakephp , Kohana , enz.) En het is de meest gebruikelijke manier om dingen te doen (zelfs in Een niet-PHP-omgeving zoals ASP.NET met zijn web.configbestanden). Hiermee kunt u ook kopiëren over configuratiewaarden van de omgeving naar de omgeving door gewoon de bestanden voor de site te kopiëren, wat een voordeel is over het vertrouwen op de omgevingsvariabelen van de serverinstellingen (die zeer snel verloren zijn en vergeten).

U hoeft zich geen zorgen te maken over obfuscatie van het wachtwoord, omdat het geen wereldtoegankelijk bestand is, het zou zeker geen web toegankelijk moeten zijn. Wat ik hiermee bedoel, is dat u of ofwel een) vertel uw webserver om uw configuratiebestand niet te bedienen (IIS al Dit met web.configbestanden en serveert een HTTP 404.8-status in plaats van de inhoud) of b) Verplaats deze buiten uw web gediende map. Als iemand uw configuratiebestand kan zien, is het erger dan het in uw broncode te hebben.

Het wordt ook een goed idee om een ​​basis (lege / standaard) -versie van het configuratiebestand te hebben en het uit te scheiden per omgevingen, zodat u een ander configuratiebestand kunt hebben voor productie, ontwikkeling en testplatforms .

Een omgevingsvariabele is de meest gebruikelijke manier om onderscheid te maken tussen deze omgevingen, zoiets als de onderstaande code:

// Check if it's been set by the web server
if (!empty($_ENV['ENVIRONMENT'])) {
    // Copy from web server to PHP constant
    define('ENVIRONMENT', $_ENV['ENVIRONMENT']);
}
if (!defined('ENVIRONMENT')) {
    // Default to development
    define('ENVIRONMENT', 'development');
}
// Load in default configuration values
require_once 'config.default.php';
// Load in the overridden configuration file for this environment
require_once 'config.' . ENVIRONMENT . '.php';

Nog een manier die vrij algemeen is, is om een ​​XML-configuratiebestand te gebruiken en alleen te lezen in de waarden die u nodig hebt (het opslaan van een cache-kopie van het configuratiebestand in het geheugen). Dit kan heel gemakkelijk worden beperkt tot alleen belasting in bepaalde waarden, in plaats van willekeurige opname van PHP-bestanden toe te staan ​​en in mijn mening een betere oplossing is, maar het bovenstaande zou u in de goede richting moeten laten beginnen.

U wilt waarschijnlijk dat uw VCShet bestand negeert. Aan de andere kant wil je misschien dat een skelet van het bestand, of een bestand met redelijke standaardwaarden (dit laatste geldt natuurlijk niet voor inloggegevens), versiebeheerst is. Een gebruikelijke manier om daarmee om te gaan is om een ​​ingecheckt sjabloonconfiguratiebestand te hebben, en de installatieprocedure kopieert dat bestand naar de locatie van het echte configuratiebestand, waar het wordt aangepast. Dit kan een handmatig of geautomatiseerd proces zijn.

_{(Hoewel het enigszins losstaat van de hoofdvraag, kun je door een constante voor je omgeving in te voeren, andere coole dingen doen, zoals het uitstellen van een nepmailimplementatie in plaats van een live SMTPéén, maar dit kan natuurlijk ook met een configuratiebestand)}

Antwoord 2, autoriteit 68%

Een mooie oplossing, als je Apache gebruikt, om de informatie op te slaan in de virtualhost-configuratie

SetEnv  MYSQL_USER     "xx"
SetEnv  MYSQL_PASSWORD "y2wrg435yw8"

De gegevens kunnen eenvoudig worden opgehaald met $_ENV[]voor gebruik in de code.

Antwoord 3, autoriteit 16%

Zoals anderen al hebben gezegd, plaats het in een apart configuratiebestand buiten bronbeheer (dit wordt uiteraard vermeld in code die onder bronbeheer staat).

Het is ook een goed idee om het bestand config.phpeen naam te geven in plaats van config.inivoor het geval de directory ooit per ongeluk wordt blootgesteld, wat betekent dat het bestand zal’ niet worden gedownload, maar levert niets op.

Antwoord 4, autoriteit 9%

Als je denkt dat de 12factormanier waardevol is, raden ze aan om de configuratie in de omgeving op te slaan.

Dit heeft als bijkomend voordeel dat u de exact dezelfde codekunt schrijven tijdens het testen of anderszins in een niet-productieomgeving. Als u de database of iets anders wilt (of moet) wijzigen, hoeft u uw code niet aan te passen – u wijzigt gewoon de omgevingsvariabelen en u bent klaar om te gaan.

Antwoord 5, autoriteit 3%

Wat ik zou doen is om alleen een voorbeeldconfiguratiebestand op te slaan in de repository, zoals config.php.dist, en niet om config.php onder versiebeheer te plaatsen.

Antwoord 6, autoriteit 3%

Goede vraag. Je zou de meest gevoelige stukjes (bijv. sleutels/wachtwoorden) naar buiten kunnen verplaatsen als omgevingsvariabelen, maar dat zou het probleem dan alleen maar uitstellen naar je serverconfiguratie (die zich vermoedelijk ook in een repository bevindt).

Je zou ook kunnen proberen om wachtwoorden voor zaken als de database te vermijden, door het wachtwoord minder te maken en het in plaats daarvan achter een firewall te beveiligen. Geen van deze zijn perfecte oplossingen, maar het zijn de benaderingen die ik ken.

Antwoord 7, autoriteit 3%

Het is een goed idee om het wachtwoord van code naar een configuratiebestand te verplaatsen, zodat het wachtwoord niet in de repository staat. Het idee om het te coderen in een configuratiebestand is twijfelachtig, omdat degene die het configuratiebestand + PHP-code heeft die het decodeert, altijd de code kan uitvoeren en een wachtwoord in leesbare tekst kan krijgen. Waarschijnlijk is het beter om het wachtwoord in een configuratiebestand als platte tekst te bewaren en na te denken over hoe u het configuratiebestand kunt beschermen tegen ongeoorloofde toegang.

Antwoord 8

Ik zie niet al dit probleem hier. Als u een repository deelt, wilt u waarschijnlijk niet de wachtwoorden en configuratie hard coderen. U moet in plaats daarvan een standaardwaarde opgeven:

host: localhost
user: root
pass: root
name: db

Als je echt wilt, kun je een .ini-bestand gebruiken en ontleden, maar het is waarschijnlijk erg traag in vergelijking met een array die in de broncode wordt ingesteld en het heeft niet zoveel zin om ik.

Onthoud: het enige dat u kunt vertrouwen, is uw broncode, als ze die kunnen krijgen, bent u toch de pineut.

Antwoord 9

Je kunt altijd een configuratie-ini-bestand maken met de functie parse_ini_file.