Технология блокчейн для веб-приложений

Блокчейн как база данных обладает рядом замечательных свойств, среди которых на обывательском уровне выделяются:

  • невозможность изменить запись в этой базе данных;
  • распределенный характер.


«Почему бы нам не применить эти замечательные свойства к веб-приложениям», - задумались мы, и оказались не единственными. На блокчейн-форумах регулярно поднимается эта тема (например:[1],[2],[3]найдено по поиску за 10 минут), и даже рассматривается экспертами[4].


Считается, что первое свойство позволит обезопасить веб-сайт от взлома, а второе – от DDoS-атак (Distributed Denial of Service – распределенный отказ в обслуживании). Мы разработали технологию блокчейн-сайтов, которая с конца 2018 г. нашла коммерческое применение.


  1. Вектор риска


  1. Киберугрозы


По запросу «как взломать сайт» Яндекс выдаст 45 млн результатов и 750 тыс.видео. Что более интересно, на протяжении 2017-2018 г.г. эту фразу искали от 16 до 26 тыс. пользователей поисковой системы – спрос не иссякает! Да, они найдут сперва «детские» инструкции как пользоваться SQL-инъекциями с помощью программ, загруженных с просторов интернета. Но даже если 5% от этой массы праздно интересующихся продолжат с практическими примерами, мы получим порядка 800-900 человек, которые приступили к тренировкам – а это уже заметное количество и заметный риск, в первую очередь для веб-ресурсов, которые находятся «на виду». Это правительственные сайты, СМИ, поисковые системы, банки, маркетплейсы и «доски объявлений».


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


Например, в сентябре 2018 г. на выборах в Свердловской области была зафиксирована DDoS-атака на сервер Избирательной комиссии[5], но системные администраторы ГБУ «Оператор электронного правительства» не смогли ей эффективно противостоять.


В 2018 г. с мая по декабрь почти 28 млрд попыток злоупотребления учетными данными пользователей зарегистрировала компания Akamai, уточнив, что e-Commerce стала наиболее частотной целью атак (10 млрд)[6].


Сбербанк отметил, что в 2018 г. по сравнению с 2017 г. число DDoS-атак высокой мощности возросло в 1,5 раза[7].


Классифицируем векторы риска.


  1. Взлом веб-ресурса


«Взлом сайта» - понятие аморфное. «Меня взломали» говорят, когда на сайте подменили главную страницу, или когда посетителя веб-сайта переадресуют на страницу с порно, а еще – когда с сайта украли личные данные пользователей – как это было уже с тысячами сайтов по всему миру, включая Facebook, Adobe и прочих. Эти явления, а также иные, могут быть сгруппированы следующим образом, начиная с формы их проявления:

ФормаЦелиСпособыУгрожаемый ресурсСпособы атаки на угрожаемый ресурс
1.Подмена сайта
  • атака на имидж;
  • фишинг (получение паролей, данных платежных карт и т.п., в т.ч. для доступа во внутрикорпоративную сеть);
  • перехват целевых посетителей;
  • перехват траффика;
  • накрутка посещаемости;
  • реклама;
  • редирект на ресурс, копирующий атакуемый ресурс, средствами веб-сервера или скриптов на стороне сервера;
  • перанаправление на ресурс, копирующий атакуемый ресурс, после загрузки страницы (на стороне клиента):
    - внедрение скриптов в верстку (шаблоны);
    - загрузка файлов скриптов;
  • переход по ссылке, копирующей атакуемый ресурс;
  • подменаDNS;
  • перенаправление на ресурс, копирующий атакуемый ресурс, при соединении (со стороны клиента или со стороны ресурса);
  • подмена оригинальной страницы на сервере;
  • внедрение расширений в браузер;
  • файловая система сервера:
    - скрипты интерпретируемых языков;
    - файлы настроек веб-сервера;
    - файлы скриптов, исполняемых на стороне клиента;
  • сетевые устройства атакуемого ресурса;
