37
RIA Security Росен Иванов

RIA Security

  • 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

Page 1: RIA Security

RIA SecurityРосен Иванов

Page 2: RIA Security

Web 2.0 Въведение RIA applications – Какво точно е това? Уязвимост и security holes в Web 2.0 и RIA Методи на защита RIA security problems Flash security problems Conclusion

Content

Page 3: RIA Security

Какво е web 2.0 в момента?

- Hosted services- Web applications- Social-networking sites- Video-sharing sites- wikis- Blogs- Mashups

Web 2.0

Page 4: RIA Security

Web 2.0?

Page 5: RIA Security

Уеб базирани приложния, които са създадени и проектирани за да предлагат функционалността на едно desktop приложние

Изпълнението става на клиентската част Работата с данни става на server-side

частта Този вид приложения работят в

браузъра, като единствено условие е инстлирането на на допълнителен plug-in.

Ria Applications?

Page 6: RIA Security

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

Page 7: RIA Security

Уеб атака?

Page 8: RIA Security

Разделяме сървисите◦ Web server, app server, db server на различни

хостове Ограничаваме привилегийте на

application потребителя◦ File system (ограничаваме правата само до

read-only)◦ Database System (ограничаваме привилегийте

на таблиците, схемите и т.н.)◦ Привилегийте за xxtomcat, apache, kobayashi и

др.

Security принципи

Page 9: RIA Security

Използване на стандартни компоненти и библиотеки◦ Винаги проверяваме дали са обновени до

последна версия Винаги пишем в логове и ги

преглеждаме за необичайна активност

Security принципи

Page 10: RIA 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 Проблема със сигуността

Page 11: RIA Security

Хакера винаги може да промени част от HTTP рекуеста преди изпращане на данните:◦ URL◦ Cookies◦ Form fields◦ Hidden Fields◦ Headers

Входните данни винаги трябва да бъдат валидирани на сървъра

Unvalidated input

Page 12: RIA Security

Access control, понякога наричан authorization, е как приложението доставя достъп и функционалност до определена група потребители.

Client-side caching Logic Flaws

Broken access control

Page 13: RIA Security

Слабост в потребителската аутентикация◦ Използва се само парола◦ Лесни потребителски имена ◦ Лошо интегриран single sign-on (SSO)

Слабост в ресурсите за аутентикация◦ Как паролите в базата данни са записани

- Могат ли да бъдат достъпени през браузъра◦ Използване на IP адрес за аутентикация?

Broken account and Session management

Page 14: RIA Security

Човека който атакува приложението...◦ Инжектира код в страница, който после се

изпълнява/показва в браузъра на потребителя◦ Използва вече trusted приложение или

компания за да отрази злонамерен код до крайния потребител

◦ 2 вида атаки – stored и reflected◦ Може да се откраднат cookies особенно

при приложения с form-based аутентикация

Cross-site scripting (XSS)

Page 15: RIA Security

Как можем да избегнем тези проблеми?◦ Валидация на input данните

- White-listing: a-z, A-Z, 0-9 и др.- Black-listing: <> () # &- Да не забравяме и : &lt &gt &#40 &#41 &#35

&#38 ◦ Output encoding (htmlEncode output)◦ Да ограничим броя на въведените символи в

input полетата

Cross-site scripting (XSS)

Page 16: RIA Security

Buffer Overflow или Buffer Overrun е аномалия където даден процес записва информация в буфер извън паметта.

Проблеми?◦ Memory access errors◦ Incorrect results◦ Program termination◦ Breach of system security

Buffer Overflow Errors

Page 17: RIA Security

Потребителя може да инжектира злонамерен код от форма или през URL◦ System commands◦ SQL

Основни проблеми◦ Динамични свързани SQL стейтмънти

Примери:◦ Path traversel : “../”◦ Команди от вида: “; rm –r *”◦ SQL injections: “OR 1=1”

Injection Flaws

Page 18: RIA Security

Решение на тези проблеми?◦ Използване на PreparedStatements в SQL◦ Изпълнение с ограничени привилегии◦ Филтриране/валидиране на input

Injection Flaws

Page 19: RIA Security

Неуместните грешки помагат на хакера, как да атакува приложнието

Често програмистите забравят да спрат debug mode. Пример: mysql_query(“SQL query”) or die(mysql_error());

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

Improper Error Handling

Page 20: RIA Security

Improper Error Handling

Page 21: RIA Security

Данни като кредитни карти, пароли, трябва да бъдат защитени

