Безопасность ColdFusion путем проверки ARGUMENTS.TargetPage в Application.onRequestStart? - PullRequest
3 голосов
/ 04 февраля 2011

У меня есть приложение ColdFusion, в котором я хочу ограничить доступ к определенным страницам на основе некоторых критериев. В настоящее время я делаю это так, в Application.cfc:

<cffunction name="OnRequestStart" access="public" returntype="boolean" output="true">
  <cfargument name="TargetPage" type="string" required="true" />
  <cfif not SESSION.isAdmin and REFindNoCase("/admin",ARGUMENTS.TargetPage) >
    <!--- Deny non-admin access to admin pages. --->
    <cfinclude template="/notauth.cfm">
    <cfreturn false />
  </cfif>
  <cfreturn true />
</cffunction>

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

Например, использование только REFind вместо REFindNoCase позволило бы людям скользить, если они перейдут в "/ ADMIN /". Есть ли здесь другие вещи, на которые стоит обратить внимание?

Я знаю, что есть другие проекты, такие как использование другого Application.cfc во вложенной папке или выполнение проверок прямо в коде страницы. Но мне нравится идея хранить весь мой код безопасности в одном месте. Поэтому, пожалуйста, предлагайте те из них, которые есть в вашем ответе, если нет способа сделать это безопасно или по какой-то причине это просто плохая идея. Благодаря.

Ответы [ 3 ]

1 голос
/ 04 февраля 2011

Я уверен, что в интернете есть куча всего этого, но вот мое мнение:)

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

Вы можете сделать это настолько сложным, насколько пожелаете, но для простого начала вы можете сравнить полное имя скрипта (CGI.SCRIPT_NAME) с запросом запросов, представляющих черные списки страниц, которые вы храните в области действия APPLICATION, которую вы загрузили в onApplicationStart() называется qRestrictedList.

Итак, в onRequestStart вы можете сделать следующее:

<cfquery name="qThisPageRestricted" dbtype="query">
  SELECT * FROM qRestrictedList
  WHERE ScriptName = '#CGI.SCRIPT_NAME#'
</cfquery>

<cfif qThisPageRestricted.recordCount and not SESSION.isAdmin>
  <cfinclude template="/notauth.cfm">
  <cfreturn false />
</cfif>

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

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

Надеюсь, это поможет.

0 голосов
/ 04 февраля 2011

Лучшим подходом было бы поместить application.cfc в каталог / admin, который контролирует доступ (возможно, на основе переменной SESSION, установленной посредством входа в систему как администратор), и чтобы этот «дочерний» application.cfc ссылался на родителяодин при необходимости.

См. этот вопрос для примера того, как это сделать: Расширение application.cfc в подкаталоге

0 голосов
/ 04 февраля 2011

Возможно, стоит сделать регулярное выражение более строгим:

REFindNoCase("\/admin\/([A-Za-z_]+)\.cfm", ARGUMENTS.thePage)
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...