Очевидная xss-уязвимость jsonp

Некоторые из наших клиентов сообщили о предполагаемой XSS-уязвимости во всех наших конечных точках JSONP, но я не согласен с тем, действительно ли это является уязвимостью. Хотелось узнать мнение сообщества, чтобы убедиться, что я ничего не упустил.

Итак, как и в любой системе jsonp, у нас есть конечная точка типа:

http://foo.com/jsonp?cb=callback123

где значение параметра cb воспроизводится обратно в ответ:

callback123({"foo":"bar"});

Клиенты жаловались, что мы не отфильтровываем HTML в параметре CB, поэтому они придумывают пример вроде этого:

http://foo.com/jsonp?cb=<body onload="alert('h4x0rd');"/><!--

Очевидно, что для URL, возвращающего тип содержимого text/html, это создает проблему, поскольку браузер отображает этот HTML, а затем выполняет потенциально вредоносный javascript в обработчике onload. Может использоваться для кражи cookies и передачи их на сайт злоумышленника или даже для создания поддельного экрана входа в систему для фишинга. Пользователь проверяет домен и видит, что это домен, которому он доверяет, поэтому он переходит на agead и входит в систему.

Но в нашем случае мы устанавливаем заголовок типа содержимого application/javascript, что вызывает различное поведение в разных браузерах. Например, Firefox просто отображает необработанный текст, а IE открывает диалог "сохранить как...". Я не считаю ни один из этих вариантов особо уязвимым. Пользователь Firefox не станет читать вредоносный текст, предлагающий ему прыгнуть с моста, и много думать об этом. А пользователь IE, вероятно, будет сбит с толку диалогом сохранения и нажмет "отмена".

Наверное, можно представить себе случай, когда пользователя IE обманом заставляют сохранить и открыть файл .js, который затем проходит через движок JScript от Microsoft и получает всевозможный доступ к машине пользователя; но это кажется маловероятным. Это самая большая угроза здесь или есть какая-то другая уязвимость, которую я пропустил?

(Очевидно, я собираюсь "исправить", поставив фильтрацию, чтобы принимать только правильный идентификатор javascript, с некоторым ограничением длины на всякий случай; но я просто хотел диалога о том, какие другие угрозы я мог пропустить)

6
задан Mike Ruhlin 5 January 2012 в 22:01
поделиться