Linux за българи: Форуми

Здравейте колеги,
Ще ви помоля за мемието ви дали тези два скрипта са достатъчно сигурни за което за предазначени.
Доста търсих из интернета, а и книги четох и това успях да измисля:

Целта ми в пръвия е да почисти входните данни от пост масива, като в същото верме, като и
прекрати автоматизирани ботове.

GeSHi (PHP):
<?php
session_start();
session_regenerate_id();
if ((isset($_POST['add']) && $_POST['add']=='1'))
      { if (isset($_SESSION['token']) && $_POST['token'] == $_SESSION['token'])
            {
   $token_age = time() - $_SESSION['token_time'];
if (($token_age < $maxTime) && ($token_age > $minTime ))
{
$valueTitle=array('Господин','Госпожа','Госпожица');text
if(in_array($_POST['title'],$valueTitle)) {$clean['title']=$_POST['title'];} 
if(preg_match("/^[a-zA-ZА]{3,32}$/",$_POST['name'])) {$clean['name']=$_POST['name'];} 
}}}
echo clean ['name'];
 
 
$token = md5(uniqid(rand(), true)); $_SESSION['token'] = $token;
$_SESSION['token_timestamp'] = time();
echo "<form action='' method='POST'>
Username: <input type='text' name='username' />    
<input type='hidden' value=".$token." name='token' />  
<input type='submit' />                            
</form>";       
 
?>
 
 
 

А врория от тях е създаването на сесия, за оторизиран потребител, до ограничена част на сайта.

GeSHi (PHP):
//someWhereInSite.php
<?php
session_start();
session_regenerate_id();
if (isset($_SESSION['HTTP_USER_AGENT']))
{                                       
    if ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT']))
    {                                                                    
echo "<form action='login_check.php' method='POST'>                      
Username: <input type='text' name='username' />                          
<input type='submit' />                                                  
</form>";                                                                
 
        /* Prompt for password */
        exit;                    
    }                            
 
    else 
        { echo "Inside security zone";
 
        exit;                                           
        }                                               
 
}
 
if (!isset($_SESSION['HTTP_USER_AGENT']))
{                                        
echo "<form action='login_check.php' method='POST'>
Username: <input type='text' name='username' />    
<input type='submit' />                            
</form>";                                          
}                                                  
?>
 
 
 
 
//login_check.php
<?php 
session_start ();
session_regenerate_id();
if (!isset($_SESSION['HTTP_USER_AGENT']) && isset($_POST['username']))
{                                                                     
  if ($_POST['username'] == 1)                                        
    {                                                                 
    $_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']);  
    echo "Inside security zone<br>"; 
    }                                                                             
  else {echo "greshna parola";exit;}  
 
?>
 

Моля дайте ваште мнения, изказвания и препръки.

Поне аз не забелязах частта, където обработваш постъпилата от формата информация и я вкарваш в базата. Тук са повечето пробойни. И там са задължителни неща от сорта на trim и addslashes.


Иначе кода поне на мен (но аз съм ламер) ми изглежда добре.

В горния случай според мен променливата $clean['name'] е достатъчно почистена да се вкара директно в базата данни. Или греша ?

както казах, не съм баш най-напред, но на доста места, съветват в конфига да имаш нещо такова:

GeSHi (PHP):
if(!get_magic_quotes_gpc())
{
$_GET = array_map('mysql_real_escape_string', $_GET);
$_POST = array_map('mysql_real_escape_string', $_POST);
$_COOKIE = array_map('mysql_real_escape_string', $_COOKIE);
}
else
{
$_GET = array_map('stripslashes', $_GET);
$_POST = array_map('stripslashes', $_POST);
$_COOKIE = array_map('stripslashes', $_COOKIE);
$_GET = array_map('mysql_real_escape_string', $_GET);
$_POST = array_map('mysql_real_escape_string', $_POST);
$_COOKIE = array_map('mysql_real_escape_string', $_COOKIE);
}

Хора дето много уважавам и знаят много, съветват всичко, което влиза в базата да минава през трим и адслашес, за да няма инжекции. Първото по-скоро за удобство на потребителя, отколкото за сигурност, но усигурява и такава. И съответно, когато излиза да има пък htmlspecialchars, за да не чупи html и js. Има и други функции, но тези са най-препоръчвани.

За ДБ данни, *трябва* се ползва *sql_real_escape_string() - няма нужда от add/stripslashes и други такива.

Trim не би трябвало да се прилага върху входните данни.

Този скрипт, който "чисти" всички входни данни може да доведе до неприятности - прилага се mysql_real_escape_string върху данни, които може изобщо да не са предназначени за ДБ.

Най-добре е да ползваш mysqli или ADO.

Автоматичното escape-ването на всички входни данни е грешен подход. Аз предпочитам да се грижа за всяка стойност, която влиза в базата, да е от правилния тип и ако е нужно - да е escape-ната.

Ако не мислите така си пуснете magic_quotes и си карайте както знаете :-)

