Как обеспечить безопасность JavaScript способы написания защищенного кода


Содержание материала:

Как защитить код JavaScript от копирования

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

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

Закончив разработку кода, нужно также разработать вторую версию, защищенную. Первая версия понадобится для поддержания кода разработчиком, вторая для распространения. Вторая версия должна содержать механизмы защиты. Реализация защиты трудозатратна, по сути приходится чуть ли не заново разработать весь функционал. Существуют различные степени защиты кода, соответственно от такого какая степень, зависит и сложность разработки.

В самом простом случае, необходимо переписать названия функций, имена переменных и т.д., чтобы они не были понятны тому, кто будет анализировать Ваш код. Далее можно реализовать в коде своего рода головоломку, чтобы запутать процесс разбора кода. Все имена, используемые в коде, можно хранить в специальном массиве, который будет предварительно загружаться из отдельного источника. Можно зашифровать имена на стороне сервера и передавать их в зашифрованном виде клиенту вместе с определенной кодовой инструкцией для расшифровки, которая будет использоваться в Вашем JS коде для динамической расшифровки. Причем также можно реализовать динамическое изменение механизма работы шифрования, что сделает почти невозможным вычисление того, как работает Ваш код.

В случае же, если Вы предоставляете свой JS код на некоторый оплаченный клиентом период, можно предоставлять и временный ключ для работы кода. Клиенту в таком случае выдается только часть программы, которая выглядит как законченная версия, остальной код будет предоставляться по запросу на удаленный сервер, который будет отдавать код только после проверки ключа.

После внедрения в код всех указанных механизмов защиты, весь код важно минимизировать, затем качественно обфусцировать. Рассмотрены базовые способы защиты JS кода, но и они способны достаточно защитить код от копирования. В таких случаях тому, кто попытается разобраться в Вашем коде, будет гораздо проще разработать код заново или он вообще не станет браться за расшифровку, так как это нецелесообразно.

Защитить код js от кражи

Я разработал веб-приложение с jquery, html-css-разметкой, которая будет лучшим веб-приложением. Поэтому я должен обеспечить безопасность кода от кражи. Но так как все это клиентская сторона, поэтому нет защищенного для них 100% -ного защищенного способа. Но я хочу сделать их сложнее воровать. Для этого я сделал:

  1. Я отключил нажатие правой кнопки мыши
  2. Я минимизировал и обфускал код.
  3. Я использовал js-код для добавления внешнего js-файла и обфускации кода, чтобы никто не мог понять имя внешнего js-файла
  4. Я создал файл index.html в папке js, чтобы никто не мог получить доступ к папке js

Считаете ли вы, что все это достаточно, чтобы усердствовать? Или любое предложение /совет для меня?

4 ответа

Невозможно предотвратить «кражу» вашего Javascript, потому что код отправляется в браузер. Чтобы ответить на ваши конкретные вопросы:

1. Я отключил кнопку правого клика мыши

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

2. Я минимизировал и обфускал код.

Это достойный шаг, так как гораздо труднее понять, что именно делает код. Тем не менее, существует множество программных «деминераторов», которые хорошо переформатируют код — хотя и с непонятными именами переменных.

3. Я использовал js-код для добавления внешнего js-файла и обфускации кода, чтобы никто не мог понять имя внешнего js-файла

Если вы загружаете внешний файл в любое время, его захватывают инструменты разработчика браузеров (проверьте вкладку «Сеть» в Google Chrome). Таким образом, это не добавит дополнительной защиты.

4. Я создал файл index.html в папке js, так что никто не может получить доступ к папке js

Опять же, это бесполезно, так как любой может видеть, какой JS-файл загружен. Кроме того, «index.html» — это ужасный способ предотвратить список папок, он должен быть выполнен на стороне сервера (например, .htaccess ).

Настоящий ответ: вы не можете предотвратить кражу Javascript вообще. Минимизируйте и запутайте, чтобы предотвратить легкое понимание вашего кода, но это все, что вы можете сделать с точки зрения JS.

Возможно, вы сможете переместить часть логики на серверную (и использовать AJAX в своем приложении), что, конечно же, помешает любым пользователям использовать JS без изменений — им нужно будет реплицировать серверную часть сама логика.

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

Я отключил кнопку правого клика мыши

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

Использовать PHP для загрузки JavaScript только в том случае, если пользователь аутентифицирован (по подписке на премию?)

Что, если они угадают имя файла? Вы должны использовать .htaccess для этого, чтобы сделать Options -Indexes , чтобы отключить просмотр каталога; это безупречно.

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

Я решил свою проблему, введя php в нее. Я написал статью об этом — Обеспечить защиту кода JavaScript от кражи . Я решил его использовать jQuery ajax, json и php. Вот фрагмент кода:

Защищаем JavaScript от копирования

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

Обращаю внимание, что любой код можно расшифровать, просто для этого нужно время. Поэтому данное решение, разумеется, не является идеальным. Тем не менее, чтобы его раскрыть, требуется время, внимательность и усидчивость. И это может оттолкнуть Ваших конкурентов на идею скопировать Ваш скрипт. Большинство из них после нескольких неудачных попыток просто будут искать аналог похожего скрипта на других ресурсах.

По итогам работ в браузере Вы увидите нечто такое:

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

При этом, ведь никто не знает, что именно здесь зашифрован скрипт. Ведь это может быть какой-то параметр, либо текст, либо изображение. Через base64 можно зашифровать всё, что угодно. Это собьёт с толку любителей копипаста.

Поищем в коде функцию glob , которой передаётся шифрованная строка.

Видим ещё несколько функций sfd и rty . Ищем эти функции.

Вот они: sfd= this [» \x65\x76\ x61\x6C»];rty= this [» \x61\x74\ x6F\x62″];

На этом месте многие закончат попытки расшифровки и оставят Ваш сайт в покое.

А мы с Вами разберём всё подробнее.

Итак, как защитить javascript от копирования на своём сайте

Первым делом, указываем в футере сайта путь на наш скрипт и тут же кодируем его:

В строке выше мы говорим интерпретатору php взять файл script.js , далее закодировать его через base64 , далее прибавить строку ‘ K ‘ и всё это записать в переменную $file base64

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

Затем где-то дальше в коде вызываем скрипт:

Пусть этот скрипт вызывается отдельно, подальше от других скриптов и ссылок на скрипты.

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

Разбираем подробно что здесь происходит.

Наша основная функция glob принимает один параметр ‘ s ‘. Параметр ‘ s ‘ сразу передаётся функции substring с параметром ‘ —

[] ‘, (это равно 1 в зашифрованном виде) которая берёт строку в параметре ‘ s ‘, начиная с первого символа (который указан в параметре в зашифрованном виде) и до конца строки. Следовательно, если мы в php коде в качестве сроки прибавляли более одного символа, скажем 3 , то нам нужно будет в функции substring указать 2+(-

[]) . Либо, путём шифрования цифр через побитовые операторы мы можем создать запутанную формулу, часть переменных которой мы можем прятать в cookies или sessionStorage, что сделает крайне затруднительным понимание того, какое количество символов необходимо отбросить для дешифровки кода.

Пример замены цифр через побитовый оператор ‘

-1 можно заменить на:

1 можно заменить на: —

