Как лучше всего представить уязвимость безопасности для команды веб-разработчиков в вашей собственной компании?

Question

Представьте себе следующий сценарий:

Вы работаете в Big Co., а ваши коллеги по коридору работают в команде веб-разработчиков для системы публичных блогов Big Co, которая во многом состоит из Big.Сотрудники Co и некоторые публичные люди используют.Система блогов допускает любой HTML и JavaScript, и вам сказали, что это был выбор (не случайно), но вы не уверены, осознают ли они последствия этого.

Итак, вы хотите убедитьим, что это плохая идея.Вы пишете некоторый демонстрационный код и внедряете сценарий XSS в свой собственный блог, а затем пишете некоторые сообщения в блоге.Вскоре после этого главный администратор блога посещает ваше сообщение в блоге, и XSS отправляет вам свои файлы cookie.Вы копируете их в свой браузер, и теперь вы вошли как он.

Хорошо, теперь вы вошли как он ... И вы начинаете понимать, что, возможно, это не такая уж хорошая идеявперед и взломать систему блогов.Но ты хороший парень!Вы не трогаете его учетную запись после входа в нее, и вы определенно не планируете обнародовать эту слабость;возможно, вы просто хотите показать им, что публика способна это сделать, чтобы они могли это исправить, прежде чем кто-то злоумышленник осознает то же самое!

Каков наилучший способ действий здесь?

Answer 1

Действительно зависит от вашей должности в компании, характера людей в зале и т. Д. И т. Д ....

Чтобы представить один вариант:

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

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

Если они не согласятся и скажут, что вы уходите, вам придется взвесить ваши варианты: либо вы возьмете его куда-нибудь повыше, либо похороните. Упомянув проблему, вы откажетесь от всех вариантов отправки анонимно.

Если вы не можете быть на 100% уверены, что все в цепочке решений разумны и полностью понимают, что вы делаете, и что это на благо компании, я бы не стал совершать мошеннические «взломы» - всегда сначала поговорим об этом, особенно в среде большой компании. Этот материал слишком легко понять как злонамеренный с вашей стороны, особенно если есть кто-то, кто будет смущен созданием этой дыры в безопасности и хотел бы обвинить кого-то еще.

Answer 2

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

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

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

Answer 3

Каждый сосредоточен на решении проблемы с веб-сайтом, и, возможно, я просто немного Макиавелли, но я бы также подумал о том, чтобы убедиться, что мои возражения были зафиксированы в письменном виде;Я написал бы электронное письмо нескольким моим руководителям.

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

Answer 4

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

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

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

Answer 5

Это тревожное поведение. Если они не понимают самых простых недостатков безопасности, таких как XSS, то они должны быть запущены . Это не из-за одной уязвимости, это просто глупо. Их следует уволить, потому что они не понимают безопасность, и я не сомневаюсь, что они внесли в систему более серьезные уязвимости. Если они не получат этот учебник XSS, то как насчет CSRF? Они будут думать, что ты сумасшедший!

Понимание влияния вашего кода на безопасность является абсолютным требованием. Без этого программист несет только ответственность.

Answer 6

У вас есть три варианта:

1. Поговорите с веб-командой.

2. Поговорите со своим собственным боссом.

3. Игнорировать это.

Думаю, я бы выбрал и 1, и 2.