·DNS;
  • БД:
    - записи БД, загружаемые без обработки на страницы;
    - сервер БД (процесс);
    - клиентский интерфейс СУБД;
  • CMS, допускающие редактирование скриптов и файлов настроек;
  • сетевые устройства пользователя;
  • устройство пользователя;
  • браузер пользователя;

  • кража или подбор паролей к хостингу ((S)FTP,SSH);
  • кража или подбор паролей вCMS;
  • кража или подбор паролей к серверу БД;
  • кража или подбор паролей к клиентскому интерфейсу БД;
  • загрузка файлов на сервер (со стороны посетителя или черезCMS);
  • SQL-инъекции;
  • MITM;
  • подменаDNS;
  • XSS;
  • CSRF;
  • социальная инженерия;
  • взлом сетевых устройств (напр., роутера) клиента;
  • установка расширений на браузер пользователя;
2.Редирект на другие ресурсы (очевидно отличные от основного сайта)
  • атака на имидж;
  • перехват траффика;
  • редирект на ресурс, копирующий атакуемый ресурс, средствами веб-сервера или скриптов на стороне сервера;
  • перанаправление на ресурс, копирующий атакуемый ресурс, после загрузки страницы (на стороне клиента):
    - внедрение скриптов в верстку (шаблоны);
    - загрузка файлов скриптов;
3.Видимая подмена содержимого страниц
  • атака на имидж;
  • перехват целевых посетителей;
  • реклама;
  • продажа ссылочной массы;
  • редактирование или подмена содержимого страниц;
  • вмешательство в верстку (шаблоны);
  • изменение видимого содержимого скриптами на стороне клиента;
  • внедрение расширений в браузер;
4.Внедрение рекламы
  • реклама;
  • эксплуатация траффика;
То же
5.Перехват форм ввода данных
  • кража личных данных;
  • внедрение скриптов, отслеживающих отправку данных, на стороне клиента;
  • внедрение скриптов-кейлоггеров;
  • подмена адреса для отсылки данных;
  • перехват незашифрованного траффика;
  • перехват переменных окружения, доступных в скриптах на сервере;
  • анализ логов (дляGET-запросов);
  • внедрение расширений в браузер;
6.Перехват сессии и данных авторизации
  • кража данных авторизации;
  • перехват незашифрованного траффика;
  • чтениеcookiesскриптами, внедренными в страницу;
7.Перехватcookies
  • кража данных авторизации
  • перехват личных данных
  • мониторинг посещений для построения
  • внедренные скрипты получают доступ к расшифрованнымcookiesв браузере пользователя, которые могут быть использованы далее для повторной авторизации на том же ресурсе, данным статистики крупных ресурсов, и т.п.

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

9.Чтение содержимого базы данных
  • кража персональной информации
  • кража каталогов

  • файловая система сервера:
    - скрипты интерпретируемых языков;
    - файлы настроек веб-сервера;
    - файлы скриптов, исполняемых на стороне клиента;
  • БД:
    - записи БД, загружаемые без обработки на страницы;
    - сервер БД (процесс);
    - клиентский интерфейс СУБД;
  • CMS, допускающие редактирование скриптов и файлов настроек;

10.Замена содержимого базы данных
  • подмена информации на сайте
  • внедрение на сайт скриптов
  • изменение текстов и оформления в видимой области сайта;

11.ХищениеSSLсертификатов
  • имитация домена дляMITM-атак

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


  1. DoS / DDoS


