Может ли злоумышленник использовать осмотреть элемент вредно?
Я знаю, что это широкий вопрос, но я думаю, что мне здесь чего-то не хватает. Может ли злоумышленник нанести ущерб сайту, просто используя элемент inspect и редактируя javascript и html? Например, кому-то кажется слишком простым изменить максимальную длину ввода и загрузить столько данных, что это может привести к сбою на сервере, я знаю, что всегда полезно проверять данные на сервере, но это все еще кажется слишком простым. Или другой, более потенциально опасный пример: атакующий может связываться с $.ajax позвонить и отправить плохую информацию на сервер. Это то, о чем я должен больше беспокоиться, или это временные изменения в браузере злоумышленников?
4 ответа
Изменения являются временными в браузере отдельного пользователя.
Тем не менее, изменения позволят этому пользователю взаимодействовать с вашим бэкэндом, как он того пожелает. Это один из способов атаки сайтов.
Стандартное правило - никогда не доверять входным данным, поступающим от пользователя / браузера. Не доверяйте значениям скрытых полей, не верьте, что они не изменили длину, не верьте, что они не добавили новые значения (например, в раскрывающийся список), не доверяйте никаким проверкам, которые были сделаны в Javascript, и т.п.
Некоторые примеры:
- Некоторые торговые сайты в прошлом включали сумму, которую нужно было заплатить, в виде скрытого поля в форме. Изменение этого значения изменило сумму, начисленную на кредитную карту, все еще подтверждая транзакцию.
- Сайты с правилами проверки Javascript, которые могут быть пропущены путем публикации непосредственно в бэкэнд-сервис, открывая себя для атак с использованием SQL и HTML / Script.
- Выпадающие списки, переключатели и флажки вводят, где неожиданные значения могут быть добавлены в форму.
Да, они могут. Когда они проверяют элементы, они могут изменять все локально, поэтому это будет временное изменение для их локальной среды, однако они могут изменять значения, которые могут повлиять на ваш сервер.
Например, давайте представим, что у вас есть интернет-магазин, и у вас есть опция "Изменить продукт". Как только вы перейдете туда, у вас появится скрытое поле, в котором вы сохраните идентификатор продукта, так что при попытке обновить этот продукт в своем бэкэнде вы будете использовать этот идентификатор, чтобы узнать, какой продукт нужно обновить. Злоумышленник может легко изменить это значение, и теперь он сможет изменять любой другой продукт (включая продукты, которые ему не принадлежат).
Другим классическим примером может быть числовое поле, где вы предполагаете, что пользователь сможет представлять только числовые значения, поэтому в вашем бэкэнде вы используете это число в своем запросе, например, что-то вроде
"SELECT * FROM Products WHERE Price > " + Price;
Вы ожидаете числовое значение, поэтому вы думаете, что злоумышленник не может отправить текст для SQL-инъекции, но он может легко изменить это значение (либо путем изменения числового ввода для ввода текста, либо изменения значения javascript перед отправив его или перехватив сетевой трафик и изменив значение оттуда), и теперь вы можете получить что-то вроде:
"SELECT * FROM Products WHERE Price > 0; DROP TABLE Products--"
Это главная причина, по которой вы никогда не должны доверять пользовательскому вводу. Вы ожидаете числовое значение? Затем убедитесь, что это число, прежде чем использовать его. Ваш пользователь обновляет продукт? Убедитесь, что продукт действительно принадлежит ему, прежде чем обновлять его. У вас есть свойство maxlength для ваших данных? Дважды проверьте ваш сервер, чтобы убедиться, что он по-прежнему имеет допустимую длину.
Это может показаться чем-то действительно легким и простым, но люди делают ошибки. Простым примером является ошибка "Heart Bleed", когда все, чего можно было избежать, проверяя длину запроса, а не доверяя предоставленным пользователем данным.
И это главная причина, по которой вам никогда не нужно доверять отправленным пользователем данным и всегда выполнять двойную проверку в своем бэкэнде.
Вы должны беспокоиться об этом. Никогда не доверяйте данным, поступающим от клиента. Не ожидайте, что любая проверка, которую вы выполняете на стороне клиента, действительно выполняется. Вам всегда нужно проверять ввод на стороне сервера. Как вы уже упоминали, пользователь может использовать различные инструменты проверки для изменения локального кода или просто вручную создать вредоносный пакет.
Да, они могут. Они могут видеть ваш код, давая им шанс найти уязвимость или сделать уязвимость и атаковать уязвимость. Хотя правки носят временный характер и предназначены только для браузера злоумышленника, они могут нанести вред.