Сигурен бях че ще се появят поне 5 различни мнения :)
Всеки си го прави както си знае.

Сигурен бях че ще се появят поне 5 различни мнения :)
Всеки си го прави както си знае.

А не трябва да е така... Има си утвърдени от опита правила, които трябва да се спазват.

Автоматичното escape-ването на всички входни данни е грешен подход. Аз предпочитам да се грижа за всяка стойност, която влиза в базата, да е от правилния тип и ако е нужно - да е escape-ната.

Ако не мислите така си пуснете magic_quotes и си карайте както знаете :-)

Съгласен, magic_quotes внесе повече проблеми отколкото успя да реши :)

@toti84
Мисля си, че ако искаш повече помощ, ще трябва да форматираш кода в някой от по-общовъзприетите стандарти... За мен е абсолютно нечетлив - напр. идея си нямам къде свършват if блоковете.

В горния случай според мен променливата $clean['name'] е достатъчно почистена да се вкара директно в базата данни. Или греша ?

Това което си направил е по-скоро проверка за "валидност въз основа на бизнес правила" - *ти* искаш *твоят* сайт да приема потребителски имена съставени само от a-z, A-Z символи. Но това няма нищо общо с ДБ. Утре можеш да решиш, че имена като Brent O'Connor са ОК за *твоя* сайт и да промениш regexp-a. Но това не би трябвало да влияе на съхраняването на данните и тяхното представяне.

Всеки път когато променяш дестинацията на данните, трябва да правиш подходящо трансформиране на данните.

Примери:

1) приемаш HTTP данни от потребителя, правиш им проверка за "бизнес" валидност, и искаш да ги съхраниш в ДБ - новата дестинация е ДБ контекстът. То тогава транформираш данните чрез инструмент предложен от дестинацията като "сигурен" - напр. *sql_real_escape_string.

2) приемаш HTTP данни от потребителя, правиш им проверка за "бизнес" валидност, и искаш да ги представиш обратно на потребителя - новата дестинация е HTML контекстът. То тогава транформираш данните чрез инструмент предложен от дестинацията като "сигурен" - напр. htmlspecialchars или strip_tags.

3) искаш да ги представиш на потребителя  данни прочетени от ДБ - новата дестинация е HTML контекстът. То тогава транформираш данните чрез инструмент предложен от дестинацията като "сигурен" - напр. htmlspecialchars или strip_tags.

OK.
Благодаря на всички за интереса към моя въпрос.
Напълно разбрах смисъла на вашите отговори. т.е. аз правя доста строго филтриране на входящите
данни от потребителите.

Вие нищо не казахте за втория ми скрипт за отвариянето на сигурна сесия. Сигурен ли е ?

session_regenerate_id() се прави само при смяна на правата чрез успешна автентификация (т.е. успешен логин). Само тогава може да се осъществи session fixation атака. Във всички останали случаи, session_regenerate_id() е източник на проблеми при използването на Back бутона на браузера.

аз правя доста строго филтриране на входящите
данни от потребителите.

Ти или използваната от теб framework. Във всички случаи трябва да е прозрачно (и централизирано) за твоите скриптове-клиенти - примерно чрез използването на DAL в случая на ДБ. Така е сигурно, че всички данни подавани към ДБ ще бъдат правилно "изчистени".

@offfffff

Владсън, винаги съм знаел, че си голям, ама с тая тема направо ми скри топката, като Миньор на Левски ;)

Привети!

Нарочно пускам ново мнение, ако Марчето реши да затрие другото да не ми иде инфото. Значи пуснах същата тема в друг форум. Всички бяха съгласни, че трябва да е едно от двете, но никога и двете, като единия от другите "младоци " даде и една връзка:

http://cognifty.com/blog.entry/id=6/addslashes_dont_call_it_a_comeback.html

