По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
FTP расшифровывается как File Transfer Protocol, или протокол передачи данных. Это сетевой протокол/протокол обмена данными, благодаря которому файлы передаются между компьютерами через сеть TCP/IP (протокол управления передачей/интернет-протокол).
Примеры сетей TCP/IP:
HTTP (протокол передачи гипертекста)
HTTPS (протокол защищенной передачи гипертекста)
FTP (протокол передачи файлов)
Как работает протокол передачи файлов?
Для обмена файлами между компьютерами через FTP необходимо открыть FTP-сервер (о том, что это такое, ниже).
В зависимости от типа посещаемого сервера, для доступа к файлам вас могут попросить ввести имя пользователя и пароль. Соединения с сервером, которые не запрашивают авторизации до открытия доступа к файлам, называются анонимными FTP.
Как только пользователь успешно открыл/авторизовался на FTP-сервере, он может скачивать или загружать файлы на сервер.
Получить доступ к FTP-серверу можно одним из нижеприведенных способов:
Через веб-браузер. Вы можете напечатать адрес сервера в своем браузере. Он будет выглядеть примерно так: ftp.myftpfiles.com или https://www.myftpfiles.com. Оказавшись на сервере, вы можете работать с файлами, которые загрузил туда их владелец.
Через FTP-клиент
Что такое FTP-клиент?
FTP-клиент – это программное обеспечение для соединения между запрашивающим доступ компьютером и сервером, на котором хранятся файлы.
Существует великое множество различных FTP-клиентов. Они предлагают графический пользовательский интерфейс (GUI), с которым можно взаимодействовать.
Ниже показано, как выглядит FTP-клиент, и как им пользоваться. Мы будем работать в FileZilla.
В изображении выше видны текстовые поля. Адрес сервера вводится в текстовое поле Host. Текстовые поля Username и Password нужны для серверов, которые открывают доступ к файлам только после авторизации. Текстовое поле Port обычно имеет значение 21. Это специальный порт для FTP. После заполнения всех необходимых полей вы можете нажать Quickconnect и подключиться к серверу.
В левой части приложения есть local site, то есть мой компьютер со списком существующих директорий. Справа – Remote site, то есть место, где показывается вся информация и файлы на сервере.
Что такое FTP-сервер?
По сути, FTP-сервер – это компьютер, на который изначально загружались файлы. У каждого сервера есть FTP-адрес. Пользователь может открыть FTP-сервер через TCP/IP в браузере или через FTP-клиент.
Сервер позволяет посетителю загружать и скачивать файлы.
Безопасны ли FTP-сервера?
Хоть многие FTP-серверы и требуют авторизации, они не считаются защищенными, поскольку в протоколе отсутствует шифрование. Из-за этого повышается вероятность того, что доступ к файлам на FTP-сервере получат сторонние или нежелательные лица.
Самый предпочтительный и безопасный протокол для FTP – это SFTP (Secure File Transfer Protocol - защищенный протокол передачи данных). Это как HTTP и HTTPS.
SFTP считается более безопасным, поскольку данные на сервере зашифрованы.
К альтернативным вариантам относятся:
FTPS (File Transfer Protocol Secure)
HTTPS (Hypertext Transfer Protocol Secure)
AS2 (Applicability Statement 2)
Плюсы использования FTP
Вот несколько плюсов от использования FTP:
более быстрая передача файлов
поддержка многими хостами
возможность передачи больших файлов
возможность запланировать передачу файлов
возобновление передачи файлов после прерывания
Минусы использования FTP
Есть ряд минусов при использовании FTP:
FTP-серверам не хватает безопасности
основные браузеры (Chrome и Firefox) больше не поддерживают FTP
файлы и учетные данные пользователей не зашифрованы
на некоторых серверах могут присутствовать вредоносные файлы
Заключение
В данной статье мы поговорили о протоколе передачи файлов, который позволяет нам обмениваться файлами между компьютерами внутри сети.
Мы разобрали, что такое FTP-клиент и FTP-сервер. Кроме того, рассказали, почему FTP-серверы считаются незащищенными и предложили ряд более «безопасных» альтернатив. И, наконец, мы рассмотрели плюсы и минусы использования FTP.
Какое будущее ждет нас в контакт центрах с точки зрения кастомер сервис (клиентского сервиса)? Как компании создают новые пространства для коммуникации со своими потребителями? Будем говорить про чат боты - будущее клиентского сервиса.
На цифрах, кейсах, исследованиях, в том числе социальных, постараюсь рассказать о том, почему в контакт центрах будущего, живых операторов будет меньше, а VoIP (классические телефоны) и CTI (интеграция компьютерных приложений и телефонии) отойдет на второй план.
Посмотреть доклад
Чат - боты это определенно хайповая история, несмотря на то, что сам хайп сейчас немного поугас. Компании абсолютно разного уровня внедряют чат - ботов: от больших банков, где чат бот органично вписывается в ИТ экосистему и помогает сократить косты на операторов и снизить их загрузку на рутинные операции до маленьких компаний, e-commerce или туристических фирм, где смысл чат - бота скорее сводится к тому, чтобы показать уровень технологичности на ряду с более "аналоговыми" конкурентами.
Посмотрим на крупных игроков IT рынка, которые уже бороздят просторы ML/AI в поиске способа доставить счастье своим пользователям, среди них как Zero UI решения, которые вовсе не имеют привычного интерфейса, так и уже вполне рабочие чат боты:
Алиса - умный помощник от Яндекс. Это мозги, которые живут почти во многих приложениях Яндекса и в хардварных устройствах. Кстати, по данным Яндекса, в приложении поиска доля голосовых запросов на октябрь 2018 года была 20%.
Помимо пользовательских сценариев, Алиса сможет решать конкретные бизнес задачи по клиентскому обслуживанию клиентов вашего контакт центра, как автоматизированном режиме, так и в режиме диалога с оператором. Это реализуется с помощью платформы Яндекс.Диалоги - легкий способ связать жителя экосистемы Яндекса с вашим бизнесом, так сказать, не отходя от кассы. Кстати, количество активных пользователей алисы в месяц (MAU) 35 млн. - подумайте, сколько из них ваших потенциальных или текущих клиентов.
Про Amazon и их разработки. Вы наверное слышали про виртуальный ассистент Alexa. Внутри алексы используются алгоритмы Amazon Lex
А так как Amazon научился монетизировать свои технологии как никто другой, то они продают Amazon Lex в видео фреймворка (интерфейса) для создания приложений - как голосовых так и текстовых, в которых используются алгоритмы понимания естественных языков (NLU), и распознавания речи ASR. О первых я расскажу подробнее в конце статьи.
Фреймворк, как заявляют ребята с Амазона, в контексте контакт центров классно подходит для рутинных операций - смена пароля, баланс, встреча с представителем компании и некоторые другие.
Бот помощник Олег от банка Тинькоф. Бот помогает управлять кредиткой или дебетовой картой или заказать финансовые документы, снижая нагрузку на живых операторов и помогает закрыть пользовательские сценарии, купить билеты в кино и забронировать столик в ресторане.
Тут можно отметить 2 самых очевидных пункта, которые дает бот:
Ретеншн (вовлеченность) пользователей. Экосистема с элементами фана повышает вовлеченность к бренду и втягивает пользователей в экосистему. Билеты в кино, скидки, столики, переводы, а еще и голосом с ботом, который может ответить что то смешное или даже грубое, что насмешит друзей и спровоцирует цепочку рассылки диалога друзьям. Из этого вытекает следующий пункт:
Виральность - распространяемость контента. На старте бот Тинькоф отвечал пользователям весьма неоднозначно. Например, на старте, попросив "сотку" у банка вы рисковали получить неплохую ответочку:
Этот ответ массово распространился по социальным сетям. Это и есть та самая виральность.
Вообще много мнений и обсуждений, касаемо чат ботов: начиная от того, что рынок еще не готов и сама технология бесполезна, заканчивая тем, что люди не любят общаться с чат ботами. Если два первых барьера мы с вами обсудили, то про второй я хочу поговорить немного подробнее.
Блок про поколение Z - почему он в соц. сетях и не любит голос
Впервые в истории, в 2011 в UK заметили, что объем телефонных звонков упал на 10%. При более детальном анализе было обнаружено, что максимально влияющая на падение показателя когорта пользователей - это люди 16 - 24 лет, которые предпочитают текстовую коммуникацию.
К обеспокоенности провайдеров, масла в огонь подлил государственный медиарегулятор Ofcom (управление по коммуникациям), отчитавшись - 96% британцев в возрасте 16 - 24 используют текстовые сообщения каждый день.
Итак, кто эта группа - 16 -24? Условно говоря, это люди рожденные после 1995 по 2012 года, и поздние Z - рожденные после 2000.
Частично, тенденции к цифровизации и ухода в онлайн начали проявляться и у Миллениалов или, как принято их называть Поколение Y. Это люди рожденные с 1981 и до 1996 года.
Несколько факторов, которые характеризуют поколение Z:
Поколение Z очень целеустремленны. как пишут в исследованиях, это, "most success oriented". Взросление в процессе рецессии, войны, террористических атак, трудные времена на территории РФ. Зачастую, им приходилось наблюдать за борьбой родителей в трудные времена. Масла в огонь подливали миллениалы, полностью зацикленные на карьере.
Настроение на успех на выходе дает следующий пункт, пусть и сомнительный - многозадачность.
Многозадачность. Поколение Z чувствует себя спокойнее, выполняя несколько задач одновременно. Запостить фотографию в инстаграм, написать друзьям, почитать новости на медузе, сделать фильтра в снэпчате, погонять слова в скаенге. Мы не говорим об эффективности подобных активностей (которая по моему мнению, околонулевая), мы говорим про сам посыл.
Тут и возникает важный нюанс - в контексте решения многозадачности, Z, решая свои вопросы с компанией, у которой они берут услугу, предпочтут отправить сообщение в бот в телеграмме или в приложении и ждать ответа, чем висеть на телефоне, холде, ждать ответа оператора и просто говорить голосом.
Но это не главная причина. Важнейшей является то, что поколение Z нативно вросло в digital.
Нативно в digital. Z находятся в цифровом пространстве полностью. Мессаджинг (текстинг), мемы, фотографии, лайки, обсуждения, снэпчаты - среда, в которой они существуют. И в ней, телефонному звонку, да и голосовой коммуникации в целом остается все меньше и меньше места.
Соответственно, Z ожидают, что диджитал будет окружать их везде - решить проблемы с банком, заказать услугу, купить товар или еду, путешествия и прочее. Не давая им возможности обратиться в диджитал, мы рискуем потерять эту аудиторию.
Существует множество других характеристик, которые прямо или косвенно влияют на стремление Z к цифре:
Конфиденциальность - Z очень ценят свою конфиденциальность. Представьте Z, который едет в полном автобусе, звонит в контакт центр, где его просят назвать кодовое слово? Кажется, он будет слегка сконфужен
Z легко принимают новое
Вот такие они, эти ребята в гучи, суприм и кроссовках на высокой платформе. Давайте закрепим и посмотрим, что об этом думают большие компании.
Пруфы того, что это важно
В феврале 2018 года в Токио консалтинговая компания Гартнер отчиталась - к 2020 году 25% всех клиентских итераций будут происходить через VCA (virtual customer assistant), если переводить дословно - виртуальных клиентских помощников, или чат ботов, в контексте моего доклада и контакт - центра.
Джин Альварез, вице - президент в Гартнер отчитался, что более чем половина крупного энтерпрайза уже начали инвестировать и исследовать виртуальных помощников, в разрезе решения стандартных вопросов с последующей эскалацией сложных на агента. Вот цитата Джина (Gene Alvarez):
"As more customers engage on digital channels, VCAs are being implemented for handling customer requests on websites, mobile apps, consumer messaging apps and social networks"
Перевод:
С погружением клиентов в цифровые каналы коммуникации, все больше VCA (виртуальные клиентские помощники) внедряются для обработки клиентских запросов на сайтах, мобильных приложениях, мессенджерах и соц. сетях"
Это важно, так как мы обсудили ранее, для подрастающего платежеспособного поколения Z - цифровые каналы это нативные вещи.
Помимо прочего, важная цифра: организации, использующие VCA, в среднем, смогли сократить количество звонков, операторских чатов и писем на 70% и срезали косты на телефонию в среднем на 33%. В отчете так же было отмечено увеличение общего уровня удовлетворенности клиентов. Я не стану добавлять это в статью, так как Гартнер поленился рассказать, какие метрики для этого они посчитали и как измерили.
Дальше. Ребята из Juniper Research еще в 2017 году говорили, что чат - боты - гейм чейнджер для банков и здравоохранения.
Джунипер прогнозирует, что количество клиентских взаимодействий с чат-ботами в здравоохранении увеличится с 12% до 75% к 2022 году, а в банковском секторе достигнет 90% к этому времени.
Автор исследования Лоурен Фои (Lauren Foye) объясняет:
"We believe that healthcare and banking providers using bots can expect average time savings of just over 4 minutes per enquiry, equating to average cost savings in the range of $0.50-$0.70 per interaction. As Artificial Intelligence advances, reducing reliance on human representatives undoubtedly spells job losses."
Перевод:
Мы считаем, что банки и компании в области здравоохранения, используя чат- боты могут сэкономить более 4 минут на один клиентский запрос. Это примерно 50 - 70 центов за одну итерацию.
4 минуты на обращении что примерно ровняется $0.5 - $0.7. Лоурен пугает нас тем, что развитие AI (искусственного интеллекта) так или иначе приведет к потере работы многими людьми. Спасибо Лоурен, тебя это тоже коснется.
Кстати, про искусственный интеллект. А точнее про одно из его направлений NLP (Natural Language Processing), или говоря по русски, обработку естественного языка.
Про natural language processing (NLP). Обработка естественного языка
Кратко пробежимся по технологии, которая драйвит эту отрасль. NLP - обработка естественного языка. Это направление породила одна проблема: компьютеры прекрасно справляются со структурированными данными, таблицами, приведенными к единообразию датасетами, но мы с вами общаемся не методами структурами, а словами. Тут и появилась идея научить машины понимать живой человеческий язык.
В рамках решения этой задачи, как и в любой другой задаче машинного обучения, принято разбивать задачу на последовательность подзадач. Это называется пайплайн, он же конвейер процессов, которые необходимо выполнить. Давайте попробуем кратко разобраться на примере текста, взятого из википедии про Лондон:
London is the capital and most populous city of England and the United Kingdom. Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia. It was founded by the Romans, who named it Londinium.
Тут есть несколько сегментов полезной информации про Лондон, где он находится и кем основан.
1. Дробим на предложения
Первый этап пайплайна - дробим текст на предложения. Самое простое - по знакам препинания. Но современные алгоритмы используют более хитрые способы. Вот что у нас получилось:
London is the capital and most populous city of England and the United Kingdom.
Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia.
It was founded by the Romans, who named it Londinium.
Три отдельных смысловых блока. Отлично.
2. Токенизация
Оно же выделение слов. Так как мы уже разбили текст на предложения, берем первое и дробим - алгоритм прост - разбиение по пробелам или знакам препинания
"London", "is", "the", "capital", "and", "most", "populous", "city", "of", "England", "and", "the", "United", "Kingdom", "."
3. Части речи
Теперь смотрим на каждое слово отдельно и понимаем, что это - существительное, глагол, прилагательное или еще что то. Готовые фреймоврки обучены на на миллионах слов и учитывают слова стоящие рядом, для повышения точности определения.
Получаем:
London - имя собственное
is - глагол
the - артикль
capital - существительное
and - союз
most - наречие
populous - прилагательное
4. Лемматизация
Лемматизация (англ. lemmatization) - приведение словоформы к ее первоначальной словарной форме (лемме). По факту, это отсечение окончаний и использование основой формы.
Например, в русском языке словарной формой считается:
существительные - именительный падеж, единственное число (руками - рука)
глаголы - инфинитивная форма (искали - искать)
прилагательные - единственное число, именительный падеж, мужской род (телекоммуникационными - телекоммуникационный)
В NLP лемматизация обычно выполняется простым поиском форм в таблице. Вот что мы получаем:
London - имя собственное (уже начальная форма)
is - глагол (превращается в be)
the - артикль (уже начальная форма)
capital - существительное (уже начальная форма)
and - союз (уже начальная форма)
most - наречие (уже начальная форма)
populous - прилагательное (уже начальная форма)
5. Стоп слова
В нашем примере мы рассматриваем англоязычный фрагмент текста. Поэтому, из него нужно убрать слова, которые создают избыточный шум - артикли, например "and", "the", "a". Обычно, это делается по готовым таблицам.
Снова смотрим на наше предложение:
London - имя собственное (уже начальная форма)
is - глагол (превращается в be)
the - артикль (уже начальная форма)
capital - существительное (уже начальная форма)
and - союз (уже начальная форма)
most - наречие (уже начальная форма)
populous - прилагательное (уже начальная форма)
6. Парсинг зависимостей
Следующим шагом нам важно понять взаимосвязь слов в предложении. Нужно понять, кто является родителем для каждого из токенов (слов) и установить тип взаимосвязи: субъект предложения, свойство, логическая связь, определение и так далее.
В результате мы получаем уже почти готовое дерево связей. Логическим продолжением этого шага является группировка токенов по признакам взаимосвязи.
Было:
London - имя собственное (уже начальная форма)
is - глагол (превращается в be)
the - артикль (уже начальная форма)
capital - существительное (уже начальная форма)
and - союз (уже начальная форма)
most - наречие (уже начальная форма)
populous - прилагательное (уже начальная форма)
Стало:
London
is
the capital
and
most populous city
7. Распознавание именованных сущностей (Named Entity Recognition, NER)
Двигаясь по пайплайну мы подходим к самому интересному, на мой взгляд, шагу - распознавание смысла слов. Вы уже заметили, что в нашем предложении встречаются географические сущности, такие как "London", "England" и "United Kingdom". На этом этапе пайплайна мы пониманием что это географический объект и определяем это, наполняя наш текст смыслом. NER алгоритмы хорошо работают с такими объектами как:
имена людей;
названия компаний;
географические обозначения (и физические, и политические);
продукты;
даты и время;
денежные суммы;
события.
Тут важно отметить, что хорошая NER система это не только словари. Они так же просматривают контекст предложения и окружение каждого конкретного токена. Адекватный NER должен уметь отличить американскую актрису Дакоту Фаннинг от штата Дакота на севере США
8. Разрешение кореференции
Если быть кратким, то это решение вопроса с местоимениями, которые во всем тексте означают тот или иной объект. Вернемся к нашему изначальному тексту, который мы разбивали на предложения
London is the capital and most populous city of England and the United Kingdom. Standing on the River Thames in the south east of the island of Great Britain, London has been a major settlement for two millennia. It was founded by the Romans, who named it Londinium.
Обратите внимание на "It was founded by the Romans, who named it Londinium." Это было основано римлянами. Это? Что это?
Вот и задача для для алгоритмов связать, что Это в данном контексте - это = Лондон.
9. Итог. Полный пайплайн NLP
Итак, подытожим. Чтобы получать смыслы из речи человека текст проходит мощную обработку в конвейере NLP. Помимо прочего, NLP можно юзать и в голосовых технологиях, преобразуя речь в текст в рамках ASR механизмов и снова пропуская через пайплайн NLP.
Суммарно, чтобы читать между строк и получать смысла информация перемалывается через эти 9 шагов (где то их может быть меньше, а где то в другом порядке, например):
Дробим на предложения
Токенизация
Части речи
Лемматизация
Стоп слова
Парсинг зависимостей
Группировка токенов (существительных)
Распознавание именованных сущностей (Named Entity Recognition, NER)
Разрешение кореференции
Кто делает?
Продуктов много. Есть как тривиальные инструменты создания блок - схем (статичных алгоритмов обработки запросов), так и интерфейсы с продвинутым NLP, о котором мы поговорили ранее, есть энтерпрайзные решения, есть и решения для SMB. Не делая рекламы, поговорим про бесплатные решения. Rasa.com
RASA.com
Ребята дают бесплатный фреймворк для быстрого старта. Есть энтерпрайз коммерческие тарифы, которые дадут SLA и не комьюнити бэйзд гарантии. У ребят 0.5 млн загрузок по миру, 3.5 активных участников комьюнити.
Схематично парни из раса.ком обозначили принципы работы их чат бота как на картинке:
Можно попробовать абсолютно бесплатно, дав плечо фреймворку в свои данные.
Итоги
С развитием машинного обучения цифровое будущее становится все ближе и ближе. На руку прогрессу и развитию роботизации в клиентском сервисе играют поколенческие факторы, общие характеристики нового поколения, тренды и даже политическая обстановка. Будьте первыми, будьте актуальными, будьте технологичными и свежими.
Разработчики программного обеспечения должны держать много информации у себя в голове. Существует множество вопросов, которые нужно задать, когда речь заходит о создании веб-сайта или приложения: Какие технологии использовать? Как будет настроена структура? Какой функционал нам нужен? Как будет выглядеть пользовательский интерфейс? Особенно на рынке программного обеспечения, где производство приложений больше похоже на гонку за репутацией, чем на хорошо обдуманный процесс, один из важнейших вопросов, который часто остается на дне “Списка важных”: Как наш продукт будет защищен?
Если вы используете надежный, открытый фреймворк для создания своего продукта (и, если он доступен и пригоден, почему бы и нет?), тогда базовые проблемы безопасности, как атаки CSFR и кодирование пароля, могут быть уже решены за вас.
Тем не менее, быстро развивающимся разработчикам будет полезно освежить свои знания о стандартных угрозах, дабы избежать ошибок новичка. Обычно самое слабое место в безопасности вашего программного обеспечения - это вы.
А кто может заниматься взломом?. Есть этичный хакер – это тот, кто ищет возможные слабости в безопасности и приватно рассказывает их создателям проекта.
А чёрный хакер, которого так же зовут “Взломщик (cracker)” – это тот, кто использует эти слабости для вымогательства или собственного блага.
Эти два вида хакеров могут использовать одинаковый набор инструментов и, в общем, пытаются попасть в такие места, куда обычный пользователь не может попасть. Но белые хакеры делают это с разрешением, и в интересах усиления защиты, а не уничтожения её. Черные хакеры – плохие ребята.
Вот некоторые примеры наиболее распространённых атаках, которые используют слабости в защите: Внедрение SQL-кода и межсайтовый скриптинг XXS.
SQL атаки
SQL-инъекция (SQLi) - это тип инъекционной атаки, которая позволяет выполнять вредоносные SQL команды, для получения данных или вывода из строя приложения. По сути, злоумышленники могут отправлять команды SQL, которые влияют на ваше приложение, через некоторые входные данные на вашем сайте, например, поле поиска, которое извлекает результаты из вашей базы данных. Сайты, закодированные на PHP, могут быть особенно восприимчивы к ним, и успешная SQL-атака может быть разрушительной для программного обеспечения, которое полагается на базу данных (например, ваша таблица пользователей теперь представляет собой пустое место).
Вы можете проверить свой собственный сайт, чтобы увидеть, насколько он восприимчив к такого рода атакам. (Пожалуйста, тестируйте только те сайты, которыми вы владеете, так как запуск SQL-кодов там, где у вас нет разрешения на это, может быть незаконным в вашем регионе; и определенно, не очень смешно.) Следующие полезные нагрузки могут использоваться для тестов:
' OR 1='1 оценивается как константа true, и в случае успеха возвращает все строки в таблице
' AND 0='1 оценивается как константа false, и в случае успеха не возвращает строк.
К счастью, есть способы ослабить атаки SQL-кода, и все они сводятся к одной основной концепции: не доверяйте вводимым пользователем данным.
Смягчение последствий SQL-кодов.
Чтобы эффективно сдержать атаки, разработчики должны запретить пользователям успешно отправлять необработанные SQL-команды в любую часть сайта.
Некоторые фреймворки сделают большую часть тяжелой работы за вас. Например, Django реализует концепцию объектно-реляционного отображения, или ORM с использованием наборов запросов. Мы будем рассматривать их в качестве функций-оболочек, которые помогают вашему приложению запрашивать базу данных с помощью предопределенных методов, избегая использование необработанного SQL.
Однако возможность использовать фреймворк никогда не является гарантией. Когда мы имеем дело непосредственно с базой данных, существуют и другие методы, которые мы можем использовать, чтобы безопасно абстрагировать наши SQL-запросы от пользовательского ввода, хотя они различаются по эффективности. Они представлены по порядку от более к менее важному:
Подготовленные операторы с переменной привязкой (или параметризованные запросы)
Хранимые процедуры
Белый список или экранирование пользовательского ввода
Если вы хотите реализовать вышеприведенные методы, то эти шпаргалки - отличная отправная точка для более глубокого изучения. Достаточно сказать, что использование этих методов для получения данных вместо использования необработанных SQL-запросов помогает свести к минимуму вероятность того, что SQL будет обрабатываться любой частью вашего приложения, которая принимает входные данные от пользователей, тем самым смягчая атаки SQL-кодов.
Межсайтовые скриптовые атаки (XSS)
Если вы являетесь хакером, то JavaScript - это в значительной степени ваш лучший друг. Правильные команды будут делать все, что может сделать обычный пользователь (и даже некоторые вещи, которые он не должен делать) на веб-странице, иногда без какого-либо взаимодействия со стороны реального пользователя.
Межсайтовые скриптовые атаки, или XSS, происходят, когда код JavaScript вводится на веб-страницу и изменяет ее поведение. Его последствия могут варьироваться от появления неприятных шуток до более серьезных обходов аутентификации или кражи учетных данных.
XSS может происходить на сервере или на стороне клиента и, как правило, поставляется в трех вариантах: DOM (Document Object Model - объектная модель документа) на основе хранимых и отображаемых XSS. Различия сводятся к тому, где полезная нагрузка атаки вводится в приложение.
XSS на основе DOM
XSS на основе DOM возникает, когда полезная нагрузка JavaScript влияет на структуру, поведение или содержимое веб-страницы, загруженной пользователем в свой браузер. Они чаще всего выполняются через измененные URL-адреса, например, в фишинговых письмах.
Чтобы увидеть, насколько легко было бы для введенного JavaScript манипулировать страницей, мы можем создать рабочий пример с веб-страницей HTML. Попробуйте создать файл в локальной системе под названием xss-test.html (или любым другим) со следующим кодом HTML и JavaScript:
<html>
<head>
<title>My XSS Example</title>
</head>
<body>
<h1 id="greeting">Hello there!</h1>
<script>
var name = new URLSearchParams(document.location.search).get('name');
if (name !== 'null') {
document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
}
</script>
</h1>
</html>
На этой веб-странице будет отображаться заголовок "Hello!” если только он не получает параметр URL из строки запроса со значением name. Чтобы увидеть работу скрипта, откройте страницу в браузере с добавленным параметром URL, например:
file:///path/to/file/xss-test.html?name=Victoria
Наша небезопасная страница принимает значение параметра URL для имени и отображает его в DOM. Страница ожидает, что значение будет хорошей дружественной строкой, но что, если мы изменим его на что-то другое? Поскольку страница принадлежит нам и существует только в нашей локальной системе, мы можем тестировать ее сколько угодно. Что произойдет, если мы изменим параметр name, скажем, на:
<img+src+onerror=alert("pwned")>
Это всего лишь один пример, который демонстрирует, как может быть выполнена атака XSS. Смешные всплывающие оповещения могут быть забавными, но JavaScript может принести много вреда, в том числе помогая злоумышленникам украсть пароли и личную информацию.
Хранимые и отраженные XSS
Хранимые (stored) XSS возникают, когда полезная нагрузка атаки хранится на сервере, например, в базе данных. Атака влияет на жертву всякий раз, когда эти сохраненные данные извлекаются и отображаются в браузере.
Например, вместо того чтобы использовать строку URL-запроса, злоумышленник может обновить свою страницу профиля на социальном сайте, чтобы внедрить скрытый сценарий, скажем, в раздел “Обо мне”. Сценарий, неправильно сохраненный на сервере сайта, будет успешно выполняться всё время, пока другой пользователь просматривает профиль злоумышленника.
Одним из самых известных примеров этого является червь Samy, который практически захватил MySpace в 2005 году. Он распространялся путем отправки HTTP-запросов, которые копировали его на страницу профиля жертвы всякий раз, когда просматривался зараженный профиль. Всего за 20 часов он распространился на более чем миллион пользователей.
Отраженные (reflected) XSS аналогично возникают, когда введенные данные перемещаются на сервер, однако вредоносный код не сохраняется в базе данных. Вместо этого он немедленно возвращается в браузер веб-приложением.
Подобная атака может быть осуществлена путем заманивания жертвы для перехода по вредоносной ссылке, которая отправляет запрос на сервер уязвимого веб-сайта. Затем сервер отправит ответ злоумышленнику, а также жертве, что может привести к тому, что злоумышленник сможет получить пароли или совершить действия, которые якобы исходят от жертвы.
Ослабление XSS
Во всех этих случаях XSS могут быть сдержаны с помощью двух ключевых стратегий: проверка полей формы и предотвращение прямого ввода данных пользователем на веб-странице.
Проверка полей формы
Фреймворки снова могут нам помочь, когда речь заходит о том, чтобы убедиться, что представленные пользователем формы находятся в актуальном состоянии. Один из примеров - встроенные классы полей Django, которые предоставляют поля, проверяющие некоторые часто используемые типы, а также задают нормальные значения по умолчанию.
Например, поле электронной почты Django использует набор правил, чтобы определить, является ли предоставленный ввод действительным письмом. Если отправленная строка содержит символы, которые обычно не присутствуют в адресах электронной почты, или если она не имитирует общий формат адреса электронной почты, то Django не будет считать это поле допустимым и форма не будет отправлена.
Если вы не можете полагаться на фреймворк, можете реализовать вашу собственную проверку входных данных. Это можно сделать с помощью нескольких различных методов, включая преобразование типа, например, гарантируя, что число имеет тип int(); проверка минимальных и максимальных значений диапазона для чисел и длин строк; использование заранее определенного массива вариантов, который позволяет избежать произвольного ввода, например, месяцев года; и проверка данных на соответствие строгим регулярным формулировкам.
К счастью, нам не нужно начинать все с нуля. Помогут доступные ресурсы с открытым исходным кодом, такой как валидация репозитория регулярных выражений OWASP, который предоставляет шаблоны для сопоставления их с некоторыми распространенными формами данных. Многие языки программирования предлагают библиотеки проверки, специфичные для их синтаксиса, и мы можем найти множество таких библиотек на GitHub.
Хотя это и может показаться утомительным, правильно реализованная проверка ввода может защитить наше приложение от восприимчивости к XSS.
Предотвращение прямого ввода данных
Элементы приложения, которые непосредственно возвращают пользовательский ввод в браузер, при обычной проверке могут быть неочевидны. Мы можем определить области приложения, которые могут быть подвержены риску, изучив несколько вопросов:
Как происходит поток данных через приложение?
Что ожидает пользователь, когда он взаимодействует с этими входными данными?
Где на нашей странице появляются данные? Становятся ли они встроенными в строку или атрибут?
Вот некоторые примеры полезных нагрузок, с которыми мы можем поиграть, чтобы проверить входные данные на нашем сайте (опять же, только на нашем собственном сайте!). Успешное выполнение любого из этих образцов может указывать на возможную уязвимость к XSS из-за прямого ввода данных.
"><h1>test</h1>
'+alert(1)+'
"onmouserover="alert(1)
http://"onmouseover="alert(1)
Как правило, если вы можете обойти прямой ввод данных, сделайте это. Кроме того, убедитесь, что вы полностью понимаете эффективность выбранных методов; например, использование innerText вместо innerHTML в JavaScript гарантирует, что содержимое будет задано как обычный текст вместо (потенциально уязвимого) HTML.
Аккуратнее с вводом!
Разработчики программного обеспечения явно находятся в невыгодном положении, когда речь заходит о конкуренции с черными хакерами. Несмотря на всю проделанную работу по защитите каждого ввода, который потенциально может скомпрометировать наше приложение, злоумышленнику достаточно только найти тот, который мы пропустили. Это все равно что установить засовы на всех дверях, но оставить окно открытым!
Однако, научившись мыслить в том же ключе, что и злоумышленник, мы можем лучше подготовить наше программное обеспечение к противостоянию плохим парням. Как бы ни было интересно добавлять функции как можно быстрее, мы избежим большого количества долгов по кибербезопасности, если заранее продумаем поток нашего приложения, проследим за данными и обратим внимание на наши входные данные.