1. Ваша перша сесія з Fiddler
2. Що ще можна зробити
3. OWASP Top 10 - # 1: Ін'єкція
4. OWASP Top 10 - # 2: Зламана аутентифікація і менеджмент сесій
5. OWASP Top 10 - # 7: Відсутній контроль доступу рівня функції
6. Як розповісти розробникам про свою знахідку
7. Насправді це не проблема!
8. Це не відбудеться на проде, тому що SSL
9. Я не хакер
10. Тепер що?
11. Посилання та інструментарій для подальшого вивчення
12. Сайти для інформації та вивчення
13. Інструменти для тестувальника

Автор: Кейт Паулке

Оригінал статті: http://dojo.ministryoftesting.com/lessons/but-im-not-a-security-tester-security-testing-on-the-web-for-the-rest-of-us

Переклад: Ольга Алифанова

Ваша перша сесія з Fiddler

Для початку мінімізуйте все, що може утруднити вам перегляд. Закрийте всі, що стукає в мережу, крім однієї вкладки одного браузера. Я вибираю IE через приємного плагіна, а потім запускаю Fiddler.

Перейдіть у вкладку «Фільтри» (Filters) і дозвольте фільтрацію, а потім переконайтеся, що відображається тільки трафік з вашого обраного браузера. В теорії запущений повинен бути тільки цей єдиний браузерні процес, але деякі з них, особливо в 64-бітних системах, запускають кілька процесів. Це ще одна причина вибирати IE. Натисніть на чек-боксі, та й все. Готово. Ви бачите тільки трафік IE.

Якщо веб-додаток, з яким ви працюєте, не має налаштованого SSL в тест-оточенні, не вмикайте розшифровку SSL. Fiddler працює як проксі-сервер для всього веб-трафіку, тому він може і буде розривати все, що розмовляє з Інтернетом. Це руйнування набагато більш ... цікаво, якщо ви тестируете щось, що приходить через SSL. Fiddler створює самостійно підписаний сертифікат, який змушує з'явитися всі можливі попередження браузера про контент, що не заслуговує довіри (важче бути більш очевидним, ніж «НЕ ДОВІРЯЙТЕ», але я впевнена, хтось впорається з більш моторошним Алерт). Ви виявите, що не можете нікуди потрапити через нескінченні попереджень безпеки. Це одна з причин, по якій профі рекомендують працювати на віртуальній машині. Метушня з Інтернет-профілем вашої віртуальної системи не вплине на вашу звичайну систему.

Погуляйте по своєму додатку. Ви отримаєте список всіх запитів, які були зроблені, і всіх відповідей. Цей список буде більш виразним, ніж той, який можна переглянути в браузерному перехопленні мережі, і його перегляд куди краще організований. Виберіть який-небудь цікавий запит, а потім відкрийте вкладку Inspectors.

Всі вкладки у вкладках Request data і Response data містять корисну інформацію в залежності від того, на що ви дивитеся. Зараз зверніть увагу на вкладку WebForms у вкладці Request.

Приховані поля, поля cookie і все, що ви заповнили, як на долоні. Це один із способів подивитися на ескалацію привілеїв (тип порушення безпеки, коли користувач може змусити додаток зробити те, на що у нього немає прав - наприклад, коментатор блогу може редагувати чиї-небудь посади).

В першу чергу перейдіть у вкладку Compose до в верхньому ряду вкладок. Цю вкладку я використовую найчастіше, крім Inspectors. Перетягніть підсвічений запит, який ви досліджуєте, у вкладку Composer. З'явиться текст запиту, що очікує ваших змін.

Тепер ви можете редагувати будь-яке поле тіла запиту, і що завгодно в рядку запиту. Або можна замінити cookie на будь-яку іншу, записану під час перегляду. Або видалити її зовсім. Якщо ви тестируете щось, що не може бути зроблено, якщо ви не авторизовані, і у вас є cookie аутентифікації - спробуйте видалити її в Composer і підтвердити.

