пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Это подробное руководство предоставит вам информацию для эффективного сравнения лицензий Open Source, что должно помочь вам при выборе лицензии Open Source, подходящей для Вашего проекта.
Итак, вы уже некоторое время работаете над крутым проектом – и вот вы готовы сделать важный шаг и превратить ваш закрытый код в открытый.
Эта задача кажется несложной – просто почистить исходники и историю версий перед тем, как залить свой репозиторий на GitHub или Bitbucket... пока не всплывает вопрос о лицензии. Оказывается, выбор такой широкий. Какую лицензию выбрать? И нужна ли она вам вообще на самом деле?
Можно коротко ответить на последний вопрос: да, вам действительно нужна лицензия. А на вопрос о том, какая лицензия вам нужна, мой ответ ещё короче: когда как. Но если вы серьёзно относитесь к своему проекту, вам, вероятно, потребуется немного больше деталей. Что ж, читайте дальше – и помните: вы вступаете на территорию бесконечных споров!
Нужна ли мне лицензия? И что вообще такое лицензия?
Лицензия – это официальное разрешение, предоставленное автором какой-либо работы («Лицензиаром») сторонним лицам («Лицензиатам») и регулирующее использование лицензиатом работы лицензиара. Она имеет форму договора, с которым должны согласиться обе стороны. В наше время - это согласие бывает неявным: подразумевается, что, просто используя какую-либо работу, вы соглашаетесь с условиями её лицензии на использование.
Поясню: выпуская свою собственную работу, лицензиаром являетесь именно вы. А лицензиатом – любое лицо, использующее ваш код. Проще говоря, речь идёт о двух главных категориях: разработчиках и конечных пользователях.
И для закрепления ещё некоторых терминов: модифицируя вашу работу, лицензиат создаёт то, что называется производной работой (производным произведением). Не все лицензии одинаково трактуют то, становится ли более масштабный по сравнению с вашей работой проект производным произведением, если она была использована в этом проекте. Как вы увидите ниже, некоторые лицензии отдельно прописывают такие случаи.
Какова цель лицензии?
В целом, лицензия – это способ договориться о правах и обязанностях сторон для лицензиара и лицензиата. Эти права и обязанности могут быть любыми – в рамках законодательства. К примеру, лицензиар может потребовать обязательного указания имени правообладателя при использовании работы лицензиатом. Или разрешить копирование своей работы, но запретить любую её модификацию. Или даже потребовать, чтобы производная работа выпускалась на тех же условиях, что и оригинальная.
С другой стороны, лицензия защищает и лицензиата. Поскольку в ней явно прописаны условия использования работы, ему не угрожает то, что вы внезапно потребуете лицензионные отчисления или любые другие виды компенсации за использование своей работы. Это важно для распространения вашей работы.
Итак, лицензия защитит вашу работу. Защитит лицензиата. Но помимо этого она защитит и вас – и я имею в виду вас лично. К примеру, ограничивая ответственность лицензиара за потенциальный вред, причиной которого стала его работа.
А что, если я не буду использовать лицензию?
При отсутствии лицензии, ассоциированной с работой, «по умолчанию» действуют авторские права в соответствии с юрисдикцией страны автора. Другими словами, никогда не считайте, что «отсутствие лицензии» подразумевает, что другие люди могут делать с вашей работой что угодно. Всё как раз наоборот: без определенной лицензии вы, автор, не отказываетесь ни от каких прав, предоставленных законом.
Но всегда помните, что лицензия регулирует права и обязанности. Вы когда-нибудь задумывались, почему в тексте многих лицензий содержится написанное БУКВАМИ В ВЕРХНЕМ РЕГИСТРЕ предупреждение о гарантиях, предоставляемых вместе с продуктом – или, куда чаще, об отсутствии таковых? Это делается для того, чтобы защитить владельца работы от пользовательских ожиданий и того, что подразумевается какая-либо гарантия. Последнее, что вам нужно – это чтобы на ваш открытый код подали в суд!
Могу ли я использовать кастомную (собственную) лицензию?
Да, можете. Но, вероятно, не стоит этого делать.
Являясь договором, лицензия не может иметь приоритет над территориальными законами. Отсюда возникает сложность соблюдения лицензионных прав в глобализированном мире. Скорее всего, будет проще (я имею в виду, менее сложно) защитить в суде «стандартную» лицензию. Собственно, такие дела уже защищались в некоторых юрисдикциях и на них можно ссылаться в качестве прецедента. Очевидно, что нельзя сказать то же про кастомную лицензию.
К тому же, кастомные лицензии (прозванные «лицензиями для тщеславных») могут оказаться несовместимыми с другими лицензиями, результатом чего станет плохая совместимость вашей работы.
Могу ли я использовать несколько лицензий?
Да. Мульти-лицензирование – и в особенности двойное лицензирование – встречается нередко. Это особенно верно, если вы хотите создать бизнес на основе своего бесплатного произведения. В этом случае ваш проект, скорее всего, будет выпушен одновременно и под лицензией FOSS (Free And Open Source Software - Свободное и открытое программное обеспечение), и под коммерческой лицензией.
Другое применение мульти-лицензирования – для улучшения совместимости, чтобы ваша работа была сочетаема с работами, опубликованными под другими условиями, или для удовлетворения иных потребностей и запросов пользователей. По этой причине некоторые проекты выпускаются под несколькими лицензиями FOSS.
Но предупреждаю: не все лицензии совместимы между собой! Опять же, я рекомендую не переизобретать колесо и использовать лицензии, совместимость которых широко известна, если вы хотите пойти этим путём.
Могу ли я поменять лицензию «позже»?
Да. Держатель авторских прав отвечает за условия лицензирования. Довольно просто поменять лицензию, если вы – единственный автор. Но если, в качестве яркого примера, Линус Торвальдс захочет выпустить ядро Линукс под другой лицензией, ему, вероятно, сначала потребуется согласие нескольких тысяч других участников этого проекта. Это невозможно в действительности.
Для проекта средней величины это реально. И на самом деле делалось, как вы увидите в некоторых примерах ниже.
Какую лицензию Open Source мне следует использовать?
Хорошо, допустим, мне удалось убедить вас в том, что вам нужна стандартная лицензия. Но какую выбрать? Окончательный выбор за вами. И в сети достаточно хороших компараторов, которые помогут вам в этом выборе. Вот некоторые их них:
http://oss.ly/licdif
https://choosealicense.com/ или https://choosealicense.com/appendix/
https://opensource.org/licenses
https://tldrlegal.com/
Но как всегда в юридических вопросах, надежнее всего будет прочитать – и понять – официальный текст самих лицензий. Для этого может потребоваться помощь профессионального юриста.
Рассмотрим некоторые общие сведения о наиболее распространённых лицензий, чтобы помочь вам сделать первые шаги в нужном направлении.
Стандартная общественная лицензия GNU (GPL - GNU General Public License)
GPL – одна из наиболее популярных лицензий Open Source. У неё есть несколько версий – но для нового проекта вам лучше рассматривать последнюю из них, на момент написания этой статьи ей является GPL 3.
Поддерживая сильный копилефт, GPL, пожалуй, защищает больше всех остальных свободных лицензий. Что может быть, как плюсом, так и минусом, в зависимости от вашей точки зрения. Основной концепт GPL – что любые производные работы должны также выпускаться под этой лицензией.
Copyleft - это практика предоставления людям права свободно распространять копии и измененные версии произведения с условием сохранения тех же прав в производных работах, созданных позже.
Сильный копилефт;
Лицензиаты могут модифицировать работу;
Лицензиаты могут распространять исходный код вместе с производной работой;
Производная работа должна выпускаться на тех же условиях.
Популярные проекты
GPL – лицензия, наилучшим образом подходящая для проектов Фонда свободного программного обеспечения (Free Software Foundation - FSF), в том числе за счёт инструментов GNU в основе любой системы Linux. Большие проекты – заведомо коммерческие – часто используют GPL вместе с одной или несколькими другими лицензиями.
Inkscape (векторный графический редактор): GPLv2
Drupal (система управления веб-контентом): GPLv2
MariaDB (базы данных): GPL v2
MySQL (базы данных): GPL и коммерческая лицензия
Qt (кроссплатформенный фреймворк для разработки приложений): LGPL, GPL и коммерческая лицензия— в зависимости от модулей и соглашения об уровне обслуживания (SLA).
Меньшая стандартная общественная лицензия GNU (LGPL - GNU Lesser General Public License)
GPL – лицензия, очень строгая к тому, чтобы каждая производная работа публиковалась на тех же условиях, что и исходная, и с открытым исходным кодом. Это особенно неудобно в случае с библиотеками, которые служат «кирпичами» для крупных программных продуктов: если библиотека выпущена под GPL, то любое использующее её приложение должно также выпускаться под GPL. Эту сложность адресует LGPL.
В отношении библиотек Фонд свободного программного обеспечения (FSF) выделяет три случая:
Ваша библиотека реализует стандарт, который конкурирует с несвободным стандартом. В таком случае широкое распространение вашей библиотеки поможет продвижению свободного ПО. В этой ситуации FSF рекомендует использование довольно либеральной (разрешительной) лицензии Apache (она описана в статье далее).
Ваша библиотека реализует стандарт, уже реализованный другими библиотеками. В этом случае, полный отказ от копилефта никак не послужит продвижению свободного ПО. Для этого случая FSF рекомендует LGPL.
Наконец, если ваша библиотека не конкурирует ни с какими другими библиотеками или стандартами, FSF рекомендует GPL.
Рекомендации FSF имеют преимущественно этические и идеологические основания. В жизни у разработчиков могут быть иные заботы. Особенно если они планирует развивать дело на базе своей лицензированной работы. Ещё раз, возможно, в таком случае стоит присмотреться к двойному лицензированию.
Слабый копилефт (из-за динамического связывания с библиотеками);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты могут выпускать исходный код вместе с производной работой;
Если вы модифицируете работу, её необходимо выпускать на тех же условиях;
Если вы просто используете работу (в качестве библиотеки), нет необходимости выпускать производную работу на тех же условиях.
Популярные проекты
OpenOffice.org 3 (пакет офисных приложений): LGPLv3 — но Apache OpenOffice 4 перешёл на лицензию Apache 2.0.
GTK+, the GIMP Toolkit (библиотека элементов графического интерфейса): LGPLv2.1
CUPS (кроссплатформенная система печати): GPL or LGPLv2, за исключением ОС Apple, — в зависимости от компонентов.
WineHQ (слой совместимости с Windows): LGPLv2.1
GNU Aspell (проверка орфографии): LGPLv2.1
Eclipse Public License (EPL 1.0)
С более слабым копилефтом, чем в LGPL, лицензия Eclipse больше подходит для бизнеса и допускает сублицензирование и создание программного обеспечения (ПО) на основе кода как под EPL, так и под другими лицензиями (даже проприетарными), с условием, что код под другой лицензией вынесен в отдельный модель программного продукта.
Кроме того, EPL предоставляет дополнительную защиту соавторам кода под EPL в случае судебных исков/ущерба, вызванного коммерческой деятельностью, связанной с этой работой.
Слабый копилефт (из-за связанных подключаемых в продукт модулей);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Если вы модифицируете работу, её необходимо выпускать на тех же условиях;
Если вы просто используете работу, нет необходимости выпускать производную работу на тех же условиях
При коммерческом распространении продукта распространители обязаны защитить или выплатить компенсацию оригинальным авторам (под EPL) в случае судебных исков/ущерба в результате коммерческого использования продукта.
Популярные проекты
Очевидно, что EPL – наиболее подходящая лицензия для проектов Eclipse Foundation, в том числе Eclipse IDE. Но она прибрела некоторую популярность и за пределами этого – особенно в мире разработки на Java:
Clojure (язык программирования)
Graphviz (пакет утилит по визуализации графов)
Jetty (сервер для приложений): двойная лицензия EPL1.0/Apache 2.0 с версии Jetty 7
JUnit (фреймворк для модульного тестирования ПО на Java)
Mozilla Public License (MPL)
MPL – лицензия, которая используется для ПО, созданного Mozilla Foundation. Но её применение этим не ограничено. MPL пытается достичь компромисса между строгими лицензиями (такими как GPL) и либеральными лицензиями (такими как лицензия MIT).
«Лицензионной единицей» в MPL является исходный файл. Лицензиарам запрещено ограничивать права пользователей и доступ к любому файлу, на который распространяется MPL. Но один и тот же проект может содержать как файлы под MPL, так и файлы под проприетарной лицензией. Полученный в результате проект может быть опубликован под любой лицензией, при условии, что предоставляется доступ к файлам под MPL.
Слабый копилефт (в связи с отдельными файлами);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не могут заново лицензировать исходный код под MPL;
Лицензиаты обязаны выпускать исходный код под MPL вместе со своей производной работой.
Популярные проекты
Mozilla Firefox (веб-браузер), Mozilla Thunderbird (почтовый клиент): MPL
LibreOffice (пакет офисных приложений): MPL 2.0
H2 Database Engine (база данных): MPL2.0 и Eclipse License 1.0
Cairo (2D графическая библиотека) MPL 1.1 или LGPLv2.1
Apache License 2.0 (ASL 2.0)
С ASL мы попадаем в мир либеральных свободных лицензий. Но даже FSF в некоторых случаях рекомендует лицензию Apache. Лицензия Apache считается либеральной, поскольку не требует того, чтобы какие-либо производные работы выпускались на тех же условиях. Другими словами, это «не-копилефт» лицензия.
ASL – единственная лицензия, которая используется для проектов Apache Software Foundation. Считающаяся удобной для бизнеса, она получила широкое распространение за пределами этой организации. Можно нередко увидеть проекты корпоративного уровня, выпущенные под этой лицензией.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой.
Популярные проекты
Android (операционная система): ASL 2.0 с некоторыми исключениями (особенно касательно ядра Linux)
Apache httpd (веб-сервер): ASL 2.0
Apache Spark (кластерная вычислительная система): ASL 2.0
Spring Framework (фреймворк для создания корпоративных приложений на Java): ASL 2.0
MIT License
Ещё одна очень популярная лицензия. Возможно, даже самая популярная. Устанавливая совсем немного ограничений на повторное использование, лицензия MIT может быть легко связана с другими лицензиями, будь то GPL или проприетарные лицензии.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой.
Популярные проекты
node.js (среда выполнения для JavaScript): MIT License
jQuery (клиентская библиотека JavaScript): MIT License (до 2012, двойная лицензия MIT/GPL)
Atom (текстовый редактор): MIT License
AngularJS (JavaScript- фреймворк): MIT License
SQLAlchemy (инструментарий SQL и объектно-реляционное отображение для Python): MIT License
Лицензии BSD
Лицензии BSD бывают трёх видов. Оригинальная лицензия «4-х пунктов», «пересмотренная» лицензия, состоящая из 3-х пунктов и «упрощённая» лицензия из 2-х пунктов. По духу все три очень близки к лицензии MIT. И действительно, между упрощенной лицензией BSD и лицензией MIT нет существенных различий.
Лицензии BSD, состоящие из 3-х и 4-х пунктов, содержат больше требований в отношении повторного использования наименований и рекламы. Это полезно учесть, если вы хотите защитить название вашего продукта или марки.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой;
Лицензиаты не могут использовать название продукта или торговую марку оригинального автора для продвижения своей производной работы (лицензии BSD из 3-х и 4-х пунктов);
Лицензиаты обязаны упоминать оригинального автора работы во всех рекламных материалах, ссылающихся на функции или использование этой работы (лицензия BSD из 4-х пунктов).
Популярные проекты
Django (фреймворк для веб-приложений): лицензия BSD из 3-х пунктов
Redis (хранилище данных): лицензия BSD из 3-х пунктов
Ruby (язык программирования): лицензия BSD из 2-х пунктов и кастомная лицензия
Nginx (веб-сервер): лицензия BSD из 2-х пунктов
NetBSD (операционная система): лицензия BSD из 2-х пунктов — лицензия BSD «4-х пунктов» до 2008
В заключение о лицензиях Open Source
Вы дочитали до этого места, поздравляю! Теперь вы понимаете, что лицензирование – это обширная и сложная тема. Но потратить время на то, чтобы выбрать подходящую лицензию для вашего проекта – стоит того, и лучше сделать этот выбор как можно раньше. Это убережёт вас от множества проблем в дальнейшем, и вы сможете направить ваше время и энергию на работу над проектом вместо того, чтобы тратить силы на разборки с авторским правом и юридической совместимостью лицензий.
И помимо нескольких известных лицензий, о которых вкратце рассказано здесь, существует ещё множество других, используемых более или менее широко. Поэтому, не стесняйтесь писать в комментариях о том, какую лицензию вы предпочитаете и почему.
Разработчики программного обеспечения должны держать много информации у себя в голове. Существует множество вопросов, которые нужно задать, когда речь заходит о создании веб-сайта или приложения: Какие технологии использовать? Как будет настроена структура? Какой функционал нам нужен? Как будет выглядеть пользовательский интерфейс? Особенно на рынке программного обеспечения, где производство приложений больше похоже на гонку за репутацией, чем на хорошо обдуманный процесс, один из важнейших вопросов, который часто остается на дне “Списка важных”: Как наш продукт будет защищен?
Если вы используете надежный, открытый фреймворк для создания своего продукта (и, если он доступен и пригоден, почему бы и нет?), тогда базовые проблемы безопасности, как атаки CSFR и кодирование пароля, могут быть уже решены за вас.
Тем не менее, быстро развивающимся разработчикам будет полезно освежить свои знания о стандартных угрозах, дабы избежать ошибок новичка. Обычно самое слабое место в безопасности вашего программного обеспечения - это вы.
А кто может заниматься взломом?. Есть этичный хакер – это тот, кто ищет возможные слабости в безопасности и приватно рассказывает их создателям проекта.
А чёрный хакер, которого так же зовут “Взломщик (cracker)” – это тот, кто использует эти слабости для вымогательства или собственного блага.
Эти два вида хакеров могут использовать одинаковый набор инструментов и, в общем, пытаются попасть в такие места, куда обычный пользователь не может попасть. Но белые хакеры делают это с разрешением, и в интересах усиления защиты, а не уничтожения её. Черные хакеры – плохие ребята.
Вот некоторые примеры наиболее распространённых атаках, которые используют слабости в защите: Внедрение SQL-кода и межсайтовый скриптинг XXS.
SQL атаки
SQL-инъекция (SQLi) - это тип инъекционной атаки, которая позволяет выполнять вредоносные SQL команды, для получения данных или вывода из строя приложения. По сути, злоумышленники могут отправлять команды SQL, которые влияют на ваше приложение, через некоторые входные данные на вашем сайте, например, поле поиска, которое извлекает результаты из вашей базы данных. Сайты, закодированные на PHP, могут быть особенно восприимчивы к ним, и успешная SQL-атака может быть разрушительной для программного обеспечения, которое полагается на базу данных (например, ваша таблица пользователей теперь представляет собой пустое место).
Вы можете проверить свой собственный сайт, чтобы увидеть, насколько он восприимчив к такого рода атакам. (Пожалуйста, тестируйте только те сайты, которыми вы владеете, так как запуск SQL-кодов там, где у вас нет разрешения на это, может быть незаконным в вашем регионе; и определенно, не очень смешно.) Следующие полезные нагрузки могут использоваться для тестов:
' OR 1='1 оценивается как константа true, и в случае успеха возвращает все строки в таблице
' AND 0='1 оценивается как константа false, и в случае успеха не возвращает строк.
К счастью, есть способы ослабить атаки SQL-кода, и все они сводятся к одной основной концепции: не доверяйте вводимым пользователем данным.
Смягчение последствий SQL-кодов.
Чтобы эффективно сдержать атаки, разработчики должны запретить пользователям успешно отправлять необработанные SQL-команды в любую часть сайта.
Некоторые фреймворки сделают большую часть тяжелой работы за вас. Например, Django реализует концепцию объектно-реляционного отображения, или ORM с использованием наборов запросов. Мы будем рассматривать их в качестве функций-оболочек, которые помогают вашему приложению запрашивать базу данных с помощью предопределенных методов, избегая использование необработанного SQL.
Однако возможность использовать фреймворк никогда не является гарантией. Когда мы имеем дело непосредственно с базой данных, существуют и другие методы, которые мы можем использовать, чтобы безопасно абстрагировать наши SQL-запросы от пользовательского ввода, хотя они различаются по эффективности. Они представлены по порядку от более к менее важному:
Подготовленные операторы с переменной привязкой (или параметризованные запросы)
Хранимые процедуры
Белый список или экранирование пользовательского ввода
Если вы хотите реализовать вышеприведенные методы, то эти шпаргалки - отличная отправная точка для более глубокого изучения. Достаточно сказать, что использование этих методов для получения данных вместо использования необработанных SQL-запросов помогает свести к минимуму вероятность того, что SQL будет обрабатываться любой частью вашего приложения, которая принимает входные данные от пользователей, тем самым смягчая атаки SQL-кодов.
Межсайтовые скриптовые атаки (XSS)
Если вы являетесь хакером, то JavaScript - это в значительной степени ваш лучший друг. Правильные команды будут делать все, что может сделать обычный пользователь (и даже некоторые вещи, которые он не должен делать) на веб-странице, иногда без какого-либо взаимодействия со стороны реального пользователя.
Межсайтовые скриптовые атаки, или XSS, происходят, когда код JavaScript вводится на веб-страницу и изменяет ее поведение. Его последствия могут варьироваться от появления неприятных шуток до более серьезных обходов аутентификации или кражи учетных данных.
XSS может происходить на сервере или на стороне клиента и, как правило, поставляется в трех вариантах: DOM (Document Object Model - объектная модель документа) на основе хранимых и отображаемых XSS. Различия сводятся к тому, где полезная нагрузка атаки вводится в приложение.
XSS на основе DOM
XSS на основе DOM возникает, когда полезная нагрузка JavaScript влияет на структуру, поведение или содержимое веб-страницы, загруженной пользователем в свой браузер. Они чаще всего выполняются через измененные URL-адреса, например, в фишинговых письмах.
Чтобы увидеть, насколько легко было бы для введенного JavaScript манипулировать страницей, мы можем создать рабочий пример с веб-страницей HTML. Попробуйте создать файл в локальной системе под названием xss-test.html (или любым другим) со следующим кодом HTML и JavaScript:
<html>
<head>
<title>My XSS Example</title>
</head>
<body>
<h1 id="greeting">Hello there!</h1>
<script>
var name = new URLSearchParams(document.location.search).get('name');
if (name !== 'null') {
document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
}
</script>
</h1>
</html>
На этой веб-странице будет отображаться заголовок "Hello!” если только он не получает параметр URL из строки запроса со значением name. Чтобы увидеть работу скрипта, откройте страницу в браузере с добавленным параметром URL, например:
file:///path/to/file/xss-test.html?name=Victoria
Наша небезопасная страница принимает значение параметра URL для имени и отображает его в DOM. Страница ожидает, что значение будет хорошей дружественной строкой, но что, если мы изменим его на что-то другое? Поскольку страница принадлежит нам и существует только в нашей локальной системе, мы можем тестировать ее сколько угодно. Что произойдет, если мы изменим параметр name, скажем, на:
<img+src+onerror=alert("pwned")>
Это всего лишь один пример, который демонстрирует, как может быть выполнена атака XSS. Смешные всплывающие оповещения могут быть забавными, но JavaScript может принести много вреда, в том числе помогая злоумышленникам украсть пароли и личную информацию.
Хранимые и отраженные XSS
Хранимые (stored) XSS возникают, когда полезная нагрузка атаки хранится на сервере, например, в базе данных. Атака влияет на жертву всякий раз, когда эти сохраненные данные извлекаются и отображаются в браузере.
Например, вместо того чтобы использовать строку URL-запроса, злоумышленник может обновить свою страницу профиля на социальном сайте, чтобы внедрить скрытый сценарий, скажем, в раздел “Обо мне”. Сценарий, неправильно сохраненный на сервере сайта, будет успешно выполняться всё время, пока другой пользователь просматривает профиль злоумышленника.
Одним из самых известных примеров этого является червь Samy, который практически захватил MySpace в 2005 году. Он распространялся путем отправки HTTP-запросов, которые копировали его на страницу профиля жертвы всякий раз, когда просматривался зараженный профиль. Всего за 20 часов он распространился на более чем миллион пользователей.
Отраженные (reflected) XSS аналогично возникают, когда введенные данные перемещаются на сервер, однако вредоносный код не сохраняется в базе данных. Вместо этого он немедленно возвращается в браузер веб-приложением.
Подобная атака может быть осуществлена путем заманивания жертвы для перехода по вредоносной ссылке, которая отправляет запрос на сервер уязвимого веб-сайта. Затем сервер отправит ответ злоумышленнику, а также жертве, что может привести к тому, что злоумышленник сможет получить пароли или совершить действия, которые якобы исходят от жертвы.
Ослабление XSS
Во всех этих случаях XSS могут быть сдержаны с помощью двух ключевых стратегий: проверка полей формы и предотвращение прямого ввода данных пользователем на веб-странице.
Проверка полей формы
Фреймворки снова могут нам помочь, когда речь заходит о том, чтобы убедиться, что представленные пользователем формы находятся в актуальном состоянии. Один из примеров - встроенные классы полей Django, которые предоставляют поля, проверяющие некоторые часто используемые типы, а также задают нормальные значения по умолчанию.
Например, поле электронной почты Django использует набор правил, чтобы определить, является ли предоставленный ввод действительным письмом. Если отправленная строка содержит символы, которые обычно не присутствуют в адресах электронной почты, или если она не имитирует общий формат адреса электронной почты, то Django не будет считать это поле допустимым и форма не будет отправлена.
Если вы не можете полагаться на фреймворк, можете реализовать вашу собственную проверку входных данных. Это можно сделать с помощью нескольких различных методов, включая преобразование типа, например, гарантируя, что число имеет тип int(); проверка минимальных и максимальных значений диапазона для чисел и длин строк; использование заранее определенного массива вариантов, который позволяет избежать произвольного ввода, например, месяцев года; и проверка данных на соответствие строгим регулярным формулировкам.
К счастью, нам не нужно начинать все с нуля. Помогут доступные ресурсы с открытым исходным кодом, такой как валидация репозитория регулярных выражений OWASP, который предоставляет шаблоны для сопоставления их с некоторыми распространенными формами данных. Многие языки программирования предлагают библиотеки проверки, специфичные для их синтаксиса, и мы можем найти множество таких библиотек на GitHub.
Хотя это и может показаться утомительным, правильно реализованная проверка ввода может защитить наше приложение от восприимчивости к XSS.
Предотвращение прямого ввода данных
Элементы приложения, которые непосредственно возвращают пользовательский ввод в браузер, при обычной проверке могут быть неочевидны. Мы можем определить области приложения, которые могут быть подвержены риску, изучив несколько вопросов:
Как происходит поток данных через приложение?
Что ожидает пользователь, когда он взаимодействует с этими входными данными?
Где на нашей странице появляются данные? Становятся ли они встроенными в строку или атрибут?
Вот некоторые примеры полезных нагрузок, с которыми мы можем поиграть, чтобы проверить входные данные на нашем сайте (опять же, только на нашем собственном сайте!). Успешное выполнение любого из этих образцов может указывать на возможную уязвимость к XSS из-за прямого ввода данных.
"><h1>test</h1>
'+alert(1)+'
"onmouserover="alert(1)
http://"onmouseover="alert(1)
Как правило, если вы можете обойти прямой ввод данных, сделайте это. Кроме того, убедитесь, что вы полностью понимаете эффективность выбранных методов; например, использование innerText вместо innerHTML в JavaScript гарантирует, что содержимое будет задано как обычный текст вместо (потенциально уязвимого) HTML.
Аккуратнее с вводом!
Разработчики программного обеспечения явно находятся в невыгодном положении, когда речь заходит о конкуренции с черными хакерами. Несмотря на всю проделанную работу по защитите каждого ввода, который потенциально может скомпрометировать наше приложение, злоумышленнику достаточно только найти тот, который мы пропустили. Это все равно что установить засовы на всех дверях, но оставить окно открытым!
Однако, научившись мыслить в том же ключе, что и злоумышленник, мы можем лучше подготовить наше программное обеспечение к противостоянию плохим парням. Как бы ни было интересно добавлять функции как можно быстрее, мы избежим большого количества долгов по кибербезопасности, если заранее продумаем поток нашего приложения, проследим за данными и обратим внимание на наши входные данные.
Ansible один из двух (наряду с SaltStack) наиболее популярных программных комплексов третьей волны, которые позволяют удалённо управлять конфигурациями. Тем не менее, в сегменте сетевого оборудования лидирует наш сегодняшний герой (если о ПО можно так сказать). В первую очередь это вызвано тем, что Ansible не поставит перед пользователем задачи устанавливать агент на хостинги, требующие от него управления. Тем паче ежели Ваш аппарат взаимодействует с ними через CLI, то Ansible это то, что доктор прописал.
Одним выстрелом три "электронных зайца"
Вообще, прежде чем знакомить уважаемых читателей со сценарием работы в данном программном комплексе, позвольте перечислить несколько его достоинств:
Ansible позволяет параллельно подключать по SSH к устройствам (пользователь может сам определить их число).
Ansible может передавать задачи на подключённые машины.
Ansible способен разбивать машины, входящих в систему, на подгруппы и передавать специальных задачи для каждой подгруппы.
Конечно, указаны не все достоинства Ansible. Просто в данных 3 пунктах, как мне кажется, отражена основная суть работы в данной среде. Выполняя эти три задачи, система автоматически освобождает Вас от головной боли по делегированию задач и функций в компании. Время деньги, как говорится.
Сценарии
Ну и переходим к основному блюду нашего материала - сценариям (playbook). Они состоят из двух частей набора команд для выполнения (play) и конкретных команд (task). Они выполняются друг за другом.
Все записи данных осуществляются с помощью YAMLа. К несомненным плюсам его использования следует отнести то, что он гораздо лучше воспринимается людьми, нежели тот же самый JSON. Ежели Вы больше привыкли Вы к Python, то тут у Вас не возникнет проблем с адаптацией, так как синтаксис у них схожий.
А вот так происходит процесс написания сценария (комментарии даны построчно к выводу):
Имя сценария обязательный элемент для любого сценария;
Сценарий применяется к машинам в подгруппе cisco-routers;
Выключение режима сбора событий в конкретной машине (если не выключить данный режим, то система потратит много времени на решение ненужных задач);
В разделе task указывается список команд для каждого конкретного случая;
После чего происходит выполнение команды:
PLAY [Run show commands on routers] ***************************************************
TASK [run sh ip int br] ***************************************************************
changed: [192.168.100.1]
changed: [192.168.100.3]
changed: [192.168.100.2]
TASK [run sh ip route] ****************************************************************
changed: [192.168.100.1]
changed: [192.168.100.3]
changed: [192.168.100.2]
PLAY [Run show commands on switches] **************************************************
TASK [run sh int status] **************************************************************
changed: [192.168.100.100]
TASK [run sh vlans] *******************************************************************
changed: [192.168.100.100]
PLAY RECAP ****************************************************************************
192.168.100.1 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.100 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.2 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.3 : ok=2 changed=2 unreachable=0 failed=0
И запускаем проверку выполнения команд:
SSH password:
PLAY [Run show commands on routers] ***************************************************
TASK [run s hip int br] ***************************************************************
Changed: [192.168.100.1] => {“changed”: true, “rc”: 0, “stderr”: “Shared connection
To 192.168.100.1 closed.
”, “stdout”: “
Interface IP-Address
OK? Method Status Protocol
Ethernet0/0 192.
168.100.1 YES NVRAM up up
Ethernet0/1
192.168.200.1 YES NVRAM up up
Loopback0
10.1.1.1 YES manual up up
”, “stdout_lines
“: [“”, “Interface IP-Address OK? Method Status
Protocol”, “Ethernet0/0 192.168.100.1 YES NVRAM up
up “, “Ethernet0/1 192.168.200.1 YES NVRAM up
up “, “Loopaback0 10.1.1.1 YES manual up
up “]}
А что внутри?
А теперь поговорим о начинке сценария. Основу составляют переменные. Это могут быть данные о машине, выводы команд, а также их можно вводить вручную.
Главное не забывать правила написания имён. Их всего два:
имена всегда должны состоять из букв, цифр и нижнего подчёркивания;
имена всегда должны начинаться с буквы.
Переменные могут быть определены разными способами:
Инвентарным файлом
[cisco-routers]
192.168.100.1
192.168.100.2
192.168.100.3
[cisco-switches]
192.168.100.100
[cisco-routers:vars]
ntp_server=192.168.255.100
log_server=10.255.100.1
PLAYBOOKом
-name: Run show commands on router:
hosts: cisco-routers
gather_facts: false
vars:
ntp_server: 192.168.255.100
log_server: 10.255.100.1
tasks:
-name: run sh ip int br
raw: s hip int br | ex unass
-name: run s hip route
raw: sh ip route
Специальными файлами, созданными для групп:
[cisco-routers]
192.168.100.1
192.168.100.2
192.168.100.3
[cisco-switches]
192.168.100.100
Или группами каталогов
|– group_vars _
| |– all.yml |
| |–cisco-routers.yml | Каталог с переменными для групп устройств
| |–cisco-switches.yml _|
|
|–host vars _
| |–192.168.100.1 |
| |–192.168.100.2 |
| |–192.168.100.3 | Каталог с переменными для устройств
| |–192.168.100.100 _|
|
|–myhosts | Инвертарный файл
Команда register позволяет сохранять результаты выполнений модулей в переменные. После чего переменная может быть использована в шаблонах, принятиях решений о выполнении заданного сценария.
---
- name: Run show commands on routers
hosts: cisco-routers
gather_facts: false
tasks:
-name: run s hip int br
raw: s hip int br | ex unass
register: sh_ip_int_br_result
---
debug отображает информацию в стандартном потоке вывода в виде произвольной строки, переменной или фактах о машине.
---
- name: Run show commands on routers
hosts: cisco-routers
gather_facts: false
tasks:
-name: run s hip int br
raw: sh ip int br | ex unass
register: sh_ip_int_br_result
-name: Debug registered var
debug: var=sh_ip_int_br_result.stdout_lines
После чего результатом работы станет следующее:
SSH password:
PLAY [Run show commands on routers] ***************************************************
TASK [run sh ip int br] ***************************************************************
changed: [192.168.100.1]
changed: [192.168.100.2]
changed: [192.168.100.3]
TASK [Debug registered var] ***********************************************************
ok: [192.168.100.1] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.1 YES NVRAM up up “,
“Ethernet0/1 192.168.200.1 YES NVRAM up up “,
“Loopback0 10.1.1.1 YES manual up up “
]
}
ok: [192.168.100.2] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.1 YES NVRAM up up “,
“Ethernet0/2 192.168.200.1 YES NVRAM administratively down down “,
“Loopback0 10.1.1.1 YES manual up up “
]
}
ok: [192.168.100.3] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.3 YES NVRAM up up “,
“Ethernet0/2 192.168.200.1 YES NVRAM administratively down down “,
“Loopback0 10.1.1.1 YES manual up up “,
“Loopback10 10.255.3.3 YES manual up up “
]
}
PLAY RECAP ****************************************************************************
192.168.100.1 : ok=2 changed=1 unreachable=0 failed=0
192.168.100.2 : ok=2 changed=1 unreachable=0 failed=0
192.168.100.3 : ok=2 changed=1 unreachable=0 failed=0
Вместо заключения
Можно ещё долго приводить примеры работы в системе, но ещё один факт так сказать "вишенка на торте". К плюсам Ansible следует отнести и то, что заданную команду система может выполнять практически до бесконечности. Пока не наступит требуемый результат трансформации не прекратятся. Пользователю можно не беспокоиться - программа сама всё сделает за Вас, а Вы можете заниматься другими делами.