Коллектив Вебасиста поздравляет всех читателей блога, пользователей WebAsyst  и Shop-Script с Новым 2012 годом, желает плодотворного и богатого на успешные проекты года!

В следующем году наша команда будет работать по насыщенному плану выпуска новых приложений для фреймворка Вебасист, который придет на смену текущего поколения приложения WebAsyst.ru. Ожидаются новые приложения «Блог», «Фото», «Календарь» и многие другие, в том числе платные приложения «Поддержка», «Заказы», «Почта». В этом году мы выполнили всю основную работу по платформе нового Вебасиста, что позволит в следующем году сконцентрироваться на интересных прикладных приложениях. Осенью 2012 мы планируем выпустить новый Shop-Script.

Все основные события, касающиеся Вебасиста, будут освещаться в блоге фреймворка: http://www.webasyst.com/ru/blog/
Подписывайтесь на блог по RSS или в соцсетях Фейсбук и Твиттер.

График работы службы поддержки в новогодние праздники 2011—2012: запросы по электронной почте будут обрабатываться в ограниченном режиме с 31 декабря 2011 по 3 января 2012 включительно. Начиная с 4 января 2012 служба поддержки возобновит работу в круглосуточном режиме.

В нашем новом блоге, посвященном фреймворку Webasyst, появился интересный пост о результатах проведения бонусной акции на «КупиКупоне» интернет-магазином, работающим на основе Shop-Script. Посмотрите:

http://www.webasyst.com/ru/blog/mega-podarki-kupikupon/

Специально для читателей блога: промо-код на 20% скидку на покупку PHP-скриптов Webasyst и Shop-Script: EBJ09V2GSH

Введите этот код при оформлении заказа на скрипты (купон вводится на последнем шаге оформления заказа) — скидка будет рассчитана автоматически. Купон действует только до конца этой недели (до 20 ноября).

Мы опубликовали дополнительные комментарии о проблеме в нашем блоге на Хабре: о том, что это за страницы, откуда мог узнать о них Яндекс, о масштабности проблемы и возможных решениях.

http://habrahabr.ru/company/webasyst/blog/124968/

UPD: А ведь уже проблема прогрессирует — вот и железнодорожные билеты проиндексированы (к Shop-Script это уже отношения не имеет).

В СМИ появилась новость о том, что Яндекс проиндексировал множество страниц с приватными данными пользователей интернет-магазинов аналогично тому, как недавно были проиндексированы СМС-сообщения, отправляемые с сайта Мегафона:
http://www.lenta.ru/news/2011/07/25/eshops/
http://habrahabr.ru/blogs/infosecurity/124898/

Оказалось, что новость касается интернет-магазинов, работающих на основе WebAsyst Shop-Script. Естественно, для нас это стало очень большой неожиданностью, и наше расследование показало следующее: проблема актуальная для магазинов, на страницах которых установлен код Яндекс.Метрики. Далее детально опишу, в чем причина проблемы и как ее разрешить.

Как так получилось?

В интернет-магазинах, работающих на основе WebAsyst Shop-Script, пользователи могут оформлять покупку без обязательной регистрации в магазине, то есть без создания аккаунта с паролем. После оформления заказа пользователю отправляется прямая ссылка на страницу с информацией о заказе и его статусе. Эта ссылка отправляется покупателю на почтовый ящик (и более нигде недоступна, в том числе и администратору магазина). После перехода по ссылке пользователю показывается страница с информацией о совершенному заказе — именно такие страницы и проиндексировал Яндекс. Так как пользователь не зарегистрирован, то у него не запрашиваются логин и пароль (их просто нет), а сразу отображается информация о совершенном заказе. Авторизация пользователя происходит по ключу hash, который фигурирует в ссылке из письма. Получилось так, что пользователь переходил по ссылке, а установленный код Яндекс.Метрики «запоминал» посещенный пользователем адрес и позже включал этот адрес в базу индексируемых адресов. Индексировались только те страницы, по которым пользователи совершали переходы. Если пользователя по ссылке не переходил, то «его страница» не индексировалась.

Ситуация сложилась неоднозначная. С одной стороны мы, разработчики Shop-Script, не предусмотрели того, что приватный адрес может быть проиндексирован поисковиком «сам по себе», считая, что раз адрес отправляется клиенту индивидуально, то в открытых источниках он не будет опубликован и, следовательно, не будет проиндексирован. С другой стороны, поведение сервиса Яндекс.Метрики — добавлять адрес любой посещенной пользователем страницы сайта сразу в основной индекс — мягко говоря, спорно.

