Если пользователь просматривает только свои собственные данные — есть ли риск XSS?

Если мой сайт когда-либо позволит пользователям видеть только свои собственные отправленные данные и никогда не будет предоставлять данные, отправленные другим пользователем (т. е. никаких общих «сообщений» и т. д.), то существует ли на самом деле риск XSS на моем сайте?

Я все еще собираюсь работать над решениями XSS (такими как httmlspecialchars() и т. д.), но мне любопытно, может ли злоумышленник получить что-нибудь, взглянув на свою собственную XSS-атаку?


person Laurence    schedule 22.04.2012    source источник
comment
Вы всегда должны использовать htmlspecialchars() при размещении переменных данных в HTML, иначе вы, вероятно, получите сломанный HTML, помимо других проблем.   -  person Brad    schedule 22.04.2012
comment
да - спасибо, Брэд - я понимаю это именно по этим причинам   -  person Laurence    schedule 22.04.2012


Ответы (3)


Злоумышленник ничего не может получить, используя методы межсайтового скриптинга на себе. Целью межсайтового скриптинга является злонамеренное манипулирование элементами страницы, отображаемыми пользователю, будь то фишинг или чтение файла cookie. Другими словами, атака может затрагивать только объекты на стороне клиента.

Однако важно помнить, что означает фраза «пользователь всегда просматривает только свои собственные данные».

Предположим, у меня есть веб-сайт, на котором пользователи могут иметь личный профиль, доступный только им самим. На странице есть элемент ввода текста, который позволяет пользователям вводить URL-адрес своего веб-сайта. Теперь предположим, что форма для обновления профиля пользователя использует GET.

Отправка обновления страницы может выглядеть так:

http://www.example.com/privateprofile.pl?action=update&userwebpage=http://www.example.net

Злоумышленник может воспользоваться этим, обманом заставив пользователя загрузить URL-адрес:

http://www.example.com/privateprofile.pl?action=update&userwebpage=[malicious_js_code_here]

Конечно, это довольно тривиальный пример, но, надеюсь, он демонстрирует общую концепцию. Проблема заключается в том, что существует вероятность того, что они могут обманом заставить пользователя войти в XSS самостоятельно. Конечно, жизнеспособность подобной XSS-атаки зависит от вашей конкретной реализации.

person Jared Ng    schedule 22.04.2012
comment
но это модификация URL-адреса, которую я никогда не мог помешать им щелкнуть по ссылке, которая больше похожа на CSRF, от которой у меня уже есть защита (т.е. путем отказа в отправке формы, если они никогда не запрашивали эту конкретную форму)? - person Laurence; 22.04.2012
comment
Пример, который я привел, является лишь иллюстрацией того, как потенциально можно организовать атаку на описанную вами систему. Приятно слышать, что у вас есть меры против CSRF. Система, которую вы описали, может быть безопасной, если она реализована правильно, но если нет особой необходимости разрешать незакодированный пользовательский ввод, я бы ошибся с осторожностью. - person Jared Ng; 22.04.2012
comment
Это может быть не форма. Например, вы можете использовать XSS в номере страницы. Нет формы для заполнения, чтобы запросить 2-ю страницу. Но злоумышленник может использовать javascript вместо числа в URL-адресе. - person Ha.; 29.05.2014

Нет, нет никакого реального риска, если все их данные просматриваются в частном порядке. Весь смысл XSS заключается в том, чтобы перехватить сеанс или другую личную информацию в браузере другого пользователя. Если такой возможности нет, то нет и XSS.

person Jordan    schedule 22.04.2012
comment
Это не верно. См. два других ответа, почему. - person Brad; 22.04.2012
comment
Нет, это определенно все еще правильно. Принятый ответ вовсе не является XSS-атакой; это скорее фишинг, чем что-либо еще. - person Jordan; 22.04.2012
comment
Итак, XSS требует двух вещей: уязвимости и редактируемой пользователем страницы, отображаемой публично. Принятый ответ надуман, поскольку вы не можете обновить личную страницу только по ссылке. Вы также должны иметь логин. Именно так сформулирован исходный вопрос, поэтому, если нет общедоступных, но редактируемых пользователем данных, риск XSS отсутствует. - person Jordan; 23.04.2012

Да, это не защищает вас вообще. На самом деле это нормальный сценарий. Вы должны учитывать, что если хакер может внедрить XSS на ваш сайт с помощью URL-адреса, а затем убедить кого-то еще открыть этот URL-адрес, тогда данные ваших пользователей (файлы cookie, пароли и т. д.) могут быть украдены.

person McGarnagle    schedule 22.04.2012
comment
но если пользователь А внедряет XSS в СВОИ данные, которые могут видеть только они, - как на самом деле пользователю Б могут быть показаны эти данные? Единственный способ — если пользователь B войдет в систему как пользователь A, и в этом случае они все равно будут видеть только данные пользователя A? - person Laurence; 22.04.2012
comment
Даже если это увидит только пользователь А, как только пользователь Б сможет вставить код на страницу, все будет кончено. Он может написать какой-нибудь Javascript для отслеживания нажатий клавиш пользователя А, получения информации о файлах cookie и т. д. и отправить ее через вызов Ajax на сервер пользователя Б куда-нибудь. - person McGarnagle; 22.04.2012
comment
но как пользователь B может получить данные пользователя A? Они должны войти в систему как пользователь А, чтобы установить его в первую очередь? Следовательно, у них уже есть полный доступ к данным? - person Laurence; 22.04.2012
comment
@Laurencei Нет ... Если пользователь B побуждает пользователя A щелкнуть XSS-модификацию URL-адреса вашего сайта, тогда пользователь A войдет в систему, как обычно, не подозревая, что вредоносный код был внедрен на страницу, которую он просматривает. - person McGarnagle; 22.04.2012
comment
но это модификация URL-адреса, которую я никогда не мог помешать им щелкнуть по ссылке, которая больше похожа на CSRF, от которой у меня уже есть защита (т.е. путем отказа в отправке формы, если они никогда не запрашивали эту конкретную форму)? - person Laurence; 22.04.2012
comment
В этом весь смысл XSS. Конечно, вы никогда не сможете помешать пользователю щелкнуть ссылку — вот почему вы должны проверять любые входные данные на свой сайт (строки запросов, сообщения формы) и следить за тем, чтобы наивно не вводить эти параметры в вашу модель DOM, операторы SQL и т. д. . - person McGarnagle; 22.04.2012