Контракты. Как Веб-Разработчики-Фрилансеры Подходят К Безопасности И Ответственности?

Обязанность

Как клиенты могут ожидать, что небольшие команды и отдельные лица будут нести ответственность за нарушение безопасности, когда новости наполнены сообщениями о взломах правительств/корпораций с огромными бюджетами ITSec? Мы всего лишь веб-разработчики, а не эксперты по безопасности. Неужели блоггеры рассчитывают добиться большего, чем финансовые учреждения, и получить «неуязвимый» продукт? Вдобавок ко всему, не существует общеотраслевого стандарта, который бы всесторонне охватывал всю веб-разработку, так кто же будет определять, что подходит, а что нет?

Когда я могу начать работать?

Если 100% безопасность — это миф (а это так), то на каком уровне квалификации ответственный разработчик может сделать свои услуги доступными? 70% веб-сайтов имеют серьезные уязвимости, поэтому люди, создавшие их, явно не ждали. Было бы неплохо научиться разрабатывать с использованием руководства OWASP, если бы их обновление было доступно. По крайней мере, тогда я мог бы четко указать степень защиты, которую предлагают мои услуги, имея при этом уважаемый стандарт, который нужно проверять. Если предположить, что это так, будет ли достаточным заявление об отказе от ответственности где-то вроде «Я не являюсь охранной компанией» и «Я не могу нести ответственность за убытки, понесенные в результате взлома?»

Соглашения между разработчиком и клиентом, включающие техническое обслуживание

Некоторые люди говорят, что вы должны нести ответственность за взлом, если с вами был заключен контракт на поддержку сайта после его завершения. Я думаю, что это должно иметь место только в том случае, если нарушение произошло из-за неспособности с вашей стороны своевременно установить исправления и обновления безопасности. Быть обвиненным в любом другом «векторе атаки», и я думаю, что от вас необоснованно ожидают защиты от каждого потенциального эксплойта (возвращая нас к этому мифу о 100% безопасности). А что касается реагирования на взлом, в зависимости от масштаба проблемы, я думаю, менее разумно предполагать, что средний разработчик должен быть компетентным, чтобы справиться с ней. Кажется, даже специалисты по безопасности разделились во мнениях относительно того, какой протокол является правильным. И они специалисты.

Третьи стороны

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

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

Информация, которая будет мне полезна

Мне было бы полезно получить рабочие примеры того, как другие фрилансеры решают эти проблемы безопасности/ответственности. Было бы здорово, если бы были конкретные формулировки личных контрактов, а также любые дополнительные меры. Кажется, юридический язык так же надежен, как и безопасность, так что мне следует стать ООО или оформить «страховку от судебных исков для разработчиков» (только что узнал, что это так)? Любые знания или опыт, прямые или косвенные, приветствуются, и я был бы очень признателен. Ничто из предоставленного не будет рассматриваться как юридическая консультация.

#контракты #юридические

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

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

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

Я не юрист, но это из моего контракта:

Юридические материалы

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

_{Первоисточник - Контрактный убийца 3}

Как веб-разработчик, вы обязаны затыкать любые очевидные дыры. Это можно найти в OWASP (Проект безопасности открытых веб-приложений) в списке 10 основных уязвимостей, но для краткости вам необходимо устранить следующие проблемы:

• SQL-инъекция (или любая инъекция!)
• Нарушение авторизации/управления сеансами (выдача себя за других пользователей)
• Межсайтовый скриптинг (XSS)
• Конфигурация безопасности
• Раскрытие конфиденциальных данных
• Подделка межсайтового запроса (CSRF/XSRF)
• Отраженные редиректы (слепое выполнение redirect($_GET['redirect']) , for example)

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

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

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

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

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