Пример за слабо/лошо криптиране:◦ Лош избор на алгоритъм◦ Проблеми при генерирането на Session tokens

Местата където тези данни са записани трябва да са защитени:◦ Databases◦ Files◦ Memory

Insecure storage

Page 22: RIA Security

DOS атаките са опити да се завземе целия компютърен ресурс и да не бъде достъпен до другите потребители.

Примери:◦ Unhandled exceptions◦ Unresolved dependencies on other system◦ Overuse of logging

Решение на проблема:◦ Load testing◦ Code review

Denial-Of-Service (DoS)

Page 23: RIA Security

Примери:◦ Unpatched security flaws◦ Misconfiguration that allow directory traversal

Решение на проблема:◦ Спиране на всички сървиси, които не се

изполват◦ Конфигуриране на роли, права и потребители◦ Конфигуриране на logging и alerts

Insecure configuration management

Page 24: RIA Security

Никога не се доверявайте на данните изпратени от потребителя

Преглеждайте за логични дупки в сигурността

Давайте само информацията, която е нужна

Тествайте Очаквайте натоварвания или

потенциални DOS атаки

Методи за защита

Page 25: RIA Security

RIA security problems Програмистите правят

много повече грешки при изработка на RIA приложния

Няма добри инструменти за да проверим дали наистина нашите RIA приложения са защитени и сигурни

Няма как да защитим на 100% рекуестите изпратени от RIA app към сървъра

Page 26: RIA Security

Примерен сценарий◦ Потребител влиза с потебителско име и

парола през RIA app, който изпраща данните до сървър през web service.

◦ Сървърът валидира тези данни и връща отговор за успешен логин на клиента

◦ Клиента дава разрешение на потребителя да работи с него

◦ Потребителя иска да изпрати отново данни, може би веднага след логин

RIA Security Problems

Page 27: RIA Security

Основен проблем◦ Как да сме сигурни, че потребителя вече е

ауторизиран в системата?◦ От сървърната част – НЕ. Потребителя трябва

да е логнат за да достъпи уеб сървиса◦ Хакера се нуждае само от URL на уеб сървиса

за да намери цялото API на сървиса.◦ Начини: декомпилиране на кода, използване

на monitoring tools като Fiddler

RIA Security Problems

Page 28: RIA Security

Основен проблем◦ Obfuscating the code – Няма да помогнe.

Можем да използваме Fiddler за да стигнем до URL на web service.

◦ HTTPS/SSL – Няма да помогне. Тук можем само да криптираме рекуестите които се изпращат в интернет. Fiddler пак ще свърши работа

◦ Passing up a hardcoded password with each request – Няма да помогне! В този случай паролата трябва да е записана някаде, но дори и с обфускация хакера може да я намери като декомпилира и промени начина на приложението

RIA Security Problems

Page 29: RIA Security

Решението◦ Трябва да пазим потребителския логин (или

поне следа от него) и да го изпращаме при всеки рекуест като сървъра трябва да валидира този логин всеки път преди да извърши исканата от нас операция

◦ Лесния начин:- Да следим user и pass в локална променлива и да ги

изпращаме всеки път до уеб сървиса. - Недостатък: хакера може да хване пакет който е

изпратен по интернет, и да го препрати до сървъра за да приеме валиден отговор от него. Сървъра няма как да направи разликата

RIA Security Problems

Page 30: RIA Security

Решението◦ Лошия начин

- Изпращане на неразпознаваемо потребителско ID с всеки рекуест. Имаме същия проблем както при първото решение.

- Основен проблем: Приложението има опция да връща списък с всички потребители и техните ID-та

RIA Security Problems

Page 31: RIA Security

Решението◦ Най-добрия начин

- Използване на Session IDs (tokens), като алтернатива на потребителски имена, пароли, ID-та.

- Веднъж потребителя влязъл в системата, получава уникално генериран token, който има връзка с потр. име и парола.

- Потребителя прави рекеуст с този token, сървъра проверява дали той е валиден и връща отговор

- Token-а трябва да expire-ва.

RIA Security Problems

Page 32: RIA Security

Flash cross-site scripting Използване на инструменти като:

OWASP’s SWF Intruder и HP’s SWFScan могат да намерят проблеми като cross-site scripting

Flash security problems

Page 33: RIA Security

Flash security problems

Page 34: RIA Security

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>

Page 35: RIA Security

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>&apos; 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

Page 36: RIA Security

Code CarefullyЗаключение

Page 37: RIA Security

Q&A