1 / 37

RIA Security

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

afra
Download Presentation

RIA Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Web 2.0 Какво е web 2.0 в момента? • Hosted services • Web applications • Social-networking sites • Video-sharing sites • wikis • Blogs • Mashups

  4. Web 2.0?

  5. Ria Applications? • Уеб базирани приложния, които са създадени и проектирани за да предлагат функционалността на едно desktop приложние • Изпълнението става на клиентската част • Работата с данни става на server-side частта • Този вид приложения работят в браузъра, като единствено условие е инстлирането на на допълнителен plug-in.

  6. Уязвимост и security problems 95% от уеб приложенията са уязвими • Cross-site scripting (80 процента) • SQL injection (62 процента) • Parameter tampering (60 процента) • Cookie poisoning (37 процента) • Database server (33 процента) • Web server (23 процента) • Buffer overflow (19 процента)

  7. Уеб атака?

  8. Security принципи • Разделямесървисите • Web server, app server, db server на различни хостове • Ограничаваме привилегийте на application потребителя • File system (ограничаваме правата само до read-only) • Database System (ограничаваме привилегийте на таблиците, схемите и т.н.) • Привилегийте за xxtomcat, apache, kobayashiи др.

  9. Security принципи • Използване на стандартни компоненти и библиотеки • Винаги проверяваме дали са обновени до последна версия • Винаги пишем в логове и ги преглеждаме за необичайна активност

  10. Open Web Application Security Project (OWASP) Top 10 Проблема със сигуността • 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

  11. Unvalidated input • Хакера винаги може да промени част от HTTP рекуеста преди изпращане на данните: • URL • Cookies • Form fields • Hidden Fields • Headers • Входните данни винаги трябва да бъдат валидирани на сървъра

  12. Broken access control • Access control, понякога наричан authorization, е как приложението доставя достъп и функционалност до определена група потребители. • Client-side caching • Logic Flaws

  13. Broken account and Session management • Слабост в потребителската аутентикация • Използва се само парола • Лесни потребителски имена • Лошо интегриран single sign-on (SSO) • Слабост в ресурсите за аутентикация • Как паролите в базата данни са записани • Могат ли да бъдат достъпени през браузъра • Използване на IP адрес за аутентикация?

  14. Cross-site scripting (XSS) • Човека който атакува приложението... • Инжектира код в страница, който после се изпълнява/показва в браузъра на потребителя • Използва вече trusted приложениеили компания за да отрази злонамерен код до крайния потребител • 2 вида атаки – stored и reflected • Може да се откраднат cookies особенно при приложения с form-based аутентикация

  15. Cross-site scripting (XSS) • Как можем да избегнем тези проблеми? • Валидация на input данните • White-listing: a-z, A-Z, 0-9 и др. • Black-listing: <> () # & • Да не забравяме и : &lt &gt &#40 &#41 &#35 &#38 • Output encoding (htmlEncode output) • Да ограничим броя на въведените символи в input полетата

  16. Buffer Overflow Errors • Buffer Overflow или Buffer Overrun е аномалия където даден процес записва информация в буфер извън паметта. • Проблеми? • Memory access errors • Incorrect results • Program termination • Breach of system security

  17. Injection Flaws • Потребителя може да инжектира злонамерен код от форма или през URL • System commands • SQL • Основни проблеми • Динамични свързани SQL стейтмънти • Примери: • Path traversel : “../” • Команди от вида: “; rm –r *” • SQL injections: “OR 1=1”

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

  19. Improper Error Handling • Неуместните грешки помагат на хакера, как да атакува приложнието • Често програмистите забравят да спрат debug mode. Пример: mysql_query(“SQL query”) or die(mysql_error()); • Добре обяснените съобщения при грешка дават достатъчно информация за потребителя, без да дават информация на хакера

  20. Improper Error Handling

  21. Insecure storage • Данни като кредитни карти, пароли, трябва да бъдат защитени • Пример за слабо/лошо криптиране: • Лош избор на алгоритъм • Проблеми при генерирането на Session tokens • Местата където тези данни са записани трябва да са защитени: • Databases • Files • Memory

  22. Denial-Of-Service (DoS) • DOS атаките са опити да се завземе целия компютърен ресурс и да не бъде достъпен до другите потребители. • Примери: • Unhandled exceptions • Unresolved dependencies on other system • Overuse of logging • Решение на проблема: • Load testing • Code review

  23. Insecure configuration management • Примери: • Unpatched security flaws • Misconfiguration that allow directory traversal • Решение на проблема: • Спиране на всички сървиси, които не се изполват • Конфигуриране на роли, права и потребители • Конфигуриране на logging и alerts

  24. Методи за защита • Никога не се доверявайте на данните изпратени от потребителя • Преглеждайте за логични дупки в сигурността • Давайте само информацията, която е нужна • Тествайте • Очаквайте натоварвания или потенциални DOS атаки

  25. RIA security problems • Програмистите правят много повече грешки при изработка на RIA приложния • Няма добри инструменти за да проверим дали наистина нашите RIA приложения са защитени и сигурни • Няма как да защитим на 100% рекуестите изпратени отRIA app към сървъра

  26. RIA Security Problems • Примерен сценарий • Потребител влиза с потебителско име и парола през RIA app, който изпраща данните до сървър през web service. • Сървърът валидира тези данни и връща отговор за успешен логин на клиента • Клиента дава разрешение на потребителя да работи с него • Потребителя иска да изпрати отново данни, може би веднага след логин

  27. RIA Security Problems • Основен проблем • Как да сме сигурни, че потребителя вече е ауторизиран в системата? • От сървърната част – НЕ. Потребителя трябва да е логнат за да достъпи уеб сървиса • Хакера се нуждае само от URL на уеб сървиса за да намери цялото API на сървиса. • Начини: декомпилиране на кода, използване на monitoring tools като Fiddler

  28. RIA Security Problems • Основен проблем • Obfuscating the code – Няма да помогнe. Можем да използваме Fiddler за да стигнем до URL на web service. • HTTPS/SSL – Няма да помогне. Тук можем само да криптираме рекуестите които се изпращат в интернет. Fiddler пак ще свърши работа • Passing up a hardcoded password with each request – Няма да помогне!В този случай паролата трябва да е записана някаде, но дори и с обфускация хакера може да я намери като декомпилира и промени начина на приложението

  29. RIA Security Problems • Решението • Трябва да пазим потребителския логин (или поне следа от него) и да го изпращаме при всеки рекуест като сървъра трябва да валидира този логин всеки път преди да извърши исканата от нас операция • Лесния начин: • Да следим user и pass в локална променлива и да ги изпращаме всеки път до уеб сървиса. • Недостатък: хакера може да хване пакет който е изпратен по интернет, и да го препрати до сървъра за да приеме валиден отговор от него. Сървъра няма как да направи разликата

  30. RIA Security Problems • Решението • Лошия начин • Изпращане на неразпознаваемо потребителско ID с всеки рекуест. Имаме същия проблем както при първото решение. • Основен проблем: Приложението има опция да връща списък с всички потребители и техните ID-та

  31. RIA Security Problems • Решението • Най-добрия начин • Използване на Session IDs (tokens), като алтернатива на потребителски имена, пароли, ID-та. • Веднъж потребителя влязъл в системата, получава уникално генериран token, който има връзка с потр. име и парола. • Потребителя прави рекеуст с този token, сървъра проверява дали той е валиден и връща отговор • Token-а трябва да expire-ва.

  32. Flash security problems • Flash cross-site scripting • Използване на инструменти като: OWASP’s SWF Intruder и HP’s SWFScanмогат да намерят проблеми като cross-site scripting

  33. Flash security problems

  34. 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>

  35. Flash security problems • Web service SQL injection HTTP RequestPOST /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:Envelopexmlns: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><GetUserInfoxmlns="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

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

  37. Q&A

More Related