CMS
Information Security
Comments 41
-2
Спасибо интересно, если в одном месте ввод не валидируется, значит скорее всего есть и еще места, если они не хотят платить, то это не беда, думаю есть и другие места, где за это могут заплатить.
+2
На самом деле я об думал. Но я не хочу ковырять их сайт. Они ясно дали понять, что оплаты не будет. Я конечно мог потребовать оплату «или я выложу это в интернет», при том, что уязвимость принимала не только html, но и js. Просто такой метод не для меня. Я решил, что отдам им уязвимость, а сам — выложу статью, дал им время на исправление.

Подход требования оплаты против воли компании не нравится мне совсем.
Если компанию не интересует безопасность в ее бизнесе — это ее право. Лично меня всегда интересовала безопасность данных пользователей в компании, где я работаю, как и ее владельцев.
-2
Ну пишешь им, типа я нашёл что то интересное, интересен ли диалог или сразу выложить в общий доступ? Тогда может и другой разговор будет, но при втором варианте дыру точно быстрее запаяют.
Только надо аккуратно, что бы не присесть за взлом сайта, все не так однозначно в этом мире.
-3
Не хочу заставлять компании платить.

Если деньги не нужны, то конечно не стоит напрягаться.
+1
Поиск уязвимостей — скорее маленькое хобби, чем способ заработка. Мне достаточно той зп, что мне платят на работе.
+1
Не стоит думать, что upCloud напрочь отказались платить. Вместо этого они предложили бесплатно свои услуги. Но я отказался от такого типа оплаты, так как меня мало интересует аренда сервера сейчас.

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

Автору респект за мужество и целеустремленность.
+3
Я думал что XSS уже неактуальна. Так вот, теперь на сайте кафедры у меня у одного есть аватарка, вместо имени. Все новое, это хорошо забытое старое.
P.s. уже написал в поддержку, должны исправить.
0
Интересно, а за что минусы, что именно плохого я написал?
1) Что старое? 1994 год.
2) Что забытое? Так если бы помнили, то дыр бы не было.
0
1. Сверять с базой промокод при рендере страницы

Мало того, что нагрузка на базу, так ведь ещё же и даёт лазейку для просто перебора этих кодов. Обычно, при регистрации нужна капча, после которой уже и код валидируется. А здесь перебирай — не хочу. Скорее, лучше уж на формат проверять
0
Потому я и пометил, что это не вариант.

А здесь перебирай — не хочу

Это на мой взгляд не важно в партнерской системе. Какая разница использует пользователь один код или другой. Основная фишка промокода — заставить посетителя сайта зарегистрироваться. С точки зрения бизнеса перебрал пользователь промокод или добыл как-то иначе абсолютно не важно.
0
Я исхожу из одноразовости кода.То есть, если человек массово спустит 100 купонов, то он вряд ли потом будет платить по 100 аккаунтам. А если 100 человек по коду на каждого — это 100 рабочих аккаунтов
+1
Поэтому мы можем:
Сверять с базой промокод при рендере страницы
Прогонять через регулярку входной промокод

Простите, рановато вам фуллстэком, лучше бы доучились.


Единственное правильное решение — при генерации HTML преобразовывать все подставляемые в шаблон строки в html entities. Все нормальные template engines умеют это делать автоматически.

+1
Для конкретной задачи (проверка промо-кода) — вообще-то не единственное, потому что без валидации данных в шаблон попадёт мусор, пусть даже и преобразованный в html entities. Да, вреда он не нанесёт, но его там быть просто не должно.

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

Это, разумеется, не избавляет от необходимости при генерации страницы убедится что все спец-символы преобразованы в entities там где не должно быть html — но без валидации это может быть как минимум некрасиво.
0

В контексте корректности кода, корректно формирующего HTML и не имеющего XSS-уязвимостей — именно что единственное правильное.


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

+2
Выше я сказал что нужна валидация и encoding, вы же говорите что достаточно только encoding — что не совсем верно.
0

Я сказал, что для защиты от XSS нужен только encoding.
А в целом нужно еще много что :-)