После се намесиха истинските програмисти. И там стигнаха до мнението, че нито разните слашес, нито real_escape в продукционна система. Трябвало да се ползва prepared statements и ORM (и двете ги чувам сефте), а всичко друго било средновековие и в никакъв случай не трябвало да се ползват.

Приятелю, умният програмист не разчита на безгрешен код и на 1000 мнения - единственно разчита на тестове.
Всичко създадено от хора може да се строши от хора. Според мене го пускай така както си го написал. Събери малко инфо за това как работи, и има-няма проблеми, и продължавай.
Дори лошо работещият код е по добър от перфектният но неработещ.
Според мене ако работи го пускай. И чакай отзиви от тестерите. Е и ти пусни няколко тестчета да видиш какво става де.
Успех

@go_fire - хех, мерси, макар че не се считам за толкова "голям" ;)
ORM и prepared statements не са единствените решения за работа с ДБ - и за тях има много "за и против". Аз също работя с ORM - ползвам Doctrine, макар и някои да я считат за прекалено тежка.

В този случай единственото, което е сигурно е, че не трябва да се създава "суперобект" (било то и процедурно имплементиран), който да върши всичко - проверка за валидност, съхранение в ДБ, генериране на HTML и т.н.
Би трябвало кодът да е разделен на Model-View-Controller принципа, като Моделът да е композитен обект - да притежава инстанции на обект за валидация, обект за съхранение в ДБ и други необходими... т.е. да има отделни обекти, всеки с една единствена отговорност в целия механизъм на обработка и представяне на данните. При това връзката между обектите и знанията им за другите обекти трябва да е минимална, а в идеалния случай - никаква.

Самият факт, че първите два реда от всички скриптове показани от toti84 се повтарят във всеки един от тях говори, че нещо определено не е както трябва.

При мен реализацията на контрол над автентификацията (и авторизацията в проекти с роли) изпълянва един единствен обект:

CodeIgniter

GeSHi (PHP):
abstract class Auth_Controller extends Base_Auth_Controller
{
	function __construct()
	{
		parent::__construct();
		$this->load->model('application/CurrentUser_Model', 'currentUser');
	}
 
	protected function _hasPermission($method, $arguments)
	{
		return $this->currentUser->isLogged;
	}
 
	protected function _notPermitted($method, $arguments)
	{
		Error::register('Не сте автентифицирали пред системата.');
		$this->view('response');
	}
}

Всички останали контролери са наследници на този контролер. Няма HTML,  няма SQL, няма дори следа от DB, SESSION и т.н. Обектът Error съдържа масив от всички съобщения за грешки - без форматиране.

Login/logout действията също се изпълняват от наследник на този контролер:

GeSHi (PHP):
class CurrentUser extends Auth_Controller
{
	function __construct()
	{
		parent::__construct();
 
		$this->suspendPermissionCheck();
	}
 
	public function login()
	{
		$this->currentUser->doLogin();
		$this->view('response');
	}
 
	public function logout()
	{
		$this->currentUser->doLogout();
		$this->view('response');
	}
}

Приятелю, умният програмист не разчита на безгрешен код и на 1000 мнения - единственно разчита на тестове.

В света на Agile Software Development ($2) едновременно си прав и грешиш.

1) Да, тестовете са задължителни, но те са измислени от теб самия и проверяват за проблеми, които ти поставяш. Поради това са ти нужни 1000+ мнения, за да покриеш непокритите от теб проблеми.

2) Според философията на Agile Software Development, решенията се базират на "добри практики", а това са точно решенията, получени чрез отсяване на 1000+ мнения ;)

@VladSun Много ли ще е нахално, ако те помоля да дадеш един прос пример как се използват твойте класове за автенитикация.

Благодаря предварително ...

Аз именно заради това пуснах темата за MVC - http://www.linux-bg.org/forum/index.php?topic=37459.0

От нея се надявам да излязат теми, които да покажат практически решения и да подтикнат хората да в този форум да ги ползват. Мисля си да започна с решения за твоята тема ;)

Както обещах, започваме дискусии на тема PHP MVC frameworks и тяхното ползване. Вече пуснах една тема с инсталация и начално конфигуриране на CodeIgniter - http://www.linux-bg.org/forum/index.php?topic=37480.msg193413

Би било добре да пробваш и да пишеш за възникнали проблеми.