Есть ли способ заставить ESAPI считывать свойства проверки из таблицы базы данных вместо использования файла validation.properties по умолчанию?
Свойства проверки ESAPI из базы данных
Ответы (1)
Краткий ответ: Нет.
Ознакомьтесь с кодом здесь.
Соответствующий ответ находится в документации:
/**
* The SecurityConfiguration manages all the settings used by the ESAPI in a single place. In this reference
* implementation, resources can be put in several locations, which are searched in the following order:
* <p>
* 1) Inside a directory set with a call to SecurityConfiguration.setResourceDirectory( "C:\temp\resources" ).
* <p>
* 2) Inside the System.getProperty( "org.owasp.esapi.resources" ) directory.
* You can set this on the java command line
* as follows (for example): java -Dorg.owasp.esapi.resources="C:\temp\resources". You may have to add this
* to the batch script that starts your web server. For example, in the "catalina" script that
* starts Tomcat, you can set the JAVA_OPTS variable to the -D string above.
* <p>
* 3) Inside the System.getProperty( "user.home" ) + "/.esapi" directory
* <p>
* 4) In an ".esapi" directory on the classpath
* <p>
* Once the Configuration is initialized with a resource directory, you can edit it to set things like master
* keys and passwords, logging locations, error thresholds, and allowed file extensions.
* <p>
* WARNING: Do not forget to update ESAPI.properties to change the master key and other security critical settings.
*
* @author Mike Fauzy ([email protected])
* @author Jim Manico ([email protected])
* @author Jeff Williams (jeff.williams .at. aspectsecurity.com) <a
* href="http://www.aspectsecurity.com">Aspect Security</a>
*/
Если вы хотите такого поведения, вам придется вручную изменить источник esapi и (надеюсь) сделать это таким образом, чтобы можно было игнорировать определенные реализации базы данных.
Также учтите, что для библиотеки безопасности немного менее безопасно управлять многими из этих вещей в базе данных. OWASP рекомендует вручную скомпилировать эту библиотеку с файлами свойств в каталоге src/main/resources. Таким образом, чтобы внешний участник мог изменить вашу конфигурацию, он должен иметь учетную запись unix на вашем компьютере, если вы придерживаетесь стандартов Java. (WEB-INF/ естественно защищен.) Если вы поместите это в базу данных, то теоретически ваши конфигурации безопасности открыты для угроз SQL Injection ... зачем рисковать?
Наличие этих файлов в самой библиотеке помещает их непосредственно в путь к классам, что значительно затрудняет их изменение. Если вы ДЕЙСТВИТЕЛЬНО решите реализовать это в базе данных, будьте чрезвычайно осторожны с ошибками TOCTOU (от времени проверки до времени использования).