0
Моя первая закладка

Статья напомнила далекий1976 год, когда я после окончания академии начал работать программистом.
Я был единственный программист и у на с была ЭВМ М-220]. В нашем отделе работал и председатель кассы взаимопомощи Борис Акиндинов (те из СССР хорошо должны помнить этот механизм). И как-то он сказал, а можно автоматизировать весь этот процесс (напомню шел 1976 год и ЭВМ М-220, 4К оперативки и ленты). Я сказал попробую. Сказал — сделал. В процессе работы я понял как на округлении тысячных долей рубля можно сварганить миллионы (правда не в Советском Союзе). Но изюминка была в другом. Мне пришла в голову шальная мысль заложить в программу закладку (такого слова тогда никто не знал), которая бы прекращала работу программ и давала команду на самоуничтожение бы либо через какой-то промежуток времени либо по команде набранной на панели управления. По задумке это команда должна была выдаться, если программу не утвердят как рацпредложение. Но до этого дело не дошло. Рацпредложение утвердили и я получил свой гонорар в размере 15 рублей, который мы коллективом и освоили. Напомню кружка пива в Прибалтике стоила 18 копеек, а бутылка пива 31-37 копеек.

+1
Уф, ну это же древнючий баянище, доли от округления собирать, даже Гарри Гаррисон про такое писал хД.
0
/[A-Z0-9]/g — вполне достаточно для валидации значений и защиты от уязвимости. Причем это работает быстрее чем запрос к базе, а эффект не хуже — XSS снята.

Что значит /[A-Z0-9]/g?
0
Что значит /[A-Z0-9]/g?

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

То есть при тестировании строки через это регулярное выражение строка
QWERTY12 пройдет тест,
а вот QwErTy12 уже нет, так как включает строчные символы
0
В этом регулярном выражении нет якорей, то есть оно проверит всего лишь наличие в строке хотя бы одного допустимого символа.
0
Это было бы так, если бы в конце регулярки не было бы символа g. Он отвечает за то, чтобы проверить все символы строки
+2
Нет. Он отвечает за то чтобы найти все совпадения (не только первое), а не проверить всю строку. Без якоря он найдёт все правильные символы, всего-то, но неправильные просто проигнорирует.
+1
Регулярное выражение /[A-Z0-9]/g будет пропускать QwErTy12 и даже <XSS> или <123>, поскольку Вы проверяете если строка содержит по крайне мере одну цифру или строчную букву (то есть, остальные символы не обязательно должны быть из этого списка).

В этом случае, для правильной валидации нужно указать, что строка должна содержать цифры и строчные буквы от начала до конца строки (то есть, использовать /^[A-Z0-9]+$/).
0
Слабенько для статьи.

Как можно использовать эту уязвимость?
Тут все просто: можно начать со сбора данных всех новых пользователей

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

П.с.: объяснение регекспов на хабре не требуется, кто не знает лучше сам нагуглит.

Итог (на мой субъективный вхгляд): за малополезную статью вы добавили скрипт-киддис-хабратаку на их сервис, ценности у статьи мало, а вместо бесплатного сервера в качестве оплаты можете получить финансовый иск, или уголовный, если вдруг что-то забыли упомянуть в статье, но делали, а они смогут эти действия доказать.
+7
Т.е. Вы в ультимативном ключе заявили компании, что даете ей 48 часов на исправление проблемы, после чего публикуете уязвимость, потому что предложенная компенсация за молчание Вас не устроила.
При этом разработка сайтов явно не в профиле компании, а значит для исправления уязвимости им надо найти исполнителя, заключить договор и т.д. И на все это Вы им отвели 48 часов. Зная, что уязвимость еще не закрыта, опубликовали статью, предоставив неопределенному кругу лиц информацию, которая может привести к проблемам не только у самой компании, но и у всех её клиентов.
ИМХО, такое поведение достойно порицания.
0
Я бы сказал, что это очень сложный вопрос.
При этом разработка сайтов явно не в профиле компании, а значит для исправления уязвимости им надо найти исполнителя, заключить договор и т.д.
Если у компании нет специалистов по разработке, то специалистов по безопасности тоже нет (адекватный безопасник может победить подобную уязвимость даже без знания конкретного языка программирования, либо сделать так, чтобы ее нельзя было проэксплуатировать, а потом ждать нормального исправления программистами). Как компания собирается бороться с атаками в таких или более сложный случаях? Хакер явно не будет говорить, что начнет ломать через 48 часов, а просто сломает все в случае более серьезной уязвимости.

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