0 можно заменить на:

Аналогично можно заменить значения true и false (true аналогично 1 при нестрогом сравнении, а false аналогично 0, также при нестрогом сравнении).

Далее полученный результат принимает функция rty() . Эта функция представляет собой набор символов, в частности: this [» \x61\x74\ x6F\x62″];

Попробуйте ввести это в консоли браузера и Вы увидите, что на самом деле делает эта функция. В частности, Вы увидите:

Т.е., набор символов — это зашифрованная функция atob , которая, согласно описанию на MDN делает Decode a base-64 encoded string , т.е. декодирует строку, полученную из base-64 .

Полученный результат декодирования получает функция sfd() . Она также представляет собой набор символов: this [» \x65\x76\ x61\x6C»];

Вы уже догадались, что нужно сделать? 🙂 Выполните в консоли браузера и Вы увидите:

Здесь, думаю, уже объяснять ничего не надо. Все мы знаем, что функция ev al выполняет скрипт, полученный из строки. «Bad practice», как сказали бы многие, для обычного кода, но в нашем случае это безопасная и нужная нам функция для реализации нашей идеи. К тому же, напрямую к этой функции пользователь не сможет получить доступ.

Наверное, Вы задались вопросом, а каким же образом функции зашифрованы в наборе символов? Очень просто: набор символов — это текст, преобразованный в шестнадцатеричную систему счисления. Т.е. это текст, в формате Hex (hexadecimal). Через hex можно зашифровать любые символы.

Таким образом, наша расшифрованная функция выглядит так:

Специально разбил по строчкам, чтобы было наглядно.

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

Вы можете пойти и далее. Если каким-то образом кто-то всё же расшифрует Ваш скрипт, немного усложните его, чтобы людям было сложнее модицифировать его. Например, можно поговорить о побитовом операторе ^ , c помощью которого можно творить чудеса. Например, a^b^b будет равно a . В качестве b может быть использован ключ, который мы зашифруем где-то выше. Но об этом расскажу как-нибудь в других постах.

Всё будет работать как и раньше, но собьёт с толку нехороших копипастеров 🙂

Подписывайтесь на группу в ВКонтакте, чтобы всегда быть в курсе актуальных выпусков W e b d e v e l o p m e n t b l o g !

Защищаем свой сайт от хакеров: 9 советов по безопасности

Перевод статьи Руалда Гербера, Тоби Комптона и Тима Перри «9 security tips to protect your website from hackers».

Возможно, вы считаете, что ваш сайт не представляет интереса для хакеров, но атаки на такие «неинтересные» сайты происходят постоянно. Большинство из них не имеют цели украсть ваши данные. Вместо этого злоумышленники пытаются использовать ваш сервер в качестве промежуточного звена для рассылки спама по email или для устройства временного веб-сервера (для обслуживания нелегальных файлов). Другие способы использования скомпрометированных машин – использование ваших серверов в качестве части ботнета или для майнинга криптовалют. Также на ваш сайт может напасть программа-шантажист.

Хакинг регулярно осуществляется автоматизированными скриптами, написанными для прочесывания интернета в попытке использовать известные проблемы в безопасности программ.

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

1. Обновляйте программное обеспечение

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

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

При использовании на сайте стороннего ПО, например, CMS или форума, нужно следить за патчами безопасности и регулярно применять их. У большинства производителей бывает рассылка или RSS, где они сообщают обо всех проблемах с безопасностью. WordPress, Umbraco и многие другие CMS уведомляют вас о наличии обновлений при каждом входе в систему.

Многие разработчики используют такие инструменты как Composer, npm или RubyGems для управления зависимостями своего ПО. В результате уязвимости в безопасности могут обнаружиться в любом пакете, на который вы полагаетесь, но не придаете значения в плане безопасности. Это один из самых простых путей «попасться».

Следите за тем, чтобы ваши зависимости были обновлены. Используйте инструменты вроде Gemnasium, чтобы получать автоматические уведомления, когда становится известно, что в одном из ваших компонентов появилась уязвимость.

2. Следите за возможным внедрением SQL-кода

SQL injection (внедрение SQL-кода) это использование атакующим поля формы или URL-параметра для получения доступа к вашей базе данных. Если вы используете стандартный Transact SQL, злоумышленникам легко незаметно вставить нестандартный код в ваш запрос, который затем будет использоваться для изменения таблиц, получения информации и удаления данных. Это можно легко предотвратить, постоянно используя параметризованные запросы. В большинстве веб-языков такой функционал есть, к тому же он прост в применении.

Обратите внимание на этот запрос:

Если бы атакующий изменил URL-параметр для передачи на ‘ or ‘1’=’1′, то запрос выглядел бы так:

Поскольку ‘1’ равно ‘1’ , это позволит злоумышленнику добавить дополнительный запрос в конце SQL предложения, который также будет исполнен.

Этот запрос можно исправить путем недвусмысленной параметризации запросов. Например, если вы используете MySQLi в PHP, это будет выглядеть так:

3. Защита от XSS-атак

При межсайтовом скриптинге (Cross-site scripting, XSS) в ваши страницы внедряется зловредный код JavaScript, который затем запускается в браузерах ваших пользователей. Он может изменять содержимое страницы, похищать информацию и отсылать ее тому, кто совершил атаку.

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

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

Эффективным может оказаться не только внедрение JavaScript в HTML, но и внедрение контента, который будет запускать код путем вставки директив Angular или использования хелперов Ember.

Топ-пост этого месяца:  Vue mixin многократное использование кода внутри компонентов с помощью миксинов, синтаксис и примеры

Главное здесь сфокусироваться на том, каким образом контент, генерируемый пользователем, может избежать ваших ограничений и интерпретироваться браузером не так, как вы предполагали. Это напоминает защиту от SQL injection.

При динамическом генерировании HTML используйте функции, которые недвусмысленно делают нужные вам изменения. Например, используйте element.setAttribute и element.textContent, которые будут автоматически экранироваться браузером, вместо ручной установки элемента .innerHTML. Или используйте функции вашего инструмента шаблонов, которые автоматически выполняют нужное экранирование, вместо строк конкатенации или установки чистого HTML-контента.

Еще одним мощным инструментом для защиты от XSS является Content Security Policy (CSP). CSP это хедер, который может возвращаться вашим сервером и который сообщит браузеру об ограничениях выполнения JavaScript на этой странице. Например, о запрете запуска любых скриптов не из вашего домена, запрете inline JavaScript или отключении eval(). У Mozilla есть прекрасное руководство с некоторыми примерами конфигураций. Это затруднит работу скриптов нападающего, даже если они попадут на вашу страницу.

4. Относитесь внимательно к сообщениям об ошибках

Будьте осторожны с тем, сколько информации вы сообщаете в ваших сообщениях об ошибках. Сообщайте пользователям только самый минимум, чтобы не допустить утечки секретных данных с вашего сервера (например, API-ключей или паролей базы данных). Не предоставляйте также подробных сведений об исключениях, поскольку они могут существенно облегчить более сложные атаки, такие как SQL injection.

5. Делайте проверку и в бэкенде, и во фронтенде

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

6. Проверяйте пароли

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

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

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

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

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