Проблема не в отсутствии файла robots.txt (в недавнем случае с Мегафоном именно это было названо основной технической проблемой), а в отправке пользователям по электронной почте ссылок, ведущих на страницы, содержащие их частную информацию. Например, ссылок на подтверждение регистрации — наиболее распространенный случай. Когда такие ссылки сопровождаются авторизацией пользователя по паролю, проблем не возникает, потому что сначала пользователю необходимо все же войти в аккаунт и уже потом видеть свою информацию. В нашем случае страница показывалась сразу, потому что пароля у пользователя не было — ведь заказ оформлялся без регистрации. Наличие robots.txt и каких бы то ни было инструкцией в нем в данном случае не является решением, так как в ссылке может перейти бот не только поисковика, но и любой другой.

Практика доступа к страницам с некоторой частной информацией по прямой ссылке применяется на различных сайтах и сервисах повсеместно, далеко не только в Shop-Script. Например, на сайтах с трассировкой почтовых отправлений, в ссылках, отправляемых пользователю по почте, переход по которым автоматически авторизуют пользователя на сайте (так делает сервис Яндекса «Мой Круг», кстати), и т.д. Очевидно, что данная ситуация с движком Shop-Script была найдена в большей степени в связи с недавним конфликтом проиндексированных SMS-сообщений на сайте «Мегафона» — их случай просто обратил большое внимание на данную проблему. Вероятно, что далее подобные ситуации будут возникать вокруг многих сайтов, сервисов и CMS в интернете, которые работают с частной информацией клиента.

Итак, инструкции по разрешению проблемы для магазинов, попавших в такую ситуацию. Если нижеприведенных инструкций будет недостаточно, мы готовы оказать всяческую оперативную техническую помощь в ее исправлении. Обращайтесь в нашу службу технической поддержки по адресу support@webasyst.ru или по телефону 8 (800) 200-1993, для международных звонков: +7 (495) 663-73-25.

Как исправить?

Данная инструкция написана для интернет-магазинов на основе WebAsyst Shop-Script, на страницах которых установлен код Яндекс.Метрик.

1. Необходимо ввести дополнительную усиленную авторизацию пользователей на просмотр информации о заказе. Для этого либо обновите ваш WebAsyst до версии №304 с помощью WebAsyst Installer (встроенной системы обновлений), либо, если вы не хотите обновлять всю установку, обновите только измененные файлы файлами из этого архива shop-script-update-304-auth-enforced.zip. Файлы из архива необходимо загрузить в папку published/SC/html/scripts/ вашей установки магазина, соблюдая структуру папок внутри архива. Просто замените существующие файлы обновленными. Функционал скрипта эти файлы не изменят — только лишь добавят дополнительную авторизацию пользователя по фамилии (так как пароля в данном случае у пользователя нет).

Архив содержит обновленные файлы, которые при любом переходе по ссылкам вида index.php?order_status=…&orderID=…&hash=… (страницы, «переданные» Яндекс.Метриками общему индексу Яндекса) делает редирект на страницу, адрес которой не содержит уже никаких параметров, и на которой в качестве дополнительной меры авторизации у пользователя запрашивается его фамилия. Если пользователь вводит данные правильно, то только тогда ему показывается страница с информацией о заказе и историей его обработки. (Напомню, что пароля в данном контексте нет, так как пользователь не является зарегистрированным в магазине.)

Это касается только пользователей скриптов Shop-Script. Во всех установках интернет-магазинов на веб-сервисе WebAsyst (*.webasyst.net) мы уже внесли эти изменения.

2. Проверить наличие файла robots.txt в корневой папке вашего сайта. Пожалуйста, обратите внимание на рекомендации по составлению этого файла: http://www.webasyst.ru/support/help/robots-txt.html

Правила, которые необходимо добавить в файл:

Для ЧПУ:

