bganonymous
Registered
Здравейте! Как според вас мога да направя config.php (файла за връзка с БД) по-защитен?
Максимална защита на config.php
- Автор bganonymous
- Начална дата
dakata__92
Super Moderator
Слагаш го в директория след което правиш един файл .htaccess и в него пишеш Deny from all като така забраняваш достъпа на абонатите към папката.bganonymous каза:
Ето още дин вариянт от мен:
По този начин само от твоя ип ще има достъп до този фаил.
PHP:
<?php
$ip = $_SERVER['REMOTE_ADDR'];
if ($ip!="Твоя ип адрес")
{
header("Location: http://site.com");
exit;
}
$db_user = "dbuser"; // Потребителско име
$db_pass = "dbspass"; // Парола
$db_database = "db"; // Датабаза име
$db_host = "host"; // Сървър , обикновено е localhost
$db_connect = mysql_connect ($db_host, $db_user, $db_pass); // Връзка.
$db_select = mysql_select_db ($db_database); // Избира датабазата.
function form($data) { // Защита
global $db_connect;
$data = ereg_replace("[\'\")(;|`,<>]", "", $data);
$data = mysql_real_escape_string(trim($data), $db_connect);
return stripslashes($data);
}
?>dakata__92
Super Moderator
systems каза:
Напълно излишно нещо. Защити директорията с htaccess както ти казах и не ползвай този начин. Първо ако не си на собственият си комп и инклудваш файла ще те пренасочва, второ хората няма да имат достъп до папката тоест до всички файлове в нея и така няма да имаш нуждата да правиш подобна проверка, като горната. Функцията също е доста остаряла като тип защита и е напълно ненужно да се използва, нито пък и е там мястото.
Безсмислено е
Ако не извеждаш никаква информация в него, а просто правиш връзка с базата данни, няма от какво да се притесняваш.
Ако толкова те е шубе, да не изкара някоя mysql грешка, която да изпее нещо, сложи в началото на кода едно
Това, от своя страна, може да е затруднение за теб - ако възникне бъг в сайта, който се нуждае от корекция, няма да знаеш, защото няма да ти изкара грешката, а ще се опита да сработи кода, ако е възможно.
Но просто няма смисъл
Ако не извеждаш никаква информация в него, а просто правиш връзка с базата данни, няма от какво да се притесняваш.
Ако толкова те е шубе, да не изкара някоя mysql грешка, която да изпее нещо, сложи в началото на кода едно
PHP:
<?php
error_reporting(0);
// останалата част от кода
?>Но просто няма смисъл
Задължително конфигурационните файлове (и ако може - цеслия изпълним сайт, без пъблик ресурсите) ги изкарваш ИЗВЪН указаната root директория на уеб сървъра.Това е 100% гаранция, че няма да имаш директен достъп. Това обаче не е достатъчно - въпросния файл може да бъде отворен чрез друг скрипт, пуснта на същия сървър... затова най-чистото положение е, въпросните файлове да се криптират. Нивото на сигурността е сравнително добре - за безобидни сайтчета е ОК.
Ако изберете да криптирате файла, то трябва да знаете, че ще е нужно да има активен определен модул от ZEND - Zend Optimizer или Zend Loader. До колкото знам на всички хостинг компании в България този модул си го има. Реално погледнато е безплатен, но криптиращата система - Zend Guard (http://shop.zend.com/en/zend-guard-annual.html) не е никак евтина (има траъл период - може да се изтегли от тук: http://www.zend.com/en/products/guard
Ако изберете да криптирате файла, то трябва да знаете, че ще е нужно да има активен определен модул от ZEND - Zend Optimizer или Zend Loader. До колкото знам на всички хостинг компании в България този модул си го има. Реално погледнато е безплатен, но криптиращата система - Zend Guard (http://shop.zend.com/en/zend-guard-annual.html) не е никак евтина (има траъл период - може да се изтегли от тук: http://www.zend.com/en/products/guard
dakata__92
Super Moderator
Да правилно е горенаписаното, но чак такава защита от типа на криптирането е малко излишна. Все пак ми се струва мнооого утежняваща скороста процедура, но наистина ако го желаеш е много добро като идея. :?:
:?:Добре бе, хора, защо не просто така: 
file.php
config.php
С .htaccess-а изглежда добра идея, но и тогава пък не си защитен от, както каза ламерко, от
А по "моя" начин ще е невъзможно config.php да се отвори сам, а дори и пуснат от друг файл на сървъра, THIS_IS_A_SECRET_CONSTANT ще бъде нещо като парола. (и тук може да се спори, че могат да ти отворят файла и да ти видят "паролата", но пак е известна защита).
file.php
PHP:
<?php
define('THIS_IS_A_SECRET_CONSTANT', 'qw9e87456das')
include "config.php";
PHP:
<?php
if(!defined('THIS_IS_A_SECRET_CONSTANT') || !(THIS_IS_A_SECRET_CONSTANT == 'qw9e87456das')
{
//грешка!
exit;
}С .htaccess-а изглежда добра идея, но и тогава пък не си защитен от, както каза ламерко, от
А по "моя" начин ще е невъзможно config.php да се отвори сам, а дори и пуснат от друг файл на сървъра, THIS_IS_A_SECRET_CONSTANT ще бъде нещо като парола. (и тук може да се спори, че могат да ти отворят файла и да ти видят "паролата", но пак е известна защита).
dakata__92
Super Moderator
Принципно мога да Ви кажа, че номера с .htaccsess си върши перфектна работа. Слагаш го в папка в която системата няма да има достъп и го инклудваш. По-скоро трябва да се защити от SQLi и XSS заедно с другите по вид атаки и това е. Той ако някой стигне до това да барника из сайта и да г счупи дали ще има глупавите настройки на конфигурационният файл е направо глупаво. Ти си правиш някакви проверки и това е. Какво ще ти напълни базата или ще ти открадне домейна ли. Ами това няма да е защото конфигурационният ти файл е криптиран или не, а защото основно си направил някъде голяма грешка в кода. Не защитена входно изходна променлива и така нататък. Използвайте неща които не са чак така проблемни и усложняващи. Да горните мнения са много правилни и страхотни като предложения, но за мен това е едно добро и сигурно решение. Кръщаваш папката и файла с някакво странно име и си готов. Ако успее да открие тази папка като стринг той няма да има достъп до нея. От код да може да извика файла но това означава, че имаш пропуск другаде.lamerko каза:И като напаря едно ехо на файла като стринг без да го прекарвам през врапъра - какво правим?
Иначе за декриптирането - няма ясно изразено забавяне.
dakata__92
Super Moderator
Не е ли така? Мнението и обяснението което даде ти е изключително правилно като расъждение и естествено добра практика ако проекта го налага. За средностатистически сайт според мен не е наложително. Да конфига трябва да е отделно от системата и прочие но е достатъчно достъпа до папката да се забрани. Външно не виждам как ще достъпиш до файла ако .htaccess-a не ти позволява. Принципно ако греша обяснете ми, все пак от наблюденията ми това е било достатъчно. :?:lamerko каза:Щом казваш
Нямаш си на идея какви трикове има. Но за твоя банален случай - нека да кажем, че има елементарен начин да заобиколим .htaccess. С една най-обикновенна заявка. Естествено има защита, но въпроса е дали е приложена. А в 80% от случаите - не е.
Казвам ти го като човек, работещ 11 години в агенция по сигурност, а преди това - около 5 години съм... се забавлявал от другата страна... та никога не се осланяй твърде много на половинчати решения. Пропуските в сигурността отдавна вече не са банални, но постоянно изникват от най-неочакваните места
Казвам ти го като човек, работещ 11 години в агенция по сигурност, а преди това - около 5 години съм... се забавлявал от другата страна... та никога не се осланяй твърде много на половинчати решения. Пропуските в сигурността отдавна вече не са банални, но постоянно изникват от най-неочакваните места
dakata__92
Super Moderator
Заявка? Добре, дай пример. Имам система както следва като директория:lamerko каза:Нямаш си на идея какви трикове има. Но за твоя банален случай - нека да кажем, че има елементарен начин да заобиколим .htaccess. С една най-обикновенна заявка. Естествено има защита, но въпроса е дали е приложена. А в 80% от случаите - не е.
Казвам ти го като човек, работещ 11 години в агенция по сигурност, а преди това - около 5 години съм... се забавлявал от другата страна... та никога не се осланяй твърде много на половинчати решения. Пропуските в сигурността отдавна вече не са банални, но постоянно изникват от най-неочакваните места
http://example.com/system/
http://example.com/settings/
Папката сетингс е защитена с .htaccess и Deny All. Системната папка също.
сайта ми се започва с инклудване на файловете и бяга към:
http://example.com/index.php в името на примера. Eror Reportinga e изключен. В папка сетингс имам конфиг файл с име nastroiki.php
http://example.com/settings/nastroiki.php
Файла съдържа масив от типа:
PHP:
<?php
$array['url_defense'] = true;
$array['content_pattern'] = '/^[а-яa-z0-9~%.:#_\-+=&?\/]+$/iu';
return $array;dakata__92
Super Moderator
Ммм странно. Не намирам из нета нещо с този параметър GETS на търсене. Това S за множествено число ли го слагаш или просто това е названието? Дай линк с обяснение на този вид "атака". Обясни ми, явно съм невежа по темата и ми казваш нещо което е доста интересно от към секюрити сектора. Впрочем да добавя, че през линк бара на сайта се прави проверка за нежелани символи: '/^[а-яa-z0-9~%.:#_\-+=&?\/]+$/iu' това е патърна и ми стана мега интересно като намеси и GET. С този патърн филтрирам ненужните за мен символи.lamerko каза:Най-лесното - ще пусна GETS заявка вместо GET
Моля те да обясниш и да дадеш повечко информация за да се обучим повечко, че явно нещо ми се разминава мисълта с реалността и е доста вероятно да съм уязвим по темата.
dakata__92
Super Moderator
Доообрее! Дай да видим някой друг линк по темата.lamerko каза:
dakata, идеята на автора нали е да си защити mysql-connect-файла? А това, което си дал, е просто някво нещо с един regexp (което не ми изглежда особено секретно)... но да со представим, че там ти стоят паролите към бд-то.
Lamerko, в този случай, ако сложим htaccess с deny from all, то за какво общо има това с типа заявка - дали е ГЕТ или ПОСТ?
Доколкото разбрах правиш заявка към сървъра, която я именуваш GETS. Но това как е свързано с htaccess? Той не забранява ли всички заявки, независимо от типа им?
А в мойто предложение разбирам, че проблемът е, че ако има някакви пропуски на друго място в кода (както предположи даката), ти ще инжектнеш някакъв код, който ше се изпълни на моя сървър, и ще прочете свързващия конфиг. Но тук идва работата с include $_GET['url']... а ние не говорим за този случай. Ако всички входни данни са ескейпнати и проверени, не би трябвало да има проблем. Оттук веднага се сещам, че може да има проблеми в самото apache (примерно). Едва ли имаш това предвид...
Ще ми бъде и на мен интересно да разясниш по темата
Lamerko, в този случай, ако сложим htaccess с deny from all, то за какво общо има това с типа заявка - дали е ГЕТ или ПОСТ?
Доколкото разбрах правиш заявка към сървъра, която я именуваш GETS. Но това как е свързано с htaccess? Той не забранява ли всички заявки, независимо от типа им?
А в мойто предложение разбирам, че проблемът е, че ако има някакви пропуски на друго място в кода (както предположи даката), ти ще инжектнеш някакъв код, който ше се изпълни на моя сървър, и ще прочете свързващия конфиг. Но тук идва работата с include $_GET['url']... а ние не говорим за този случай. Ако всички входни данни са ескейпнати и проверени, не би трябвало да има проблем. Оттук веднага се сещам, че може да има проблеми в самото apache (примерно). Едва ли имаш това предвид...
Ще ми бъде и на мен интересно да разясниш по темата
dakata__92
Super Moderator
anonimen: Автора не написа конкретно какъв конфиг файл защитава, но да прав си, че се подразбира за какво е говорил. Дадох просто някакъв файл но това си важи и за парола на хоста и прочие. Ти вече обясни за include но просто ми стана интересно lamerko какво има предвид точно под банален случай и как ще заобиколи .htaccess файла и командата. Ако има пропуск на друго място то това не е защото папката не е защитена, а защото системата има дупка. Преди гледах клипчета как бъгват Wordpres през cmd но пак би трябвало да не дава достъп файла дори когато се достъпва сайта през нея.