К счастью, многие CMS предоставляют менеджмент пользователей «из коробки», причем многие из указанных нами средств обеспечения безопасности являются встроенными в них.

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

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

7. Избегайте загрузки файлов

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

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

Даже открытие файла и чтение хедера или использование функций проверки размера изображения не являются полностью надежными. Многие форматы изображений допускают хранение секции комментариев, где может содержаться PHP-код, который может выполниться на вашем сервере.

Так что же делать, чтобы это предотвратить? По крайней мере, следует запретить пользователям выполнять любой файл из загружаемых ими. По умолчанию веб-серверы не пытаются выполнять файлы с расширением изображений, но не стоит на это слишком полагаться, потому что файл под названием image.jpg.php, например, может пройти.

Есть такие варианты как переименование файла при загрузке для обеспечения правильного расширения файла, или смена прав доступа к файлу, чтобы он не мог быть выполнен, например, chmod 0666. При использовании *nix можно создать файл .htaccess (см. ниже), в котором прописать защиту от двойного расширения (как image.jpg.php).

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

Если ваши файлы недоступны напрямую, вам нужно создать скрипт для их выбора из приватной папки (или HTTP handler в .NET) и доставки в браузер. Теги изображений поддерживают атрибут src, который не является прямым URL изображения. Поэтому ваш атрибут src может указывать на ваш скрипт доставки файлов, позволяющий установить правильный тип содержимого в HTTP-хедере. Например:

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

Убедитесь, что у вас установлен файервол и заблокированы ненужные порты. По возможности установите DMZ (Demilitarised Zone), что позволяет ограничить внешний доступ к порту 80 и 443. Но это может быть невозможно, если у вас нет доступа к вашему серверу из внутренней сети, поскольку вам придется открыть порты для разрешения загрузки файлов и удаленно логиниться на ваш сервер по SSH или RDP.

Если вы разрешаете загрузку файлов из интернета, допускайте только безопасные методы передачи, такие как SFTP или SSH.

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

Наконец, не забывайте об ограничении физического доступа к вашему серверу.

8. Используйте HTTPS

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

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

Это уже не так сложно и дорого, как было раньше. Let’s Encrypt предоставляет совершенно бесплатные и автоматизированные сертификаты, которые вам понадобятся для включения HTTPS. Также есть доступные инструменты сообщества для широкого спектра распространенных платформ и фреймворков, позволяющие автоматическую настройку этого протокола.

Примечательно, что Google собирается выше ранжировать сайты с HTTPS. Небезопасный HTTP устарел, пора апгрейдиться.

Вы уже используете HTTPS повсюду? Идите дальше: обратите внимание на HTTP Strict Transport Security (HSTS) – простой хедер, который вы можете добавлять к ответам вашего сервера для запрета небезопасного HTTP для всего вашего домена.

9. Используйте инструменты обеспечения безопасности

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

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

Стоит обратить внимание на такие бесплатные инструменты:

  • Netsparker (доступны бесплатный вариант от сообщества и пробная версия). Хорошо подходит для тестирования на SQL injection и XSS.
  • OpenVAS. Претендует на звание самого продвинутого open source сканера безопасности. Хорош для тестирования известных уязвимостей, в настоящее время их в его базе больше 25 тысяч. Но его может быть трудно установить, для этого может потребоваться OpenVAS сервер, а он запускается только на *nix. OpenVAS это форк Nessus, сделанный до того, как последний стал коммерческим продуктом с закрытым кодом.
  • SecurityHeaders.io (бесплатная онлайн-проверка). Инструмент для быстрого уведомления о том, какие хедеры безопасности домена, упомянутые выше (например, CSP и HSTS), включены и правильно настроены.
  • Xenotix XSS Exploit Framework. Инструмент от OWASP (Open Web Application Security Project), включающий огромную выборку примеров XSS-атак. Вы можете запускать его для быстрой проверки уязвимости инпутов вашего сайта в Chrome, Firefox и IE.

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

Можно пойти дальше, попытавшись скомпрометировать сайт вручную с использованием значений POST/GET. Здесь вам может помочь прокси отладки: он позволит вам перехватить значение HTTP-запроса между вашим браузером и сервером. Для начала с этой целью можно воспользоваться бесплатным приложением Fiddler.

Что же стоит попытаться изменить в запросе? Если у вас есть страницы, которые должны быть видны только вошедшим в систему пользователям, вы можете попытаться изменить такие URL-параметры как id пользователя или значения cookie, чтобы попытаться увидеть подробности о другом пользователе. Также стоит протестировать формы, изменяя значения POST, чтобы попытаться отправить код для осуществления XSS или загрузить скрипт на сервер.

Какие варианты защиты, кто пробовал, Обфускация JavaScript?

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

Столкнулся по долгу службы, что код написанный на фронте легко стырить. И в некоторых ситуациях обфускация не помогает(html,css,js,jquery). У меня лично на массивах в js все слетало, при обфускации из темы хабра https://habrahabr.ru/post/112530/

Какие варианты защиты, кто пробовал?

ФИЛОСОФЫ и красавчики, спасибо за ваше время, но Вам посрать на техническую сторону вопроса, воздержитесь от высказываний, не тратьте чужое время понапрасну пожалуйста.

  • Вопрос задан более года назад
  • 2239 просмотров

Есть более превентивный вариант:

Опубликовать на Github и сделать для скрипта статью
И быть не жлобом, и помогать сообществу и тем, кому нужно схожее решение.
И только придется доработать его, продумать варианты использования.

Вопрос:
Почему вы не хотите делиться?

AlikDex, я выскажу своё мнение с нейтральной точки зрения (я сейчас «стою по середине» мнений относительно защиты кода калькулятора: за/против = 50/50):

Как Вы оценили:
1. Трудоёмкость данной задачи
2. Навыки исполнителя (программиста этого калькулятора)
3. По какому/каким критериям сделали вывод, что:

Этот говнокалькулятор писать два часа делов. Еще полчаса дизайнить. Что тут защищать, стесняюсь спросить?

Т.е. вопрос прост: за что был оскорблён Oscar Handsome, попытавшийся понять, как не работать бесплатно на других и как уберечь себя от упущенной выгоды, защитив свой интеллектуальный труд?

Очень хотелось бы понять для себя.

xmoonlight,
1. Сколько примерно времени понадобится написать подобное решение (из личного опыта).
2. Навыки не имеют никакой важности в глазах клиента. Либо он может сделать этот калькулятор, либо нет.
3. Пункт 1.

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

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

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

На это есть отличный пост у меня: этот.

Весь вопрос в затраченном времени на реализацию поставленной задачи.
Что проще? Или просто взять с другого сайта и поставить себе на сайт, или заказывать, ЖДАТЬ и платить деньги за разработку?

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

Сергей, Алексей Ярков, Максим Федоров, еб*ть, да вы че бл*ть мужики, при чем здесь максимализм и прочая тупая поеб*нь, что вы тут пишите ВСЯКУЮ ДРЯНЬ? ИДИТЕ РАЗГЛАГОЛЬСТВОВАТЬ В ДРУГИЕ СЕРВИСЫ, для своих бла бла бла. ХОТЬ ОДИН ИЗ ВАС БЫ НАПИСАЛ, что можно технически. ПОДЧЕРКИВАЮ! сделать. НИ ОДИН. ДАЖЕ В КАКУЮ сторону нюхать. а вот вижу xmoonlight хоть что то прислал, благодарствую!