Имхо, длительное время на исправление уязвимости допустимо тогда, когда это какая-то нетривиальная проблема, которую очень сложно предсказать и найти. XSS в публично доступных формах — имхо, не из этой категории.
+2
Исследователь — это когда ты на hackerone зарегался, ищешь уязвимости и рассказываешь о них владельцам, а когда ты на произвольном сайте полез копаться в код, нашел уязвимость и рассказал о ней во всеуслышание, то это 272 УК РФ.
0
Вы можете перечитать статью 272. Дело в том, что нахождение уязвимости не карается законом. Вот ее использование — да, если повлекло копирование, модификацию, шифровку или удаление. В моем случае нет ничего противозаконного. Даже если бы я сообщил о ней сразу. Я не могу отвечать за действия других.
0
Ну если истец не будет заявлять, что вы у него что-то поломали или блокировали, то ок, 273-я
тоже под ваши действия хорошо подходит: «распространение… компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации».
Там сроки еще больше. Вы ведь еще и шантажировать пострадавшего умудрились. Тут и корыстный умысел значит есть.

Но вообще, я тут не столько про УК РФ тру, а больше про здравый смысл и этичность.

Правоприменительную практику 272 и 273 можете тут почитать на всякий случай, если уж встали на путь такой:
www.sud-praktika.ru/precedent/category/299.html
www.sud-praktika.ru/precedent/category/138.html
-2
Тут есть несколько факторов.
1) Это все же IT-компания.
2) Она не работает на российском рынке и статью она навряд ли увидит
3) Это обычная xss. Я кинул ссылку, позволяющую воспроизвести уязвимость и дал полное описание, а так же сообщил как ее закрыть. Если it-компания не может за 2 дня вставить регулярку — скорее всего компании это не нужно.

Сейчас, кстати, я проверил наличие уязвимости. Уязвимость закрыта — блокируются пробелы и <, >. Поле для ввода промокода пропадает в случае несоответствия.
0
Вообще-то далеко не во всех IT компаниях сотрудники работают 24/7/365, и даже наличие специалистов не всегда даёт возможность исправить что-то за 48 часов.

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

Вы, конечно, можете сказать что они «сами виноваты», но это реальная жизнь — т.е. это даже при желании исполнителей просто может быть невозможно в короткие сроки, если только не обнаружена уязвимость которая приводит к чудовищным последствиям, причём она очевидна даже для ничего не понимающих в IT и уже активно эксплуатируется.

Или совсем другой вариант. Есть у меня один знакомый, он предоставляет услуги хостинга, хотя сам в этой области обладает минимальными знаниями — он банально перепродаёт услуги другого хостера, добавив чуть-чуть сервиса, и всё очень автоматизировано. Несмотря на это, ему удалось построить вполне прибыльный и стабильный бизнес, а когда нужно сделать что-то сложнее стандартного развёртывания сайта или VPS (как раз то что автоматизировано), он привлекает фрилансеров. Разумеется, у него есть сайт, где всё это продаётся, и выглядит он совсем не колхозно, создаётся впечатление что компания вполне даже IT, солидная и совсем немаленькая, хотя де-факто это один человек.