(Распределенный) отказ в обслуживании – один из наиболее распространенных приемов блокировки ресурсов, состоящий в создании такого числа и объема запросов, при котором атакуемый ресурс будет недоступен для обычных пользователей, или по крайней мере доступ к нему будет существенно затруднен. Основные направления атаки:

  • переполнение полосы пропускания – flood-атаки;
  • атаки, нацеленные на захват системных ресурсов (оперативной и (или) физической памяти, ресурсов процессора;
  • атаки, нацеленные на DNS-сервера.


Мощность DDoS-атак измеряется в Гбит/с или числе соединений в секунду. Наиболее известные атаки – на сервис CloudFare (65 Гбит/с) в 2012 г., на Spamhouse (120-300 Гбит/с) в 2013 г.


Считается, что полностью защититься от DoS/DDoS атак невозможно [10].


  1. Угрожаемые ресурсы и способы атаки на них


Суммируя предыдущее, видим, что:

  • взлом, как правило, состоит в загрузке определенных скриптов, которые будут исполняться на самом сервере или на стороне клиента, замене или дополнении содержимого файлов и базы данных информацией злоумышленника, чтении содержимого файлов или базы данных;
  • DoS/DDoS, как правило, состоит в создании нагрузки на один или несколько процессов, что делает их недоступными, или переполнение полосы пропускания интернет-канала.

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


ОбъектАтака при взломеАтака приDDoS
1.АдминистраторДА
2.Браузер администратораДА
3.Сервер системы администрированияДАДА
4.Сервер БДДАДА
5.Сервер веб-приложенияДАДА
6.Сетевая инфраструктура веб-приложенияДАДА
7.Публичная сеть (объекты интернет-инфраструктуры, включаяDNS-сервера)ДАДА
8.Сетевая инфраструктура клиентаДА
9.Устройство клиентаДА
10.Браузер клиентаДА
11.КлиентДА


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


Мы намеренно разделили сервер системы администрирования (3) и сервер веб-приложения (5), хотя в большинстве классических сайтов CMS (content management system) объединена с самим сайтом. В то же время это идеологически различные системы: первая – приватная, вторая – публичная. Первая позволяет изменять содержание веб-ресурса (и в ряде случаев менять верстку и внедрять скрипты, исполняемые на стороне клиента и на стороне сервера). Вторая предназначена для доставки пользователям контента и предоставления им определенных сервисов, в том числе редактировать собственные данные пользователя. И как раз эти данные, а также возможность выполнять действия от имени пользователя, являются наиболее «лакомой» добычей.


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


  1. «Классические» веб-сайты


Мы считаем, что частично за столь существенные риски взлома и DDoSна базовом уровне ответственна сама концепция веб-сайтов. Как правило, веб-ресурс рассматривается как нечто не зависящее от публичной интернет-инфраструктуры (например, DNS), а также – часто – и не зависящее от хостинга. В последнем случае часть моральной ответственности лежит на хостинг-провайдерах, которые в угоду прибыли предоставляют пользователям виртуальный хостинг, самостоятельно его администрируют и позволяют как владельцам и администраторов сайтов, так и веб-разработчикам просто не думать о качестве сетевой инфраструктуры, настроек и администрирования сервера.


«Классический» веб-сайт обслуживают множество процессов. Рассмотрим распространенную конструкцию вебсайта, написанного на языке PHP и размещенного на хостинге под управлением ОС Linux:

  • веб-сервер Apache или связка Nginx+Apache. Веб-сервер Apache через расширение php*.so связан с интерпретатором PHP;
  • сервер баз данных MySQL;
  • почтовый сервер (например, sendmail или Postfix) – как правило, авторы сайтов пользуются функцией PHP mail(), которая требует наличия внешнего процесса;
  • набор PHP скриптов – файлы, сохраненные на жестком диске, и которые интерпретатор PHP должен прочитать с жесткого диска и обработать;
  • набор файлов jаvascript, CSS и изображений, которые необходимо прочитать и передать на сторону клиента при обращении к ним.


Как видим, одно соединение поддерживают суммарно 4 или 5 разных процессов, и их число увеличивается при каждом новом соединении. Каждое соединение сопровождается большим числом операций чтений файлов, перекрестных обращений к разным сервисам, которые занимают оперативную память и требуют ожидания основного процесса, пока не будет получен ответ на промежуточном этапе. Это время ожидания усугубляется тем, что разработчики на языке PHP редко используют многопоточность – хотя соответствующее решение имеется[8]. Как результат, одно соединение обрабатывается очень долго. В хорошем случае это могут быть десятки миллисекунд, но часто время ответа превышает и секунду, и три.


Большое число процессов = занятая память и процессорное время (ведь процессор занят не только тем, что обрабатывает сайт, – существуют еще и поддерживающие процессы).


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


Большое число процессов, которые занимают порты (Apache – 80 + 443, MySQL – 3306, sendmail/Postfix – 25 + если выбранный почтовый сервер поддерживает входящие - 110) создает множественные точки входа для внешних соединений. А т.к. на сервер необходимо загружать скрипты и вообще как-то им управлять – мы имеем FTP или SSH (а часто и то и другое) на 20/21 и 22 портах. Микросервисы, реализованные как программы, могут не требовать собственных портов – но, если они вынесены на отдельные сервера, число портов и сложность перекрестных обращений растет многократно.


«Интерпретируемость» PHP, Python и C# как часто применяемых технологий означает, что каждый раз при обработке обращений клиента следует что-то прочитать с диска и, доверяя этому скрипту, выполнить его. Необходимо также получить данные из СУБД и, точно так же доверяя им, отдать клиенту. И то же со скриптами и файлами оформления, которым предстоит работать на стороне клиента – мы им доверяем и позволяем работать.


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


Отсюда формируются два главных вектора риска:

  • если злоумышленнику требуется добиться неработоспособности сайта – он может:
    • нагружать любой из процессов на сервере, и даже все вместе;
    • использовать ограничение пропускной способности сетевой карты;
  • если злоумышленнику требуется получить доступ к информации в базе данных, использовать веб-ресурс для выполнения «полезной» работы на стороне клиента или на стороне сервера – требуется сохранить необходимые скрипты в подходящем хранилище. Таким хранилищем может быть как файловая система, так и база данных.


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


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


  1. Постановка задачи


Определим круг задач следующим образом:

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


Из этих размышлений у нас родилась идея создать веб-приложения со следующими свойствами:

  1. изоляция CMS от «фронта»;
  2. распределение всего объема входящих соединений между большим количеством устройств, которые будут отвечать посетителю всегда одинаковым образом;
  3. неизменяемость всего набора объектов, составляющих веб-приложение в его «фронте»: скриптов, базы данных, файлов для загрузки и выполнения на стороне клиента, включая:
  4. возможность отслеживания и купирования попыток редактирования таких файлов;
  5. разделение пользовательских данных и данных веб-приложения между разными хранилищами.



  1. Блокчейн


  1. Технология


Договоримся о терминах – и заодно воспользуемся привилегией разработчика в свободе определения понятий.


Технология распределенного реестра (DLT, Distributed Ledger Technology) – это способ хранения информации, при котором цифровые данные имеют множество равнозначных копий и хранятся на множестве географически распределенных устройств. Соответственно, распределенный реестр – база данных, организованная таким способом.


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


Мы понимаем «записи» как структурированную информацию, которую тот или иной пользователь базы данных передал для сохранения в ней – по сути, это транзакции.


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


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


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


  1. Блокчейн для веб-приложений


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


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

  1. значительное количество одновременных соединений с веб-приложением можно распределить среди множества устройств;
  2. существует возможность произвольным образом менять количество таких копий – например, добавлять новые экземпляры веб-приложения и базы данных;
  3. при распознавании атаки – возможность изоляции атакуемых копий от основной сети при сохранении нормального функционирования системы в целом.


Непосредственно блокчейн обеспечивает неизменность хранимых данных. При этом, как правило, неверно понимается само выражение «неизменяемость»: в действительности, на одном или нескольких устройствах данные как раз могут быть изменены. Однако блокчейн располагает встроенными механизмами как для проверки записей, так и для проверки узлов (мы посчитали разумным встроить механизм регулярной проверки образа ноды, который был запущен и находится в оперативной памяти). Используя эти механизмы, возможно строить полезные сервисы, например:

  1. проводить валидацию как непосредственно записей базы данных, так и всех компонентов приложения;
  2. распознать измененные данные и компоненты, прекратить их использование и автоматически восстановить первоначальное состояние;
  3. распознать вмешательство в процесс ноды и, как минимум, прекратить его участие в работе блокчейна.



  1. Блокчейн-сайты


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


Технология блокчейн-сайта предусматривает:

  • прием входящих соединений на специальный балансирующий узел, который ведет учет нагрузки на множество идентичных экземпляров веб-сайта, а также отслеживает случае не разрешенного их изменения. Этот «балансировщик» может быть объединен с DNS-сервером, работающим по технологии DNSSEC, для купирования рисков атаки на DNS-серверы. Таких «балансировщиков» предусматривается несколько в блокчейн-сети, они не читают входящие данные и обеспечивают (текущая версия, по результатам нагрузочного тестирования) свыше 30,000 соединений в секунду независимо от объема входящего траффика;
  • доступ к CMS и загрузка исходных файлов веб-приложения на доверенной ноде блокчейн-сети через интерфейс, доступный только на локальной машине (через localhost). Этот узел блокчейн-сети выпускает транзакции, которые затем добавляются в блоки и распространяются по всей сети;
  • специализированные блокчейн-узлы, на которых размещаются публичные копии веб-сайта, принимают транзакции, определяют, какие из этих транзакций содержат изменения для размещенных на данной ноде сайтах, и производят обновления;
  • публичные ноды принимают только соединения от «балансировщика», блокируя прочие соединения. Они также могут вносить такие недоверенные соединения в бан-лист, пресекая попытки многократного использования скомпрометированных (подозреваемых в DDoS или попытке взлома) клиентов;
  • на всех нодах предусматривается отказ от приема входящих соединений из публичной сети на порты, помимо портов веб-сервера, так же обеспечивая бан скомпрометированных клиентов.


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


Веб-приложение может быть выполнено как:

  • часть блокчейна (компилируемая библиотека, в настоящее время мы выполняем такие проекты на C++; 1 блокчейн-нода в таком случае на нагрузочных тестах обслуживала 12,000 соединений в секунду);
  • содержимое записи в блокчейне (веб-сайт, разработанный на интерпретируемом языке (PHP или Python), со всеми скриптами, файлами оформления и содержания, дампом SQL сохраняется в блокчейне). В этом случае на устройстве с узлом блокчейна может быть автоматически развернута требуемая инфраструктура (напр., Nginx+Apache, MySQL, PHP). Программное обеспечение блокчейн-ноды обеспечивает автоматическое управление этой инфраструктурой.


Варианты представлены в таблице:

Тип блокчейна:ПриватныйПриватныйПубличныйПубличный
Технология веб-приложенияКомпилируемоеИнтерпретируемое с веб-серверомТо жеТо же
Хранилище:



Компонентов системы администрированияНа доверенных узлахТо жеТо жеТо же
Компонентов веб-приложенияНа узлах с публичным доступомНа узлах с публичным доступомВ сети публичного блокчейн-хостингаВ сети публичного блокчейн-хостинга
Данных приложенияНа всех узлахНа всех узлахВ сети публичного блокчейн-хостингаУ пользователя
Данных пользователяНа доверенных узлахУ пользователяНа доверенных узлахУ пользователя


Вариант компилируемого веб-приложения позволяет обеспечить высокую производительность по сравнению с «классическими» технологиями, проверку соединений на уровне ядра и жестко ограничить объем принимаемого траффика. Этот вариант имеет недостатки – сложность разработки и необходимость тщательно проектировать все функции, о которых даже не привыкли задумываться разработчики на PHP, Python и C#. Веб-ресурсы, переносимые на блокчейн-технологию с использованием компилируемого приложения, потребуют переписать их полностью. В то же время, мы считаем именно этот подход наиболее верным в плане безопасности, поскольку он позволяет инкапсулировать веб-сайт напрямую в блокчейне и предусмотреть тщательный мониторинг событий на публичном сервере.


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

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



Ссылки

  1. Как создать сайт или приложение на blockchain? -https://toster.ru/q/486393
  2. Интернет сайты в блокчейне -https://bitcointalk.org/index.php?topic=2062667.0
  3. [BOUNTY] 3% up to $ .5 mlnA BLOCKCHAIN-POWERED USER-CENTRIC WEB 3.0 PLATFORM -https://bitcointalk.org/index.php?topic=2897802.0
  4. Is Blockchain suitable for web applications? -https://www.quora.com/Is-Blockchain-suitable-for-web-applications
  5. Чайников дал Тунгусову преимущество над областной властью -https://m.ura.news/articles/1036276202
  6. Хакеры занялись торговлей -https://www.kommersant.ru/doc/3897106
  7. «КИБЕРПРЕСТУПНИКИ ЧАЩЕ ВЗЛАМЫВАЮТ НЕ IT-СИСТЕМУ, А ЧЕЛОВЕКА» -http://marrket.org/novosti/kiberprestupniki-chasche-vzlamyvayut-ne-it-sistemu-a-cheloveka
  8. Многопоточные вычисления в PHP: pthreads -https://habr.com/en/post/300952/
  9. Jaeger Opentracing и Microservices в реальном проекте на PHP и Golang - https://habr.com/ru/company/carprice/blog/340946/
  10. Поиск и редактирование значений в памяти сторонней программы на C++ -https://habr.com/en/post/93437/
  11. Криминалистический анализ слепков оперативной памяти -https://xakep.ru/2013/11/16/forensic-ram-ringerprints/
  12. DoS-атака -https://ru.wikipedia.org/wiki/DoS-атака



блокчейн блокчейн сайт применение блокчейна блокчейн для веб приложений

Курс криптовалют онлайн

Официальные курсы Нацбанка Казахстана
Ежедневные курсы валют в Республике Казахстан