AlikDex, Ну раз невь*б*нно умный иди и пиши. Красавчик, смотри что бы корона не слетела. Для меня как начинающего в то время, написание калькулятора на js+jquery было не сложным. было сложно сделать распечатывание документа в pdf, благо библиотеки были написаны, иначе я бы не осилил думаю задачу, тем более за не большую плату и время на разработку. А делал я дохера времени всецело эту задачу. Если интересует время, я и это подниму, будешь умиляться какой ты невьебенный и мог бы это за 2 часа написать.

МУЖИКИ МЕНЯ БОМБИТ ОТ ВАШИХ ОТВЕТОВ, ВЫ ХУЖЕ БАБ. РАЗВОДИТЕ ВОДУ! ЧТО НЕ ПОНЯТНОГО В МОЕМ ВОПРОСЕ ИЗ ПОСТА.

У меня заказчик спрашивал как можно защитить наработки, я тогда читал и пытался понять как можно фронт работы защитить, и сделал выводы, что это почти нереальная задача, и так же объяснял заказчику. ЧЕРЕЗ пол года, все что я делал сперли, и моему заказчику обидно, что он платил бабки, а наработки уже на 5-10 других сайтах конкурентов, которые не могут своего ничего хорошего сообразить. А я в же в свою очередь, жадностью не страдаю. МНЕ ИНТЕРЕСНО ЧТО В ЭТО ОТРАСЛИ КАК МОЖНО ЗАЩИТИТЬ ПРИ ЖЕЛАНИИ. Do you undestand me?

Web в Windows 8: защита

Продукты и технологии:

Windows 8, JavaScript, HTML5

В статье рассматриваются:

  • переход веб-разработчиков на Windows 8;
  • встраивание защиты в приложения Windows Store;
  • проверка ввода;
  • хранение конфиденциальных данных;
  • использование локальных и веб-контекстов;
  • взаимодействие между контекстами.

Когда-то давно я думал, что было бы неплохо научиться играть в гольф. Перед тем как записаться на соответствующие занятия в своих краях, я никогда не брал в руки клюшку для гольфа. На первом занятии инструктор спросил меня, брал ли я когда-нибудь уроки по игре в гольф и вообще пробовал ли я играть в гольф. Когда я ответил ему отрицательно, он сказал: «Хорошо! Нам не придется сначала избавляться от старых привычек при взмахе».

Веб-разработчики, переходящие с браузера на приложения Windows Store, несут с собой определенные привычки. Хотя они могут гордиться своими познаниями в JavaScript, некоторые возможности совершенно новые и требуют перемен в образе мышления. Безопасность — одно из таких фундаментальных различий. У многих веб-разработчиков сложилась привычка перекладывать защиту приложений на сервер из-за таких причин, как «Зачем этим заморачиваться? JavaScript можно легко обойти». На стороне веб-клиента средства защиты рассматриваются как функционал для большего удобства в использовании без улучшения общей безопасности веб-приложения.

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

Проверка допустимости ввода

Веб-разработчик JavaScript-проверка предназначена для удобства в использовании и ничего не дает для защиты самого приложения.

Разработчик для Windows 8 Проверка допустимости ввода средствами HTML5 и JavaScript — первая линия обороны от зловредного контента, попадающего в ваше приложение.

В традиционных веб-приложениях JavaScript зачастую является не более чем воротами, открывающими путь к серверу. Все важные операции с данными вроде проверки ввода и хранилищ выполняются на сервере. Атакующие могут отключить JavaScript в своих браузерах или напрямую передавать написанные вручную HTTP-запросы для обхода любой защиты на клиентской стороне. В приложении Windows Store разработчик не может полагаться на сервер в очистке пользовательского ввода до операций над данными, потому что нет никакого сервера. Когда дело доходит до проверки допустимости ввода, JavaScript и HTML5 предоставляются сами себе.

Топ-пост этого месяца:  Динамическое меню на AJAX

В защите программного обеспечения проверка ввода является критически важным для поддержания целостности данных элементом. Без нее атакующие могут использовать любое поле ввода как вектор возможной атаки на приложение Windows Store. Во втором издании книги «Writing Secure Code» (Microsoft Press, 2003) авторы Майкл Говард (Michael Howard) и Стив Липнер (Steve Lipner) написали фразу, которая стала одной из мантр в управлении вводом: «Весь ввод является злонамеренным, пока не доказано обратное».

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

Ограничивай, отклоняй и дезинфицируй

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

Рис. 1. Проверка ввода (схема основана на рис. 4.4 из главы 4 «Design Guidelines for Secure Web Applications» документа «Improving Web Application Security: Threats and Countermeasures», доступного по ссылке bit.ly/emYI5A)

Constrain Ограничение
Allow known good data Разрешение известных хороших данных
Reject Отклонение
Reject known bad data Отклонение известных вредных данных
Make potentially malicious data safe Потенциально вредные данные превращаются в безопасные

Проверка данных начинается с ограничения данных теми, которые считаются «известными хорошими». Веб-разработчики, знакомые с HTML5, могут использовать существующие знания новых типов и атрибутов input для ограничения данных, поступающих в их приложения Windows Store. Ключевое различие между Web и Windows 8 в том, что «за кулисами» приложения Windows Store нет сервера, который проверял бы ввод. Ограничение данных должно происходить в HTML5 или JavaScript.

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

  • Name Только буквы с несколькими специальными символами; общая длина не может превышать 45 знаков. Данный критерий основан на том, что целевым рынком этого приложения будет США.
  • E-mail Address Ввод должен соответствовать допустимому формату адреса электронной почты.
  • Weight и Height Числа с сопоставленными метками для отображения данных в футах и дюймах для роста и фунтах для веса.
  • Notes HTML-контент, создаваемый с помощью стандартного HTML-редактора Contoso.

Для input-элемента Name мне нужно ограничить, какие символы допустимы в этом поле, а также какой длины может быть значение. Это можно сделать с помощью двух новых атрибутов тега input: pattern и title.

Pattern — это регулярное выражение, которому должны удовлетворять вводимые данные. MSHTML (механизм рендеринга, применяемый для приложений HTML5 в Windows 8) проверяет, что данные, вводимые в поле, соответствуют регулярному выражению. Если пользователь вводит данные, не отвечающие регулярному выражению pattern, передача формы закончится неудачей, и пользователю будет указано исправить недопустимые данные в поле. Например, поле Name может состоять из букв и пробелов и должно быть длиной от трех до 45 символов. Для этого используется следующее значение pattern:

С помощью title пользователь информируется о том, что ожидает система. В данном случае нечто вроде «Имя должно быть длиной от трех до 45 символов и содержать только буквы и пробелы» исчерпывающе поясняет ожидаемый шаблон. Ничто так не сбивает пользователей с толку, как неправильный ввод, без знания правильного шаблона ввода. Будьте внимательны к своим пользователям и подсказывайте им, что именно допускается. Атрибут title именно это и делает; это сообщение, поясняющее, что ожидается в данном поле.

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