Disallow: /order_status/
Disallow: /order_history/
Disallow: /*ukey=order_status
Disallow: /*ukey=order_history

Без ЧПУ:

Disallow: /*ukey=order_status
Disallow: /*ukey=order_history

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

Перечисленные две меры (рекомендуем выполнить обе) полностью закроют доступ к проиндексированной информации с ваших сайтов, однако не уберут данную информацию из кеша поисковиков. Мы уже обратились в Яндекс с просьбой содействия для решения проблемы и исключения всех проиндексированных страниц из результатов поиска.

Мы понимаем, что часть ответственности лежит на разработчиках Shop-Script, и стараемся реагировать на проблему максимально оперативно. Еще раз повторю, что мы готовы оказывать всяческую оперативную техническую помощь всем пострадавшим интернет-магазинам, работающим на основе WebAsyst Shop-Script. Если у вас есть какие-либо вопросы, незамедлительно обращайтесь в нашу службу поддержки по адресу support@webasyst.ru или по телефону 8 (800) 200-1993, для международных звонков: +7 (495) 663-73-25.

Если в вашем интернет-магазине вы используете Google Analytics, то описанная проблема для вас не актуальна.

В ближайшие дни мы выпустим дополнительное обновление Shop-Script, которое полностью и более основательно устранит описанную проблему.

UPD 26.07 13:40 МСК: Предложено обновленное решение проблемы — см. пункт №1 выше (обновление до версии №304 или замена отдельных скриптов файлами из архива).

UPD 26.07 17:20 МСК: Продолжение обсуждения сложившейся ситуации и дополнительные комментарии с нашей стороны: http://habrahabr.ru/company/webasyst/blog/124968/

UPD 26.07 18:30 МСК: Как я и говорил в тексте поста, проблема прогрессирует — вот и железнодорожные билеты проиндексированы (к Shop-Script это уже отношения не имеет). Я знал, что это только начало подобных проблем, но не думал, что проявляться это станет настолько быстро.

UPD 29.07: Мы связались с Яндексом по поводу удаления из общего индекса проиндексированных страниц с информацией о заказах пользователей магазинов. Насколько это было возможно, проиндексированные страницы были удалены из индекса. Однако, для некоторых магазинов проиндексированные страницы все же остались в индексе.

Проверить, есть ли для вашего магазина какие-либо страницы с информацией о заказах в кеше Яндекса, можно с помощью поискового запроса site:YOURDOMAIN.ru inurl:order_status hash

Если какие-то из страниц остались, воспользуйтесь инструмент Яндекса.Вебмастер http://webmaster.yandex.ru/delurl.xml

Сегодня, 7 июня 2011, мы выпускаем новый продукт — PHP-фреймворк Вебасист! Это большой шаг вперед для всех сегодняшних продуктов Вебасиста и, наверное, самый значимый выпуск за всю историю компании.

www.webasyst.com

Новый Вебасист — это открытая платформа для создания веб-приложений с бекендом. Вебасисту всегда не хватало открытости платформы разработки и «рельс», по которым можно было бы быстро разрабатывать приложения. Именно с этой целью мы и создали открытый фреймворк. Фреймворк написан полностью с нуля. Разработка велась полтора года. Так что для нашей команды сегодняшний выпуск — это особенно приятный и волнительный момент.

Фреймворк Webasyst — это  проект, который будет развиваться параллельно существующим WebAsyst.ru и Shop-Script, и постепенно существующие приложения перейдут на новую технологию. Все подробности перехода есть на новом сайте.

Ну и немного информации по поводу нового Shop-Script, чтобы подкрепить интерес ко фреймворку: новый Shop-Script будет работать на базе фреймворка, будет правильно спроектирован, полностью продолжая MVC-парадигму построения фреймворка и реализуя гибкую модульную структуру. Новый Shop-Script будет выпущен в 2012 году.

Добро пожаловать на сайт нового Вебасиста: www.webasyst.com

Выпущено обновление WebAsyst до версии №302, в которой обновлена система безопасности. Доработана проверка данных, которая исправляет возможность чтения файлов в установке Вебасиста на сервере.

ВАЖНО: Мы настоятельно рекомендуем обновиться до последней версии всем пользователям скриптов Вебасиста. Все установки веб-сервиса Вебасиста уже обновлены.

UPD: Если на вашем сервере установлена модифицированная установки WebAsyst (вы меняли скрипты) или по какой-то причине не желаете устанавливать обновление через «Инсталлер», пожалуйста, обратитесь в службу поддержки за инструкциями по обновлению только системы безопасности WebAsyst — вам отправят инструкции и архив только с модифицированными файлами, которые необходимо просто отдельно загрузить на сервер. Инструкции будут отправлены только зарегистрированным пользователям скриптов WebAsyst с действующей лицензией.

UPD 2: Во всех установках скриптов на хостинге WebAsyst (ранее — Архост) файлы, входящие в обновление №302, заменены. Пользователям хостинга WebAsyst обновляться не обязательно.

UPD 3: Спасибо http://www.free-lance.ru/users/Lettex за помощь в поиске недостатков в системе безопасности.

Представляем специальное весеннее предложение:

10% скидка на Shop-Script и WebAsyst Поддержка

15% скидка на комплект “Электронная коммерция”

20% скидка на комплект “Электронная коммерция Плюс”

Предложение действует с 15 по 31 марта включительно и распространяется на покупку первой и всех последующих лицензий. Спешите купить скрипты WebAsyst, пока действуют скидки.

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

Для чего вообще нужна такая проверка? Ведь, если деньги получены, то вполне логично просто предоставить заказчику оплаченный товар или услугу. Однако нельзя забывать о том, что мошенник может предоставить украденные платежные данные другого человека, в результате чего денежные средства списываются со счета жертвы, а мошенник получает доступ к товару или услуге, за которые сам ничего не заплатил. Человек, чьи платежные данные используются для такой «покупки», вправе обратиться в свой банк с требованием вернуть денежные средства на свой счет.

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

Статистика

Ниже приведены собранные нами данные об обработке заказов, оплаченных с помощью пластиковых карт за последние 5 лет:

• 6,17% (1048 из 16973) заказов вызвали подозрение, и заказчикам были отправлены запросы на подтверждение платежа.
• Более 46% (486 из 1048) подозрительных заказов действительно оказались мошенническими. В их числе есть некоторый процент реальных заказчиков, которые отказались отправлять копии документов. Некоторые из таких клиентов впоследствии пишут письмо в нашу службу поддержки и объясняют причину отказа. Однако большинство из тех, кто не ответил на запрос — вероятнее всего, действительно мошенники, пытавшиеся оплатить заказ по чужой карте.
• Почти 2% (11 из 562) заказов, для которых клиенты подтвердили платеж, тем не менее стали причиной возврата средств. Это весьма интересная группа заказчиков, в которую входят либо мошенники, имеющие на руках чужую карту или ее изображение, либо так называемые «чарджбек-мошенники». Такие «заказчики» оплачивают и получают товар (обычно нематериальный, например, программное обеспечение), после чего направляют в свой банк требование возврата денег, заявляя что их карта якобы была использована третьими лицами (мошенниками). Один из способов борьбы с чарджбек-мошенниками — это сохранять информацию о доставке оплаченного товара заказчику. Если точно известно, что заказчик получил оплаченный товар, и есть документальное подтверждение этого факта, продавец в большинстве случаев может обоснованно оспорить чарджбек и вернуть деньги.
• 0,67% (107 из 15925) заказов были отгружены без запроса копий документов заказчиков, которые на деле оказались мошенниками. С такими преступниками бороться сложнее всего, т. к. их платежи очень похожи на транзакции, сделанные реальными заказчиками. С накоплением опыта обработки заказов доля таких заказов постепенно уменьшается, и с их наличием пока приходится мириться как с неизбежным следствием лояльного отношения к заказчикам.

Как происходит проверка

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

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

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

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

1. Стоимость заказа. Если из ассортимента нашей продукции оплачен самый дорогой товар, велики шансы того, что мошенник пытается оплатить его за чужой счет.
2. IP-адрес плательщика. С помощью специальных онлайн-сервисов мы проверяем, какой стране соответствует IP-адрес, с которого выполнена оплата. Всегда подозрительно, когда страна проживания заказчика не совпадает с названием страны, из которой пришел платеж.
3. Время оплаты. Когда известна страна, автоматически становится известным предположительный часовой пояс плательщика. Крайне редко реальный заказчик оплачивает товар или услугу в 3—4 часа ночи. Как правило, платежи выполняются в светлое время суток или, как минимум, до полуночи.
4. Адрес электронной почты. Если почтовый адрес заказчика создан с помощью бесплатного сервиса и до символа @ содержит бессмысленный набор символов, это верный признак попытки мошеннической оплаты. Если же адрес создан на доменном имени существующего сайта и имеет вид sales@…, payment@… и т. п., как правило, это сотрудник реально существующей компании, и вероятность мошенничества в таком случае минимальна.
5. Количество попыток оплаты. Если мошенник ранее пытался оплатить заказ, но ему это не удалось, то мы видим в истории платежей такие неудачные попытки. Даже если после нескольких попыток оплаты с нескольких банковских карт одна транзакция все же будет принята процессинговым центром, мы считаем своим долгом дополнительно убедиться в том, что имеем дело не с мошенником.
6. Наличие запросов в службу поддержки. Если заказчик «вдруг» решил купить что-то, не задав ни одного вопроса службе поддержки (а ведь некоторые делают это, как минимум, чтобы убедиться в наличии и оперативности службы поддержки продавца!), это бывает подозрительно, особенно в совокупности с несколькими другими факторами, перечисленными выше.
7. Наличие информации о компании, указанной заказчиком. Если заказчик во время оформления заказа сообщил название своей компании, мы выполняем поиск дополнительной информации в интернете, чтобы найти подтверждения связи человека с таким именем и данной компании (организации). Если таких подтверждений найти не удается, то платеж попадает в категорию подозрительных.

Вывод

В качестве итога подчеркну, что, если бы проверка платежей не выполнялась, мы имели бы 604 случая чарджбека, что составляет 3,56% от общего числа заказов, оплаченных банковской картой (16973). Это более чем в пять раз превышает фактическую долю чарджбеков — 0,7% (т. е. 118 из 16973). Главный вывод отсюда — проверка электронных платежей обязательна, т. к. позволяет интернет-продавцам обезопасить себя от затрат, связанных с выплатой штрафов, и опасности отказа от приема платежей банковскими картами со стороны банков-эквайеров и международных платежных систем.

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

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

Первым «бойцом» на пути спама выступает наш почтовый сервер, который уже на этапе предварительной обработки отвергает более 90% писем! На сервере выполняется многоэтапная фильтрация. Начинается все с проверки IP-адреса отправителя на предмет его отсутствия в черном списке спамеров и наличия корректной DNS-записи на почтовом сервере отправителя. Затем заголовки писем проверяются на соответствие стандартам RFC, а также проверяется фактическое наличие адреса отправителя на данном почтовом сервере. Затем выполняется проверка содержимого письма на принадлежность к спаму. В случае получения отрицательных результатов хотя бы на одном из этих этапов проверки почтовый сервер отвергает сообщение и возвращает на сервер отправителя соответствующий код ошибки.

Не все сообщения, прошедшие спам-фильтр почтового сервера, являются реальными запросами клиентов. Согласно нашей статистике за последние три месяца (с 25 августа по 25 ноября 2010 г.), успешно прошли спам-фильтр почтовика 9324 сообщения; из них только 3056 (примерно треть) были подтверждены отправителями, а почти 6000 запросов остались неподтвержденными:

Что означает строка «не подтверждены отправителем»? Это результат работы дополнительного внутреннего спам-фильтра в нашей системе приема и обработки запросов — приложении WebAsyst Поддержка. Он работает следующим образом: каждый раз при получении сообщения с адреса, который не зарегистрирован в системе, автоответчик отправляет в ответ сообщение с просьбой подтвердить отправку запроса. Для подтверждения необходимо перейти по специальной ссылке, которая присутствует в тексте автоматического ответа. Такое действие для каждого почтового адреса нужно выполнить только один раз, после чего такой адрес становится зарегистрированным в нашей базе данных. Все последующие сообщения с этого адреса пройдут «мимо автоответчика» и не потребуют подтверждения.

Из таблицы выше видно,  что большинство сообщений, дошедших до нашей базы данных (а именно 5939 из 9324, т. е. примерно 64%) не были подтверждены отправителями, так как тоже являются спамом. Обратите внимание на то, что 329 сообщений были удалены операторами. Это такие сообщения, которые либо были  подтверждены отправителем, либо пришли  с ранее зарегистрированных (т. е. подтвержденных) адресов, но тем не менее были вручную классифицированы оператором как спам! Что делать, бывает и такое.

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

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

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

В таблице ниже показана наша статистика для всех трех способов приема запросов за три месяца. В колонке «Email» данные показаны в сравнении с аналогичными характеристиками для двух других способов приема запросов: веб-формой и личным кабинетом.

Для эффективной защиты от спама при приеме электронных запросов используйте следующие приемы:

1. Предоставьте всем клиентам защищенные личные кабинеты, из которых они смогут писать вам запросы — это почти 100%-ная защита от спама.
2. Разместите на своем сайте веб-форму с «капчей», через которую будут отправлять запросы незарегистрированные клиенты.
3. Если необходимо получать запросы по электронной почте, настройте спам-фильтр на почтовом сервере и в дополнение к этому используйте отправку авто-запроса на подтверждение для новых клиентов.