Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ – ВАРНА            ЦЕНТЪР ЗА МАГИСТЪРСКО ОБУЧЕНИЕ                 КАТЕДРА “ИНФОРМАТИКА”      Сигу...
Варна 2013                                   Съдържание  Въведение1. Обичайни уязвимости в уеб приложенията  1. Невалидира...
3.1.1.1.   Аутентикация        3.1.1.2.   Оторизация  3.2. Определяне на идентичност  3.3. Контрол на достъпа        3.3.1...
Въведение      Целта на този реферат е да ни запознае със проблемите и решенията в областтана сигурността на уеб приложени...
само стойности за които сме сигурни че са приемливи     • „Дезинфекциране“ на входни данни (Sanitize) – вместо да се прием...
•   JavaScript (XSS)         •   SQL  $sql = "INSERT INTO Students (name) VALUES (". {$_POST[student_name]}. ")";  Може да...
потребители с делегирано право на достъп5. Некоректен директен достъп до обекти     •   Стриктна проверка дали потребителя...
Често допускани грешки:              1. Пропуск в криптиране на критични данни              2. Несигурно съхраняване на кл...
•   Всички сесийни бисквитки се създават с установен флаг “secure”                  •   Сървърния сертификат е легитимен и...
Фиг. 5. Основна структура на входящите заявки в Yii                         Таблица 1. Примери за работни рамки използващи...
4. Сигурност на уеб приложенията      Сигурността на уеб приложенията зависи главно от това кой е потебителя койтоизползва...
му характеристики: например сканиране на дланта, геометрия на ръката,сканиране от ириса на окото, модел на ретината, отпеч...
Използвайки този компонент можем да проверим дали потребителя е влязъл всистемата или не чрез метода CWebUser::isGuest, мо...
В примера са посочени следните три стъпки:         •   Имплементация на метода authenticate() за да се направи            ...
реализира с помощта на компонента authManager. В следващият пример можемда се запознаем със основните концепции на тази сх...
Конфигуриране на мениджъра за достъп          Yii дефинира два вида мениджъри за достъп: CPhpAuthManager иCdbAuthManager. ...
установим връзките между тях:         •   CAuthManager::addItemChild         •   CAuthManager::removeItemChild         •  ...
$auth->assign(author,authorB);$auth->assign(editor,editorC);$auth->assign(admin,adminD);Проверка за достъп:if(Yii::app()->...
Upcoming SlideShare
Loading in …5
×

Сигурност и права за достъп в уеб приложения изработени с работната рамка Yii

2,456 views

Published on

Published in: Technology
  • Be the first to comment

Сигурност и права за достъп в уеб приложения изработени с работната рамка Yii

  1. 1. ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ – ВАРНА ЦЕНТЪР ЗА МАГИСТЪРСКО ОБУЧЕНИЕ КАТЕДРА “ИНФОРМАТИКА” Сигурност и права за достъп в уеб приложения изработени с работната рамка Yii. (Реферат)Изготвил: Проверил:Илко Качаров Доц. д-р Стефан ДражевСпециалност:Приложна информатика – ДОВОVII курс, I гр., Ф No 6042
  2. 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. Прилагане на модел-изглед-контролер в Yii3. Сигурност на уеб приложенията 3.1. Аутентикация и оторизация
  3. 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. 4. Въведение Целта на този реферат е да ни запознае със проблемите и решенията в областтана сигурността на уеб приложенията. Ще бъдат разгледани изградените стандарти вобластта и тяхното приложение в популярни софтуерни продукти, в частност YiiFramework. Когато се разработват интерактивни софтуерни приложения сигруността накомпонентите е от огромно значение. Изолирането на отделни функционни елементиедин от друг улеснява сигурността на даден елемент без да има нужда да се променяструктурата на цялата система. За улеснение на софтуерното производство, по-бързото обучение на кадри и по-лесно управление на промените в продуктите през годините са се изготвили различнисистеми за разработка на софтуер. След като тези системи са се утвърдили, чеулесняват работата на разработчиците за многобройни проектите те са се превърнали втака наречените софтуерни шаблони за дизайн (англ. 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. 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,83,83))//";alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--></SCRIPT>">><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>Начини за премахване • htmlentities() • Валидиране на код (HTML, XML, JSON и други) 3. Injection flaws Места където се проявяват injection flaws: • Команда / Протокол • E-Mail • XML
  6. 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. 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. 8. Често допускани грешки: 1. Пропуск в криптиране на критични данни 2. Несигурно съхраняване на ключове, сертификати и пароли 3. Некоректна конфигурация 4. Несигурно съхраняване в паметта 5. Слабо използване на randomness 6. Лош избор на алгоритъм 7. Опит за имплементация на алгоритъм за шифриране 8. Липса на поддържка за смяна/обмен на шифриращи ключове и други 9. Липса на ограничения за достъп до URL адрес Необходим ли е оторизиран достъп до конкретна страница / ресурс? • Ако да – удостоверена ли е самоличността на потребителя и делегиран ли е достъп до страницата / ресурса? • Принцип на най-ниските привилегииНачини за защита: • Имплемнтиране на надежден механизъм за удостоверяване на самоличност • Имплементиране на ролево-базиран контрол на достъпа • Имплементиране на лесно-разширяем модел за сигурност с цел избягване на твърдо-зададени дефиниции в изходния код • По подразбиране достъпът трябва да бъде забранен 10. Недостатъчна защита при пренос (transport layer) Използва ли се SSL за защита при пренос на чувствителни /кондфиденциални данни? • Използва ли се SSL при предаване на login credentials? • Използва ли се SSL при операции с данни за потребител? • Използват ли се “силни” алгоритми за криптиране
  9. 9. • Всички сесийни бисквитки се създават с установен флаг “secure” • Сървърния сертификат е легитимен и правилно конфигуриран? Глава 2. Какво представлява Yii Framework 1. Какво е Работна рамка (Фреймуърк) Работна рамка (от английски: framework) е структура на програмна система, коятооблегчава разработката и обединението на различни компоненти на голям програменпроект. За разлика от библиотеките, които обединяват набор от подпрограми с близкафункционалност, фреймуъркът съдържа в себе голямо количество различни попредназначение библиотеки и програмни връзки между тях. Софтуерната работна рамка е универсална, многократно употребяема софтуернаплатформа, използвана за да се разработват приложения, продукти и софтуернирешения. 2. Прилагане на модел-изглед-контролер в Yii Приложението на MVC в работната рамка е представено сравнително упростено.Основните компоненти на шаблона (Модел,Изглед,Контролер) са изнесени в различнипапки, като всеки един от тези компоненти се намира в отделен файл в съответнатадиректория. Обикновенно всеки от тези три компонента допълва основният интерфейсза компонент. В самата работна рамка има базови класове които спомагат за по-лесната разработка на нови модели и контролери. След като се стартира приложението ако не е посочен контролер или метод, поподразбиране се задейства индекс метода на главният контролер. Той на свой редсъздава обекти за нужните за изпълнението му модели и ги предава на изгледът койтоги визуализира. Фиг. 5. Основна структура на работната рамка Yii
  10. 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. 11. 4. Сигурност на уеб приложенията Сигурността на уеб приложенията зависи главно от това кой е потебителя койтоизползва системата и до какво има има достъп той. Процесът на определяне наидентичността на потербителя се нарича Автентикация (англ. Authentication). Процесътза определянето на правата му за достъп до ресурсите се нарича Оторизация (англ.Authorization). 4.1. Автентикация и оторизация Автентикация е проверка на идентичността, която даден потребител,процес или машина твърдят, че имат. Следващите нива при контрола на достъпазависят от аутентикацията. Обикновенно този процес включва потребителскоиме и парола, но може да включи и други методи за доказване на идентичността,например сертификат електронен подпис, пин код, устройство за разпознаванена пръстови отпечатъци и други. Нивото на автентикация, изисквано за дадена система, зависи отизискванията за сигурност, идващи от самата нея. Например публичнодостъпните уеб сървъри могат да позволяват анонимен достъп, както и достъп загости. Финансовите транзакции трябва да изискват много силна аутентикация.Пример за слаба форма на аутентикация е използването на IP адрес заопределянето на идентичност. Подмяната или нелегалното използване на IPадреса може лесно да излъже този механизъм. Силната форма на аутентикацияизисква поне два фактора за доказване на идентичността:Какво знае човек: пароли и лични идентификационни номера (PIN кодове) сапример за това какво човек може да знае. Паролите могат да бъдат заеднократно или многократно използване. S/Key е пример за система заеднократни пароли (http://en.wikipedia.org/wiki/S/KEY).Какво притежава човек: Различни хардуерни устройства или софтуерниприложния: Смарт карти, също така и SecureID, CRYPTOCard, и SafeWord.Кой е човекът: Биометричните характеристики са това, което показва кой точное човекът, защото разпознаването на идентичността се базира на физическите
  12. 12. му характеристики: например сканиране на дланта, геометрия на ръката,сканиране от ириса на окото, модел на ретината, отпечатъци от пръсти, модел нагласа, разпознаване на лице или подпис.Съществуват много системи за мрежова аутентикация. TACACS+ (TerminalAccess Controller Access System), Kerberos и RADIUS (Remote Access Dial In UserService) са протоколи за аутентикация, поддържани от Сиско.Тези системи зааутентикация могат да бъдат конфигурирани да изпозват много от примерите заустановяване на идентичността, посочени по-гореОторизацията е привилегията да се разрешава достъпа до услуги илиинформация само за определени групи или личности. За системи, които трябвада поддържат високо ниво на сигурност, нивото на достъп по принцип трябва дабъде забранено за всички, като изключенията се добавят допълнително. Дори идобавени допълнително, правилата за достъп трябва да са на принципа на най-малкото, което е нужно на даден човек. За публични системи оторизация можеда се даде и на гости или анонимни потребители. Нужно е да се определятизискванията ни за сигурност,за да се определят подходящите граници на оторизация. Нивото на оторизация внякой случай се определя от групата или ролята на потребителя. Определенигрупи и роли може да имат достъп до всеки ресурс по отделно и по този начинедин потребител да получи повече от една роля или да участва в повече от еднагрупа.В работната рамка Yii има вградена система за автентикация и оторизация коятое лесна за употреба и има възможност за фини настройки според нуждите наприложението.Главната част на тази система е предефинираният потребителски компоненткойто е обект имлементиращ интерфейсътIWebUser. Този компонент представяпостоянната информация за идентичността на текущия потребител. Тозикомпонент може да се достъпи чрез обекта Yii::app()->user
  13. 13. Използвайки този компонент можем да проверим дали потребителя е влязъл всистемата или не чрез метода CWebUser::isGuest, можем да проверим далипотребителя може да изпълнява определени действия чрез методаCWebUser::checkAccess. Също така можем да вземем уникалният ключ и другалична информация за потребителя. 4.2. Определяне на идентичностВ стандартно уеб приложение имплементацията на автентикацията обикновенносъдържа комбинация от потребителско име и парола за да се потвърдиидентичността на потербителя. Фреймуърка дава възможност да се използват идруги методи за автентикация. Ние дефинираме клас за идентичност който дасъдържа основната логика за автентикация. Този клас трябва да се основава наинтерфейсът IUserIdentity. За различните методи за автентициране имаразлични подходи и за всеки от тях може да има различен клас за идентичност.Едни от най-известните начини за автентикация в момента са OpenID, LDAP,Twitter OAuth, Facebook Connect. Най-добрата практика ако се пише нов клас заидентичност е да се наследи класът CUserIdentity който е основен клас заавтентикация използваш комбинация от потребител(емейл) и парола. Основната дейност на класът за идентичност е да имплементира методаIUserIdentity::authenticate. Този метод се използва за да енкапсулира главнитедетайли на даден начин за автентикация. Един клас за идентичност може дадефинира допълнителна информация за потребителя която трябва да бъдепостоянна за цялата сесия на потребителя.Пример:В следващият пример се използва клас за идентичност за да се демонстрираподход за автентикация който използва база данни за съхранение напотребители и паролите. Потребителя трябва да въведе своето потребителскоиме и парола в формата за вход в системата и след това ние трябва дапотвърдим тези данни в таблицата за потребители използвайки ActiveRecordспособа за връзка с базата.
  14. 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. 15. реализира с помощта на компонента authManager. В следващият пример можемда се запознаем със основните концепции на тази схема. Основно понятие в RBAC (Role-Based Access Control) е елементът наразрешение. Това е разрешението да се извърши дадено действие ( да сесъздаде пост в блог, да се изтрие потребител и др.) Според обясненията ицелевата аудитория разрешителните елементи могат да бъдат квалифицираникато операции, задачи и роли. Ролята се състои от задачи, задачата от операцииа операцията е разрешение което е неделимо. Например може да има система вкоято има роля Администратор, която има ръковдна длъжност върхууправлението на потребители и статии. Управлението на потребители може да сесъстои от операции за създаване, промяна и изтриване на потребител. За по-голяма гъвкавост Yii позволява ролята да съдържа други роли, задачи иоперации. Всеки елемент на разрешение може да се дефинира уникално по своетоиме. Той може да бъде свързън с определено бизнес правило. Бизнес правилотов фреймуърка може да бъде част PHP код който ще бъде изпълнен когато сеизисква достъп до даден елемент. Само ако бизнес правилото върне стойностистина потребителя ще има достъп до изисканият ресурс. Например ако трябвада се промени дадена статия, бизнес правилото може да проверява далистатията е написана от потребителя който иска да я промени и ако е само тогаватой ще има достъп. Използвайки елементите за разрешение може да се построи йерархия отразрешителни в която един елемент може да наследява един или повече другиелементи от тази йерархия. След като имаме такава изградена йерархия можемда раздадем роли на потребители. След като една роля е дадена на потебителятой получава правата които са включение в нея. Проверката за права става вкода по следният начин:if(Yii::app()->user->checkAccess(deletePost)){ // delete the post}
  16. 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. 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. 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

×