Когда просто отфильтровать параметры запроса недостаточно или о вреде универсальности

[@Ocelot]

Ужасно чешутся руки проверить! Может, стоит перенести топик в закрытые?

[@korvindest]

А вы уверены что ограничения Java машины на процесс не выкинут вовремя исключение о том что память кончилась и никакого падение в своп не будет?
Мне кажется это логичной мерой. ведь в Java использование памяти жестко лимитируется.

[@crea7or]

Это же хабр — сейчас проверят :)

[@barbalion]

А как раз не надо просить слишком много памяти, т.к. виртуальная машина отдаст Out of memory. Но вот если попросить МНОГО памяти, но все же чуть меньше чем лимит, то выбрать несколькими потоками всю имеющуюся память у виртуальной машины довольно легко.

[@webmaks]

Я в другом у них уязвимость нашёл. Отправил, так же сказали учтут. Но публиковать пока не буду, уж больно она каверзная. По телефону горячей линии оператор вообще не поняла о чём речь. Но там дело обстоит игрой с датой отправки.

Хотя в этой организации, думаю пока жаренный петух не клюнет. Не дёрнутся.

[@diamant]

А когда клюнет, с вами свяжутся специалисты.

[@webmaks]

Ага, правоохранительных органов. Чтоб повесить вину на меня :)))

[@impass]

анонимно тоже стрёмно публиковать?

[@akshakirov]

«А если неправильные настройки ОС, и она начнет свопится, то недалеко и до аппаратной смерти сервера.»

Расскажите пожалуйста каким образом свопящийся сервер может умереть аппаратно.

[@barbalion]

Аппаратный сбой HDD из-за большого кол-ва операций.
А почему, вы думали, падают кластеры/облака и почему их так долго поднимают?
Когда падает часть кластера, на остальные узлы попадает чрезмерная нагрузка, из-за которой отказывает аппаратура на новых узах. И так далее — цепная реакция. Пока не придет «лесник» и всех разгонит остановит работу всего кластера, перенастроит и запустит в щтатном режиме.

[@dmandreev]

Вроде кластеры на то и нужны чтобы резерв давать при таких ситуациях. А сбой HDD в таких системах должен быть тем более предсказуемо резервируемым событием.

[@barbalion]

У любой системы есть предел устойчивости. И любую систему делают с неким запасом по прочности, но не более, чем это целесообразно. И кластеры тоже имеют предел. Когда есть 1 сервер под DDoS'ом, то он под такой дикой нагрузкой может проработать, допустим в среднем 3 дня, то когда есть 1000 серверов, каждый час вылетает (грубо) по 14 серверов. В кластере не делают сверх надежных узлов, потому что это 1) дорого 2) не нужно. Делают с определенным запасом, но не более того.

[@amarao]

Я так и не понял, откуда вы выводите зависимость времени работы сервера от его нагрузки. Единственный вариант, который я знаю — это херовые БП, которые при нагрузке проседают по напряжению. Но это мир лоукостных десктопов, а не серверов.

В кластерах обычно используют то же железо, что и для обычных серверов, просто потому, что так проще. Типичные юнитовые/полуюнитовые платформы. В стоимости эксплуатации железо, конечно, играет некоторую роль, но не самую значительную, ибо плотность размещения и эксплуатационные расходы выше.

[@phasma]

свап не сможет физически убить сервер. Не знаю как в виндусе, а в линупсе либо он повиснет намертво, либо оом киллер убьет жабосервер.

[@ComputerPers]

Вы Плохо читаете, убьет HDD.

[@Harkonnen]

Только если хреновый HDD/БП. Это цифровые технологии, а не паровые машины. Без оверклокинна у них 100-1000-кратный запас прочности.

[@akshakirov]

А скажите пожалуйста, сколько свопящихся серверов на вашей практике, умерло аппаратно?

[@amarao]

«аппаратный сбой HDD из-за большого числа операций»? Извините, вы несёте чушь. throttling — да, лаги — да. Я ни разу не видел «аппаратных сбоев» из-за большого числа операций. Причина проста — если в диске забить очередь заданий, то он просто перестанет принимать новые, пока не выполнит старые. Таким образом, никаких «аппаратных сбоев» там быть не может — диск будет делать столько операций, сколько может (и весь мир подождёт).

