| Autor | Zpráva | ||
|---|---|---|---|
| Tori Profil |
#1 · Zasláno: 31. 1. 2011, 20:05:27 · Upravil/a: Tori
Pěkný večer,
zajímalo by mne, kam ukládáte přístupové údaje k databázi, případně jiné citlivé údaje (samostatné soubory pro localhost/production, natvrdo do loaderu aplikace (+podmínka zjišťující server), či jinak? Je na toto nějaká best practice? :) A jak to případně řeší OS projekty s veřejným repozitářem? edit: ↓ Myslela jsem např.údaje, které použiji v mysql_connect. |
||
| l564 Profil |
#2 · Zasláno: 31. 1. 2011, 21:13:34
No přístupové hesla mám v hlavě.
A přistupové hesla od registrací na web stránkach se zahashované ukládají do MySql databáze |
||
| Radovan789 Profil * |
#3 · Zasláno: 31. 1. 2011, 22:19:27
Tori:
Problém je když Apache nezpracuje php soubor a nabídne ho uživateli ke stažení (šance cca 99,98% a většinou záleží na zatížení, tím pádem u kvalitního hostingu nemožné). Když budeš hesla includovat přes cizí soubor: udajekpripojeni.php obsahuje: $host = "localhost"; $jmeno = "jmeno"; $heslo = "heslo"; index.php obsahuje:
include_once("include/udajekpripojeni.php");
mysql_connect($host,$jmeno,$heslo);
Tak je to mnohem bezpečnější řešení, když uživatel stáhne soubor index.php tak tam uvidí jen include a proměnné. Jenže co když uživatel bude refreshovat stránku include/udajekpripojeni.php dokud se mu nenabídne na uložení do počítače ? Pokud nejseš banka nebo vydělávající institut s měsíčním příjmem nad 100k tak bych to nechal bejt, protože formou include to má skoro každý web a ještě se nic špatného nestalo. Jinačí forma útoku než chyba Apache mě nenapadá (bavíme-li se pouze o kódu uvedeném výše). |
||
| Alphard Profil |
#4 · Zasláno: 31. 1. 2011, 22:41:24
Tori:
Obvykle se používají konfigurační soubory, např. config.ini. Ty jsou samozřejmě uložené v adresáři aplikace, kam je zakázán přístup zvenku. Pokud jde o development/production verzi, je více možností. Mohou být samostatné soubory, nebo je vše v jednom a aplikace si vybere, který použije. |
||
| dan55 Profil |
#5 · Zasláno: 1. 2. 2011, 07:44:59
Radovan789:
„Tak je to mnohem bezpečnější řešení, když uživatel stáhne soubor index.php tak tam uvidí jen include a proměnné.“ Tak je lepší adresáři include zakázat přístup z venku v .htacces, nebo např. v index.php definovat nějakou proměnnou a v udajekprupojeni.php ověřit, jestli existuje. |
||
| Liennie Profil |
#6 · Zasláno: 1. 2. 2011, 15:46:59
Radovan789:
„Problém je když Apache nezpracuje php soubor a nabídne ho uživateli ke stažení“ Tohle se mi párkrát stalo, ze zvědavosti jsem dal uložit a server mi odeslal prázdný dokument, takže myslím, že je hodně malá šance, že by uživatel něco zjistil. |
||
| l564 Profil |
#7 · Zasláno: 1. 2. 2011, 15:51:12 · Upravil/a: l564
Celý config.php soubor
<?
$server = "localhost"; // jméno serveru
$login = "test"; // přihlašovací jméno
$heslo = "test"; // heslo
$databaze = "db"; // název databáze
MySQL_Connect($server, $login, $heslo) or die("Nepodařilo se připojit k databázi"); // připojení k databázi
MySQL_Select_DB($databaze) or die("Nepodařilo se otevřít databázi"); // výběr databáze
?> Doplnění : Já mám na webu svým složku , a tam mám všechny config.php uložené , ta složka je chráněná .htaccess a mám tam pak ještě deny all |
||
| Tomashekk Profil |
#8 · Zasláno: 2. 2. 2011, 00:47:22
l564:
jak to tam přesněji je prosím? když to co chci ochránit dám do např. složky inc tak htaccess dám také do té složky? |
||
| Alphard Profil |
#9 · Zasláno: 2. 2. 2011, 00:53:23
Tomashekk:
Ano, typicky u návrhu MVC je zakázán přístup všude kromě www/public/… na jménu nezáleží. Konfigurační soubor bývá většinou v adresáři aplikace, třeba app. Ukázka konfiguračního souboru, který jsem měl na mysli já, je třeba na http://doc.nette.org/cs/nette-environment. Není tam žádné PHP, jen konfigurační data. |
||
| Tomashekk Profil |
#10 · Zasláno: 2. 2. 2011, 01:05:29
Alphard:
ok, takže po tom $config = Config::fromFile('config.ini');
Debug::dump((array) $config);s tím htaccess jsem celkem naštíru. takže tam zakážu přístup do všech podsložek krom rootu (tam kde je index)?? |
||
| Alphard Profil |
#11 · Zasláno: 2. 2. 2011, 01:15:17
Tomashekk:
> $config = Config::fromFile('config.ini'); > Debug::dump((array) $config); Pokud máte načtené Nette. Já jsem to odkazoval kvůli ukázce configu, kód není standardní součástí PHP. „s tím htaccess jsem celkem naštíru. takže tam zakážu přístup do všech podsložek krom rootu (tam kde je index)?“ Stačí do .htaccess vložit Order Allow,Deny Deny from all Častá adresářová struktura MVC návrhu je např. app libs log temp www tohle je v rootu, přístupné je pouze www (kde jsou kromě indexu už jen veřejné věci jako CSS, JS, obrázky, …). Pokud hosting neumožňuje tohle nastavení, lze za www považovat root, na zakázání přístupu do dalších adresářů to nemá vliv. |
||
| Tomashekk Profil |
#12 · Zasláno: 2. 2. 2011, 01:17:49
Alphard:
„Pokud máte načtené Nette. Já jsem to odkazoval kvůli ukázce configu, kód není standardní součástí PHP.“ A když nette nevyužívám :) .. já to vše mám v config.php a je to čisté php. V podstatě bych to tak mohl nechat ne? A zda ano, tak toto mohu uložit i do té složky app? |
||
| Alphard Profil |
#13 · Zasláno: 2. 2. 2011, 01:29:50
Tomashekk:
Samozřejmě, že to jde i bez Nette. Můžete sám parsovat config, můžete to mít v PHP. Tori tady položila zajímavý dotaz, ke kterému jsem chtěl připsat, jak se to často dělá. Použil jsem příklad z Nette, ale stejné je to v Zendu a dalších. Pokud jde o ukládání, tak přípona .php do jisté míry snižuje šanci, že vám to někdo stáhne (na kvalitní hostingu se to nesmí stát ani při vytížení). Zakazovat přístup do adresářů, ve kterých nemá uživatel, co dělat je běžná praxe, ať už používáte framework, nebo ne. |
||
| Tomashekk Profil |
#14 · Zasláno: 2. 2. 2011, 01:34:46
Alphard:
já jsem koukal na náš hosting... a mám tam pouze složku home a další nejdou vytvořit... ovšem jak k této složce mám přistupovat? |
||
| Alphard Profil |
#15 · Zasláno: 2. 2. 2011, 01:59:16
|
||
| Tori Profil |
#16 · Zasláno: 2. 2. 2011, 19:22:31 · Upravil/a: Tori
Alphard:
Moc děkuji (i ostatním). Ještě dodatečná otázka ke konfiguráku: je nějaký důvod, proč upřednostnit nadefinování n konstant před tím, že vše dám do jednoho pole a uložím ho do registru (nebo Nette/Environment)? Zatím u mne důvody pro pole převažují, ale viděla jsem už použít oboje, tak mne to zajímá. |
||
|
Časová prodleva: 14 let
|
|||
0