1. ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ – ВАРНА
ЦЕНТЪР ЗА МАГИСТЪРСКО ОБУЧЕНИЕ
КАТЕДРА “ИНФОРМАТИКА”
Сигурност и права за достъп в уеб приложения
изработени с работната рамка Yii.
(Реферат)
Изготвил: Проверил:
Илко Качаров Доц. д-р Стефан Дражев
Специалност:
Приложна информатика – ДОВО
VII курс, I гр., Ф No 6042

2. Варна 2013
Съдържание
Въведение
1. Обичайни уязвимости в уеб приложенията
1. Невалидирани входни данни
2. Cross-site scripting (XSS)
3. Injection flaws
4. Некоректно управление на автентикация и сесии
5. Некоректен директен достъп до обекти
6. Cross-Site Request Forgery (CSRF)
7. Некоректно управление на конфигурацията
8. Незащитени хранилища (file storage)
9. Липса на ограничения за достъп до URL адрес
10. Недостатъчна защита при пренос (transport layer)
11. Невалидирани пренасочвания (redirects) и препращания (forwards)
2. Какво представлява Yii фреймуърк
2.1. Какво е Работна рамка (Фреймуърк)
2.2. Прилагане на модел-изглед-контролер в Yii
3. Сигурност на уеб приложенията
3.1. Аутентикация и оторизация

3. 3.1.1.1. Аутентикация
3.1.1.2. Оторизация
3.2. Определяне на идентичност
3.3. Контрол на достъпа
3.3.1.1. Списъци с права за достъп
3.3.1.2. Ролеви контрол на достъп
3.4. Съхранение на данни
3.5. Бизнес правила и проверка за достъп
4. Заключение

4. Въведение
Целта на този реферат е да ни запознае със проблемите и решенията в областта
на сигурността на уеб приложенията. Ще бъдат разгледани изградените стандарти в
областта и тяхното приложение в популярни софтуерни продукти, в частност Yii
Framework.
Когато се разработват интерактивни софтуерни приложения сигруността на
компонентите е от огромно значение. Изолирането на отделни функционни елементи
един от друг улеснява сигурността на даден елемент без да има нужда да се променя
структурата на цялата система.
За улеснение на софтуерното производство, по-бързото обучение на кадри и по-
лесно управление на промените в продуктите през годините са се изготвили различни
системи за разработка на софтуер. След като тези системи са се утвърдили, че
улесняват работата на разработчиците за многобройни проектите те са се превърнали в
така наречените софтуерни шаблони за дизайн (англ. Software design patterns). В тези
шаблони се застъпват основните похвати за разработка на сигурен софтуер.
Глава 1. Обичайни уязвимости в уеб приложенията
1. Невалидирани входни данни
Обичайни места за проява на невалидирани входни данни
• Свойства
• Параметри на заявката (Request params)
• HTTP headers
• Бисквитки
• Скрити полета (hidden fields [HTTP forms])
Стратегии за валидиране
• No validation – липса на валидация. Много опасен и не се препоръчва
• Blacklist / negative validation (Reject known bad) – Отхрълят се стойности, за
които сме сигурни че са недопустими
• Whitelist / positive validation (Accept known good) – Допускат се като валидни,

5. само стойности за които сме сигурни че са приемливи
• „Дезинфекциране“ на входни данни (Sanitize) – вместо да се приемат
или отхвърлят, входни данни се привеждат до приемлив вид Sanitize
with whitelist – всички символи, които не са част от одобрен списък се
премахват, заменят или кодират
• Sanitize with blacklist – премахване или транслиране на нежелани
символи (htmlentities или премахване на кавички)
Допуска се валидиране на данни само от страна на сървъра!!!
2. Cross-site scripting (XSS)
Обичайни места за проява на XSS
• Client-side scripts (JavaScript, VB Script)
• Embedded code (ActiveX, Flash, Java applets)
•
Пример:
Въвеждане на <script>alert("TEST");</script> в input control (type=“text”)
-';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,8
3,83))//";alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCod
e(88,83,83))//--
></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIP
T>
Начини за премахване
• htmlentities()
• Валидиране на код (HTML, XML, JSON и други)
3. Injection flaws
Места където се проявяват injection flaws:
• Команда / Протокол
• E-Mail
• XML