[@Daedmen]

Полтора часа прошло, а ржд не лежит, так что или все нормально работает, или что-то не так с хабром.

[@impass]

или что-то не так с хабром

очередной слон из мухи

[@egorF]

width у них, кажется, умножается на 194 у них. :)

[@Ocelot]

width — это ширина узкой полосы.

[@egorF]

Error 500: java.lang.OutOfMemoryError

[@Lure_of_Chaos]

ну сколько раз можно говорить, что обязательно проверять все входные данные на допустимость!
«учтут» они…

[@lehha]

Ох, это далеко не единственный сайт…

standartno.ru/Captcha.ashx?w=8000&h=3200&c=GK/z8VK2MYE0uJ+kbVS53w==&bc=ffffff

Вруцентре такая же беда…

[@skitalets]

Автор, закройте топик, или хабралюди полезут проверять!

[@Lure_of_Chaos]

Может быть, иначе и не закроют дыру. Как говорится, «пока гром не грянет, мужик не перекрестится» (ц). А ведь залатать дыру дело нескольких минут.

[@ivanko]

Увы. Дело нескольких минут — внести изменения в код. Вынести на боевой сервер — может занимать часы. С учетом тестов, согласований и прочего. Тут конечно бюрократия наносит страшный удар по пользователям.

[@step307]

Ха! Минут!? Нескольких дней! ))

Сначала человек, отвечающий за прием сообщений с сайта, сообщит об этом главному по ИТ.

Тот прочтет письмо только через день и перенаправит его главному по веб. Главный по веб выйдет из отпуска через несколько дней и назначит «ASAP-пипецсрочно-приступитьнемедленно» таск разработчику.

Тот офигеет от такого события, особенно не поняв с чего такой кипеш по поводу каких-то банальных проверок левых парамтеров. Но на следующий день пофиксит (скорее всего только в этом месте и только половину уязвимостей)

Дальше это все пойдет в отдел QA, который вообще не поймет в чем проблема, «картинка же показывается!»

Ну и потом все это пойдет по цепочке наверх, чтобы сформировать очередную итеррацию по выкладыванию фикса на продакшн.

Чтоб еще страшнее было — могу рассказать, как случайно выложат какие-то левые изменения относящиеся к еще не реализованной фиче, скрипт еще денек не будет работать и т.д. и т.п.

Хотя, может это я такой пессимист и у них там все будет хорошо )))

[@Lure_of_Chaos]

угу, засекаем время )

[@webmaks]

Забыли согласование ФСТЭК добавить. Часть покупки билетов работает с их системой которая обрабатывает персональные данные.

[@MadRogue]

Замечательную зебру можно сгенерировать размером в 20 700px × 5 000px. Больше по размеру не получается сделать, различные ошибки выдаёт.

[@seriyPS]

Да это что… Вот на Zakupki.gov файлы можно заливать какие хошь zakupki.gov.ru/pgz/documentform?id=null&class=null&docType=null

[@mihaild]

Так вот почему им понадобилось 770млн. на модернизацию…

[@burdakovd]

Хм. А если им залить туда что-то запрещенное, а потом пожаловаться что они это хранят у себя на серверах?

[@ComputerPers]

Чего париться, лить туда всё с рутрекера ) хостинг же, халява…

[@Mithgol]

Пример файла, только что залитого на zakupki.gov.ru через эту «дыру»:

[@Mithgol]

Адрес http://zakupki.gov.ru/pgz/documentdownload?documentId=39240775 как бы говорит нам, что можно скачать все документы, на zakupki.gov.ru залитые, перебирая их номера.

[@ChemAli]

Наконец-то хоть какой-то API сделали.

[@Mithgol]

Адрес заливки, кстати, может быть проще: http://zakupki.gov.ru/pgz/documentform (несуществующие параметры самостоятельно принимают там значение «null»).

[@seriyPS]

Там еще в одном из GET параметров XSS уязвимость была, но я уж не стал о ней говорить.