Некоторые поля имеют специфические типы данных, например числа, даты и адреса электронной почты. HTML5 помогает и здесь, предоставляя массу новых input-типов, такие как email, phone, date, number и многие другие. Используя эти input-типы данных, MSHTML проверяет, допустимы ли введенные пользователем данные; при этом не нужны никакие регулярные выражения или JavaScript-код. Новые типы данных обрабатывает атрибут type элемента input. (Подробнее о новых типах и их применении см. по ссылке bit.ly/OH1xFf.) Скажем, чтобы получить адрес электронной почты для страницы Profile, я указал бы атрибут type равным email, как в следующем примере:

Это поле принимает значение, только если оно удовлетворяет формату адреса электронной почты. Если MSHTML не распознает ввод как допустимый адрес электронной почты, в поле выводится ошибка проверки, когда пользователь пытается отправить форму. Применение новых input-типов HTML5 ограничивает данные ожидаемым подмножеством безо всякой возни со сложными проверками на основе JavaScript.

Некоторые из новых input-типов также поддерживают ограничения диапазонов с помощью новых атрибутов min и max. В качестве примера у людей рост не может выходить за пределы от трех до восьми футов. Тогда в поле height могут быть использованы следующие ограничения диапазона:

В предложенных примерах используются четыре способа ограничения данных с помощью HTML5-тега input. Проверяя длину (pattern), формат (и вновь pattern), тип данных (новые input-типы) и диапазон (атрибуты min/max), вы можете ограничивать ввод до известных хороших данных. Не все атрибуты и типы предлагают внести коррективы перед отправкой. Обязательно проверяйте содержимое формы методом checkValidity (bit.ly/SgNgnA) — по аналогии с Page.IsValid в ASP.NET. Вероятно, вас интересует, можно ли похожим образом ограничивать данные, используя только JavaScript. Да, можно, но использование HTML5-атрибутов сокращает общий объем кода, который разработчику приходится управлять самостоятельно, и позволяет передавать всю черновую работу механизму MSHTML.

Reject отклоняет известный вредный ввод (т. е. это список отклоняемых элементов). Хороший пример reject — создание списка отклоняемых IP-адресов, с которых нельзя подключаться к вашему вею-приложению. Списки отклоняемых элементов полезны, когда у вас есть некие фиксированные области, определенные для тех элементов, которые вы хотите блокировать. В качестве примера возьмем список рассылки сообщений электронной почты какой-либо группе (скажем, вашей группе разработки), из которого вы намеренно исключаете определенных лиц. В этом примере вы знаете, какие почтовые адреса следует отклонять из списка адресов группы разработки. В защищенном программном обеспечении предпочтение следует отдавать ограничению (списку разрешенных элементов), а не отклонению (списку отклоняемых элементов). Всегда помните, что известные вредные данные постоянно меняются, так как взломщики изобретают все более изощренные способы обхода средств защиты. В предыдущем примере вообразите, что к группе присоединяются новые разработчики и они должны пройти некий испытательный период перед тем, как вы включите их в список почтовой рассылки. В долгосрочном плане управлять ограничениями гораздо легче, а список разрешенных элементов проще поддерживать в противоположность списку запрета с тысячами элементов.

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

Иногда ввод содержит известные хорошие и вредные данные. Примером тому является HTML-контент. Некоторые теги разрешается отображать, тогда как другие — нет. Процесс фильтрации или отключения известных вредных данных и пропуск одобренных данных известен как дезинфекция ввода (sanitizing the input). Поле заметок в приложении Contoso Health как раз является отличным примером этому. Пользователи могут вводить HTML-теги через HTML-редактор, но, когда ввод отображается приложением, визуализируются лишь определенные HTML-теги. Процесс дезинфекции данных принимает данные, которые могут быть вредоносными и делает их безопасными, удаляя небезопасный контент. В приложения Windows Store можно задать значение HTML-элемента, используя innerText (вместо innerHTML), что приводит к рендерингу HTML-контента как текста, а не HTML-кода. (Заметьте: если в приложении innerText тега script задать JavaScript, вы получите исполняемый скрипт.) JavaScript также предоставляет еще одно полезное средство дезинфекции: toStaticHTML.

Вот пример кода из обработчика btnSave_Click страницы Profile:

Если пользователь вводит в txtNotes строку:

метод window.toStaticHTML удаляет тег script и оставляет только одобренный тег strong. Вызов toStaticHTML удаляет любой тег, который отсутствует в списке одобренных безопасных тегов (еще один пример использования списка разрешенных элементов), а также любой неизвестный атрибут. В выводе метода toStaticHTML остаются только известные хорошие данные. Полный список одобренных тегов, атрибутов, CSS-правил и свойств см. по ссылке bit.ly/KNnjpF.

Проверка ввода уменьшает риск попадания в систему вредоносных данных. С помощью HTML5 и toStaticHTML приложение может ограничивать ввод известными хорошими данными и удалять или отключать потенциально вредоносный контент без участия сервера.

Теперь, когда приложение Contoso Health получает допустимые данные, обсудим, как обращаться с конфиденциальными данными, к которым относится медицинская или финансовая информация.

Хранилище конфиденциальных данных

Веб-разработчик Никогда не храните конфиденциальные данные на клиенте, так как у него нет защищенного хранилища.

Разработчик для Windows 8 Конфиденциальные данные можно шифровать и безопасно хранить средствами Windows Runtime.

В предыдущем разделе приложение Contoso Health получало общую профильную информацию. По мере разработки заказчиком была затребована форма медицинской карты (medical history form). В эту форму вводятся все значимые с медицинской точки зрения события, происходящие на протяжении жизни пациента, например самый последний визит к врачу. Согласно старым правилам веб-разработки, хранение конфиденциальной информации, такой как медицинская карта пациента, на клиенте — плохая идея из-за потенциальной утечки этих данных. В приложении Windows Store конфиденциальные данные можно хранить локально, используя средства защиты в Windows Runtime.

Для защиты медицинской карты пациента Contoso Health использует WinRT Data Protection API. Шифрование должно быть единственным элементом вашей стратегии защиты данных (продумывайте эшелонированную оборону, а не что-то одно вроде шифрования). Не забывайте о рекомендациях, относящихся к конфиденциальным данным, например о доступе к таким данным только при необходимости и об их хранении вне кеша. Отличный ресурс, в котором вы найдете много соображений по хранению конфиденциальных данных, — документ «Improving Web Application Security: Threats and Countermeasures» в MSDN Library (bit.ly/NuUe6w). Хотя в этом документе основное внимание уделяется рекомендациям в области веб-разработки, он дает много превосходных фундаментальных знаний, применимых к любому типу разработки.

На странице Medical History в приложении Contoso Health есть кнопка btnAddItem. Когда пользователь щелкает ее, приложение шифрует данные, введенные в форму Medical History. Чтобы зашифровать информацию Medical History, приложение использует встроенный WinRT Data Protection API. Это простая система шифрования, позволяющая разработчикам быстро шифровать данные без издержек, связанных с управлением ключами. Начните с пустого обработчика событий click для btnAddItem. Приложение Contoso Health собирает информацию с формы и сохраняет ее в JSON-объекте. В обработчик событий я добавляю код для быстрого формирования этого JSON-объекта:

