В своїй презентації The Critical Need to Secure the Web in Your Company, Osterman Research розповідає про критичну необхідність захистити Веб в вашій компанії. Про сучасні ризики, що існуєть в Інтернеті, та про захист від них.
Продовжуючи розпочату традицію, після попереднього відео про основи веб безпеки, пропоную нове відео на веб секюріті тематику. Цього разу відео про безпеку веб шлюзу. Рекомендую подивитися всім хто цікавиться цією темою.
В відео розповідається про надання послуги безпеки веб шлюзу з використанням хмарних (cloud) технологій, зокрема на прикладі Trend Micro Smart Protection Network. Секюріті продукт Secure Web Gateway від Trend Micro використовує дану хмарну технологію і має численні переваги над традиційними рішеннями. Про подібні хмарні продукти від Google та Zscaler я вже писав раніше.
Рекомендую подивитися дане відео для розуміння сучасної ситуації з безпекою в Інтернет.
Існують такі логічні уразливості як Business Logic, що дозволяють маніпулювати фінансовими даними у веб дадатках. І мені неодноразо доводилося знаходити подібні уразливості, починаючи ще з уразливості на clx.ru, що я виявив в 2005 році.
Враховуючи, що Business Logic дірки - це логічні уразливості, то вони відносяться Abuse of Functionality (WASC-42). Атака відбувається при спеціальному використуванні функціоналу сайта (веб додатка), що не очікувався його розробниками.
Але окрім “серверних” Business Logic уразливостей, існують ще “клієнтські”, які мені також доводилося зустрічати (зокрема нещадовно виявив подібні під час секюріті аудиту). І приклади подібних дірок на різних сайтах я з часом оприлюдню. Суть таких атак зводиться до проведення CSRF атаки на користувача з метою маніпуляції його фінансами.
Прикладом подібної уразливості, з якою я стикався неодноразово, є маніпуляція з виведенням коштів на електронні гаманці. Тобто відбувається зловживання функціоналом виводу коштів з аккаунта користувача.
При наявності Cross-Site Request Forgery (WASC-09) на сайті, сценарій атаки буде наступним:
1. Провести CSRF-атаку на користувача, щоб змінити його гаманець (наприклад, WebMoney) на гаманець нападника.
2. Провести другу CSRF-атаку на користувача, щоб ініціювати виведення коштів (на заданий в аккаунті гаманець).
За звичай необхідні два кроки атаки (два CSRF запити), тому що процес зміни гаманця і виведення коштів розбитий на окремі функціонали. Якщо на вразливому сайті ці дві операції об’єднані в один фунціонал, то можна послати один CSRF запит - для виведення коштів на вказаний гаманець.
Для даних задач також можна використовувати і XSS уразливості. В тому числі при наявності на сайті захисту від CSRF, можна через XSS обійти захист від CSRF атак. Але якщо від XSS власники сайтів ще іноді захищаються, то від CSRF захищаються набагато рідше. До того ж, від CSRF атак не захистить жоден WAF 
. Тому CSRF атаки буде досить для виведення коштів з рахунку користувача.
Продовжуючи розпочату традицію, після попереднього відео про DoS атаки на сервер, пропоную нове відео на веб секюріті тематику. Цього разу відео про основи веб безпеки. Рекомендую подивитися всім хто цікавиться цією темою.
В відео розповідається про основи безпеки веб сайтів. Про необхідність слідкувати за безпекою навіть невеликих сайтів. Тому що в наш час цілями хакерів є не тільки державні сайти чи сайти банків, а будь-які веб ресурси, в тому числі невеликі сайти. Які можуть використовуватися для різноманітних зловмисних цілей, зокрема і для проведення атак на більш крупні й важливі сайти.
Рекомендую подивитися дане відео для розуміння необхідності слідкувати за безпекою власних сайтів.
Одним з найбільш критичних витоків інформації є витоки паролів. Коли на сайті розміщується в тестовому вигляді інформація про логіни і паролі - до адмінки сайта чи хостінга, до FTP чи до MySQL або іншої СУБД. За звичай подібна інформація розміщується у txt-файлі. І при цьому власник сайта думає, що ніхто цього файла не знайде 
.
З подібніми витоками інформації мені доводилося стикатися неодноразово. І про один такий випадок, що я виявив нещодавно, я зараз розповім.
Як можна побачити на сайті airbrush.atmosphereart.com.ua - на сайті в “непримітному” файлі p.txt розміщені логіни та паролі доступу до адмінки хостінга, FTP та MySQL. І доступ до файлу не захищений паролем, як це варто було зробити, якщо вже адмін вирішив розмістити таку важливу інформацію в Інтернеті.
Таких витоків інформації (Information Leakage) не варто допускати. Зазначу, що наведена в файлі інформація є застарілою і жоден з цих паролей не працює. Але тим не менше, логіни цілком могли залишитися тими самими. І тому нападники можуть скористатися цими логінами, щоб підібрати до них паролі. Тому не варто робити витоків навіть застарілої інформації (зокрема про логіни і паролі), бо деяка частина інформації може бути все ще актуальною.
Продовжуючи традицію, пропоную вашій увазі цікаві секюріті статті. Щоб ви поповнювали свої знання з веб безпеки.
Добірка цікавого чтива на тему безпеки, в тому числі web security (статті з Вікіпедії):
Продовжуючи розпочату традицію, після попереднього відео про захмарну веб безпеку, пропоную нове відео на веб секюріті тематику. Цього разу відео про DoS атаки на сервер. Рекомендую подивитися всім хто цікавиться цією темою.
В відео розповідається про різні програми для проведення DoS та DDoS атак на сервери (в тому числі веб сервери в Інтернеті). Серед різних додатків, зокрема розповідається про такий потужний інструмент як ping . Рекомендую подивитися дане відео для розуміння векторів DoS атак на сервери.
Окрім “Warning” Google хакінга існують інші види запитів, по яким можна шукати дірки на веб сайтах. Зокрема “Error” Google хакінг, про який я вже давно запланував написати. Це ще один різновид Гугл хакінга - використання пошукових систем (зокрема Гугла) для пошуку уразливостей на сайтах.
Дана методика передбачає використання Гугла (чи інших пошукових систем) з метою пошуку повідомлень на сайтах про помилки, і дозволяє знайти важливу інформацію стосовно даних сайтів. За допомогою спеціальних пошукових запитів (дорків) можна знайти Full path disclosure та Information leakage уразливості на різноманітних сайтах в Інтернеті.
Зокрема можна використовувати наступні “еррор” пошукові запити:
“Software error” “program files”
“You have an error in your SQL syntax”
Продовжуючи розпочату традицію, після попереднього відео про захист електронної пошти, пропоную нове відео на веб секюріті тематику. Цього разу відео про захмарну веб безпеку (тобто про “хмарний” веб секюріті сервіс). Рекомендую подивитися всім хто цікавиться цією темою.
В відео розповідається про надання послуги веб безпеки з використанням хмарних технологій, зокрема на прикладі хмарного (cloud) секюріті продукту від Zscaler. Та про його переваги над традиційними рішеннями. Про подібний хмарний секюріті продукт від Google я вже писав раніше.
Рекомендую подивитися дане відео для розуміння сучасної ситуації з безпекою в Інтернет.
В 2007 році в записі Як знайти 1000000 XSS уразливостей, я розповів про методи знаходження мільйона (і більше) XSS уразливостей (з використанням пошукових систем). А наприкінці минулого року і початку цього року в статтях XSS уразливості в 8 мільйонах флеш файлах та XSS уразливості в 34 мільйонах флеш файлах я розповів про те, що можна знайти мільйони XSS дірок у флешках по всьому Інтернету.
А зараз я розповім, як знайти мільярд уразливостей, зокрема мільярд XSS уразливостей. З використанням “Warning” Google хакінга, як я вже неодноразово писав, можна знаходити мільйони Full path disclosure, але Cross-Site Scripting уразливості та ще й у великих масштабах - це більш цікаво . Зазначу, що для пошуку великої кількості дірок з використанням мого нового методу навіть не потрібно буде використовувати пошукові системи.
За допомогою даного методу можна знайти хоч мільйон, хоч мільярд, хоч трильйон дірок - взагалі нескінченне число дірок. І при цьому для пошуку не потрібні пошуковці, лише потрібно знайти одну спеціальну XSS дірку. З якої потім можна буде зробити будь-яке (навіть нескінченне) число XSS уразливостей.
Суть метода зводиться до пошуку XSS дірки (на будь-якому веб сайті чи веб додатку) в параметрі, що являє собою масив. Подібні параметри зокрема можливі в PHP. І у випадку, якщо веб додаток оброблює всі параметри-у-вигляді-масива відповідним чином (як масив чи хеш), то існує можливість reflected XSS уразливості. Причому не в одному параметрі елементі масива, а в будь-яких - тобто в довільних елементах даного масива (з довільними іменами). Що дозволяє з однієї дірки створити нескінченне число дірок . Тому що різні імена параметрів - це різні дірки.
Наприклад, є веб додаток уразливий до XSS:
http://site/script?p[0]=<script>alert(document.cookie)</script>
При відповідному алгоритмі обробки масиву параметрів p[], можливі й XSS в інших елементах (в тому числі й в пустому - []). Таких елементах як 1, 2, a і т.д.:
http://site/script?p[1]=<script>alert(document.cookie)</script>
Для імені уразливого параметра використовується наступний шаблон: “p” + “[]” або будь-яке слово у “[]”. Можливі також багатовимірні масиви, де будуть відповідні шаблони.
Подібну уразливість я вперше виявив в WordPress цього року (уразливі WordPress 2.7 - 3.0.1). А потім виявив подібні уразливості на одному сайті, під час комерційного секюріті аудиту. Тому в будь-яких PHP додатках, де використовуються параметри-масиви і має місце XSS дірка, можна створити мільйони, мільярди і будь-яке число XSS уразливостей.
* 
You are currently browsing the archives for the Статті category.
Copyright © 2006-2025 MustLive. Усі права захищені.
Партнер проекту Websecurity.com.ua - веб проект mlfun.org.ua.