Правильное предотвращение XSS в сообщениях iframe между источниками - PullRequest
0 голосов
/ 20 февраля 2019

Я создаю сайт, где любой сможет взаимодействовать с моим iFrame с помощью команды postMessage (т. Е. Функции с песочницей, а не полный контроль над окном).Как я могу сделать это, не раскрывая куки моего посетителя через XSS?https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#Security_concerns

Допустим, у меня есть следующая функция получения:

var secret = localStorage.getItem("secret");

window.addEventListener(message,function(e){
     // any e.origin is allowed
     if(e.func=="doX"){
            var string = e.data.string1 * e.data.string2;

     }else if(e.func=="doY"){
            // another javascript function, no DOM interaction
            config[e.data.key] = e.data.value;

     }else if(e.func=="doZ"){
          document.getElementById("app")=e.data.title
          document.getElementById("description")=e.data.description
     }
})


Я прочитал на странице Mozilla, что разрешение запроса из любого источника довольно опасно.Как я могу правильно предотвратить XSS для каждого из doX, doY и doZ, в зависимости от ситуации?

Я тоже попробовал.Безопасны ли эти функции?

var secret = localStorage.getItem("secret");

window.addEventListener(message,function(e){
     // any e.origin is allowed
     if(typeof e.func!=Number) return;

     if( e.func < 0 || e.func > 2) return;

     if(e.func==0){ //  we will call this "Safe 0"

            if(e.data.num1 > 1000 || e.data.num2 > 1000) return;
            var num3 = e.data.num1 * e.data.num2;

     }else if(e.func==1){ // safe 1

            if(!isHex(e.data.value))return; // see below for isHex func

            config['something'] = e.data.value;

     }else if(e.func==2){ // safe 2

          if(e.data.title.length < 8) document.getElementById("app")=e.data.title;

          if(e.data.description.length < 15)document.getElementById("description")=e.data.description

     }
})
function isHex(h) {

    var a = parseInt(h,16);
    return (a.toString(16) === h)

}

Я узнал, что элементы ввода HTML также будут недоступны с хостинг-сайта, а это означает, что эти "postMessage" являются основным источником уязвимости.Источник для этого последнего оператора: Получить значение поля ввода внутри iframe

Ответы [ 2 ]

0 голосов
/ 02 марта 2019

Насколько я могу судить, уязвимости XSS лучше рассматривать на уровне конкретного случая.Это не просто безопасное получение переменной в вашем окне через postMessages, это то, что вы делаете с переменной, когда она там есть.Например, вы не захотите принимать переменный аргумент и загружать скрипт, поскольку переменная может быть изменена для загрузки вредоносного скрипта.Вы бы не запустили eval-заявление.Я до сих пор не уверен, применимо ли «evalByProxy» в чисто javascript-среде (нет манипуляций с HTML / элементами ввода; нет связи с базой данных).Поскольку я попросил другого ответчика дать разъяснения по этому вопросу и не могу найти какую-либо информацию об этом через Google, я предполагаю, что это на самом деле не проблема, если я не передаю сообщение iFrame в базу данных сервера, DOMили запустите оператор eval.Посмотрите больше на основные примеры чатов XSS для примера того, почему отправка этих сообщений на сервер - плохая идея.

То, что я обнаружил, представляет собой большую угрозу безопасности в случае попытки обеспечить безопасность iFrame - это наличие расширений браузера (например, блокировщиков рекламы).Они получают разрешение на доступ к каждой части веб-страницы.Это означает, что они могут получить доступ к любой глобальной переменной на вашей веб-странице и любой глобальной функции.Я еще не уверен, могут ли они получить доступ к переменной локальной области (например, внутри объекта).Я не уверен, что они могут получить доступ к localStorage, но я думаю, что они могут.Поэтому я продолжил мягко продолжать в пространстве сообщений XSS и пересматриваю любой метод, который использует localStorage.

0 голосов
/ 22 февраля 2019

Пока я не выполняю оператор eval для сообщений, отправленных с помощью функции postMessage в мое окно, есть ли способ выполнить произвольный код?

Любой изобычные клиентские векторы атаки JS XSS открыты.

Так же, как и eval, у вас есть различные функции eval-proxy (такие как new Function()), эффект вставки данных из сообщенияв DOM небезопасным способом и т. д.

...