Короче говоря, XSS позволяет запускать javascript в контексте пользователя, предоставляемого через входные данные приложения. Это означает, что делать это через, скажем, консоль разработчика не в счет, пользователю активно приходится открывать консоль и делать то, что он обычно не делает - это не является допустимым вектором атаки в большинстве случаев. Однако все входные данные приложения (входные данные в пользовательском интерфейсе, строке URL, заголовках запросов и т. Д.) Являются потенциальными способами ввода javascript.
В случае отраженного или сохраненного xss запрос отправляется на сервер, и ответ содержит javascript из запроса таким образом, что он запускается на клиенте. Поэтому им нужен сервер.
Однако в случае DOM xss все это может быть на клиенте в уязвимом javascript коде.
Рассмотрим пример, в котором пользовательский интерфейс имеет вход поле, и когда пользователь нажимает кнопку («отправить»), все, что он ввел, добавляется в какой-то журнал (например, «окно чата») с помощью javascript на клиенте. Если пользователь вводит <script>alert(1)</script>, он может быть добавлен как html в область журнала, таким образом, будучи выполненным как javascript, без какой-либо отправки на сервер. Это может быть примером DOM xss, и исправление, очевидно, заключается в добавлении его в виде текстового узла вместо html.
Обычно это оценивается как более низкий риск, поскольку во многих случаях удаленный злоумышленник ограничен возможность фактически использовать это против ничего не подозревающего пользователя. Но это все еще уязвимость (например, злоумышленник может заставить пользователя скопировать что-либо в поле и т. Д.).
Также типичный случай, когда это возможно, - javascript читает и добавляет к DOM - часть URL-адреса, которую фактически может предоставить удаленный злоумышленник (в виде ссылки, отправленной пользователю-жертве).