Лучший способ состоит в том, чтобы настроить Apache и установить доступ через него. Проверьте svn книга для справки. Если Вы не хотите использовать Apache, можно также сделать минималистическое управление доступом с помощью svnserve.
Я не знаю, что вы подразумеваете под «уязвимостью», но есть одна ошибка, которую многие люди делают с разделами CDATA. Это случается, когда ленивый программист на самом деле не понимает экранирование текста и пытается избежать обычного процесса и
-кодирования специальных символов в XML. Они думают, что им сойдет с рук:
print "<element><![CDATA["+textstring+"]]></element>";
и хотя это действительно предотвратит обработку символа <
или &
в текстовой строке
как разметки, это не является водонепроницаемым потому что текстовая строка может содержать последовательность ]]>
, в результате чего:
<element><![CDATA[ Foo ]]> <bar>I'm an unexpected element!</bar> ]]></element>
Это XML-инъекция, которая, как и HTML-инъекция, потенциально может иметь влияние на безопасность, подобное XSS.
Итак, вы все еще нужно экранировать некоторые последовательности в CDATA (обычно вы должны разделить ]]>
последовательность между двумя секциями CDATA). На практике это делает использование CDATA не проще, чем обычное и
-кодирование вашего текстового контента. Так что на самом деле нет никаких причин использовать раздел CDATA.
Раздел CDATA - это просто еще один способ представления символьных данных в документе XML. Это означает то же самое, что и любой другой (не теговый) текст в документе, за исключением того, что он экранирован по-другому.
Нет никакой дополнительной «уязвимости», связанной с CDATA (за исключением, конечно, ошибок в вашей библиотеке синтаксического анализа XML. ).
Чему подвержены? Какая-то инъекционная атака? CDATA сообщает синтаксическому анализатору передать содержимое без его анализа, поэтому, если вы проверяете свой XML, я полагаю, что раздел CDATA пропускает этап проверки.
Код, который использует поток XML, должен иметь некоторую бизнес-проверку выше. и за пределами проверки схемы, поэтому вы рискуете только в том случае, если не сможете проверить входные данные перед их использованием.