ColdFusion: серверные пользовательские проверки
Есть ли способ улучшить проверку этих пользовательских полей на стороне сервера?
<cfif Form.LoginName EQ ""><h1>Login Name is required.</h1></cfif>
<cfif Form.Password EQ ""><h1>Password is required.</h1></cfif>
<cfif Form.Password NEQ Form.PasswordConfirmation><h1>Password confirmation does not match Password.</h1></cfif>
<cfif Form.FirstName EQ ""><h1>First Name is required.</h1></cfif>
<cfif Form.LastName EQ ""><h1>Last Name is required.</h1></cfif>
<cfif Form.LoginName EQ "" OR Form.Password EQ "" OR Form.Password NEQ Form.PasswordConfirmation OR Form.FirstName EQ "" OR Form.LastName EQ "">
<p>User has not been created</p>
<p>You can use your browser's back button to keep form fields filled and try again.</p>
<p><a href="users.cfm">Return to users list</a>.</p>
<cfabort>
</cfif>
3 ответа
То, как вы связываете свою бизнес-логику с дисплеем, оставляет желать лучшего. Вы могли бы, вероятно, извлечь выгоду из чтения на MVC и разделения проблем.
С точки зрения вашей логики, ваши правила проверки кажутся нормальными, но вы делаете проверку дважды, что кажется чрезмерным: каждый элемент, затем все элементы. Частично это связано с проблемой, которую я выделил выше.
Я хотел бы подумать о том, чтобы перестать мыслить процедурно, думать более ооо, определять понятие User.cfc и иметь какую-то службу проверки (см. ValidateThis). Или что-то типа того.
Наконец, это не совсем тот вопрос, который лучше всего задавать при переполнении стека, но он подойдет для Code Review. На этот вопрос нет единого ответа, поэтому люди будут склонны предлагать закрыть его, поскольку он "в первую очередь основан на мнении".
Я также собираюсь пометить это как "ColdFusion", а не "ColdFusion 10", так как это действительно не имеет никакого отношения к CF10, это просто вопрос CFML. Вы получите большую аудиторию с пометкой "ColdFusion".
Вместо того, чтобы делиться с вами кодом, я хотел бы представить вам эти концепции. Первое, что вы должны сделать, это прочитать рекомендации OWASP по проверке данных. В нем они предполагают, что существует четыре стратегии проверки данных, и их следует использовать в следующем порядке. Я опубликую некоторые выдержки здесь, но я настоятельно рекомендую вам прочитать всю статью.
Принять известное добро
Эта стратегия также известна как "белый список" или "положительная" проверка. Идея состоит в том, что вы должны проверить, что данные являются одним из набора жестко ограниченных известных хороших значений. Любые данные, которые не соответствуют, должны быть отклонены.Отклонить известное плохо
Эта стратегия, также известная как "отрицательная" или "черный список" проверки, является слабой альтернативой положительной проверке. По сути, если вы не ожидаете увидеть символы, такие как%3f или JavaScript или аналогичные, отклоните строки, содержащие их. Это опасная стратегия, потому что набор возможных плохих данных потенциально бесконечен. Принятие этой стратегии означает, что вам придется вести список "известных плохих" персонажей и шаблонов навсегда, и вы по определению будете иметь неполную защиту.Sanitize
Вместо того, чтобы принимать или отклонять ввод, другой вариант - изменить ввод пользователя в приемлемый формат.Нет проверки
Это по своей сути небезопасно и настоятельно не рекомендуется. Бизнес должен подписать каждый пример отсутствия проверки, так как отсутствие проверки обычно приводит к прямому отказу от контроля безопасности приложений, хоста и сети.
В статье обсуждается каждый из них более подробно и многое другое.
Это другой способ. Вы можете решить для себя, лучше это или нет.
Шаг 1 - создать переменную сообщения об ошибке.
<cfset ErrorMessage = "">
Шаг 2 - Проверь свои чеки. Если вы видите что-то, что вам не нравится, добавьте текст к вашей переменной.
<cfif len(trim(form.LoginName)) gt 0>
<cfset ErrorMessage &= "<h3>Login Name is required</h3>">
</cfif>
more checks
Шаг 3 - Проверьте длину переменной сообщения об ошибке
<cfif len(ErrorMessage) gt 0>
display it
<cfelse>
code for no errors
</cfif>
В дополнение ко всему этому вы, возможно, захотите проверить, действительно ли запрос страницы поступил со страницы формы. Вы можете использовать cgi.http_referrer для этого.
Еще кое-что. Вместо тега привязки обратно на страницу формы, как это,
<p><a href="users.cfm">Return to users list</a>.</p>
Вы можете использовать JavaScript, чтобы страница не загружалась в браузере.
<p><a href="javascript:history.back()">Return to users list</a>.</p>