Какие имена пользователей я должен запретить? [закрытый]
HTTP - это текстовый протокол. ENTIRE структура заголовка / тела запроса может быть подделана, чтобы сказать что угодно.
9 ответов
Допустимые имена пользователей
В качестве общей политики я ограничиваю имена пользователей в системах, которые я проектирую, следующими способами:
- Имена пользователей должны быть ниже ascii - это исключает имена пользователей в формате Unicode, которые могут использоваться для обмана пользователей. Например, когда вы включаете юникод в имена пользователей, имя «admin» и «ａｄｍｉｎ» являются отдельными именами пользователей, но могут казаться идентичными ничего не подозревающим пользователям.
- Имена пользователей должны быть уникальными - Использование имени пользователя в качестве уникального идентификатора не рекомендуется , но все же имеет смысл иметь его как уникальное значение, если оно используется для электронной почты или входа в систему.
- Имена пользователей не конфликтуют с зарезервированными ключевыми словами. - Запретить использование имен пользователей в качестве общих системных имен пользователей полезно , поскольку это один из способов социальной инженерии, который черные шляпы могут использовать для обмана пользователей в вашей системе. . Это означает, что должны быть заблокированы администратор, веб-администратор, постмастер, root, администратор, системный администратор и т. Д. Более того, если вы будете использовать систему URL-адресов в стиле REST, убедитесь, что имена пользователей не конфликтуют с любыми потенциальными путями, которые вы, вероятно, можете включить в будущем.
- Имена пользователей очищены - Важно, чтобы любые Разметка html или css удаляется из введенных имен пользователей, чтобы предотвратить атаки XSS или возможные попытки олицетворения пользователя. Кроме того, не забывайте обрезать начальные и конечные пробелы в имени пользователя.
Вопрос действительно сводится к вашему использованию. Если ваши имена пользователей - это просто имена, связанные с пользователями веб-форума, это не имеет особого значения. Однако, если имена пользователей являются частью большой системы с проблемами безопасности, у вас должна быть политика. Основная опасность неправильных имен пользователей заключается в том, что черная шляпа может использовать их как один из методов социальной инженерии невинных пользователей для раскрытия конфиденциальной информации.
Интересно, что после публикации этого ответа я проверил проверку имени пользователя Stack Overflow, и он действительно запрещает символы Unicode как я предложил. Однако он дает загадочную ошибку о том, что имя пользователя «зарезервировано».
если имена пользователей являются частью большой системы с проблемами безопасности, у вас должна быть политика. Основная опасность неправильных имен пользователей заключается в том, что черная шляпа может использовать их как один из методов социальной инженерии невинных пользователей для раскрытия конфиденциальной информации.Интересно, что после публикации этого ответа я проверил проверку имени пользователя Stack Overflow, и он действительно запрещает символы Unicode как я предложил. Однако он дает загадочную ошибку о том, что имя пользователя «зарезервировано».
если имена пользователей являются частью большой системы с проблемами безопасности, у вас должна быть политика. Основная опасность неправильных имен пользователей заключается в том, что черная шляпа может использовать их как один из методов социальной инженерии невинных пользователей для раскрытия конфиденциальной информации.Интересно, что после публикации этого ответа я проверил проверку имени пользователя Stack Overflow, и он действительно запрещает символы Unicode как я предложил. Однако он дает загадочную ошибку о том, что имя пользователя «зарезервировано».
s проверка имени пользователя, и он не позволяет использовать символы Unicode, как я предлагал. Однако он дает загадочную ошибку о том, что имя пользователя «зарезервировано». s проверка имени пользователя, и он не позволяет использовать символы Unicode, как я предлагал. Однако он дает загадочную ошибку о том, что имя пользователя «зарезервировано».
Если серьезно, то хорошей идеей является фильтрация имен, содержащих потенциально вредоносный код. Кроме того, любая цензура против ненависти / троллей / спама / * зависит от вас и / или вашего сообщества.
Лучший способ уберечь людей от «подделки» «авторитетно звучащими именами» - это просто отличить «авторитетность» каким-либо другим способом (например, у вас есть особый цвет текста в сообщении , у вас есть специальный значок или аватар и т. д.).
Серьезно, вам нужно убедиться, что все данные, сгенерированные пользователем (а не только имена пользователей), правильно экранированы, прежде чем переходить в базу данных. Это гарантирует, что ваши пользователи не смогут выполнить атаку с использованием SQL-инъекции (например, мультфильм Bobby Tables, на который ссылается Эван Мигер). Если ваш пользователь хочет войти в систему под таким именем пользователя, как "Robert '); DROP TABLE", тогда пусть они крутятся. Просто убедитесь, что это не повредит вашу базу данных.
Точно так же, если вы показываете имя пользователя где-нибудь на сайте, убедитесь, что ваши специальные символы html правильно закодированы, чтобы они не вставляли теги » никогда не должен видеть окно предупреждения.
Если вы не видите причин, по которым вы должны запрещать имена пользователей, которые выглядят как SQL-инъекции или XSS-атаки, при условии, что вы абсолютно уверены, что пользователь не может нанести вред системе, имея их.
Если вы предоставляете какие-либо службы электронной почты, привязанные к имени пользователя (например, службу веб-почты), вам необходимо убедиться, что пользователи не могут зарегистрироваться, используя один из RFC 2142 зарезервированных адресов электронной почты (или что вы регистрируете их все самостоятельно перед запуском.
Наконец, есть нетехническая причина. Если имя пользователя появляется где-нибудь на сайте, может быть желательно запретить такие имена пользователей, как «admin», «administrator», «root», «системный администратор», «веб-мастер», «модератор», поскольку эти имена пользователей могут подразумевать какое-то владение или контроль над сайтом другому пользователю. Скорее всего, вы хотите, чтобы владельцы сайта имели возможность подразумевать, что они владеют сайтом. Это может быть необязательно во всех ситуациях.
Возможно, стоит запретить любую комбинацию товарных знаков вашей компании. Это не только имеет смысл с юридической точки зрения, но и удерживает злоумышленников от попыток выглядеть как член вашей организации.
В зависимости от того, что вы делаете с именами, это не имеет значения. Вы определенно не должны вводить их в операторы SQL, поэтому следует минимизировать вред ключевых слов базы данных. Мой подход заключался бы в том, чтобы разрешить практически все, но не доверять всему, что введено - используйте параметры в своем операторе SQL и / или очистите данные, если вы собираетесь включить их, например, в HTML.
Рассмотрите возможность чтения с этот вопрос, чтобы получить немного больше информации об атаках с использованием SQL-инъекций: Как лучше всего избежать атак с использованием SQL-инъекций?
Я должен сказать, что вы должны разрешить что угодно, и если вы не хотите, чтобы у кого-то был такой пользователь, как Администратор, вы должны изначально создать этого пользователя для собственного использования. Как уже говорили другие, если вы правильно программируете приложение, не должно возникнуть проблем с использованием таких вещей, как ключевые слова базы данных. Если вы неправильно программируете (пишете код, восприимчивый к внедрению sql), нет ничего, что помешало бы действительно творческому человеку обойти ваш черный список.
Подумайте о замене имени пользователя электронной почтой, поскольку в настоящее время пользователи часто забывают свои имена.
Если пользователь использует свой пароль электронной почты, то у вас есть свободный доступ к его электронной почте :) Но серьезно, экономия пароли в открытом виде - не лучшая идея.
Если у вас есть имена пользователей, которые являются частью URL-адресов, вы можете запретить некоторые или все из следующего:
- api
- beta
- blog
- demo
- форум
- форумы
- iphone
- мобильный
- безопасный
- svn
- блог
- добро пожаловать
- www