Не нужно идеализировать специалистов по безопасности / хакеров, наделяя их особыми сверхспособностями. Прежде всего это люди, обладающие некими техническими навыками, которые позволяют им выполнять определенные задачи.
Они точно также ковыряются в носу, ходят в храм и забывают включенный утюг дома — то есть допускают самые обычные человеческие ошибки. А если в историю добавить дополнительный ингредиент вроде спешки по срокам, то и вовсе все выглядит вполне правдоподобно. У всех пельмени падают.
Ну вот про это и речь — вы просто не понимаете риски и опасность того, что вы пишите. «С User-Agent вообще спорно». Для вас подмена юзерагента без исходного кода приложения — нечто из рамок выходящее, маловероятное и все такое. Вы по другую сторону барьера, вы не знаете техник атакующего. Для пентестера(и всяких взломщиков в том числе) — один из базовых подходов при backbox тестировании. Просто вот так при анализе веб приложения пентестеры практически сразу же берут да и втыкают кавычки в юзерагент, не пользуясь для этого браузером, а например Burp Suit'ом или Fiddler'ом. Просто так все сканнеры, начиная с Acunetix'a делают тоже самое в автоматическом режиме. Такая уязвимость найдется любым адекватным сканнером уязвимостей.
Очень много бед в ИБ идет из-за непонимания. Непонимания механизмов, процессов, рисков. В вашем случае видна нехватка знаний в теме «безопасность веб приложений», есть перекос в сторону «кражи кук по вине дыры в безопасности браузера», но при этом приводите в примере sql инъекции. Это намекает на незнание темы и на неправильную оценку рисков по теме «безопасности веб приложений», на которую вы подвязались учить других. Чревато это тем, что часть людей(не берем в счет те приложения, где вы уже успели внедрить вышеприведенный код — там отдельные риски), которые точно также не понимают нюансов, стянут код у вас(просто нагуглят по запросу «Надёжная авторизация для веб-сервиса за один вечер») и влепят к себе. А достаточно было хотя бы просто не учить тому, в чем сами пока не являетесь специалистом.
Мне думается, что у млекопитающих мышление превалирует над инстинктами, а у насекомых — инстинкты над мышлением. Разные ветки эволюции, разные принципы выживания.
Человек прав. Подобный подход «бездумной» комбинации фильтрующих функций сам по себе может создать баг, и лишь говорит о не компетенции советующего в данном вопросе. К сожалению, не все кулхацкеры умеют что-то тольковое советовать в разработке и обеспечении безопасности.
Если контекст вывода — html, то фильтровать надо при обработке функцией htmlspecialchars с нужной комбинацией флагов, в зависимости, опять-таки, от контекста использования конкретно этих данных в конкретном месте приложения.
Встречал как-то эксплуатацию подобной html инъекции в почте мейл.ру года 4 назад.
В письмо встраивался html + inline css код, который добавлял прозрачный слой с position:absolute на весь экран, обернутый в ссылку на фейк сайт злоумышленника.
Так, как слой перекрывал весь интерфейс почты, по любому клику в любом месте происходил редирект на фейк, который выглядел как страница логина в мейл.ру и невнимательный пользователь думал, что его просто выкинуло из сессии при входе в просмотр письма и клику например на «Входящие». Я к тому, что сценарии эксплуатации подобных вещей имеются, но немало зависит от контекста. В почте это было опасно.
https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40
Hashtype: WPA/WPA2
Speed.Dev.#*.: 3177.6 kH/s
А это уже 3 с лишним миллиона хешей в секунду.
Они точно также ковыряются в носу,
ходят в храми забывают включенный утюг дома — то есть допускают самые обычные человеческие ошибки. А если в историю добавить дополнительный ингредиент вроде спешки по срокам, то и вовсе все выглядит вполне правдоподобно. У всех пельмени падают.в целом рановато вам еще рассуждать о безопасности, на данный момент статья — набор вредных советов из 1999 года.
sql injection
Если контекст вывода — html, то фильтровать надо при обработке функцией htmlspecialchars с нужной комбинацией флагов, в зависимости, опять-таки, от контекста использования конкретно этих данных в конкретном месте приложения.
В письмо встраивался html + inline css код, который добавлял прозрачный слой с position:absolute на весь экран, обернутый в ссылку на фейк сайт злоумышленника.
Так, как слой перекрывал весь интерфейс почты, по любому клику в любом месте происходил редирект на фейк, который выглядел как страница логина в мейл.ру и невнимательный пользователь думал, что его просто выкинуло из сессии при входе в просмотр письма и клику например на «Входящие». Я к тому, что сценарии эксплуатации подобных вещей имеются, но немало зависит от контекста. В почте это было опасно.