На определенном этапе, когда программа уже пофиксена от багов (исправлены ошибки), проведены работы по рекламе, продукт стал более-менее популярен и информация о нем распространяется естественным образом (рекомендации и обсуждения на форумах Интернета, в варез-блогах, публикации в тематических изданиях и т.п.), остро становится вопрос о защите программы от взлома и дальнейшего бесплатного распространения.
Защиту можно реализовать разными методами, в том числе и комплексом. Существуют различные способы защиты, от простых до очень сложных, программных и программно-аппаратных. К тому же есть специальные платные проекты, ориентированные на авторов программного обеспечения.
Например, тот же ASProtect, который и по сей день является незаменимым помощником шароварщика притом, что продукт продолжительное время не обновляется и у него практически отсутствует техническая поддержка. Есть, конечно, и другие популярные протекторы, но сейчас речь немного о другом. Считается, что чем сложнее защита, тем труднее взломать программу. Несомненно, это так.
Как Защитить DLL от Взлома на C++
Но так же верно, что нет ничего невозможного. Если программа очень популярна, то наверняка рано или поздно она будет взломана.
Возьмем для примера программное обеспечение от корпорации Microsoft. Такой передовик с огромным штатом программистов наверняка уделяет большое значение защите своих продуктов. А между тем, масштабы нелицензионного использования той же операционной системы Windows описывать не приходится.
Но, в нашем случае, популярность и объемы продаж не в сравнении. Стоит ли тратиться на сторонние решения? Опыт подсказывает, что совсем необязательно. Намного дешевле и проще использовать фиктивные временные ключи активации. Как это работает?
Да очень просто.
Допустим, в программе используется проверка на «волшебное слово», то есть по окончании пробного периода пользователь должен оплатить дальнейшее использование программы и получить ключ активации, который необходимо ввести в программу, иначе она работать не будет. Такую защиту, даже при особом шифровании кода приложения, взломают очень быстро. Так же не спасут проекторы, которые нацелены на препятствование считывание кода из памяти, где ранее зашифрованный код приложения отображается как на ладони – как есть. В обычной практике, «волшебное слово» можно найти на варезах (сайты распространяющие нелицензионное программное обеспечение) через 2-3 дня после появления информации о продукте в тематических каталогах Интернета. И вот тут можно использовать неизбежное в своих интересах.
Для этого всего лишь требуется разместить в разных частях программы дополнительные проверки на… тут уже кому что угодно. И далее, при каком либо несоответствии, дать понять пользователю, что его программа не является зарегистрированной. Отображать эту информацию рекомендую не сразу после проверки, а рандомно (с задержкой через таймер, где время задержки не фиксировано).
Да и саму проверку стоит запускать тем же образом, чтобы было сложнее отловить место запуска. Первый этап защиты оставляем неизменным. Готовим релиз и выкладываем на своем сайте.
Как защитить свой код на Python от ВЗЛОМА
Что же происходит дальше. Почти двухлетний опыт показал, что горе хакеры, прежде чем взяться за парсинг новой версии, применяют ключи (волшебные слова активации) от предыдущих версий программы. Естественно, срабатывает первый этап защиты, ключ честно принят, программа благодарит за регистрацию. После этого новая версия вместе со старым ключом упаковывается в архив и выкладывается на всеобщее обозрение. Максимум одной – двух недель достаточно для того, чтобы масса варез-сайтов разместили у себя новость со ссылкой на эту «работающую» программу, что в свою очередь так же сыграет нам на руку — обеспечит трудность нахождения в поисковых системах рабочего ключа, в том случае, если все же будет пройден дополнительный этап проверки.
На мой взгляд, изящно и просто. А главное – работает!
Вам также может понравиться
Контроль запущенных копий программы 2
03.10.2012
Источник: commix.ru
Как защитить приложение от хакеров
Невозможно полностью защитить приложение от атак. Постоянно появляются новые технологии и npm-пакеты, выходят обновления для CMS и фреймворков — всё это создается людьми, поэтому неизбежны баги и уязвимости. А ещё на пути данных от клиента к серверу и обратно находится большое количество протоколов — они тоже содержат уязвимости и могут быть источниками угроз. Поэтому задача разработчика — предусмотреть «дыры» в безопасности и написать код, устойчивый к большинству атак. Давайте посмотрим, как фронтендеру обезопасить веб-приложение.
Какие бывают атаки
Чтобы понимать, куда направлены атаки, важно знать структуру передачи данных. Задачи по их отправке и получению разделены между клиентом и сервером. Клиент отправляет запрос, а сервер принимает его и возвращает ответ. Клиент — это любое устройство для работы с сайтом, например, ноутбук или смартфон. Сервер — специальная программа, или мощный компьютер.
Атаки делятся на те, которые направлены на клиентскую часть, и те, которые направлены на серверную. Но это распределение условно, ведь есть атаки, которые направлены и на клиент, и на сервер. А некоторые атаки направлены на сервер, но реализуются на клиенте. Например, взлом базы данных, когда киберпреступник через поля ввода добирается до информации о базе данных.
MITM — группа атак с участием посредника, когда киберпреступник тайно вмешивается в обмен данными, чтобы получить или изменить информацию. К таким атакам относятся XSS-атаки и SQL-инъекции.
XSS-атаки — попытка захвата данных, когда киберпреступник внедряет собственный JavaScript-код в веб-приложение и затем использует в личных целях. Такую атаку используют, чтобы захватить учётные записи, украсть личные данные, выдать себя за пользователей или получить доступ к информации.
SQL-атака — атака на базу данных веб-приложения. При работе с базой разработчики используют SQL-запрос. Когда хакер добавляет к таким запросам вредоносный код, происходит SQL-атака, или SQL-инъекция.
CSRF-атака — подделка межсайтовых запросов. При атаке пользователя обманом заставляют делать в веб-приложении то, что он не хотел. Например, пользователя переводят на поддельный сайт, чтобы он перевёл деньги киберпреступнику или ввёл логин и пароль.
DoS и DDoS-атаки — попытка вывести веб-приложение из строя. Такие атаки происходят через настолько большой поток трафика, что веб-приложение не может его обработать и выходит из строя. DoS-атака организовывается с одного источника, а DDoS — с двух и более.
Атаки с загрузкой файлов — попытка получить информацию или нарушить работу веб-приложения, когда злоумышленник отправляет файл с вредоносным кодом через поле для загрузки.
Манипуляция URL — изменение URL в адресной строке браузера. Если веб-приложение не защищено, то киберпреступник добирается до приватной информации, например, личных данных или сведений о заказанных товарах. Ещё к этой атаке относится поиск страниц, скрытых от пользователей.
Как оценить безопасность приложения
Оценить безопасность веб-приложения можно с помощью специальных сервисов и программ: OWASP ZAP, Arachni, Burp Suite или других. Они помогают срежиссировать разные атаки и узнать об уязвимостях при разработке или в готовом веб-приложении.
На скриншоте показаны результаты тестирования в Burp Suite— найдено несколько уязвимостей, и в правом нижнем углу описано, как тестировали определённую атаку.
Такие сканеры проверяют приложение на все основные атаки, в том числе XSS, SQL-инъекции, CSRF и загрузку вредоносных файлов. После тестирования вы получаете подробный отчёт об уязвимости веб-приложения — он пригодится при составлении карты задач для повышения безопасности.
Как защитить приложение от атак
Обо всех способах защиты невозможно рассказать в одной статье — их слишком много. Мы коротко разберём основные, а если вы захотите углубиться в тему, вам поможет курс «Протоколы и сети: веб-безопасность».
Защита сайта на CMS
Выбирайте для веб-приложения популярные CMS с частыми обновлениями — их разработчики постоянно работают над исправлением уязвимостей. При этом помните, что обновления могут не только закрывать старые слабые места в безопасности, но и обнажать новые.
Узнать о новых уязвимостях можно на сайте Банка данных угроз безопасности информации. А ещё разработчики популярных CMS сами предупреждают пользователей, например, список уязвимостей для WordPress есть на сайте.
Как защитить сайт на CMS:
- Обновляйте CMS.
- Обновляйте темы и плагины.
- Используйте как можно меньше плагинов.
- Скройте данные входа в админку, изменив стандартный URL входа.
- Ограничьте количество попыток входа в админку.
- Выберите собственный префикс таблицы. Например, в WordPress по умолчанию задан префикс wp_ , а вы можете изменить его на academy_ или keks_ . Задавать префикс нужно при установке CMS — в готовом проекте его нельзя менять, иначе вы потеряете доступ к базе данных.
А ещё в документации к CMS иногда есть рекомендации по защите. Например, такие советы есть у 1С-Битрикс и OpenCart — обязательно следуйте им.
Защита со стороны клиента
Защищайте и валидируйте поля ввода. Поля ввода очень уязвимы, ведь злоумышленники могут отправлять через них вредоносный код. Поэтому не разрешайте пользователям вводить символы, которые запускают JavaScript или PHP: слэш, угловые скобки и знак вопроса. Также хорошая практика — не давать отправлять форму, если ни одно поле не заполнено.
Старайтесь валидировать все поля, например, запретите ввод букв в поле для номера телефона. Можно ограничить максимальное количество символов, только учитывайте, что номера телефонов в международном формате бывают длинными, а ещё пользователи из России по-разному вводят номера: кто-то начинает с +7, а кто-то пишет восьмёрку, поэтому длина номера может варьироваться. Для таких случаев разрешите вводить в поле как минимум 20 символов, в том числе плюс, скобки, дефис и пробел.
При валидации важное правило — не создать проблем для пользователя. Здесь есть две стратегии:
- «чёрные списки» — запретить для ввода набор символов, а остальные разрешить,
- «белые списки» — разрешить только необходимые символы, а остальные запретить.
«Белые списки» безопаснее, но такая степень защиты не всегда подходит. Например, при создании сайта, похожего на StackOverflow, нельзя ограничивать ввод символов, используемых в коде — иначе пользователи не смогут задавать вопросы. Поэтому здесь подойдёт чёрный список.
Создавайте системы с авторизацией. Создавайте разные уровни доступа, чтобы одни пользователи могли только читать страницы, другие — читать и редактировать, а третьи — редактировать код. Такое разделение защищает от SQL-инъекций, кражи cookies и других атак. Главное — не создавать «суперадминистратора» с максимальным количеством прав, иначе при взломе этого пользователя вся информация станет доступна киберпреступнику. Например, владельцу компании не нужны доступы к коду веб-приложения, а техлиду — к бухгалтерским отчётам.
Подключите WAF — брандмауэры веб-приложений. Они защищают сайты, фильтруя входящий поток пользователей, и анализируют HTTP-трафик, блокируя ботов и выявляя аномалии трафика. Чтобы их подключить, обратитесь в хостинговую компанию или установите специальные системы, например, Nemezida WAF.
WAF нельзя использовать как единственный способ защиты: они не защищают от всех атак, так как есть множество способов их переобхода.
Защищайте cookies. Храните в cookies только настройки веб-приложения для конкретного пользователя, например, язык сайта по умолчанию — эти данные не являются конфиденциальными, и при их краже ничего страшного не произойдёт. А вот данные банковских карт, пароли или паспортные данные пользователей в cookies хранить нельзя. Также хороший способ защиты — недолгий срок жизни cookies и ограничение на действие только в рамках домена веб-приложения.
Защищайте файлы при загрузке. Разрешайте пользователям загружать только необходимые типы файлов. Например, при загрузке фото в профиль разрешайте только растровые форматы графики. Для загрузки pdf-файла разрешайте только формат pdf.
Атрибут accept со значением «image/*» разрешит все типы изображений:
Атрибут accept со значением «audio/*» и «video/*» разрешит все типы аудио и видео:
Можно прописать определённые типы. Разрешим прикреплять только pdf:
Источник: htmlacademy.ru
Какие надежные системы защиты от взлома защиты программ существуют? [закрыт]
Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы он был сосредоточен только на одной проблеме.
Закрыт 6 лет назад .
Какие надежные системы защиты от взлома защиты программ существуют? В частности, от реверс инженеринга? Слышал краем уха про защиту на основе выполнения кода в самописных виртуальных машинах. Кто что знает на этот счет?
Отслеживать
11.4k 8 8 золотых знаков 42 42 серебряных знака 69 69 бронзовых знаков
задан 9 ноя 2012 в 16:41
760 2 2 золотых знака 8 8 серебряных знаков 22 22 бронзовых знака
Если что-то можно запустить, это что-то можно и взломать.
11 ноя 2012 в 16:18
Что имеется ввиду под защитой? Защита чего? От копирования, защита алгоритма, пароля, доступа или что? Поточнее пожалуйста
11 ноя 2012 в 17:05
5 ответов 5
Сортировка: Сброс на вариант по умолчанию
OpenSource. Если все открыто, то кто будет взламывать? Make love not war.
Это шутка, конечно. Тут такая же ситуация, как и с железной дверью. Все эти шифрования, обфускаторы и пр. — защита от шпаны. Серьезных специалистов это не остановит. Замедлит, конечно, их действия, но все равно взломают.
Отслеживать
ответ дан 9 ноя 2012 в 17:37
23.9k 2 2 золотых знака 37 37 серебряных знаков 69 69 бронзовых знаков
100% надежных систем от взлома нет. Другой вопрос, что возможно имеет смысл сделать так, чтобы программную системы было бессмысленно взламывать.
Существует множество трюков, предназначенных для защиты программы от взлома:
- программы-упаковщики. Они упаковывают исполняемый файл, причем иногда весьма причудливыми способами.
- программы-протекторы. Они зачастую пакуют исполняемый код программы + всячески перерабатывают его: изменяют таблицы импорта и расположение модулей исполняемого файла, добавляют вызовы левого кода, зашифровывают код, использование самомодифицирующегося кода и пр.
- программы-обфускаторы. Они добавляют лишних код, переименовывают переменные и ф-ции (в случае, например, платформы .net, где распространяется промежуточный байт-код, а не исполнимые файлы под конкретную машину)
- антиотладочные приемы. Примеры: 1, 2
- написать свою виртуальную машину (а спецификации никому не давать :-)) и написать программу под нее.
Возможно использование всяких привязок к аппаратной части ПК.
В конечном счете, стоимость защиты не должна превосходить стоимость защищаемого =)
Источник: ru.stackoverflow.com