6. • JavaScript (XSS)
• SQL
$sql = "INSERT INTO Students (name) VALUES (". {$_POST['student_name']}. ")";
Може да доведе до изпълнение на:
INSERT INTO students (name) VALUES ('Robert'); DROP TABLE Students;--')
4. Некоректно управление на автентикация и сесии
Удостоверяването на самоличност (автентикация) е критичен процес за
защита на потребителските данни. За запазване на удостоверената самоличност
на потребителя се използват активни сесии. При некоректно управление или
недостатъчна надежност на автентикационния процес, или съхраняване на
активните сесии атакуващият лесно може да открадне идентичността на друг
потребител
Начини за защита:
• Надеждни пароли – изискване за минимална дължина, включване на
специални символи в паролата, изискване за честа смяна на паролата
• Използване на парола – изискване за определен брой опити за вход в
системата
• Механизъм за смяна на парола – навсякъде, където е необходимо трябва
да се използва един и същ механизъм за смяна на парола; изискват както
старата, така и новата парола
• Сигурни хранилища за пароли – паролите трябва да бъдат съхранявани
във криптиран вид или като hash. За предпочитане е да се ползват hash-
ове.
• Защита на credentials при транспорт – постига се, чрез използване на SSL
• Защита на сесийни идентификатори – потребителските сесии трябва да
бъдат защитени със SSL
• Списък с потребители – при никакви условия не трябва да се разрешава
достъп до списък с потребители на системата, освен при нужда – на

7. потребители с делегирано право на достъп
5. Некоректен директен достъп до обекти
• Стриктна проверка дали потребителя има достъп за заявения обект
• Стриктно валидиране на входни данни
6. Cross-Site Request Forgery (CSRF)
Пример:
• http://example.com/app/transfer.php?amount=1500&destinationID=123
• <img src="http://example.com/app/transfer.php?
amount=1500&destinationID=123#“ width="0" height="0" />
• Начин за защита: добавяне на security token като скрито поле (input
type=“hidden”) и валидацията му при изпращане на фомуляри
7. Некоректно управление на конфигурацията
Достъп до чувствителна информация
• Достъп до листинг на обекти за конкретна директория
• Достъп до логове на системата
• Достъп до конфигурационни файлове
• Достъп до хранилища за данни
• Предпоставки за path traversal атаки
• Начини за защита:
• Стриктен контрол на достъп до конфигурацията
• Избягване използване настройки по подразбиране
• Познаване настройките и начина на работа на обкръжението
8. Незащитени хранилища (file storage)
Къде се съхранява чувствителна информация.
Кой и как има достъп до нея?

8. Често допускани грешки:
1. Пропуск в криптиране на критични данни
2. Несигурно съхраняване на ключове, сертификати и пароли
3. Некоректна конфигурация
4. Несигурно съхраняване в паметта
5. Слабо използване на randomness
6. Лош избор на алгоритъм
7. Опит за имплементация на алгоритъм за шифриране
8. Липса на поддържка за смяна/обмен на шифриращи ключове и други
9. Липса на ограничения за достъп до URL адрес
Необходим ли е оторизиран достъп до конкретна страница / ресурс?
• Ако да – удостоверена ли е самоличността на потребителя и
делегиран ли е достъп до страницата / ресурса?
• Принцип на най-ниските привилегии
Начини за защита:
• Имплемнтиране на надежден механизъм за удостоверяване на
самоличност
• Имплементиране на ролево-базиран контрол на достъпа
• Имплементиране на лесно-разширяем модел за сигурност с цел
избягване на твърдо-зададени дефиниции в изходния код
• По подразбиране достъпът трябва да бъде забранен
10. Недостатъчна защита при пренос (transport layer)
Използва ли се SSL за защита при пренос на чувствителни
/кондфиденциални данни?
• Използва ли се SSL при предаване на login credentials?
• Използва ли се SSL при операции с данни за потребител?
• Използват ли се “силни” алгоритми за криптиране