Теперь представьте, что вы находите уязвимость на его сайте, и даёте ему 48 часов. Ему нужно найти того кто делал сайт (или того кто в нём разбирается), договориться о том когда можно глянуть, как исправить — т.е. нужно и время, и деньги. Вполне может оказаться что он в отпуске, или у него любимая собака заболела, в общем масса всего что может сделать невозможным исправление в эти самые 48 часов, а тут вы со своими требованиями — ведь вы же уверены что «это IT компания», «они должны», etc. — в то время как это что ни на есть малый бизнес с минимальными знаниями, который жил себе спокойно 10 лет и никого не трогал, даже своего веб-девелопера не имеет в связи с отсутствием необходимости (ибо всё настроено и работает почти полностью автоматически).

Подумайте — этично ли в такой ситуации ставить условия и столь жёсткие сроки? А ведь большинство сайтов (в т.ч. тех кто выглядит как IT компании и предлагают хостинг) — это именно малый бизнес, у некоторых даже постоянных изредка приходящих админов нет, и просто глядя на сайт вы никогда на 100% не можете быть уверены что компания действительно способна быстро всё исправить.
0
Они отказались платить за уязвимость, они могли избежать всего этого и, я думаю, ваш знакомый именно это бы и сделал. + я нашел уязвимость и передал им.

Я не имею отношения к тому, что компания по какой-то причине не может исправить уязвимость. Точно так же как не имею отношения к тому, что они валидируют ввод. Сроки не жесткие по причине того, что она фиксится в 2 щелчка. А то, что компания будет тянуть это неделями — не мое дело. Будь это мой сервис — я бы выкатил фикс уже через 5 минут. Я не ставил ультиматум — я поставил выбор, рассказал как ее исправить и дал время на исправление среди рабочей недели.

Хакинг априори не совсем этичное занятие. Ты находишь уязвимость, которую не заметили разработчики — как минимум с них спросят: «как же так?». Я оказался не этичным потому что оказался более внимательным, чем разработчики этого сервиса? На мой взгляд я был бы не этичным если бы начал шантажом требовать оплату, как делают многие в этой сфере. Или выложил бы не сказав компании ни слова.

Компания должна либо заботиться о своих сервисах, либо это ей выходит в копеечку. Так всегда. И причем не важно уязвимость это или баг, который тоже может съедать часть прибыли. Я же этой компании отдал уязвимость бесплатно, не взяв ничего и предоставив время на исправление.

Если за 2 дня компания не может написать одну строчку — виноваты полностью они. Была бы уязвимость с базой — я повременил бы больше. Была бы она критическая — тоже повременил бы больше. 2 дня на строчку — не жесткие сроки на мой взгляд.
0
Они отказались платить за уязвимость

Они и не обязаны это делать — вас ведь никто не нанимал для поиска уязвимости, так что это ваши проблемы.

Сроки не жесткие по причине того, что она фиксится в 2 щелчка.

Тем кто не понимает в js и html — тоже фиксится? Вот есть абстрактный магазин ёлочных игрушек, они наняли Васю Пупкина который им сделал сайт, прошло много лет, Вася Пупкин давно уехал — кто будет фиксить? Специалиста нужно найти — а это время. Ему нужно заплатить — а это деньги. Ему нужно доверять — значит быстро не найти. Вот вы доверите фиксить баг на своём сайте кому-то незнакомому или хотя бы просто мало кому неизвестному?

То, что для вас кажется быстрым и естественным, для человека далекого от области может быть в принципе непреодолимым препятствием, и не у всех есть знакомые «тыжпрограммисты» в шаговой доступности, не говоря уже о специально нанятых сотрудниках, которые бдят 48 часов в сутки.

Ты находишь уязвимость, которую не заметили разработчики — как минимум с них спросят: «как же так?».

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

Я бы ещё понял если бы вы нашли серьезную уязвимость в онлайн-банкинге или там портале госуслуг — да, там это может привести к куче проблем у кучи людей, и можно попытаться подтолкнуть их исправить побыстрее — но промо-код? Извините, но это не та уязвимость ради которой стоит всё бросить и начать фиксить прям счас, если это, к примеру, не Amazon или крупный мобильный оператор (где благодаря XSS много чего плохого можно сделать).

