Символы UTF-8, которые не являются уязвимостями XSS

Question

Символы UTF-8, которые не являются уязвимостями XSS

Наличие нескольких не связанных между собой типов в одном и том же списке немного пахнет кодом, я бы посоветовал реорганизовать ваш код, чтобы это было не так, даже просто держа объекты в отдельных списках, например. Сказав это, вы можете сделать что-то вроде этого:

foreach (var dbObject in dbObjects)
{
    switch (dbObject)
    {
        case Database db:
            _webApi.DeleteObject<Database>(db.id);
            break;

        case Table tbl:
            _webApi.DeleteObject<Table>(tbl.id);
            break;

        default:
            throw new Exception("Someone added a weird object to the collection...");
    }
}

6

php utf-8 xss

задан Alan Moore 30 April 2009 в 02:48

2 ответа

Другие вопросы по тегам:

php utf-8 xss

Похожие вопросы:

score 11 · Answer 1

Может быть (намного) проще, если вы просто передадите кодировку htmlentities () / htmlspecialchars

echo htmlspecialchars($string,  ENT_QUOTES, 'utf-8');

Но то, достаточно ли этого или нет, зависит от того, что вы печать (и где).

см. также:
http://shiflett.org/blog/2005/dec/googles-xss-vulnerability
http://jimbojw.com/wiki/index.php ? title = Sanitizing_user_input_against_XSS
http://www.erich-kachel.de/?p=415 (на немецком языке. Если я найду что-то похожее на английском -> update) edit: ну, я думаю, вы можете получить главное не владеть немецким языком;) The string

javascript:eval(String.fromCharCode(97,108,101,114,116,40,39,88,83,83,39,41))

passes htmlentities() unchanged. Now consider something like

<a href="<?php echo htmlentities($_GET['homepage']); ?>"

which will send

<a href="javascript:eval(String.fromCharCode(97,108,101,114,116,40,39,88,83,83,39,41))">

to the browser. And that boils down to

href="javascript:eval(\"alert('XSS')\")"

While htmlentities() gets the job done for the contents of an element, it's not so good for attributes.

score 5 · Answer 2

В общем, да, вы можете полагаться на что-нибудь, кроме ASCII, чтобы быть «безопасным», однако есть некоторые очень важные предостережения, которые следует учитывать:

Всегда проверяйте это то, что ты отправка клиенту помечается как UTF-8. Это означает наличие заголовка который явно говорит "Content-Type: текст / html; charset = utf-8 " каждые одна страница , включая все ваши страницы с ошибками, если какой-либо контент на эти страницы ошибок генерируются из пользовательский ввод. (Многие люди забывают протестируйте их страницу 404 и получите дословно включать ненайденный URL)
Всегда проверяйте, то, что вы отправляете клиенту, это действующий UTF-8. Это значит, что ты не может просто пройти байтов, полученных от пользователя, обратно в пользователь снова. Вам нужно расшифровать байты как UTF-8, примените предотвращение XSS-кодирования html, а затем закодируйте их как UTF-8, когда вы их пишете out.

Первое из этих двух предостережений заключается в том, чтобы браузер клиента не видел кучу информации, включая символы с высокими буквами, и не возвращался к некоторому локальному набору многобайтовых символов. Этот локальный многобайтовый набор символов может иметь несколько способов указания вредоносных символов ascii, от которых вы не защититесь. В связи с этим некоторые старые версии определенных браузеров - кашель то есть кашель - были немного перенапрягаются при обнаружении страницы в кодировке UTF-7; это открывает бесконечные возможности XSS. Чтобы защититься от этого, вы можете убедиться, что вы закодировали в HTML любой исходящий знак «+»; это чрезмерная паранойя, когда вы генерируете правильные заголовки Content-Type, но она спасет вас, когда какой-нибудь будущий человек щелкнет выключателем, который отключит ваши пользовательские заголовки. (Например, поставив плохо настроенный обратный прокси-сервер кэширования перед вашим приложением или сделав что-то для вставки дополнительного заголовка баннера - php не позволит вам установить какие-либо заголовки HTTP, если какой-либо вывод уже записан)

Второй из них - потому что в UTF-8 можно указать «слишком короткие» последовательности, которые, хотя и недопустимы в соответствии с текущими спецификациями, будут интерпретироваться старыми браузерами как символы ASCII. ( Посмотрите, что говорится в Википедии ) Также возможно, что кто-то может вставить один неверный байт в запрос; если вы передадите этот пакет пользователю, это может привести к тому, что некоторые браузеры заменят плохой байт и один или несколько байтов после него на "?" или какой-то другой персонаж "не мог понять этого". То есть один плохой байт может привести к тому, что некоторые хорошие байты будут поглощены. Если вы внимательно посмотрите на то, что вы выводите, вероятно, где-то есть место, где злоумышленник, который смог стереть байт или два из вывода, мог бы выполнить некоторый XSS. Декодирование ввода как UTF-8 и последующее его перекодирование предотвращает этот вектор атаки.