Upload
afra
View
69
Download
0
Embed Size (px)
DESCRIPTION
RIA Security. Росен Иванов. Content. Web 2.0 Въведение RIA applications – Какво точно е това? Уязвимост и security holes в Web 2.0 и RIA Методи на защита RIA security problems Flash security problems Conclusion. Web 2.0. Какво е web 2.0 в момента? Hosted services - PowerPoint PPT Presentation
Citation preview
RIA SecurityРосен Иванов
Web 2.0 Въведение RIA applications – Какво точно е това? Уязвимост и security holes в Web 2.0 и RIA Методи на защита RIA security problems Flash security problems Conclusion
Content
Какво е web 2.0 в момента?
- Hosted services- Web applications- Social-networking sites- Video-sharing sites- wikis- Blogs- Mashups
Web 2.0
Web 2.0?
Уеб базирани приложния, които са създадени и проектирани за да предлагат функционалността на едно desktop приложние
Изпълнението става на клиентската част Работата с данни става на server-side
частта Този вид приложения работят в
браузъра, като единствено условие е инстлирането на на допълнителен plug-in.
Ria Applications?
95% от уеб приложенията са уязвими
Cross-site scripting (80 процента) SQL injection (62 процента) Parameter tampering (60 процента) Cookie poisoning (37 процента) Database server (33 процента) Web server (23 процента) Buffer overflow (19 процента)
Уязвимост и security problems
Уеб атака?
Разделяме сървисите◦ Web server, app server, db server на различни
хостове Ограничаваме привилегийте на
application потребителя◦ File system (ограничаваме правата само до
read-only)◦ Database System (ограничаваме привилегийте
на таблиците, схемите и т.н.)◦ Привилегийте за xxtomcat, apache, kobayashi и
др.
Security принципи
Използване на стандартни компоненти и библиотеки◦ Винаги проверяваме дали са обновени до
последна версия Винаги пишем в логове и ги
преглеждаме за необичайна активност
Security принципи
1. Unvalidated input 2. Broken access control 3. Broken account/session management 4. Cross-site scripting (XSS) flaws 5. Buffer overflows 6. Injection flaws 7. Improper error handling 8. Insecure storage 9. Denial-of-service 10. Insecure configuration management
Open Web Application Security Project (OWASP) Top 10 Проблема със сигуността
Хакера винаги може да промени част от HTTP рекуеста преди изпращане на данните:◦ URL◦ Cookies◦ Form fields◦ Hidden Fields◦ Headers
Входните данни винаги трябва да бъдат валидирани на сървъра
Unvalidated input
Access control, понякога наричан authorization, е как приложението доставя достъп и функционалност до определена група потребители.
Client-side caching Logic Flaws
Broken access control
Слабост в потребителската аутентикация◦ Използва се само парола◦ Лесни потребителски имена ◦ Лошо интегриран single sign-on (SSO)
Слабост в ресурсите за аутентикация◦ Как паролите в базата данни са записани
- Могат ли да бъдат достъпени през браузъра◦ Използване на IP адрес за аутентикация?
Broken account and Session management
Човека който атакува приложението...◦ Инжектира код в страница, който после се
изпълнява/показва в браузъра на потребителя◦ Използва вече trusted приложение или
компания за да отрази злонамерен код до крайния потребител
◦ 2 вида атаки – stored и reflected◦ Може да се откраднат cookies особенно
при приложения с form-based аутентикация
Cross-site scripting (XSS)
Как можем да избегнем тези проблеми?◦ Валидация на input данните
- White-listing: a-z, A-Z, 0-9 и др.- Black-listing: <> () # &- Да не забравяме и : < > ( ) #
& ◦ Output encoding (htmlEncode output)◦ Да ограничим броя на въведените символи в
input полетата
Cross-site scripting (XSS)
Buffer Overflow или Buffer Overrun е аномалия където даден процес записва информация в буфер извън паметта.
Проблеми?◦ Memory access errors◦ Incorrect results◦ Program termination◦ Breach of system security
Buffer Overflow Errors
Потребителя може да инжектира злонамерен код от форма или през URL◦ System commands◦ SQL
Основни проблеми◦ Динамични свързани SQL стейтмънти
Примери:◦ Path traversel : “../”◦ Команди от вида: “; rm –r *”◦ SQL injections: “OR 1=1”
Injection Flaws
Решение на тези проблеми?◦ Използване на PreparedStatements в SQL◦ Изпълнение с ограничени привилегии◦ Филтриране/валидиране на input
Injection Flaws
Неуместните грешки помагат на хакера, как да атакува приложнието
Често програмистите забравят да спрат debug mode. Пример: mysql_query(“SQL query”) or die(mysql_error());
Добре обяснените съобщения при грешка дават достатъчно информация за потребителя, без да дават информация на хакера
Improper Error Handling
Improper Error Handling
Данни като кредитни карти, пароли, трябва да бъдат защитени
Пример за слабо/лошо криптиране:◦ Лош избор на алгоритъм◦ Проблеми при генерирането на Session tokens
Местата където тези данни са записани трябва да са защитени:◦ Databases◦ Files◦ Memory
Insecure storage
DOS атаките са опити да се завземе целия компютърен ресурс и да не бъде достъпен до другите потребители.
Примери:◦ Unhandled exceptions◦ Unresolved dependencies on other system◦ Overuse of logging
Решение на проблема:◦ Load testing◦ Code review
Denial-Of-Service (DoS)
Примери:◦ Unpatched security flaws◦ Misconfiguration that allow directory traversal
Решение на проблема:◦ Спиране на всички сървиси, които не се
изполват◦ Конфигуриране на роли, права и потребители◦ Конфигуриране на logging и alerts
Insecure configuration management
Никога не се доверявайте на данните изпратени от потребителя
Преглеждайте за логични дупки в сигурността
Давайте само информацията, която е нужна
Тествайте Очаквайте натоварвания или
потенциални DOS атаки
Методи за защита
RIA security problems Програмистите правят
много повече грешки при изработка на RIA приложния
Няма добри инструменти за да проверим дали наистина нашите RIA приложения са защитени и сигурни
Няма как да защитим на 100% рекуестите изпратени от RIA app към сървъра
Примерен сценарий◦ Потребител влиза с потебителско име и
парола през RIA app, който изпраща данните до сървър през web service.
◦ Сървърът валидира тези данни и връща отговор за успешен логин на клиента
◦ Клиента дава разрешение на потребителя да работи с него
◦ Потребителя иска да изпрати отново данни, може би веднага след логин
RIA Security Problems
Основен проблем◦ Как да сме сигурни, че потребителя вече е
ауторизиран в системата?◦ От сървърната част – НЕ. Потребителя трябва
да е логнат за да достъпи уеб сървиса◦ Хакера се нуждае само от URL на уеб сървиса
за да намери цялото API на сървиса.◦ Начини: декомпилиране на кода, използване
на monitoring tools като Fiddler
RIA Security Problems
Основен проблем◦ Obfuscating the code – Няма да помогнe.
Можем да използваме Fiddler за да стигнем до URL на web service.
◦ HTTPS/SSL – Няма да помогне. Тук можем само да криптираме рекуестите които се изпращат в интернет. Fiddler пак ще свърши работа
◦ Passing up a hardcoded password with each request – Няма да помогне! В този случай паролата трябва да е записана някаде, но дори и с обфускация хакера може да я намери като декомпилира и промени начина на приложението
RIA Security Problems
Решението◦ Трябва да пазим потребителския логин (или
поне следа от него) и да го изпращаме при всеки рекуест като сървъра трябва да валидира този логин всеки път преди да извърши исканата от нас операция
◦ Лесния начин:- Да следим user и pass в локална променлива и да ги
изпращаме всеки път до уеб сървиса. - Недостатък: хакера може да хване пакет който е
изпратен по интернет, и да го препрати до сървъра за да приеме валиден отговор от него. Сървъра няма как да направи разликата
RIA Security Problems
Решението◦ Лошия начин
- Изпращане на неразпознаваемо потребителско ID с всеки рекуест. Имаме същия проблем както при първото решение.
- Основен проблем: Приложението има опция да връща списък с всички потребители и техните ID-та
RIA Security Problems
Решението◦ Най-добрия начин
- Използване на Session IDs (tokens), като алтернатива на потребителски имена, пароли, ID-та.
- Веднъж потребителя влязъл в системата, получава уникално генериран token, който има връзка с потр. име и парола.
- Потребителя прави рекеуст с този token, сървъра проверява дали той е валиден и връща отговор
- Token-а трябва да expire-ва.
RIA Security Problems
Flash cross-site scripting Използване на инструменти като:
OWASP’s SWF Intruder и HP’s SWFScan могат да намерят проблеми като cross-site scripting
Flash security problems
Flash security problems
Flash security problems Слабост във Flash конфигурацията
◦ Crossdomain.xml – позволява Flash content-а да бъде достъпван от други домейни
◦ Проблем: Ако cross domain policy е конфигуриран да дава достъп до всеки домейн това може да доведе до cross-site request forgery attacks (XSRF attacks)
◦ Пример за недобре конфигуриран cross domain:<?xml version="1.0"?><!DOCTYPE cross-domain-policy blah, blah, blah><cross-domain-policy><allow-access-from domain="*" /></cross-domain-policy>
Flash security problems Web service SQL injectionHTTP Request
POST /acuservice/service.asmx HTTP/1.0Accept: */*Content-Type: text/xmlUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)Host: testaspnet.acunetix.comContent-Length: 549Connection: CloseSOAPAction: "http://tempuri.org/GetUserInfo"Expect: 100-continuePragma: no-cache
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:m0="http://tempuri.org/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Header/><SOAP-ENV:Body><GetUserInfo xmlns="http://tempuri.org/"><username>' or 1=1 -- </username><password>1</password></GetUserInfo></SOAP-ENV:Body></SOAP-ENV:Envelope>
HTML ResponsefalseSELECT * FROM users WHERE username='' or 1=1 -- ' AND password='c4ca4238a0b923820dcc509a6f75849b'0bladebogdan calin2009-06-02T16:50:00.4671234512345 address
Code CarefullyЗаключение
Q&A