https://www.opennet.me/openforum/vsluhforumID3/112832.html Изучив 433 тысячи сайтов, информация о которых собрана в рамках проекта HTTP Archive (http://httparchive.org/) и доступа для анализа при помощи интерфейса BigQuery (https://bigquery.cloud.google.com/), исследователи обнаружили (https://snyk.io/blog/77-percent-of-sites-still-vulnerable/), что 77% из изученных сайтов используют как минимум одну JavaScript-библиотеку, содержащую известные уязвимости. <br>51.8% из этих сайтов содержат более одной уязвимости в библиотеках, а 9.2 более трёх уязвимостей. <br><br><br> Наиболее часто встречаются уязвимые копии библиотеки jQuery (https://snyk.io/vuln/npm:jquery), которая используется на 82.4% из всех проверенных сайтов. 92.5% из сайтов, использующих jQuery, содержат необновлённые уязвимые версии. На втором месте библиотека jQuery UI (https://snyk.io/vuln/npm:jquery-ui), которая применяется на 19.9% сайтов и 89.7% из используемых копий уязвимы. Далее следуют Moment.js (https://snyk.io/vuln/npm:Moment) - 73.0% уязвимых версий из всех установок данной библиотеки, AngularJS (htt https://www.opennet.me/openforum/vsluhforumID3/112832.html#63 Sun, 26 Nov 2017 18:03:20 GMT Но ведь XSS всегда экранируется на сервере. Не придет ничего клиенту.<br>Хорошо, допустим у нас плохой сервер, он не экранирует XSS и отдает пользователям все как есть. В ответ на асинхронный запрос, некая библиотека начинает модифицировать дом и вставлять полученный результат, тут должна себя проявить уязвимость?<br>Но ведь, странная ситуация, у нас получается сервер которому мы не доверяем.<br> https://www.opennet.me/openforum/vsluhforumID3/112832.html#62 Sun, 26 Nov 2017 17:22:48 GMT Атака на фронтэнд, это не атака на сервер/инфраструктуру проекта, а атака на пользователя и его данные. Например, если удастся выполнить javascript в web-интерфейсе при его просмотре администратором (самый тривиальный случай - script injection из-за проблемы с валидацией комментариев) много чего можно натворить.<br><br> https://www.opennet.me/openforum/vsluhforumID3/112832.html#61 Sun, 26 Nov 2017 10:32:31 GMT Дело не вот что программисты не хотят переходить на новые версии.<br>А дело в том что для перехода на новую версию надо переписать сайт целиком.<br> <br> https://www.opennet.me/openforum/vsluhforumID3/112832.html#60 Sun, 26 Nov 2017 06:02:02 GMT Если у апологетов уязвимостей в на фронтенде закончились аргументы, то даже не смешно, люди всерьез не понимают о чем говорят. Весь отчет похоже сделали те, кто решил заработать на аудит безопасности фронтенда, дело бестолковое, но менеджерам можно продемонстрировать длинный список уязвимостей на странице их корпоративного сайта, расцветить все красным, нагнать жути и продать свои услуги.<br> https://www.opennet.me/openforum/vsluhforumID3/112832.html#59 Sun, 26 Nov 2017 05:47:56 GMT Я, как и многие тут, не понимаю про опасность уязвимостей фронтенд библиотеках. Сам я бекендщик, фронтенд это всегда не доверенная среда, кто угодно может поменять дом (пользователь, аддон в броузере и т.д.), модицицироваь запрос к серверу, потому все XSS и некорректные запросы фильтруется на сервере.<br>Дайте кейс когда уязвимость в фроненд библиотеке может нанести хоть какой вред?<br> https://www.opennet.me/openforum/vsluhforumID3/112832.html#57 Sat, 25 Nov 2017 12:46:52 GMT Меня одного шокирует сложившая сегодня ситуация, что недостаточно образованные верстальщики за типовые сайты с кривоватой версткой и уязвимыми JS библиотеками (фреймворками) получают в разы больше чем люди закончившие профильные университеты (а то и несколько) и работающие по профессии годами с опытом в десятки лет?<br><br>Может быть уже как-то изменить данную ситуацию, а давайте закроем JavaScript и сделаем поддержку WebAssembly и поддержку в LLVM что бы самый оптимальный и качественный код мог по прежнему быть написан на годами проверенных языках?<br><br>А еще вся эта чепуха с анимацией в CSS выкинуть надо и добавить в WebAssembly (то есть все поведение в код), а стиль в CSS.<br><br>А ну и еще конечно нужен инструментарий для WebAssembly наборы компиляторов и интерпретаторов.<br><br>С точки зрения пользователей правда непонятная выгода конечно так вроде как на коленке чет понаписали и работает и ладно, а так сайты будут целыми монстрами и приложениями ...<br> https://www.opennet.me/openforum/vsluhforumID3/112832.html#56 Sat, 25 Nov 2017 09:55:03 GMT &gt; Ну, блин, поменять ядро 3.15 на 4.14 я могу. <br><br>это потому, что на самом деле оно не "4.14", а 2.7.4.14 (ну, ок, может 2.8)<br>А при замене ядер в те времена, когда инвесторы еще не любили большие числа (сейчас даже при замене 2.6.что-то на 4ю ветку нет таких глобальных изменений), чтение Documentation/Changes вовсе не было рутинной процедурой. "поставьте make версии n+1, правда, он не ставится без апдейта libc, которая не собирается этим мэйком, иначе ведро вообще не соберете. Тут в proc изменился один файлик, и ваши procps утилиты превратились в тыкву. Здесь пересоберите ppp и все связанное с ним барахло. И мы опять сломали nfs, надеемся, вы не с него загружались."<br><br><br> https://www.opennet.me/openforum/vsluhforumID3/112832.html#55 Sat, 25 Nov 2017 09:14:12 GMT И какое сколь угодно RESTFUL API требует от вас, приняв произвольный комментарий от пользователя, сохранять его в неприкосновенности, надеясь на то, что при выводе его что-то на клиенте проэкранирует? А если, не дай бог, админка наваяна на коленке и в ней забудут проэкранировать тот же комментарий и аккуратно выведут его администратору - этот дятел таки порушит всю вашу цивилизацию?<br> https://www.opennet.me/openforum/vsluhforumID3/112832.html#54 Fri, 24 Nov 2017 21:33:44 GMT &gt; Какой же дурак делает экранирование - на клиенте? <br><br>API, REST? Нет, не слышал.<br><br>&gt; То есть первый же бот, посылающий ответ без всякого браузера, сделает то же самое, как бы вы ни обновляли библиотеки?!<br><br>Задаю наводящий вопрос: "И от чьего же имени сможет написать бот?". <br><br>&gt; это глупость программиста, который доверяет данным, пришедшим с фронтенда.<br><br>Мысль о том, что и бекенду тоже не надо доверять, в голову никогда не заглядывала?<br>