Объект healthItem представляет запись Medical History, введенную пользователем в форму. Шифрование healthItem начинается с создания экземпляра DataProtectionProvider:

Конструктор DataProtectionProvider (для шифрования) принимает строковый аргумент, который определяет, с чем сопоставляется Data Protection. В данном случае я шифрую контент для локального пользователя. Вместо локального пользователя можно было бы выбрать машину, набор веб-удостоверений, участника подсистемы защиты Active Directory или некоторые другие варианты. Список вариантов вы найдете в разделе «Protection Descriptors» в Dev Center (bit.ly/QONGdG). Какой дескриптор защиты (protection descriptor) вы будете использовать, зависит от требований приложения. На данный момент Data Protection Provider готов к шифрованию данных, но данные нужно немного изменить. Алгоритмы шифрования работают с буферами, а не с JSON-объектами, поэтому на следующем этапе healthItem преобразуется в буфер:

В CryptographicBuffer имеется много объектов и методов, которые работают с буферами, используемыми в шифровании и дешифровании. Первый из этих методов — convertStringToBinary, который принимает строку (в данном случае строковую версию JSON-объекта) и преобразует ее в зашифрованный буфер. Используемая кодировка задается с помощью объекта Windows.Security.Cryptography.BinaryStringEncoding. В этом примере я использую UTF8 в качестве системы кодировки своих данных. Метод convertStringToBinary возвращает буфер, основанный на строковых данных и указанной кодировке. Как только буфер готов к шифрованию и создан экземпляр Data Protection Provider, я могу вызвать метод protectAsync для шифрования этого буфера:

Аргумент encryptedBuffer является выводом метода protectAsync и содержит зашифрованную версию буфера. Иначе говоря, это зашифрованные данные, готовые к сохранению. После этого encryptedBuffer передается в метод SaveBufferToFile, который записывает шифрованные данные в файл в локальную папку приложения.

Шифрование для healthItem сводится к трем строкам кода.

  1. Создание экземпляра Data Protection Provider.
  2. Преобразование данных в буфер.
  3. Вызов protectAsync для шифрования данных.

Дешифрование данных осуществляется так же легко. Отличия заключаются лишь в том, что вы используете пустой конструктор для DataProtectionProvider и вызываете метод unprotectAsync вместо protectAsync. Метод GetBufferFromFile загружает переменную encryptedBuffer из файла, созданного методом SaveBufferToFile:

Можно ли использовать шифрование в случаях с JavaScript, отличных от WinRT? Да! Так же это легко? Нет! На пути шифрования в браузере возникает многочисленные трудности, в частности хранение секретного ключа, а также управление размером файла алгоритмов, необходимых для качественного шифрования. WinRT Data Protection API, равно как и другие средства шифрования в пространстве имен Windows.Security.Cryptography, упрощают защиту ваших данных. Применяя средства защиты Windows Runtime, разработчики могут безопасно хранить конфиденциальные данные в приложениях Windows Store, в то же время легко управляя своими шифровальными ключами.

Локальные контексты в сравнении с веб-контекстами

Веб-разработчик Веб-приложения выполняют ссылки на внешние скрипты в том же источнике, откуда вызываются эти скрипты.

Разработчик для Windows 8 Приложения Windows Store отделяют пакет локального приложения от ссылок на внешние скрипты.

Web 2.0 научила разработчиков тому, что контент может поступать с их сайтов, с других сайтов или через взаимодействие с пользователями. В Web контент практически доступен для всех, при этом разработчики используют ссылки на скрипты и API-данные от третьих сторон. Сети доставки контента (content delivery networks, CDN) и онлайновые сервисы вроде Bing Maps избавляют от издержек управления библиотеками кода или большими репозитариями данных, позволяя легко расширять функциональность веб-приложений. Меньшие издержки — штука хорошая, но тут есть потенциальный риск.

В качестве примера вообразим, что один из партнеров Contoso в индустрии медицинского ПО — Litware Inc. Компания Litware выпускает новый Exercise API и предоставляет разработчикам Contoso Health ключи для использования ежедневно обновляемого канала данных. Если бы Contoso Health было веб-приложением, группа разработки могла бы реализовать Exercise API, используя примерно такую ссылку на скрипт:

Разработчики в Contoso доверяют Litware, которая предоставляет важный контент, и знают, что у этой компании большой опыт в защите данных. К сожалению, серверы Litware были скомпрометированы одним недовольным разработчиком, и exercise.js был изменен так, что стартовый скрипт в нем выводит всплывающее окно с сообщением «Contoso Health нуждается в техническом обслуживании; пожалуйста, загрузите следующее приложение для обслуживания». Пользователь, уверенный в полной легитимности этого сообщения, загружает вредоносное ПО. Разработчики Contoso озадачены: Litware использует отличные процедуры проверки, как же такое могло случиться?

В Web скрипты, на которые ссылаются так, как только что было описано, выполняются с тем же источником (origin), что и скрипт на том же сайте. Это означает, что exercise.js (выполняемый как JavaScript-код) получает несанкционированный доступ к DOM-дереву, а также к любому скриптовому объекту. Как было показано ранее, это может приводить к серьезным проблемам в защите. Чтобы ослабить риск таких проблем, Windows 8 разбивает ресурсы приложения на два контекста, представленных на рис. 2.

Рис. 2. Функции локального контекста в сравнении с веб-контекстом (взято из «Features and Restrictions by Context» [bit.ly/NZUyWt] и «Secure Development with HTML5» [bit.ly/JOoMOS])

Local Context Локальный контекст
Trusted Resources from App Package Доверяемые ресурсы из пакета приложения
• Access to WinRT Libraries • Доступ к библиотекам WinRT
• Access to Windows Library for JavaScript • Доступ к Windows Library for JavaScript
• Use of Cross-Domain XHR Requests • Использование кросс-доменных XHR-запросов
Web Context Веб-контекст
Remote Resources Удаленные ресурсы
• Limited Use of Windows Library for JavaScript • Ограниченное использование Windows Library for JavaScript
• Use of JavaScript URIs • Использование JavaScript URI-идентификаторов
• Use of External Script References • Применение ссылок на внешние скрипты
Both Have Access to W3C API Оба контекста имеют доступ к W3C API

Локальный контекст позволяет обращаться к Windows Runtime, а также к любым ресурсам, включенным в пакет приложения (например, к HTML, скриптам, CSS и данным приложения, хранящимся в каталогах его состояния), но из него недоступен удаленный HTML, JavaScript или CSS (как в предыдущем примере с exercise.js). Приложение верхнего уровня в Windows 8 всегда выполняется в локальном контексте. На рис. 2 ms-appx:// используется для разрешения контента в локальном контексте. Эта схема применяется для ссылок на контент в пакете приложения, выполняемом в рамках локального контекста. Зачастую используется третий слеш (ms-appx:///), чтобы ссылаться на полное имя пакета. Для веб-разработчиков этот подход аналогичен использованию протокола file://, где третий слеш ссылается на локальную файловую систему (file:/// предполагает file://КОМПЬЮТЕР КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ/ вместо file://УДАЛЕННЫЙ КОМПЬЮТЕР/).

Топ-пост этого месяца:  Появились первые жертвы сентябрьского апдейта Google

