С чего начинается работа с приложением, ботом или сайтом? Ответ прост — с регистрации пользователя в вашей системе.
В этой статье я расскажу, с какими неочевидными проблемами мы столкнулись при разработке регистрации в ботах, сайтах и приложениях. Простая на первый взгляд операция может принести существенные проблемы, если не учитывать некоторые нюансы.
Кажется, что может быть проще регистрации? Сделал стринговую переменную с ФИО, закрыл дело и пошел писать настоящий функционал. Но не тут-то было.
С вероятностью 90%, если вы сделаете так, то поначалу все будет хорошо работать, однако через некоторое время могут возникнут проблемы. Вы посмотрите в свою БД и обнаружите огромное количество мусора вместо данных, а в худшем — вы найдете свою базу в открытом доступе на всяких сомнительных форумах.
Почему это произошло?
Во-первых, никакой мотивации давать вам свои реальные данные у пользователя нет, например, в стиме 93% пользователей родилось 1 января. Объясняется такая аномалия очень просто — первый день в году стоит по умолчанию в форме выбора даты рождения и, конечно, пользователь не тратит свое время на выбор реальной даты, а просто жмет кнопку ОК и идет качать игры. И получается, что эти данные просто мусор и никакой адекватной аналитики сделать не получится. Почему это плохо, я не буду тут писать, вы все сами понимаете. Ну, а второе — просто безопасность, но об этом я расскажу чуть позже.
У нас есть проблема и нам надо ее решать. Как всегда, нужно использовать кнут и пряник для баланса. Как накормить кондитерским изделием — это задача вашего продукта, потому что для каждого случая все уникально. А вот кнут достаточно стандартный и универсальный для всех проектов.
Регулярные выражения
Очевидным решением будет проверять на адекватность данные, которые пишет пользователь. Есть всякие исключения, но, как правило, людей не зовут "X Æ A-12". Поэтому можно смело внедрять регулярные выражения и прогонять через них данные от пользователя.
Какие конкретно регулярки ставить решать только вам, для каждого проекта, повторяюсь, свое решение. А далее поговорим о типовых случаях, которые нам доставили немало головной боли.
Итак, вам в начале надо определиться о ЦА вашего продукта, поскольку каждый конкретный выбор поведет вас по уникальному пути. Продукт для какого рынка? Русского или зарубежного? Если зарубежного, то какого — китайского или европейского? Пользователи пишут на латинице, кириллице или на своей уникальной системе письма?
Да-да, это все нужно для простой и тупой, на первый взгляд, задачи как регистрация пользователя. Дело в том, что мы с вами европейцы и мыслим соответствующее, а в мире огромное количество народа с другими культурами, у которых другой тип письменного мышления, если это так можно назвать. Вариантов огромное количество, более опытные люди расскажут вам о работе со всякими редкими вещами по типу старомоногольской вертикальной письменности ᠮᠤᠩᠭᠤᠯ ( Вот тут забавно, хабр не умеет корректно отображать такой вариант письма) или арабской вязи. Поэтому определяемся, с чем мы будем работать и отсекаем все лишнее. По стандарту будем регистрировать человека на кириллице, в регулярных выражениях разрешаем только её.
Но есть одиннадцать нюансов:
ФИО одним полем.
Зачастую вместо трех полей делают одно, куда предлагают ввести все, что у человека есть. Кажется, в чем тут проблема? Первое слово — фамилия, второе — имя, а третье, соответственно — отчество. Но не тут было, во-первых, пользователи часто путают очередность, во-вторых, уних может быть двойное имя или отсутствовать отчество. И это либо запретит регистрацию этого пользователя, либо снизит качество данных.В идеале вы должны всегда разбивать ФИО на три разных переменных, но иногда это невозможно, потому что долгая регистрация отобьет желание использовать ваш продукт, и поэтому надо от человека в одном поле как можно быстрее получить данные. Но тогда вам надо будет отказываться от части функционала или писать монстра, который определяет где что находится и уже внутри вашей программы присваивать соответствующий класс.
2. Двойные фамилии.
Раз уже начали с этим нюансом, то продолжаем. Банальная конструкция из одного поля нормально работает, до того как вам впервые встречается человек с двойной фамилией. И тут возникает проблема — двойная фамилия по сути это одно слово, но знак не принадлежит к кириллице, из-за чего регистрация невозможна. Так что необходимо помнить об этом.
3. Двойные имена.
Аналогично с предыдущим пунктом, только теперь представьте, что бывают люди с двойными именами и с двойными фамилиями одновременно, и их полное ФИО может быть очень длинным, поэтому разучиваем максимальную длину вводимого текста с запасом.
4. ФИО из большого количества слов.
Культурный фактор, мы в России привыкли, что слов в ФИО три, хотя в некоторых странах оно может состоять из большего количества. Поэтому также учитываем это в регулярных выражениях, или делаем пометку какую часть имени и где использовать.
5. Отчество.
Из-за того, что мы все немного русскоцентричны, мы иногда забываем о других культурах, где наименования строились по совершенно другим принципам. Среднеазиатские, японские, китайские, корейские ФИО могут состоять из большего количества слов, и ни одно из них не будет отчеством.
6. Проблемы с Оглы, ибн.
А тут обратная ситуация, в тюркских языках Оглы по сути является отчеством, однако оно может писаться как через дефис, так и как отдельное слово. Учтите этот пункт, чтобы не перепутать расфасовку по переменным.
7. Несколько видов - .
‐, −, –, —. Нет, это не смайлики, это слева на право: дефис, минус, короткое тире и тире. И если у вас стоит проверка на двойное имя/фамилию, то там должен стоять знак дефиса, но пользователи могут вставить любой другой из этих символов, а регулярка просто не пропустит дальше.
8. Латиница в буквах.
Еще дополнительный аргумент вводить регулярки — это латинские буквы в русских словах. Вы не представляете сколько вам добавит боли выискивать скрытую латинскую "o" в фамилии Иванoв.
9. Буква Ё.
Если все остальные случаи являются универсальными для любых языков, то этот кейс только для русского языка. Дело в том, что regex просто не знает, что у нас в алфавите есть буква ё. Т.е. если вы напишите регулярное выражение для имени и фамилии не больше, чем 50 символов([А-Я][а-я]{1,49})\ ([А-Я][а-я]{1,49}), то такое выражение не пропустит ни мое имя (Пётр), ни содержащую эту букву фамилию. Поэтому отдельно добавляем ее в регулярки.
10. Несколько тысяч символов.
Самый тупой и самый надежный способ повесить регистрацию. Вы вводите несколько десятков тысяч символов и просто ждете. Вот тут зависит от платформы, с которой вы работаете. У нас часто был телеграмм, поэтому на нем и покажу. Он разбивает огромные сообщения на несколько частей и одновременно отсылает их на сервер. И получается, что тригер работает не на одно сообщение, а на десятки, если не сотни. Например, если у вас стоит ответное сообщение после регистрации
привет, username,
то пользователю придут несколько сотен огромных сообщений, включая это длинное имя на тысячи символов. Из-за этого есть вероятность повесить весь ваш сервис или частично сломать его.
Я лично видел, как загрузочный экран мобильного приложения Сбербанка был искорежен именем в несколько тысяч случайных символов. Так что это бич не только маленьких проектов.
11. Транскрипция (слаги).
Чуть в сторону, но думаю будет полезно. Если у вас есть перевод значений в латиницу (например, ФИО для писем за границу), то необходимо использовать единый инструмент создания слагов (человекочитаемые идентификаторы) в проекте. У нас в одном проекте были использованы 2 разных методологии создания слагов на фронте и бэке, и мы долго не понимали в чем проблема. Оказалось, что у нас идет ключевание через слаги, которые сформированы по-разному. Например, слово "транслитерация" в различных системах выглядит вот так: Transliteraciya и Transliteratsiya.
Ну, а теперь ответ на главный вопрос — почему такая обложка поста?
На скрине вы видите SQL-инъекцию. Вы наверное часто встречали это выражение, но не понимали что это по сути.
Так что же такое эта ваша SQL-иньекция? Если совсем просто, то при регистрации под видом имени пользователя вам в БД летит тупо, скорее всего, вредоносный SQL-код. Какой конкретно — неизвестно, но это дыра прямо к вам в БД.
- Как вас зовут?
- Меня зовут DROP DATABASE base1
И все, вашей базы больше нет. Да, конечно, шанс, что атакующий угадает с названием таблицы, очень мал, но никто не отменял брутфорс и промышленный шпионаж, оставлять такую дыру очень опасно. По защите от инъекций написаны сотни статей и это стандарт в ИБ. Поэтому инъекции, в подавляющем числе случаев можно сделать только тогда, когда разработчик вообще не подозревает, что так можно.
Это было финальным аргументом необходимости вводить регулярные выражения.
Основные выводы:
Меньше европоцентричности. У других культур свои правила составления имен —и это надо учитывать. Либо подгонять под свой формат, но по унифицированым сценариям.
Если можно разделить ФИО на отдельные поля — делите обязательно, это вам значительно упростит жизнь.
Если нет совсем критичных противопоказаний, то на всякий случай добавьте регулярные выражения.
Помните, что если вы напрямую кладете что-то в БД, то значит при желании, внешние специалисты могут сделать все что угодно с вашей базой.
Лучше предусмотреть самые редкие варианты написания имен, чтобы потом не бегать и искать проблему, которую зачастую сложно обнаружить.
Я не претендую на гайд, описал лишь те случаи, с которыми лично столкнулся и которые добавили мне немало головной боли. Смысл статьи — помочь новичкам обнаружить скрытые подводные камни и избавить их проекты от потенциальных проблем.