Якщо у відповідь ви отримали відповідь 200 ОК, то ваш наступний крок - перевірити, чи змогли ви змінити дані, незважаючи на правила. Уявіть, що станеться, якщо в онлайн-банку хтось зможе обійти стандартні правила і перевести гроші з вашого профілю. Вони зможуть змінити ваш пароль на що завгодно, і гра буде закінчена - з точки зору сервера, це ви вносите всі ці зміни.

Що ще можна зробити

• Подивіться, що станеться, якщо ви додасте в GET що-небудь на зразок цих рядків:
  • <Script> alert (document.cookie); </ script>
  • % 3Cscript% 3Ealert (document.cookie)% 3B% 3C% 2Fscript% 3E
  • (Це спрощені приклади, але якщо ваша команда не особливо досвідчена в області безпечного коду, вони можуть спрацювати. Це означає, що будь-хто може зробити поп-ап з підказкою пароля, що дозволяє збирати імена та паролі користувачів).
  • Досвід у XKCD з littleBobbyTablesв будь-якому з полів форми.

Що ви можете знайти

Відкритий проект з безпеки веб-додатків (( OWASP ) Підтримує список десяти найбільш поширених веб-вразливостей. Зараз вони приймають пропозиції для списку 2016 року, але список 2013 року все ще корисний. Хакери ціляться в легені мішені, тому переконайтеся, що в плані цих вразливостей ви захищені. Зараз я пробіжуся за деякими уязвимостям зі списку, щоб показати, як можна використовувати Fiddler, тестуючи їх.

OWASP Top 10 - # 1: Ін'єкція

Ін'єкція змушує сайт запускати код, який заклали ви, замість власного коду або разом з власним кодом. Вона не просто так йде в списку першим номером. Хто завгодно може це зробити, для цього не потрібно особливих навичок, а руйнування вона може принести колосальні.

Вкладка Composer в Fiddler дозволяє перевіряти кілька типів ін'єкцій, редагуючи запити, які ви вже відправили, і міняти значення полів або рядків запитів. Великий список неприємних запитів на GitHub - непогане місце для старту, тому що він групує рядки в міру того, якої шкоди вони можуть завдати.

OWASP Top 10 - # 2: Зламана аутентифікація і менеджмент сесій

Ця вразливість виникає, коли тип зберігання даних вашим додатком дозволяє доступ до захищеної інформації без попереднього логіна. Якщо ви можете перевідкрити закриту вкладку і перейти безпосередньо до сторінки, для перегляду якої потрібна авторизація - особливо якщо ви вийшли з системи перед закриттям вкладки - то ви натрапили на зламану авторизацію або менеджмент сесій.

Перевірити це через Fiddler до смішного просто. При запущеному Fiddler авторизуйтесь в додатку, зробіть що-небудь, що вимагає авторизації, потім вийдіть із системи. Виберіть момент, який вимагав авторизації, клікніть правою кнопкою і виберіть Replay.

Якщо менеджмент сесій працює як повинен, вас повинно перенаправити на сторінку авторизації, або на помилку «не авторизований». Запит ні в якому разі не повинен успішно відпрацювати. Бачите, все не так складно, як здавалося! Чекайте опору від розробників, якщо ви знайшли тут вразливість. Зміна авторизації і менеджменту сесій зазвичай означає реінжиніринг всієї системи, і якщо вони використовують сесії з коротким терміном життя, то вашої організації цього може бути достатньо.

OWASP Top 10 - # 3: Крос-сайтовий сценарії (XSS)

Крос-сайтовий сценарії, або XSS - можливо, найпоширеніша уразливість сайтів згідно з базою даних OWASP. XSS просто змушує сайт запускати Javascript, закладений атакуючим. Це один із способів викрасти дані користувачів. Якщо вони можуть змусити сервер запустити Javascript, що відкриває діалогове вікно повторного введення логіна і пароля, вони можуть змусити це вікно відправити логін і пароль їм на пошту, поки ви, жертва, думаєте, що сайт просто перестраховується.

Для перевірки цієї уразливості, як і для перевірки будь-ін'єкції, можна використовувати Fiddler. Використовуйте що завгодно в секції Script Injection з Великого список неприємних запитів (використовуйте blns.txt і почніть з 268 рядки) і подивіться, що буде. Якщо ви побачите спливаюче вікно Javascript - ви знайшли XSS-уразливість.

OWASP Top 10 - # 7: Відсутній контроль доступу рівня функції

Ця вразливість просто дає браузеру вирішувати, які поля показувати, приховувати, або робити доступними тільки для читання в залежності від вашого рівня доступу, і не проводити той же набір перевірок, вносячи зміни. Це важче знайти, але в будь-якому веб-додаток, де люди вводять дані, чекаючи, що вони будуть захищені, дуже важливо переконатися, що додаток перевіряє, що у користувача є права доступу, коли дані відображаються, і коли вони зберігаються.

Щоб перевірити це через Fiddler, треба добре знати додаток і бути в курсі того, який рівень доступу дозволений яким користувачам і за яких умов, і бути здатним дістатися туди послідовними сесіями різних користувачів.

1. Увійдіть як адміністратор, зробіть що-небудь, що може зробити тільки адміністратор. Переконайтеся, що зміни збережені, і перевірте, що вони застосовані, перед виходом із системи. Fiddler запише інформацію про вашу сесії.
2. Тепер зайдіть звичайним користувачем, або походіть по системі. Все, що вам насправді потрібно - отримати cookie звичайного користувача через Fiddler. Вам може знадобитися вхід в систему для отримання такої cookie, залежить від програми.
3. Тепер починається веселуха. Перетягніть форму адміністратора у вкладку Composer. Так ви побачите всі відправлені поля. Ви хочете змінити дані форми, щось очевидне - наприклад, ім'я.
4. Тепер перейдіть в Inspector і виберіть останній запит звичайного користувача. Скопіюйте cookie вашого звичайного користувача з вкладки Raw, і замініть cookie в запиті Composer. Все готово до відправки!
5. Надсилайте ваші підроблений запит з Composer, щоб зберегти змінені дані в системі. Якщо збереження правильно працює з авторизацією, змін не буде. Отримайте ви помилку чи ні - залежить від програми, головне, чи збережуться дані. Якщо це сталося ура! Ви знайшли уразливість, яка вимагає виправлення.

Як розповісти розробникам про свою знахідку

Я бачила різні реакції - від «О ні, це треба виправити!» До «Як ти посміла технічно втручатися в мій код!» - від розробників. Як сказати їм, що в коді проблема? Найчастіше це «не їхня код», тому що кожна система накопичує легаси-проблеми в процесі використання, але хтось повинен її підтримувати, і де-факто за код відповідають розробники. Багато що тут залежить від того, наскільки хороші ви як команда, наскільки велика проблема, і скільки роботи потрібно, щоб її виправити.

Мій підхід дуже простий: описати проблему, кроки її відтворення, додати посилання на бази безпеки, що описують проблему, і описати потенційні наслідки присутності цієї уразливості в системі. Переконайтеся, що ваші опису нейтральні, і ніколи не звинувачуйте нікого за невдачу.

Насправді це не проблема!

Фраза, відома також, як «ніхто ніколи так не зробить» і «що за хренью ти тут томишся?» Так, ми також відомі, як «ніхто», тому що тільки що зробили «так».

Вам доведеться доводити, що проблема є, якщо ви отримали таку реакцію, тому перший крок - відтворення проблеми. Якщо доведеться, зробіть це кілька разів, під наглядом розробників. Якщо вони не можуть подивитися, то запис екрану спрацює (для цього можна скористатися Jing).

Зв'язок із OWASP top 10 і Information Security Stack Exchange теж допомагають.

Тримайте в розумі, що насправді це дійсно може бути не проблемою. Ви працюєте на тестовому сайті, у якого є уразливості, про які ви не в курсі, тому що сайт зроблений більш відкритим для тест-завдань. Це ще одна причина відправитися на Information Security Stack Exchange - є шанси, що хтось вже зробив те, що зробили ви, знайшов те, що знайшли ви, і має на руках рішення або доказ, що це не проблема (або проблема).

Це не відбудеться на проде, тому що SSL

З цим я теж стикалася - відповідайте, повторюючи те, що ви зробили, на проде, використовуючи свої дані або відомі тестові дані, потім зайшла в оркестр результат. Однак обмежтеся в результаті тільки фактами - тим, що ви зробили, і результатами.

Я не хакер

Настав ваш зоряний час для опору. «Ну так і я не хакер, і якщо Я можу це зробити, хакер тим більше зможе!»

Тепер що?

Не бійтеся ескаліровать проблему, якщо ваші розробники серйозно налаштовані нічого не робити, а ви переконані, що проблема є. Розробникам легко втратити загальну картину і відкинути проблему безпеки, тому що вони не в курсі, що те, що вони вважають рідкісними ситуаціями, може коштувати їх роботодавцю мільйони, якщо хтось до цього додумається (стикалася і з таким). Або вони недостатньо знайомі з вимогами до доменної безпеки (і з цим я стикалася). Або вони не вірять, що тестувальники досить розбираються в їх області (так, і з цим теж).

Документуйте, документуйте, документуйте, ескаліруйте при необхідності, і прийміть як даність підсумкове рішення. Іноді те, що виглядає жахливо з вашої точки зору, не так вже й погано.

Посилання та інструментарій для подальшого вивчення

Місць, куди можна відправитися, щоб дізнатися більше, мільйон, і багато хто з них безкоштовні. Це, безумовно, неповний список, але непогане місце для старту.

Сайти для інформації та вивчення

Сюди я ходжу, якщо у мене виникають питання, проблема чи це, чи мені потрібно знайти спосіб краще, щоб протестувати безпеку.

Information Security Stack Exchange - Тут ви знайдете безліч корисної інформації. Шукайте відповіді на свої питання, і ви будете винагороджені глибокими знаннями, знайшовши відповідь. Або просто вивчіть інформацію по тегу, який привернув вашу увагу. Тут можна знайти практично все, що стосується безпеки інформації.

OWASP - Відкритий проект по веб-безпеки - це ще один прекрасний інструмент для навчання. У них є секція для допомоги тестувальникам, які шукають проблеми безпеки, і безліч іншої інформації.

Troy Hunt's site - Трой Хант веде відмінний блог з безпеки з безліччю додаткової інформації для тих, кому вона необхідна.

PCI Security Standards - Якщо ви тестируете додаток, що приймає кредитні картки, то цей сайт - ваш головний помічник.

Bill Sempf's site - Блог Білла Семпфа населений безліччю посилань на корисні ресурси. Він також містить цікаві та доступні статті про інструменти.

Інструменти для тестувальника

The Big List of Naughty Strings - Містить відмінну колекцію рядків, що викликають проблеми в різних середовищах. Використовувати з обережністю, але використовувати обов'язково.

IronWASP - IronWASP - це хороший базовий сканер безпеки, який буде коштувати вам тільки витраченого часу. Чесно кажучи, я вважаю його допомогу і пояснення можливих проблем більш корисними, ніж саме сканування, але ваш досвід може відрізнятися від мого.

Fiddler - Мій особистий друг для більшої частини тестування на проникнення. Я отримую від нього більше інформації, ніж від інструментів розробника в браузері, і у мене більше контролю над даними, якими я маніпулюю.

Jing - Jing я віддаю перевагу для захоплення екрану і запису відео. Він швидко створює скріншоти, і вміє записувати короткі (до п'яти хвилин) відео, які запускаються в більшості браузерів.

Notepad ++ - Це мій улюблений текстовий редактор. До нього є купа плагінів, включаючи шифровку / дешифрування URL, підсвічування синтаксису коду (яка робить читання коду дуже простим), і автоформатирование HTML і XML для простоти читання.

Обговорити в форумі