Веб-контекст позволяет разработчикам использовать удаленный контент в приложениях Windows Store через iframe. Подобно iframe в веб-браузере контент, выполняемый в iframe, не получает доступа к внешним ресурсам, таким как Windows Runtime и некоторые средства Windows Library for JavaScript. (Полный список см. по ссылке bit.ly/PoQVOj.) Предназначение веб-контекста — дать возможность разработчикам ссылаться на сторонние API, например Bing Maps, или извлекать какую-то библиотеку из CDN в свое приложение.

Использование http:// или https:// в качестве источника iframe автоматически преобразует контент iframe в веб-контекст. Кроме того, iframe может быть ресурсом в пакете приложения, когда вы используете ms-appx или ms-appx-web. Если источник iframe ссылается на схему ms-appx://, содержимое iframe выполняется в локальном контексте. Это позволяет встраивать ресурсы пакета приложения в iframe, в то же время сохраняя доступ к функциональности локального контекста (например, Windows Runtime, Windows JavaScript API и др.). Другая схема — ms-appx-web://, позволяющая выполнять контент локального пакета приложения в веб-контексте. Эта схема полезна, когда вам нужно встроить удаленный контент в свою разметку, например добавить в приложение Contoso Health результат поиска местных больниц на основе местонахождения пациента, полученный через Bing Search (от Bing Search API). Попутно отмечу: всякий раз, когда какие-то iframe упоминаются вместе с HTML5, помните, что вы можете использовать атрибут sandbox как дополнительную защиту своего приложения, ограничивая скриптовое выполнение контента рамками iframe. Подробнее об атрибуте sandbox см. по ссылке bit.ly/Ppbo1a.

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

Табл. 1. Схемы с примерами контекста

Схема Местонахождение контента Контекст Пример Когда используется
ms-appx:// Пакет приложения Локальный Загружает контент в iframe, которому нужен доступ к Windows Runtime или полному Windows JavaScript API
ms-appx-web:// Пакет приложения Веб Использует контент из удаленного источника как часть интерфейса приложения Windows Store, например показывает картографический виджет или результаты поиска
http:// Удаленный источник Веб Ссылается на удаленный контент, такой как веб-страница или файл скрипта на другом сервере

К какому контексту принадлежит iframe, зависит от того, как он ссылается на контент. Другими словами, контекст определяется схемой. Подробнее о схемах, применяемых в Windows 8, см. по ссылке bit.ly/SS711o.

Помните сценарий взлома Litware, с которого мы начали этот раздел? Разделение контекстов в Windows 8 поможет ограничить атаку с использованием кросс-сайтовых скриптов веб-контекстом, где злоумышленник не получит доступа ни к Windows Runtime, ни к данным приложения Contoso Health. В веб-контексте нельзя модифицировать локальный контекст. Взаимодействие между контекстами возможно, но вы получаете контроль за тем, какой тип взаимодействия будет осуществляться.

Node.js — Защита кода?

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

Есть ли способ защитить код JavaScript?

Вы можете выполнить это с помощью NativeExtension для node

У вас будет файл boostrap.js , который добавит обработчик расширения для файлов .jse

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

Теперь у вас есть функция NativeExtensions decrypt , которая преобразует исходный код обратно в javascript. Просто создайте процесс создания зашифрованных версий .jse всех ваших файлов и отпустите их для своих клиентов. Они также нуждаются в родном расширении, но теперь вам было немного сложнее изменить код без особых усилий. Вы даже можете сделать родной внутренний звонок и проверить информацию о лицензии, чтобы предотвратить пиратство (помните, что это не остановит пиратство, для этого нет решения).

Просто включите лицензионное соглашение и дайте им исходный код. Возможно, они захотят настроить его.

Чтобы быть предельно ясным, клиентский Javascript (загруженный с удаленного сервера в стандартный веб-браузер) не может быть защищен от просмотра и/или модификации независимо от того, как вы запутываете его с момента восстановления ( «de-obfuscation» ) исходный источник технически тривиален. (Обфускация Javascript — это просто еще один пример широко используемой «неправильной» безопасности «безопасность через неясность».)

Если вы хотите использовать Javascript и Node.js для обеспечения защищенного «продукта» (который в этом контексте является приложением или услугой, требующей установки на сервере, которую ваша компания не контролирует), вы не можете защитить ее либо как единственный доступный вам вариант (обфускация) не обеспечивает такую ​​защиту.

Следует отметить, что даже если ваш продукт предоставляется как исполняемый файл, который не является гарантией, вы можете защитить его интеллектуальную собственность, поскольку любой двоичный файл может быть декомпилирован в понятный формат. В этом случае нам нравится некоторый уровень безопасности, основанный на чрезмерных ресурсах (времени/экспертизе), необходимых для преобразования низкоуровневого машинного кода (как обеспечивается декомпиляцией) в логические конструкции более высокого уровня, используемые современными языками программирования. (Это от того, кто однажды декомпилировал CP/M в понимание своего внутреннего дизайна вручную.;)

Все, однако, не потеряно: если мы предположим, что можно программно защитить интеллектуальную собственность (жюри по-прежнему отсутствует), есть способ обеспечить продукт Node.js безопасным образом, но это не для технически unadventurous, поскольку это потребует существенного рефакторинга исходного кода Node.js(чтобы добавить поддержку криптографически защищенных библиотек и удалить или иным образом защитить — отражение объекта для ваших собственных библиотек).

Поскольку я только что завершил огромный чистый проект Nodejs в 80+ файлах, у меня была такая же проблема, как и у OP. Мне нужна была минимальная защита для моей тяжелой работы, но, похоже, эта основная проблема не была охвачена сообществом OS NPMjs. Добавьте соль к травме. Система шифрования пакетов JXCore была взломана на прошлой неделе в течение нескольких часов, чтобы вернуться к обфускации.

Итак, я создал полное решение, которое обрабатывает слияние файлов, uglifying. У вас есть возможность оставить определенные файлы/папки, а также от слияния. Затем эти файлы копируются в новое местоположение вывода объединенного файла, а ссылки на них переписываются автоматически.

PS: Я был бы рад, если бы люди помогли сделать его еще лучше. Это война между ворами и трудолюбивыми программистами, такими как вы. Давайте присоединимся к нашим силам, увеличим боль обратного проектирования!

нужна идея по защите кода на javascript

Всем привет, нужна идея по защите кода на javascript/
Обфускация не подходит..так как дебагером все равно перехватывается
сейчас продумываю мысль по асимметричному шифрованию.
Задача сделать для енд юзера расшифровку проги нерентабельной, то бишь чтоб дешевле было купить чем нанять программиста который взломает. условная стоимость 300-400 баков.

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

29.09.2011, 23:47

Что должны делать муниципальные предприятия по защите персональных данных и защите информации
Что должны делать муниципальные предприятия по защите персональных данных и защите информации?

stm32f4 использование flash при включенной защите кода
Добрый день! Вопрос такой: у меня во flash контроллера stm32f405 содержатся настройки для.

