Какие имена пользователей я должен запретить?

Ответ 1

Допустимые имена пользователей

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

• Имена пользователей должны быть ниже ascii - это исключает имена пользователей Unicode, которые могут использоваться для обмана пользователей. Например, когда вы включаете unicode в имена пользователей, имя "admin" и "admin" являются отдельными именами пользователей, но могут казаться идентичными пользователям, которые ничего не подозревают.
• Имена пользователей должны быть уникальными - Использование имени пользователя как уникального идентификатора не рекомендуется, но все же имеет смысл иметь его как уникальное значение, если оно используется для электронной почты или логинов.
• Имена пользователей не конфликтуют с зарезервированными ключевыми словами. - Запретить использование имен пользователей из общих системных имен пользователей полезно, потому что это один из способов социальной инженерии, который можно использовать черными шляпами для мошенников в вашей системе. Это означает, что администратор, webadmin, postmaster, root, администрирование, sysadmin и т.д. Должны быть заблокированы. Более того, если вы будете использовать систему URL-адресов стиля REST, убедитесь, что имена пользователей не конфликтуют с потенциальными путями, которые, вероятно, могут быть включены в будущем.
• Убираются имена пользователей. - Важно, чтобы любая html или css-разметка была удалена из введенных имен пользователей, чтобы предотвратить атаки XSS или возможные попытки олицетворения пользователя. Кроме того, не забудьте обрезать ведущие и завершающие символы пробела из имени пользователя.

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

Если у вас есть имена пользователей, которые являются частью URL-адресов, вы можете запретить некоторые или все из следующих действий:

• апи
• бета
• Блог
• демо
• Форум
• Форумы
• iphone
• мобильный
• безопасным
• SVN
• Weblog
• Добро пожаловать
• WWW

Ответ 5

Серьезно, вам нужно обеспечить, чтобы все данные, созданные пользователем (а не только имена пользователей), были правильно экранированы перед входом в базу данных. Это гарантирует, что ваши пользователи не смогут вытащить инъекцию SQL-инъекций (например, мультфильм Bobby Tables, связанный с Эваном Мигером). Если ваш пользователь хочет войти в систему с именем пользователя, таким как "Robert" ), "DROP TABLE", то, пусть их отпускают. Просто убедитесь, что это не повредит вашей базе данных.

В равной степени, если вы укажете имя пользователя в любом месте сайта, убедитесь, что ваши специальные символы html правильно закодированы, чтобы предотвратить их инъекцию <script> теги и javascript в ваш результат (уязвимость XSS). например пользователь с именем пользователя <script> alert ('Hi'); </script> " никогда не увидите окно предупреждения.

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

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

Наконец, есть нетехническая причина. Если имя пользователя человека появляется в любом месте сайта, может быть желательно запретить имена пользователей, такие как "admin", "administrator", "root", "sysadmin", "webmaster", "moderator", поскольку эти имена пользователей могут означать какую-то владение или контроль сайта другому пользователю. Возможно, вы хотите, чтобы владельцы сайтов могли иметь в виду, что они владеют сайтом. Это может быть не обязательно во всех ситуациях.

Ответ 6

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

Ответ 7

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

Если пользователь использует свой почтовый пароль, у вас есть бесплатный доступ к его электронной почте:) Но если серьезно, то сохранить незашифрованные пароли не очень хорошо.

Ответ 8

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

Рассмотрите возможность чтения с этим вопросом, чтобы получить немного больше информации о SQL Injection Attacks: Каков наилучший способ избежать атак SQL-инъекций?

Ответ 9

Я должен сказать, что вы должны что-то разрешить, и если вы не хотите, чтобы кто-то имел пользователя, например Admin, вы должны сначала создать этого пользователя для вашего собственного использования. Как и другие, если вы правильно программируете приложение, не должно быть никаких проблем с использованием таких вещей, как ключевые слова базы данных. Если вы неправильно программируете (написание кода восприимчиво к sql-инъекции), нет ничего, что помешает действительно творческому человеку обойти ваш черный список.