Даже для критичных уязвимостей можно поступить более корректно — не публиковать саму уязвимость и способ её эксплуатации, а только сам факт её обнаружения — это как раз и может стать побудительной причиной для компании заняться проблемой, при этом минимизируя возможность угрозы.

Компания должна либо заботиться о своих сервисах, либо это ей выходит в копеечку.

Да, должна. Но так как считает нужным — не вам решать как именно и как быстро. Нашли, сообщили — молодец. Не дали денег? Так и не обещали вроде. Не исправили за 48 часов? Так см. выше — много причин почему. Но угроза «разоблачения» если не исправят — это как минимум подстава, потому что вы можете быть вообще единственным кто нашёл этот баг за 5-10 лет, и без вашей статьи угроза просто минимальна, а после неё — вы её увеличили на порядки. За это, кстати, по крайней мере в ЕС, можно статью получить — и это правильно.

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

И ещё — я, конечно, не юрист, но мне почему кажется что если кто-то пострадает из-за опубликовайнной вами уязвимости, при этом если это произойдёт после публикации — то у них будет хороший шанс притянуть вас к ответственности (если, конечно, они вас найдут) — как раз потому что 48 часов это очень мало.

Я же этой компании отдал уязвимость бесплатно, не взяв ничего и предоставив время на исправление.

Ещё раз — если это не супер-пупер критичная уязвимость с важностью землетрясения — то вообще некорректно ставить сроки, особенно если это не угрожает вам лично. Если критичная — то нужно договариваться о сроках, почему — см. раньше.

Если за 2 дня компания не может написать одну строчку — виноваты полностью они.

Снова абстрактный магазин ёлочных игрушек, никаких своих девелоперов или сисадмина, владельцы в IT почти ни бум-бум. Бизнес семейный, вся семья в двухнедельном отпуске на Гаваях. В чём их вина? В том что у них нет денег на то чтобы постоянно отслеживать и отвечать на email? Да даже если не в отпуске — если нет специально выделенного email для таких случаев, вы понятия не имеете как много писем им приходит, сколько там спама, какова вероятность того что ваше попало в спам или ждёт своей очереди. Вспомните все эти письма в духе «я хакнул ваш рутер и теперь у меня видео как вы смотрите порно, заплатите на bitcoin или я всем расскажу» (тоже, кстати, дают 48 часов) — и поймёте как может быть воспринято ваше сообщение.

Может быть потом, когда у вас будет своя компания, или просто свой бизнес без компании, вы поймёте что не всё в этом мире идеально, и то что кажется «пустяком» на самом деле требует больше усилий, времени и ресурсов чем кажется кому-то со стороны. А в идеальном мире оно конечно, легко во всех тыкать палочкой и говорить «это неправильно» и «вы должны».
0
Иногда помогают аналогии:
Представьте, что ваш сосед прочитал интересную книжку про домушников и решил поковыряться в замке двери в вашу квартиру. Неожиданно для себя легко подобрал отмычку, после чего предложил вам заплатить ему 1000 руб в обмен на объяснения как он взломал ваш замок. Вы в оплате отказали, на что он дал вам 48 часов на замену замка, по истечении которых отнес рабочую отмычку нарикам из соседнего квартала.
Он сам тоже ничего не ломал у вас, не грабил. Он просто подобрал отмычку к замку и отнес её неопределенному кругу лиц.
0
Будь это мой сервис — я бы выкатил фикс уже через 5 минут.
А уязвимость, всё равно не была бы исправлена ;)

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

Как правило, не нужно тестировать на наличие уязвимостей, если Вас не просили. А если и решили сделать доброе дело, просто не ждите награды и уж тем более не сообщите об этом в открытом доступе без согласия пострадавшего.

Если хотите носить белую шляпу и при этом хорошо зарабатывать, посмотрите в сторону bugcrowd.com, hackerone.com и других сервисов, где действует программа Bug Bounty.
0
Привет, расскажи, пожалуйста, о своём пути разработчика к 20 годам. Как попал в американскую компанию, какая сейчас позиция, каким было собеседование? (и т.п.)
Спасибо!
Only those users with full accounts are able to leave comments., please.