нужна идея.
как можно выполнить такую процедуру: нужно отлавливать нажатие клавиши контрл или альт(без.

Нужна идея
Всем привет! А также с праздником! Люди, подкиньте идею создание приложения на андроид. Чего вам.

Нужна идея!
Подскажите пожалуйста. . ситуация следующая: есть таблица с наименованиями и кол-вом.

30.09.2011, 09:38 2

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

Далее: код доступен в зашифрованном виде, например, в JSON-формате, мы его грузим, парсим, и запускаем порционно (построчно, блоками) через eval(), перед каждым запуском спрашивая пароль на сервере (ибо хранить в переменной небезопасно) и декодируя листинг. Но тогда непонятно один на всех пароль? Или под каждого юзера свой пароль, а значит и свой зашифрованный листинг? Или у вас будет пароль один, но каждый день разный? Или пароль вводит юзер? Тогда всё проще, но непонятно, почему бы юзеру не продать пароль ещё десятку тысяч пользователей за треть стоимости. Надо привязывать пароль к железу или там сигнатуре браузера.

А вообще, можно придумать способ собрать код и из сегментированного eval(). Достаточно инъекций User JS и не устоит никакая защита. В итоге, в момент исполнения, код всё равно будет в программе в явном виде. Можно, конечно, отправлять серверу все включения js, а он уже будет сравнивать их все с эталоном и если всё ок, только тогда отдавать зашифрованный листинг. Но, подозреваю, это тоже вариант защиты только от «продвинутого пользователя». Единственный 90% вариант защиты — выполнять работу на стороне сервера на серверном языке (10% на взлом сервака). Решайте сами, что важнее — код на JS и хрупкая защита или неудобный для вас серверный вариант, но более надёжная защита.

Если работать прога будет как десктопное приложение. Сделать прогу на HTML/JS, в формате HTA, затем конверировать её в exe, например вот этой прогой (вечный триал) и voila, код недоступен. Но надо разобраться в HTA, предложенная программа, кстати, поможет вам с тем, чтобы убрать контекстные меню, настроить окно и т.д.

А вообще, открывайте код по GNU GPL и просите Donate, может так и выгоднее получится? =)

Создание приложения для шифрования файлов с помощью JavaScript

Безопасность и конфиденциальность — это одни из самых актуальных тем на сегодняшний день. Это заставляет нас еще раз пересмотреть подходы к безопасности. И, как всегда, все зависит от оптимального баланса — удобства и факторов риска. Сегодня мы попытаемся найти формулу их оптимального соотношения.

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

Нет, в серверном коде необходимости не будет, никакая информация между клиентом и сервером передаваться не будет. Чтобы сделать это, мы будем использовать HTML5 FileReader API , и библиотеку шифрования JavaScript — CryptoJS .

Обратите внимание, что приложение будет шифровать не сам файл, а его копию, так что оригинал в любом случае у вас сохранится.

Но прежде чем мы начнем, вот несколько проблем и ограничений, с которыми нам придется столкнуться:

Проблемы и ограничения

Лимит в 1 Мб

Если вы попробуете поработать с демонстрационной версией, то заметите, что она не позволяет шифровать файлы размером более 1 МБ. Я установил такой лимит, потому что атрибут HTML5 download , который я использую для запроса на загрузку файла для шифрования, не слишком хорошо работает с большими объемами данных.

При загрузке больших файлов текущая вкладка в браузере Google Chrome просто зависает, при использовании Firefox вылетает весь процесс браузера.

Способом решить эту проблему могло бы стать использование File System API и запись в нем двоичных данных, но на данный момент это приложение поддерживается только в Google Chrome.

Причем, на скорости шифрования файла размер не сказывается, это проблема только для возможности скачивания файлов.

Как насчет HTTPS?

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

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

Насколько это безопасно?

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

Я использовал алгоритм AES из коллекции, которая, насколько мне известно, безопасна. Для большей безопасности используйте длинные пароли, которые трудно подобрать:

JavaScript File Encryption App

Разметка приложения состоит из обычного документа HTML5 и нескольких блоков, которые разделяют приложение на несколько отдельных экранов. Вы увидите, как они взаимодействуют в разделах JavaScript и CSS данной статьи.

Во время работы приложения только один из блоков выполнения виден на экране. В зависимости от выбора пользователя — шифрование или расшифровка — для элемента тела устанавливается имя класса.

С помощью CSS это имя класса определяет скрываются или выводятся элементы с классами if-encrypt или if-decrypt . Этот простой способ разделения позволяет обеспечить более чистый код, в котором минимально присутствуют элементы интерфейсов:

Выбор файла для шифрования

Код JavaScript

Как я уже упоминал, мы собираемся использовать HTML5 FileReader API ( поддержка ) и библиотеку CryptoJS .

Объект FileReader позволяет нам читать содержимое локальных файлов с помощью JavaScript, но только тех файлов, которые были выбраны пользователем непосредственно через диалоговое окно, предлагающее выбрать файл.

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

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

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

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

При этом никакие данные на сервер на самом деле не пересылаются. Если на то пошло, вам даже не нужен сервер, вы можете просто открыть HTML-файл непосредственно из папки на вашем компьютере, и использовать его как есть.

Ввод пароля

Здесь я опишу только наиболее интересные части CSS-кода, остальное вы можете увидеть в таблице стилей из zip -архива с исходными материалами.

Первое, о чем я хочу рассказать — это стили, которые создают макет и обеспечивают возможность плавного перехода между экранами путем изменения свойства top элемента #stage :

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

Еще одним интересным фрагментом кода являются условные классы, которые значительно упрощают наш JavaScript:

Таким образом, классы шифрования и расшифрования тела приложения управляют видимостью элементов, которые имеют соответствующий класс if-* .

Мы закончили!

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

Или можете записать HTML-код приложения на флешку, вместе с вашими зашифрованными файлами и расшифровать их напрямую, открыв файл index.html .

Данная публикация представляет собой перевод статьи « Creating a File Encryption App with JavaScript » , подготовленной дружной командой проекта Интернет-технологии.ру

Язык JavaScript в файлах PDF, представляющий угрозу безопасности

Acrobat DC и Acrobat Reader DC позволяют настраивать поведение приложений таким образом, чтобы сценарий JavaScript () выполнялся в пределах установленного уровня защиты. Это позволяет ограничить доступ приложений к API-функциям JavaScript и отделить рабочие процессы, для выполнения которых не требуется доступ к этим функциям.

Выберите «Редактирование» > «Установки» (ОС Windows) или «Acrobat DC»/«Acrobat Reader DC» > «Установки» ( Mac OS ).

В области «Категории» в левой части выберите «JavaScript» .

На панели «Безопасность сценария JavaScript» , установите параметры исполнения сценария JavaScript по необходимости.

Включение Acrobat JavaScript

Снимите флажок, чтобы отключить JavaScript полностью или ограничить исполнение сценариев JavaScript через API.

Включить права выполнения сценариев JavaScript для элементов меню

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

Включение глобальной стратегии защиты объектов

Разрешает JavaScript глобально через API или делает доверенными определенные документы, содержащие JavaScripts.

Можно также изменить системные настройки реестра для управления выполнением сценариев JavaScript.

Дополнительные сведения см. в документе Application Security Guide (Защита приложений) на странице www.adobe.com/go/learn_acr_appsecurity_ru.

На посты, размещаемые в Twitter™ и Facebook, условия Creative Commons не распространяются.

Добавить комментарий