9. • Всички сесийни бисквитки се създават с установен флаг “secure”
• Сървърния сертификат е легитимен и правилно конфигуриран?
Глава 2. Какво представлява Yii Framework
1. Какво е Работна рамка (Фреймуърк)
Работна рамка (от английски: framework) е структура на програмна система, която
облегчава разработката и обединението на различни компоненти на голям програмен
проект. За разлика от библиотеките, които обединяват набор от подпрограми с близка
функционалност, фреймуъркът съдържа в себе голямо количество различни по
предназначение библиотеки и програмни връзки между тях.
Софтуерната работна рамка е универсална, многократно употребяема софтуерна
платформа, използвана за да се разработват приложения, продукти и софтуерни
решения.
2. Прилагане на модел-изглед-контролер в Yii
Приложението на MVC в работната рамка е представено сравнително упростено.
Основните компоненти на шаблона (Модел,Изглед,Контролер) са изнесени в различни
папки, като всеки един от тези компоненти се намира в отделен файл в съответната
директория. Обикновенно всеки от тези три компонента допълва основният интерфейс
за компонент. В самата работна рамка има базови класове които спомагат за по-
лесната разработка на нови модели и контролери.
След като се стартира приложението ако не е посочен контролер или метод, по
подразбиране се задейства индекс метода на главният контролер. Той на свой ред
създава обекти за нужните за изпълнението му модели и ги предава на изгледът който
ги визуализира.
Фиг. 5. Основна структура на работната рамка Yii

10. Фиг. 5. Основна структура на входящите заявки в Yii
Таблица 1. Примери за работни рамки използващи MVC шаблон
Език за програмиране Приложение / Работна рамка
Smalltalk AIDA/Web
Ruby Ruby On Rails
Python Django
ASP, C#, VB .Net Framework, Spring.NET
Java Apache Struts, VRaptor
PHP Zend, CakePHP, Yii
JavaScript SpineJs, Backbone, Ember
Повече информация може да бъде открита на адрес http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

