1.1 Testing for Credentials Transported over an Encrypted Channel
Суть тестування:
Тестування передачі облікових даних означає перевірку того, що дані для аутентифікації користувача передаються через супер пупер зашифровані канали, щоб уникнути перехоплення хлопцями зловмисниками. Аналіз зосереджений просто на спробі зрозуміти, або передається все в незашифрованому вигляді з веб-браузера на сервер, або програма суцільна діра і передає все у відкритому вигляді на сервер. Також слід зрозуміти, що веб-додаток вживає відповідних заходів безпеки з використанням протоколу, такого як HTTPS. Протокол HTTPS побудований на TLS/SSL для шифрування даних, що передаються, і варто переконатися, що користувач направляється на бажаний сайт.
Очевидний факт, що якщо трафік зашифрований, це не означає його повну безпеку. Безпека також залежить від алгоритму шифрування та надійності ключів, які використовує додаток. Трохи про те, як варто хешувати критичні дані ваших користувачів, я писав у цій статті. Тут тестувальнику просто треба зрозуміти, чи є дані, які користувачі вводять у веб-форми для входу на сайт або здійснюючи покупку, передаються з використанням безпечних протоколів, які захищають їх від хацкерів.
В даний час найбільш поширеним прикладом цієї проблеми є сторінка входу до системи веб-програми. Тестувальник повинен переконатися, що облікові дані користувача передаються зашифрованим каналом. Щоб увійти на веб-сайт, користувач зазвичай повинен заповнити просту форму, яка передає вставлені дані на веб-додаток за допомогою методу POST. Потрібно визначити те, що ці дані не передані за допомогою протоколу HTTP, який передає дані в незахищеній формі. А передаються за допомогою протоколу HTTPS, що шифрує дані під час передачі.
Як протестувати
У таких прикладах ми будемо використовувати веб-проксі для захоплення пакетів даних та їх перевірки. Можете використовувати будь-який веб-проксі, який ви віддаєте перевагу. Як налаштовувати проксі можна глянути в цьому видосі за брутфорсом. Приклад 1. Надсилання даних методом POST через HTTP Припустимо, що сторінка входу є формою з полями User, Pass і кнопкою Submit для автентифікації та надання доступу до програми. Якщо ми подивимося на заголовки нашого запиту за допомогою веб-проксі, ми можемо отримати щось на зразок цього:
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404Accept: text/xml,application/xml,application/xhtml+xml
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64
delegated_service=218&User=test&Pass=test&Submit=SUBMIT
З цього прикладу тестувальник може зрозуміти, що запит POST надсилає дані на сторінку. www.example.com/AuthenticationServlet за допомогою HTTP. Таким чином, дані передаються без шифрування і якщо знайдеться хацкерок, який це помітить, він зможе стирати ім'я користувача і пароль, просто обнюхуючи мережу за допомогою такого інструменту, як Wireshark. Приклад 2: Надсилання даних методом POST через HTTPS Припустимо, що наш веб-додаток використовує протокол HTTPS для шифрування даних, які ми надсилаємо. У цьому випадку при вході в веб-додаток заголовок нашого запиту POST буде схожий на наступний:
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50
Command=Login&User=test&Pass=test
Ми бачимо, що запит адресований на www.example.com:443/cgi-bin/login.cgi за протоколом HTTPS. Це гарантує, що наші облікові дані надсилаються за допомогою зашифрованого каналу і що облікові дані не можуть бути прочитані зловмисником, який використовує різні сніфери.
Приклад 3: Надсилання даних методом POST через HTTPS на сторінці, доступній через HTTP
Тепер уявіть, що веб-сторінка доступна через HTTP, і що тільки дані, надіслані з форми автентифікації, надсилаються HTTPS. Така ситуація виникає, наприклад, коли ми знаходимося на порталі великої компанії, яка пропонує різні інформація та послуги, які є загальнодоступними без ідентифікації, але на сайті також є особистий розділ доступний з домашньої сторінки, коли користувачі входять до системи. Тому, коли ми намагаємося увійти до системи, заголовок нашого запиту буде виглядати як такий приклад:
POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45
User=test&Pass=test&portal=ExamplePortal
Ми бачимо, що наш запит адресовано на www.example.com:443/login.do за допомогою HTTPS. Але якщо ми подивимося на заголовок Referer (сторінка, з якої ми прийшли), це www.example.com/homepage.do та доступний через простий HTTP. Хоча ми надсилаємо дані через HTTPS, це розгортання може допускати SSLStrip атаки.
Приклад 4: Надсилання даних методом GET через HTTPS
У цьому останньому прикладі припустимо, що програма передає дані за допомогою методу GET. Цей метод ніколи не повинен бути використаний у формі, яка передає конфіденційні дані, такі як ім'я користувача та пароль, тому що дані відображаються у відкритому вигляді в URL-адресі, і це викликає низку проблем з безпекою. Наприклад, запитана URL-адреса легко доступна з журналів сервера або з історії вашого браузера, що робить ваші конфіденційні дані доступними для сторонніх осіб. Таким чином, цей приклад є чисто демонстраційним, але насправді рекомендується використовувати POST замість цього.
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
Ви можете бачити, що дані передаються у вигляді відкритого тексту в URL-адресі, а не в запиті, як раніше. Це не найкраща практика. використовувати метод GET для надсилання конфіденційних даних у веб-додаток, оскільки інформація, що міститься в URL-адресі, може зберігатися в багатьох місцях, наприклад, у журналах проксі та веб-сервера.
Тестування сірої скриньки
Поговоріть з розробниками веб-програми та спробуйте зрозуміти, чи знають вони про відмінності між протоколами HTTP і HTTPS :-))) і чому вони повинні використовувати HTTPS для передачі конфіденційної інформації. Потім перевірте, чи HTTPS використовують у кожному конфіденційному запиті, наприклад, на сторінках входу, щоб запобігти перехопленню неавторизованими користувачами даних.