Как лучше всего представить уязвимость системы обеспечения безопасности команде веб-разработки в Вашей собственной компании?
Вообразите следующий сценарий:
Вы работаете в Big Co. и Ваших коллегах вниз, Холл находится в команде веб-разработки для общедоступной системы блога Big Co, которую использует много сотрудников Big Co и некоторых общедоступных людей. Система блога позволяет любой HTML и JavaScript, и Вам сказали, что это был выбор (не случайно), но Вы не уверены, осознают ли они последствия этого.
Таким образом, Вы хотите убедить их, что это - плохая идея. Вы пишете некоторый демонстрационный код и прививаете сценарий XSS в Вашем собственном блоге и затем пишете некоторые сообщения в блоге. Вскоре после главный администратор блога (вниз Холл) посещает Ваше сообщение в блоге, и XSS отправляет его cookie Вам. Вы копируете их в свой браузер, и Вы теперь зарегистрированы как он.
Хорошо, теперь Вы зарегистрированы как он... И Вы начинаете понимать, что это, возможно, не была такая хорошая идея идти вперед и 'взломать' систему блога. Но Вы - хороший парень! Вы не касаетесь его учетной записи после вхождения в него, и Вы определенно не планируете разглашение этой слабости; Вы просто, возможно, хотите показать им, что общественность может сделать это, так, чтобы они могли зафиксировать ее перед кем-то злонамеренным, осознает то же самое!
Каков лучший план действий отсюда?
6 ответов
На самом деле зависит от вашего положения в компании, характера людей в коридоре и т. Д. И т. Д.
Чтобы представить один вариант:
Подойдите к ним, опишите угрозу абстрактно («кто-то может захватить ваши файлы cookie, которые, в свою очередь ...»), и спросить их, не хотят ли они увидеть демонстрацию? Если в игре присутствует большое эго, и вы действительно хотите, чтобы они это исправили, не разговаривайте со всей командой, а только с ее руководителем.
Если они согласны, подождите несколько часов, затем войдите в систему как «он» и сделайте что-нибудь неразрушающее, но заметное в системе - вы сделали это с их разрешения. Они, вероятно, будут впечатлены и проследят, чтобы дыра была исправлена.
Если они не согласятся и скажут вам уйти, что ж, вам придется взвесить все варианты: либо вы возьмете это где-нибудь выше, либо закопаете. Упомянув о проблеме, вы откажетесь от всех вариантов ее анонимной отправки.
Если вы не можете быть на 100% уверены, что все участники цепочки принятия решений разумны и полностью понимают, что вы делаете, и что это во благо компании, я бы не стал прибегать к мошенническим «взломам» - всегда говорят об этом в первую очередь, особенно в среде большой компании. Этот материал слишком легко ошибочно принять как вредоносный с вашей стороны - особенно если есть кто-то, кто будет смущен созданием этой дыры в безопасности и хотел бы свалить вину на кого-то другого.
Все сосредоточены на устранении проблемы с веб-сайтом, и, возможно, я просто немного макиавеллист, но я бы также подумал о том, чтобы мои возражения были зафиксированы в письменном виде; я бы написал письмо нескольким своим начальникам.
Последнее, что вам нужно, - это чтобы сайт использовался, а лицо, принимающее решение, настаивало на том, что это была ваша работа (или работа вашего приятеля) - рассмотреть этот технический аспект, а вы обнаружили, что никто не помнит, что вы высказались.
Я думаю, что вы превысили свои полномочия. Хотя XSS-уязвимости представляют собой серьезную проблему, если вы не занимаетесь информационной безопасностью в своей организации, вы не имеете права вмешиваться в то, как работает организация разработчиков, расположенная в соседнем здании.
Абсолютной безопасности не существует, но я представляю, что люди, курирующие проект блога, спокойно отдыхают по ночам, зная, что если кто-то из сотрудников злоупотребит технологией, его можно отследить по журналам и принять соответствующие меры.
Если вы написали вредоносный код "для демонстрации этого" без их согласия, это довольно серьезное действие, которое можно предпринять без одобрения, и я полагаю, что ваше начальство будет считать так же.
Всякий раз, когда я сталкивался с проблемой безопасности, которую в прошлом требовала решить наша внутренняя ИТ-группа, я просто говорю им, в чем проблема и что можно сделать, чтобы потенциально воспользоваться ею.
В зависимости от того, насколько они чувствительны и какое положение вы занимаетесь ими / своей компанией, проверочный код может быть, а может и не быть хорошей идеей. Если у них есть основания подозревать, что вы используете его злонамеренно, я бы оставил это при себе. В противном случае, если они это оценят, поделитесь им.
Это единственная чувствительная область. Просто сообщите о проблеме ответственно, чтобы было ясно, что вы просто беспокоитесь о проблемах безопасности и не собираетесь использовать их.
У вас есть три возможных варианта:
Поговорить с веб-командой.
Поговорить со своим начальником.
Проигнорировать это.
Думаю, я бы выбрал и 1, и 2.
Это тревожное поведение. Если они не понимают самых простых недостатков безопасности, таких как XSS, то они должны быть уволены. Это не из-за одной уязвимости, это просто глупо. Их следует уволить, потому что они не понимают безопасности, и я не сомневаюсь, что они ввели в систему более серозные уязвимости. Если они не получат этот учебник XSS, как насчет CSRF? Они будут думать, что вы сумасшедший!
Понимание влияния кода на безопасность является абсолютным требованием. Без этого тогда программист является лишь обузой.