11. 4. Сигурност на уеб приложенията
Сигурността на уеб приложенията зависи главно от това кой е потебителя който
използва системата и до какво има има достъп той. Процесът на определяне на
идентичността на потербителя се нарича Автентикация (англ. Authentication). Процесът
за определянето на правата му за достъп до ресурсите се нарича Оторизация (англ.
Authorization).
4.1. Автентикация и оторизация
Автентикация е проверка на идентичността, която даден потребител,
процес или машина твърдят, че имат. Следващите нива при контрола на достъпа
зависят от аутентикацията. Обикновенно този процес включва потребителско
име и парола, но може да включи и други методи за доказване на идентичността,
например сертификат електронен подпис, пин код, устройство за разпознаване
на пръстови отпечатъци и други.
Нивото на автентикация, изисквано за дадена система, зависи от
изискванията за сигурност, идващи от самата нея. Например публично
достъпните уеб сървъри могат да позволяват анонимен достъп, както и достъп за
гости. Финансовите транзакции трябва да изискват много силна аутентикация.
Пример за слаба форма на аутентикация е използването на IP адрес за
определянето на идентичност. Подмяната или нелегалното използване на IP
адреса може лесно да излъже този механизъм. Силната форма на аутентикация
изисква поне два фактора за доказване на идентичността:
Какво знае човек: пароли и лични идентификационни номера (PIN кодове) са
пример за това какво човек може да знае. Паролите могат да бъдат за
еднократно или многократно използване. S/Key е пример за система за
еднократни пароли (http://en.wikipedia.org/wiki/S/KEY).
Какво притежава човек: Различни хардуерни устройства или софтуерни
приложния: Смарт карти, също така и SecureID, CRYPTOCard, и SafeWord.
Кой е човекът: Биометричните характеристики са това, което показва кой точно
е човекът, защото разпознаването на идентичността се базира на физическите

12. му характеристики: например сканиране на дланта, геометрия на ръката,
сканиране от ириса на окото, модел на ретината, отпечатъци от пръсти, модел на
гласа, разпознаване на лице или подпис.
Съществуват много системи за мрежова аутентикация. TACACS+ (Terminal
Access Controller Access System), Kerberos и RADIUS (Remote Access Dial In User
Service) са протоколи за аутентикация, поддържани от Сиско.Тези системи за
аутентикация могат да бъдат конфигурирани да изпозват много от примерите за
установяване на идентичността, посочени по-горе
Оторизацията е привилегията да се разрешава достъпа до услуги или
информация само за определени групи или личности. За системи, които трябва
да поддържат високо ниво на сигурност, нивото на достъп по принцип трябва да
бъде забранено за всички, като изключенията се добавят допълнително. Дори и
добавени допълнително, правилата за достъп трябва да са на принципа на най-
малкото, което е нужно на даден човек. За публични системи оторизация може
да се даде и на гости или анонимни потребители. Нужно е да се определят
изискванията ни за сигурност,
за да се определят подходящите граници на оторизация. Нивото на оторизация в
някой случай се определя от групата или ролята на потребителя. Определени
групи и роли може да имат достъп до всеки ресурс по отделно и по този начин
един потребител да получи повече от една роля или да участва в повече от една
група.
В работната рамка Yii има вградена система за автентикация и оторизация която
е лесна за употреба и има възможност за фини настройки според нуждите на
приложението.
Главната част на тази система е предефинираният потребителски компонент
който е обект имлементиращ интерфейсътIWebUser. Този компонент представя
постоянната информация за идентичността на текущия потребител. Този
компонент може да се достъпи чрез обекта Yii::app()->user

13. Използвайки този компонент можем да проверим дали потребителя е влязъл в
системата или не чрез метода CWebUser::isGuest, можем да проверим дали
потребителя може да изпълнява определени действия чрез метода
CWebUser::checkAccess. Също така можем да вземем уникалният ключ и друга
лична информация за потребителя.
4.2. Определяне на идентичност
В стандартно уеб приложение имплементацията на автентикацията обикновенно
съдържа комбинация от потребителско име и парола за да се потвърди
идентичността на потербителя. Фреймуърка дава възможност да се използват и
други методи за автентикация. Ние дефинираме клас за идентичност който да
съдържа основната логика за автентикация. Този клас трябва да се основава на
интерфейсът IUserIdentity. За различните методи за автентициране има
различни подходи и за всеки от тях може да има различен клас за идентичност.
Едни от най-известните начини за автентикация в момента са OpenID, LDAP,
Twitter OAuth, Facebook Connect. Най-добрата практика ако се пише нов клас за
идентичност е да се наследи класът CUserIdentity който е основен клас за
автентикация използваш комбинация от потребител(емейл) и парола.
Основната дейност на класът за идентичност е да имплементира метода
IUserIdentity::authenticate. Този метод се използва за да енкапсулира главните
детайли на даден начин за автентикация. Един клас за идентичност може да
дефинира допълнителна информация за потребителя която трябва да бъде
постоянна за цялата сесия на потребителя.
Пример:
В следващият пример се използва клас за идентичност за да се демонстрира
подход за автентикация който използва база данни за съхранение на
потребители и паролите. Потребителя трябва да въведе своето потребителско
име и парола в формата за вход в системата и след това ние трябва да
потвърдим тези данни в таблицата за потребители използвайки ActiveRecord
способа за връзка с базата.

14. В примера са посочени следните три стъпки:
• Имплементация на метода authenticate() за да се направи
проверка в базата данни
• Използване на променена версия на
метода CUserIdentity::getId() която да връща полето _id на
потребителя защото стандартното е да връща потребителското име.
• Използване на метода setState() (CBaseUserIdentity::setState) за
демонстрация как мможе една и съща информация да бъде запазена
и лесно преизползвана..
class UserIdentity extends CUserIdentity
{
private $_id;
public function authenticate()
{
$record=User::model()->findByAttributes(array('username'=>$this-
>username));
if($record===null)
$this->errorCode=self::ERROR_USERNAME_INVALID;
else if($record->password!==crypt($this->password,$record->password))
$this->errorCode=self::ERROR_PASSWORD_INVALID;
else
{
$this->_id=$record->id;
$this->setState('title', $record->title);
$this->errorCode=self::ERROR_NONE;
}
return !$this->errorCode;
}
public function getId()
{
return $this->_id;
}
}
4.3. Ролеви контрол на достъп
Контрол на достъпа реализиран чрез роли е сравнително леснен, но
мощен начин за централизиран достъп до данните. В Yii ролевият контрол се

15. реализира с помощта на компонента authManager. В следващият пример можем
да се запознаем със основните концепции на тази схема.
Основно понятие в RBAC (Role-Based Access Control) е елементът на
разрешение. Това е разрешението да се извърши дадено действие ( да се
създаде пост в блог, да се изтрие потребител и др.) Според обясненията и
целевата аудитория разрешителните елементи могат да бъдат квалифицирани
като операции, задачи и роли. Ролята се състои от задачи, задачата от операции
а операцията е разрешение което е неделимо. Например може да има система в
която има роля Администратор, която има ръковдна длъжност върху
управлението на потребители и статии. Управлението на потребители може да се
състои от операции за създаване, промяна и изтриване на потребител. За по-
голяма гъвкавост Yii позволява ролята да съдържа други роли, задачи и
операции.
Всеки елемент на разрешение може да се дефинира уникално по своето
име. Той може да бъде свързън с определено бизнес правило. Бизнес правилото
в фреймуърка може да бъде част PHP код който ще бъде изпълнен когато се
изисква достъп до даден елемент. Само ако бизнес правилото върне стойност
истина потребителя ще има достъп до изисканият ресурс. Например ако трябва
да се промени дадена статия, бизнес правилото може да проверява дали
статията е написана от потребителя който иска да я промени и ако е само тогава
той ще има достъп.
Използвайки елементите за разрешение може да се построи йерархия от
разрешителни в която един елемент може да наследява един или повече други
елементи от тази йерархия. След като имаме такава изградена йерархия можем
да раздадем роли на потребители. След като една роля е дадена на потебителя
той получава правата които са включение в нея. Проверката за права става в
кода по следният начин:
if(Yii::app()->user->checkAccess('deletePost'))
{
// delete the post
}

16. Конфигуриране на мениджъра за достъп
Yii дефинира два вида мениджъри за достъп: CPhpAuthManager и
CdbAuthManager. Първият съхранява достъпа до ресурсите в самите php
файлове, а другия ги съхранява база данни.
return array(
'components'=>array(
'db'=>array(
'class'=>'CDbConnection',
'connectionString'=>'sqlite:path/to/file.db',
),
'authManager'=>array(
'class'=>'CDbAuthManager',
'connectionID'=>'db',
),
),
);
4.4. Дефиниране на йерархия за оторизация
Този процес включва три стъпки:
• дефиниране на елементите за достъп
• дефиниране на връзките между отделните елементи в роли
• задаването на ролите на потребителите
За да дефинираме елемент можем да използваме следните методи:
• CAuthManager::createRole
• CAuthManager::createTask
• CauthManager::createOperation
След като имаме набор от елементи със помощта на следните методи можем да

17. установим връзките между тях:
• CAuthManager::addItemChild
• CAuthManager::removeItemChild
• CAuthItem::addChild
• CauthItem::removeChild
И за да добавим роли на потребители можем да използваме тези методи:
• CAuthManager::assign
• CAuthManager::revoke
Пример за йерархия на достъпа:
$auth=Yii::app()->authManager;
$auth->createOperation('createPost','create a post');
$auth->createOperation('readPost','read a post');
$auth->createOperation('updatePost','update a post');
$auth->createOperation('deletePost','delete a post');
$bizRule='return Yii::app()->user->id==$params["post"]->authID;';
$task=$auth->createTask('updateOwnPost','update a post by author himself',$bizRule);
$task->addChild('updatePost');
$role=$auth->createRole('reader');
$role->addChild('readPost');
$role=$auth->createRole('author');
$role->addChild('reader');
$role->addChild('createPost');
$role->addChild('updateOwnPost');
$role=$auth->createRole('editor');
$role->addChild('reader');
$role->addChild('updatePost');
$role=$auth->createRole('admin');
$role->addChild('editor');
$role->addChild('author');
$role->addChild('deletePost');
$auth->assign('reader','readerA');

18. $auth->assign('author','authorB');
$auth->assign('editor','editorC');
$auth->assign('admin','adminD');
Проверка за достъп:
if(Yii::app()->user->checkAccess('createPost'))
{
// create post
}
$params=array('post'=>$post);
if(Yii::app()->user->checkAccess('updateOwnPost',$params))
{
// update post
}
Заключение
Използването на работна рамка за извършване на стандартни процедури
като автентикация и оторизация може много да намали времето за изработка на
даден продукт, да увеличи неговите вложени защити и да намали риска за
приложението. Разбира се, това е само първата стъпка към осигуряването на
едно приложение, но започнем ли да изграждаме сигурността от по стабилно
базово ниво можем да сме сигурни, че приложението ни ще бъде по-добре
защитено.
Използвана литература:
1. http://www.yiiframework.com/doc/guide/1.1/en/topics.auth
2. http://www.yiiframework.com/wiki/425
3. http://security.stackexchange.com/questions/7193/cryptographic-security-of-dynamically-
generated-non-random-salts/7195#7195
4. http://www.rhyous.com/2012/06/18/how-to-effectively-salt-a-password-stored-as-a-hash-in-a-
database/
5. http://en.wikipedia.org/wiki/Salt_(cryptography)
6. http://en.wikipedia.org/wiki/Role-based_access_control