Предотвращение символьной сущности HTML в файлах локали от того, чтобы быть портившимся защитой Rails3 xss

Если вы используете XAMPP, вы включаете extension=php_fileinfo.dll в php.ini

26
задан Chris S 13 August 2010 в 13:58
поделиться

2 ответа

Известно ли вам о методе html_safe, который можно использовать в помощниках? Я не уверен, что я полностью понимаю проблему здесь, так как я никогда не работал с I18n, но можно ли использовать пользовательский помощник, который определяет, следует ли экранировать символы и возвращать "string" .html_safe, и должен ли он быть экранированным, вернуть "строку".

Или, возможно, переопределить помощник «t» и добавить свои экранирующие логические условия + .html_safe

0
ответ дан johnmcaliley 28 November 2019 в 07:25
поделиться

Хорошо. Вчера я добавил этот вопрос в закладки из-за угла зрения i18n, но не ответил на него, так как я человек Python, который никогда не использовал Rails. Я все еще не собираюсь на него отвечать, но, учитывая, что вас не одолеют полезные Railsian, которые могли бы указать вам на хороший способ обойти внутренности Rails, тем не менее, вот моя точка зрения.

Прежде всего, я думаю, здорово , что вы думаете о проблеме с самого начала. Это довольно редко. Во-вторых, я полностью согласен с тем, что использование необработанных строк или выборочный выбор строк с объектами для особой обработки звучит как хрупкий, уродливый, подверженный ошибкам взлом.

Теперь, если я правильно понимаю Rails (я прочитал это руководство по i18n ), файлы YAML содержат локализованную строку для каждого языка. В этом случае я настоятельно рекомендую использовать в них обычные символы (в UTF-8). В противном случае, поддерживая локализацию или даже читая через файл перевода - подумайте о языках с нелатинскими шрифтами! - будет ад.

Да, это означало бы, что вам нужно выяснить методы ввода, но решение чистое и простое.

8
ответ дан 28 November 2019 в 07:25
поделиться