Предисловие
Всем привет. Мне 20 лет. Еще недавно я учился в лицее и готовился поступать в медицинский ВУЗ, а сейчас я — фулстэк разработчик в одной американской компании. На самом деле я очень рад, что с медициной у меня не вышло — программирование было моим хобби, а сейчас я могу им заниматься постоянно. Сейчас я хотел бы написать скорее не об успехе в IT. Прямо сейчас я хочу поговорить о том, как я прочитал пару книг по уязвимостям (для защиты своих проектов) и мне удалось применить эти знания на практике.
Дисклеймер
Все материалы, скриншоты, а так же ссылки на сторонние ресурсы, размещены в образовательных целях. Автор не несет ответственности за их использование другими посетителями хабра. Компания заранее уведомлена за 48 часов об уязвимости и получила достаточно данных для ее исправления.
Как все начиналось
Был вполне обычный день. Я выполнил несколько задач на работе и заварил себе чашку кофе. Заодно решил прочитать одну статью про деплой приложения на AWS, которую некогда репостнул себе в вк (кстати, статью я так и не прочитал). В колонку справа от статьи выведено несколько других статей и партнерский баннер на хостинг-провайдера.
Не помню уже что именно заставило меня перейти на сайт, но при переходе я заметил одну интересную особенность: ссылка ведет на страницу регистрации и на ней сразу заполнено одно поле — промокод.
Если сравнить промокод, который находится в поле для ввода и в адресной строке — увидим что они полностью совпадают.
Что мы с этим можем сделать?
Банально — попробовать изменить. Если промокод сравнивается со значением в базе — с большой вероятностью нам вернут ошибку. Но При изменении в инпуте — на сервер запроса нет и выходит, что инпут проверяется только при нажатии на кнопку регистрации.
Думаю тут уже можно сделать что-то более интересное: меняем наш промокод прямо в адресной строке и смотрим что же выйдет. Если у них нет промокода специально под хабр, который я так слету угадал,
Следущий шаг — смотрим HTML-код. ПКМ по полю для ввода -> Просмотр кода элемента.
Здесь сразу видно, что мы меняем value поля для ввода. Попробуем выйти из него и добавить например ссылку. Для этого нам достаточно изменить ссылку и мы сможем изменить контент страницы:
Результат: только что мы нашли xss-уязвимость на сайте хостинг-провайдера.
И что дальше?
Думаю стоит пойти глубже. Ссылка — как-то мелко и не интересно. Мы же хотим это все рассказать владельцам сервиса и, в идеале, получить вознаграждение (компания, кстати, не имеет bug bounty, а значит все это не оплачивается, но тогда я еще об этом не знал). Попробуем разместить блок, застиллизовать его и вставить изображение. Что для этого нужно? все то же — менять url.
Думаю описывать html и css не стоит, поэтому я просто положу тут то, что вышло. Хабр блокирует часть тегов, другие отбрасывает — не могу выложить код ссылки сюда.
Выложу сюда ссылку. Не знаю работает ли она в данный момент, но при выкладывании поста работала. Кому надо — вытащит ссылку и распарсит.
Вознаграждение
Не стоит думать, что upCloud напрочь отказались платить. Вместо этого они предложили бесплатно свои услуги. Но я отказался от такого типа оплаты, так как меня мало интересует аренда сервера сейчас.
Как можно использовать эту уязвимость?
Тут все просто: можно начать со сбора данных всех новых пользователей, а закончить фишинговыми сайтами и использованием чужого хостинга в качестве своего. Можно заменить все ссылки на странице на собственные или подменить форму у пользователей. Достаточно их отправить как рефералов. И конечно же можно подменять запрос к серверу с формы, чтобы он не проверял промокод (при регистрации промокод проверяется, а на клиент возвращается ответ с ошибкой, но это все решается включением жс).
Что забыли сделать разработчики:
Все просто — валидировать пользовательский ввод. SQL-Inj там не проходит — сервис висит на вордпрессе, а он в свою очередь, обрабатывает входящие строки.
Поэтому мы можем:
- Сверять с базой промокод при рендере страницы
Это медленно и не оправдано. Не стоит дополнительной нагрузки на базу, да и смысла в этом нет, если он все равно проверяется при регистрации.
- Прогонять через регулярку входной промокод
/^[A-Z0-9]+$/ — вполне достаточно для валидации значений и защиты от уязвимости. Причем это работает быстрее чем запрос к базе, а эффект не хуже — XSS снята.
Заключение
Владельцы сервиса были уведомлены за 48 часов + 2 дня до этого я вел переговоры по электронной почте и LinkedIn с теми, кто хоть как-то относится к разработке. Все разговоры приходили к: «Скажите нам пожалуйста как вы это сделали, но за уязвимости мы, конечно же, платить не будем.». Так же добавлю, что точно таким же образом сайт принимает сторонние js-скрипты: как через сторонний источник, так и прямым написанием кода, однако во втором случае Google Chrome автоматически обнаруживает xss и рендерит страницу ошибки вместо страницы сервиса.
Надеюсь каждый программист будет валидировать все входные данные и не будет забывать про querystring. А так же уверен что статья поможет кому-то заблаговременно заметить + исправить эту проблему у себя.
Большое спасибо за внимание.
Комментарии (41)
Koneru
15.06.2019 16:39+3Я думал что XSS уже неактуальна. Так вот, теперь на сайте кафедры у меня у одного есть аватарка, вместо имени. Все новое, это хорошо забытое старое.
P.s. уже написал в поддержку, должны исправить.Koneru
15.06.2019 19:53Интересно, а за что минусы, что именно плохого я написал?
1) Что старое? 1994 год.
2) Что забытое? Так если бы помнили, то дыр бы не было.
prs123
15.06.2019 19:371. Сверять с базой промокод при рендере страницы
Мало того, что нагрузка на базу, так ведь ещё же и даёт лазейку для просто перебора этих кодов. Обычно, при регистрации нужна капча, после которой уже и код валидируется. А здесь перебирай — не хочу. Скорее, лучше уж на формат проверятьEgorVolokitin Автор
15.06.2019 20:47Потому я и пометил, что это не вариант.
А здесь перебирай — не хочу
Это на мой взгляд не важно в партнерской системе. Какая разница использует пользователь один код или другой. Основная фишка промокода — заставить посетителя сайта зарегистрироваться. С точки зрения бизнеса перебрал пользователь промокод или добыл как-то иначе абсолютно не важно.prs123
15.06.2019 20:52Я исхожу из одноразовости кода.То есть, если человек массово спустит 100 купонов, то он вряд ли потом будет платить по 100 аккаунтам. А если 100 человек по коду на каждого — это 100 рабочих аккаунтов
symbix
15.06.2019 20:39+1Поэтому мы можем:
Сверять с базой промокод при рендере страницы
Прогонять через регулярку входной промокодПростите, рановато вам фуллстэком, лучше бы доучились.
Единственное правильное решение — при генерации HTML преобразовывать все подставляемые в шаблон строки в html entities. Все нормальные template engines умеют это делать автоматически.
Tangeman
16.06.2019 05:11+1Для конкретной задачи (проверка промо-кода) — вообще-то не единственное, потому что без валидации данных в шаблон попадёт мусор, пусть даже и преобразованный в html entities. Да, вреда он не нанесёт, но его там быть просто не должно.
Правильный вариант (опять-таки, для данного случая) — как раз убедиться что промо-код содержит только допустимые символы, с чем отлично справится регулярка.
Это, разумеется, не избавляет от необходимости при генерации страницы убедится что все спец-символы преобразованы в entities там где не должно быть html — но без валидации это может быть как минимум некрасиво.symbix
16.06.2019 06:57-1В контексте корректности кода, корректно формирующего HTML и не имеющего XSS-уязвимостей — именно что единственное правильное.
Логика, связанная с корректностью промокода — это отдельная валидация, не имеющая никакого отношения к XSS. То, что в данном конкретном случае этой валидации оказалось бы достаточно, чтобы неправильный код формирования шаблона никак себя не проявил, не значит ровно ничего. Не надо смешивать слои.
saipr
15.06.2019 20:41Моя первая закладка
Статья напомнила далекий1976 год, когда я после окончания академии начал работать программистом.
Я был единственный программист и у на с была ЭВМ М-220]. В нашем отделе работал и председатель кассы взаимопомощи Борис Акиндинов (те из СССР хорошо должны помнить этот механизм). И как-то он сказал, а можно автоматизировать весь этот процесс (напомню шел 1976 год и ЭВМ М-220, 4К оперативки и ленты). Я сказал попробую. Сказал — сделал. В процессе работы я понял как на округлении тысячных долей рубля можно сварганить миллионы (правда не в Советском Союзе). Но изюминка была в другом. Мне пришла в голову шальная мысль заложить в программу закладку (такого слова тогда никто не знал), которая бы прекращала работу программ и давала команду на самоуничтожение бы либо через какой-то промежуток времени либо по команде набранной на панели управления. По задумке это команда должна была выдаться, если программу не утвердят как рацпредложение. Но до этого дело не дошло. Рацпредложение утвердили и я получил свой гонорар в размере 15 рублей, который мы коллективом и освоили. Напомню кружка пива в Прибалтике стоила 18 копеек, а бутылка пива 31-37 копеек.
Nimbus
15.06.2019 20:51/[A-Z0-9]/g — вполне достаточно для валидации значений и защиты от уязвимости. Причем это работает быстрее чем запрос к базе, а эффект не хуже — XSS снята.
Что значит /[A-Z0-9]/g?EgorVolokitin Автор
15.06.2019 20:54Что значит /[A-Z0-9]/g?
Это регулярное выражение. Вообще в разных языках они могут выглядеть по разному.
Конкретно это проверяет все символы строки на то, чтобы они включали в себя либо только заглавные буквы латиницы, либо цифры.
То есть при тестировании строки через это регулярное выражение строка
QWERTY12 пройдет тест,
а вот QwErTy12 уже нет, так как включает строчные символыTangeman
16.06.2019 04:57В этом регулярном выражении нет якорей, то есть оно проверит всего лишь наличие в строке хотя бы одного допустимого символа.
EgorVolokitin Автор
16.06.2019 07:37Это было бы так, если бы в конце регулярки не было бы символа g. Он отвечает за то, чтобы проверить все символы строки
Tangeman
16.06.2019 14:44+1Нет. Он отвечает за то чтобы найти все совпадения (не только первое), а не проверить всю строку. Без якоря он найдёт все правильные символы, всего-то, но неправильные просто проигнорирует.
w0den
16.06.2019 15:29Регулярное выражение
/[A-Z0-9]/gбудет пропускатьQwErTy12и даже<XSS>или<123>, поскольку Вы проверяете если строка содержит по крайне мере одну цифру или строчную букву (то есть, остальные символы не обязательно должны быть из этого списка).
В этом случае, для правильной валидации нужно указать, что строка должна содержать цифры и строчные буквы от начала до конца строки (то есть, использовать/^[A-Z0-9]+$/).
lytican
15.06.2019 23:34Слабенько для статьи.
Как можно использовать эту уязвимость?
Тут все просто: можно начать со сбора данных всех новых пользователей
Не бывает чтобы все просто. Вы сперва попробуйте стать обычным прибыльным реферралом у любого хостера. Если вы сможете распространять ссылки, тогда есть о чем говорить в том параграфе, но в целом это вымерший способ партнерства и ни одного перехода скорее всего не будет.
П.с.: объяснение регекспов на хабре не требуется, кто не знает лучше сам нагуглит.
Итог (на мой субъективный вхгляд): за малополезную статью вы добавили скрипт-киддис-хабратаку на их сервис, ценности у статьи мало, а вместо бесплатного сервера в качестве оплаты можете получить финансовый иск, или уголовный, если вдруг что-то забыли упомянуть в статье, но делали, а они смогут эти действия доказать.
denis-isaev
16.06.2019 02:19+5Т.е. Вы в ультимативном ключе заявили компании, что даете ей 48 часов на исправление проблемы, после чего публикуете уязвимость, потому что предложенная компенсация за молчание Вас не устроила.
При этом разработка сайтов явно не в профиле компании, а значит для исправления уязвимости им надо найти исполнителя, заключить договор и т.д. И на все это Вы им отвели 48 часов. Зная, что уязвимость еще не закрыта, опубликовали статью, предоставив неопределенному кругу лиц информацию, которая может привести к проблемам не только у самой компании, но и у всех её клиентов.
ИМХО, такое поведение достойно порицания.pyrk2142
16.06.2019 07:31Я бы сказал, что это очень сложный вопрос.
При этом разработка сайтов явно не в профиле компании, а значит для исправления уязвимости им надо найти исполнителя, заключить договор и т.д.
Если у компании нет специалистов по разработке, то специалистов по безопасности тоже нет (адекватный безопасник может победить подобную уязвимость даже без знания конкретного языка программирования, либо сделать так, чтобы ее нельзя было проэксплуатировать, а потом ждать нормального исправления программистами). Как компания собирается бороться с атаками в таких или более сложный случаях? Хакер явно не будет говорить, что начнет ломать через 48 часов, а просто сломает все в случае более серьезной уязвимости.
Зная, что уязвимость еще не закрыта, опубликовали статью, предоставив неопределенному кругу лиц информацию, которая может привести к проблемам не только у самой компании, но и у всех её клиентов.
Имхо, перекладывание вины за использование уязвимостей на исследователя — это не очень эффективно в перспективе. Тимлид или директор по разработке нанимает вялых программистов, вялых тестировщиков и безопасников, которые делают дырявые сайты (особенно, если абстрагироваться от конкретного примера и думать о более опасных уязвимостях у тех же хостеров), поэтому именно создатели дырявых систем виноваты в утечках, а не исследователи, которые по какой-то причине не хотят облизывать компании, чтобы они что-то сделали (а компании почему-то считают, что исследователи должны предоставлять информацию только им, в удобном формате и без просьб о вознаграждении).
Имхо, длительное время на исправление уязвимости допустимо тогда, когда это какая-то нетривиальная проблема, которую очень сложно предсказать и найти. XSS в публично доступных формах — имхо, не из этой категории.denis-isaev
16.06.2019 12:51Исследователь — это когда ты на hackerone зарегался, ищешь уязвимости и рассказываешь о них владельцам, а когда ты на произвольном сайте полез копаться в код, нашел уязвимость и рассказал о ней во всеуслышание, то это 272 УК РФ.
EgorVolokitin Автор
17.06.2019 00:13Вы можете перечитать статью 272. Дело в том, что нахождение уязвимости не карается законом. Вот ее использование — да, если повлекло копирование, модификацию, шифровку или удаление. В моем случае нет ничего противозаконного. Даже если бы я сообщил о ней сразу. Я не могу отвечать за действия других.
denis-isaev
17.06.2019 01:32Ну если истец не будет заявлять, что вы у него что-то поломали или блокировали, то ок, 273-я
тоже под ваши действия хорошо подходит: «распространение… компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации».
Там сроки еще больше. Вы ведь еще и шантажировать пострадавшего умудрились. Тут и корыстный умысел значит есть.
Но вообще, я тут не столько про УК РФ тру, а больше про здравый смысл и этичность.
Правоприменительную практику 272 и 273 можете тут почитать на всякий случай, если уж встали на путь такой:
www.sud-praktika.ru/precedent/category/299.html
www.sud-praktika.ru/precedent/category/138.html
EgorVolokitin Автор
16.06.2019 07:45Тут есть несколько факторов.
1) Это все же IT-компания.
2) Она не работает на российском рынке и статью она навряд ли увидит
3) Это обычная xss. Я кинул ссылку, позволяющую воспроизвести уязвимость и дал полное описание, а так же сообщил как ее закрыть. Если it-компания не может за 2 дня вставить регулярку — скорее всего компании это не нужно.
Сейчас, кстати, я проверил наличие уязвимости. Уязвимость закрыта — блокируются пробелы и <, >. Поле для ввода промокода пропадает в случае несоответствия.Tangeman
16.06.2019 23:01Вообще-то далеко не во всех IT компаниях сотрудники работают 24/7/365, и даже наличие специалистов не всегда даёт возможность исправить что-то за 48 часов.
Простой пример из жизни одного из крупнейших телеком-операторов — для внесения изменений в код на их сайте и последущего выкатывания на прод нужно пройти сложную бюрократическую процедуру согласования, не говоря уже тестировании, даже если речь об исправлении пунктуации в тексте, и это может занять от нескольких дней до нескольких недель(!).
Вы, конечно, можете сказать что они «сами виноваты», но это реальная жизнь — т.е. это даже при желании исполнителей просто может быть невозможно в короткие сроки, если только не обнаружена уязвимость которая приводит к чудовищным последствиям, причём она очевидна даже для ничего не понимающих в IT и уже активно эксплуатируется.
Или совсем другой вариант. Есть у меня один знакомый, он предоставляет услуги хостинга, хотя сам в этой области обладает минимальными знаниями — он банально перепродаёт услуги другого хостера, добавив чуть-чуть сервиса, и всё очень автоматизировано. Несмотря на это, ему удалось построить вполне прибыльный и стабильный бизнес, а когда нужно сделать что-то сложнее стандартного развёртывания сайта или VPS (как раз то что автоматизировано), он привлекает фрилансеров. Разумеется, у него есть сайт, где всё это продаётся, и выглядит он совсем не колхозно, создаётся впечатление что компания вполне даже IT, солидная и совсем немаленькая, хотя де-факто это один человек.
Теперь представьте, что вы находите уязвимость на его сайте, и даёте ему 48 часов. Ему нужно найти того кто делал сайт (или того кто в нём разбирается), договориться о том когда можно глянуть, как исправить — т.е. нужно и время, и деньги. Вполне может оказаться что он в отпуске, или у него любимая собака заболела, в общем масса всего что может сделать невозможным исправление в эти самые 48 часов, а тут вы со своими требованиями — ведь вы же уверены что «это IT компания», «они должны», etc. — в то время как это что ни на есть малый бизнес с минимальными знаниями, который жил себе спокойно 10 лет и никого не трогал, даже своего веб-девелопера не имеет в связи с отсутствием необходимости (ибо всё настроено и работает почти полностью автоматически).
Подумайте — этично ли в такой ситуации ставить условия и столь жёсткие сроки? А ведь большинство сайтов (в т.ч. тех кто выглядит как IT компании и предлагают хостинг) — это именно малый бизнес, у некоторых даже постоянных изредка приходящих админов нет, и просто глядя на сайт вы никогда на 100% не можете быть уверены что компания действительно способна быстро всё исправить.EgorVolokitin Автор
16.06.2019 23:51Они отказались платить за уязвимость, они могли избежать всего этого и, я думаю, ваш знакомый именно это бы и сделал. + я нашел уязвимость и передал им.
Я не имею отношения к тому, что компания по какой-то причине не может исправить уязвимость. Точно так же как не имею отношения к тому, что они валидируют ввод. Сроки не жесткие по причине того, что она фиксится в 2 щелчка. А то, что компания будет тянуть это неделями — не мое дело. Будь это мой сервис — я бы выкатил фикс уже через 5 минут. Я не ставил ультиматум — я поставил выбор, рассказал как ее исправить и дал время на исправление среди рабочей недели.
Хакинг априори не совсем этичное занятие. Ты находишь уязвимость, которую не заметили разработчики — как минимум с них спросят: «как же так?». Я оказался не этичным потому что оказался более внимательным, чем разработчики этого сервиса? На мой взгляд я был бы не этичным если бы начал шантажом требовать оплату, как делают многие в этой сфере. Или выложил бы не сказав компании ни слова.
Компания должна либо заботиться о своих сервисах, либо это ей выходит в копеечку. Так всегда. И причем не важно уязвимость это или баг, который тоже может съедать часть прибыли. Я же этой компании отдал уязвимость бесплатно, не взяв ничего и предоставив время на исправление.
Если за 2 дня компания не может написать одну строчку — виноваты полностью они. Была бы уязвимость с базой — я повременил бы больше. Была бы она критическая — тоже повременил бы больше. 2 дня на строчку — не жесткие сроки на мой взгляд.Tangeman
17.06.2019 01:49Они отказались платить за уязвимость
Они и не обязаны это делать — вас ведь никто не нанимал для поиска уязвимости, так что это ваши проблемы.
Сроки не жесткие по причине того, что она фиксится в 2 щелчка.
Тем кто не понимает в js и html — тоже фиксится? Вот есть абстрактный магазин ёлочных игрушек, они наняли Васю Пупкина который им сделал сайт, прошло много лет, Вася Пупкин давно уехал — кто будет фиксить? Специалиста нужно найти — а это время. Ему нужно заплатить — а это деньги. Ему нужно доверять — значит быстро не найти. Вот вы доверите фиксить баг на своём сайте кому-то незнакомому или хотя бы просто мало кому неизвестному?
То, что для вас кажется быстрым и естественным, для человека далекого от области может быть в принципе непреодолимым препятствием, и не у всех есть знакомые «тыжпрограммисты» в шаговой доступности, не говоря уже о специально нанятых сотрудниках, которые бдят 48 часов в сутки.
Ты находишь уязвимость, которую не заметили разработчики — как минимум с них спросят: «как же так?».
Не секрет что людям свойственно ошибаться, всем людям — так что ошибки это часть процесса разработки. Если о них не сообщать — они не будут пофиксены, так что нет ничего неэтичного в том чтобы их искать и сообщать. А вот требовать за это денег или обещать всем рассказать (особенно если это некритичная уязвимость) — это неэтично. Ставить какие-то сроки перед тем как рассказать, без согласования с компанией — тоже неэтично, вы ведь не знаете их ситуацию и возможности.
Я бы ещё понял если бы вы нашли серьезную уязвимость в онлайн-банкинге или там портале госуслуг — да, там это может привести к куче проблем у кучи людей, и можно попытаться подтолкнуть их исправить побыстрее — но промо-код? Извините, но это не та уязвимость ради которой стоит всё бросить и начать фиксить прям счас, если это, к примеру, не Amazon или крупный мобильный оператор (где благодаря XSS много чего плохого можно сделать).
Даже для критичных уязвимостей можно поступить более корректно — не публиковать саму уязвимость и способ её эксплуатации, а только сам факт её обнаружения — это как раз и может стать побудительной причиной для компании заняться проблемой, при этом минимизируя возможность угрозы.
Компания должна либо заботиться о своих сервисах, либо это ей выходит в копеечку.
Да, должна. Но так как считает нужным — не вам решать как именно и как быстро. Нашли, сообщили — молодец. Не дали денег? Так и не обещали вроде. Не исправили за 48 часов? Так см. выше — много причин почему. Но угроза «разоблачения» если не исправят — это как минимум подстава, потому что вы можете быть вообще единственным кто нашёл этот баг за 5-10 лет, и без вашей статьи угроза просто минимальна, а после неё — вы её увеличили на порядки. За это, кстати, по крайней мере в ЕС, можно статью получить — и это правильно.
Представьте это с другой стороны — вы ходите по улице с рядом домов и пробуете спичкой открывать двери. А потом бросаете им в почтовый ящик письмо «У вас дверь открывается спичкой, а ну быстро исправьте или я через двое суток расскажу всему интернету». А теперь, для полноты картины, представьте что кто-то так поступил с вашим домом — как вы к его поступку отнесётесь? А если вы были в недельном походе в горах и почту проверить не могли?
И ещё — я, конечно, не юрист, но мне почему кажется что если кто-то пострадает из-за опубликовайнной вами уязвимости, при этом если это произойдёт после публикации — то у них будет хороший шанс притянуть вас к ответственности (если, конечно, они вас найдут) — как раз потому что 48 часов это очень мало.
Я же этой компании отдал уязвимость бесплатно, не взяв ничего и предоставив время на исправление.
Ещё раз — если это не супер-пупер критичная уязвимость с важностью землетрясения — то вообще некорректно ставить сроки, особенно если это не угрожает вам лично. Если критичная — то нужно договариваться о сроках, почему — см. раньше.
Если за 2 дня компания не может написать одну строчку — виноваты полностью они.
Снова абстрактный магазин ёлочных игрушек, никаких своих девелоперов или сисадмина, владельцы в IT почти ни бум-бум. Бизнес семейный, вся семья в двухнедельном отпуске на Гаваях. В чём их вина? В том что у них нет денег на то чтобы постоянно отслеживать и отвечать на email? Да даже если не в отпуске — если нет специально выделенного email для таких случаев, вы понятия не имеете как много писем им приходит, сколько там спама, какова вероятность того что ваше попало в спам или ждёт своей очереди. Вспомните все эти письма в духе «я хакнул ваш рутер и теперь у меня видео как вы смотрите порно, заплатите на bitcoin или я всем расскажу» (тоже, кстати, дают 48 часов) — и поймёте как может быть воспринято ваше сообщение.
Может быть потом, когда у вас будет своя компания, или просто свой бизнес без компании, вы поймёте что не всё в этом мире идеально, и то что кажется «пустяком» на самом деле требует больше усилий, времени и ресурсов чем кажется кому-то со стороны. А в идеальном мире оно конечно, легко во всех тыкать палочкой и говорить «это неправильно» и «вы должны».
denis-isaev
17.06.2019 01:50Иногда помогают аналогии:
Представьте, что ваш сосед прочитал интересную книжку про домушников и решил поковыряться в замке двери в вашу квартиру. Неожиданно для себя легко подобрал отмычку, после чего предложил вам заплатить ему 1000 руб в обмен на объяснения как он взломал ваш замок. Вы в оплате отказали, на что он дал вам 48 часов на замену замка, по истечении которых отнес рабочую отмычку нарикам из соседнего квартала.
Он сам тоже ничего не ломал у вас, не грабил. Он просто подобрал отмычку к замку и отнес её неопределенному кругу лиц.
w0den
17.06.2019 01:52Будь это мой сервис — я бы выкатил фикс уже через 5 минут.
А уязвимость, всё равно не была бы исправлена ;)
Хакинг априори не совсем этичное занятие.
Хакинг — это лишь знания, и всё зависит от человека, как он будет распоряжаться ими. То, что делаете Вы, конечно, не этично, поскольку Вы пытаетесь нанести ущерб репутации компании и поставить под угрозу безопасность/конфиденциальность других.
Как правило, не нужно тестировать на наличие уязвимостей, если Вас не просили. А если и решили сделать доброе дело, просто не ждите награды и уж тем более не сообщите об этом в открытом доступе без согласия пострадавшего.
Если хотите носить белую шляпу и при этом хорошо зарабатывать, посмотрите в сторону bugcrowd.com, hackerone.com и других сервисов, где действует программа Bug Bounty.
Neighbourhood
16.06.2019 07:54Привет, расскажи, пожалуйста, о своём пути разработчика к 20 годам. Как попал в американскую компанию, какая сейчас позиция, каким было собеседование? (и т.п.)
Спасибо!
1c80
Спасибо интересно, если в одном месте ввод не валидируется, значит скорее всего есть и еще места, если они не хотят платить, то это не беда, думаю есть и другие места, где за это могут заплатить.
EgorVolokitin Автор
На самом деле я об думал. Но я не хочу ковырять их сайт. Они ясно дали понять, что оплаты не будет. Я конечно мог потребовать оплату «или я выложу это в интернет», при том, что уязвимость принимала не только html, но и js. Просто такой метод не для меня. Я решил, что отдам им уязвимость, а сам — выложу статью, дал им время на исправление.
Подход требования оплаты против воли компании не нравится мне совсем.
Если компанию не интересует безопасность в ее бизнесе — это ее право. Лично меня всегда интересовала безопасность данных пользователей в компании, где я работаю, как и ее владельцев.
1c80
Ну пишешь им, типа я нашёл что то интересное, интересен ли диалог или сразу выложить в общий доступ? Тогда может и другой разговор будет, но при втором варианте дыру точно быстрее запаяют.
Только надо аккуратно, что бы не присесть за взлом сайта, все не так однозначно в этом мире.
EgorVolokitin Автор
Это не мой подход. Не хочу заставлять компании платить.
1c80
Если деньги не нужны, то конечно не стоит напрягаться.
EgorVolokitin Автор
Поиск уязвимостей — скорее маленькое хобби, чем способ заработка. Мне достаточно той зп, что мне платят на работе.
Zoomerman
Не то, чтобы это ошибка. Конвертировать сервер в деньги довольно просто.
Помню свою первую крупную сделку… Также отказался от вознаграждения, посчитав его слишком заниженным относительно моих ожиданий )
Автору респект за мужество и целеустремленность.