Объявите войну атакам SQL-инъекций
Мы уже должны были искоренить атаки SQL-инъекций. SQL-инъекция должна стать оспой или полиомиелитом интернет-поколения - ушла навсегда. Контрмеры легко доступны и понятны. Их легко реализовать. И все же я продолжаю видеть заголовки вроде: "огромная хакерская атака в Интернете заражает 500 000 страниц."
Атаки SQL-инъекций по-прежнему остаются одними из самых плодотворных против веб-сайтов и приложений. А почему бы и нет? С точки зрения злоумышленника, база данных, стоящая за многими веб-приложениями, является местом, где живут действительно сочные цели. Вот где вы найдете записи клиентов, номера кредитных карт и другие хорошие вещи.
И теперь злоумышленники начали использовать SQL инъекции для установки вредоносных программ на веб-сайтах, так что посетители этих сайтов получают свои компьютеры зараженными вредоносными программами. Базы данных находятся не только там, где находятся сочные цели; они созрели для посадки вредоносных данных, которые заражают компьютеры других людей.
Это повышает ставки и делает еще более убедительным аргументом для искоренения всех существующих дефектов SQL-инъекций. Мы должны убедиться, что ни одно из будущих приложений не имеет дефектов SQL-инъекции. Давайте посмотрим поближе, чтобы увидеть, что происходит.
SQL, или язык структурированных запросов, - это интерпретируемый язык баз данных, который обычно используется серверами приложений при общении с серверами баз данных. Базы данных-это то место, где, как я уже сказал, Мы храним такие вещи, как записи клиентов. Запись может состоять из имени клиента, адреса, адреса электронной почты, номера телефона и информации об оплате кредитной картой.
Как это работает
Чтобы просмотреть данные одного клиента в базе данных, на сервере приложений создается SQL-запрос и отправляется в базу данных, которая должна возвращать информацию этого клиента и ничего больше. Запрос может выглядеть примерно так:
выберите * из клиентов, где last_name= 'Smith'
Так в чем же дело? Ну, на серверах приложений имя клиента обычно представляется в виде переменной со значением, которое вводится в приложение через веб-форму - с данными, поступающими от пользователя приложения. Таким образом, в Java запрос может быть построен примерно следующим образом:
String query = " Select * from customers where last_name=' " + req.getParameter ("фамилия")+"'";
Видишь, в чем проблема? Ну, в обычном функциональном случае пользователь вводит в это поле фамилию, такую как "Смит", но злоумышленник может так же легко ввести значение "' или '1'='1'-". Это приведет к тому, что на сервер будет отправлен запрос, подобный следующему:
выберите * из клиентов, где last_name= " или ' 1 ' = '1'
Это логическое выражение (last_name=" или '1'='1') всегда будет истинным, что приведет к тому, что сервер базы данных ответит всем содержимым таблицы данных клиента. То есть наш злоумышленник, скорее всего, просто преуспел в извлечении клиентских данных каждого из наших клиентов. Не хороший.
Но я сказал, что эту проблему легко исправить. Видите ли, основная проблема в приведенном выше сценарии заключается в том, что намерение логики SQL может быть изменено злонамеренно сформированными пользовательскими данными. Но Java и большинство веб-языков предоставляют нам простое решение, называемое параметризованными запросами.
В параметризованном запросе данные передаются в SQL-запрос как фактические данные, а не как часть самого синтаксиса SQL. Требуется лишь немного больше усилий, чтобы настроить запрос, но затем это делается, и любые данные, предоставленные злоумышленником, не изменят намерения нашего запроса.
Как это исправить
Вот как выглядел бы наш запрос выше, если бы мы использовали параметризованный механизм запросов Java, известный как подготовленные операторы:
Строка фамилия = req.getParameter ("фамилия"); String query = " Select * from customers where last_name = ?"PreparedStatement pstmt = соединение.prepareStatement (запрос); pstmt.setString(1, фамилия); try { ResultSet results = pstmt.выполнять( ); }
Итак, это еще пара строк кода, но это простой шаблон, которому нужно следовать. И результаты функционально идентичны уязвимой форме - но без уязвимости.
Если мы просто пройдем через наши веб-приложения и изменим все наши SQL-запросы в форму готового оператора, мы сможем полностью уничтожить все слабые места SQL-инъекций в мире. Серьезно.
У нас все еще будет много других проблем, таких как межсайтовые сценарии (также известные как "XSS"), но мы полностью исключим эту проблему с SQL-инъекцией.
Я знаю, что вы, должно быть, думаете: это не может быть так просто, иначе мы бы покончили с SQL-инъекцией много лет назад. Это было бы правдой лишь отчасти. На техническом уровне все очень просто. Но на человеческом уровне-не так уж и много.
Чтобы решить проблему SQL-инъекции, должно существовать несколько предварительных условий. Во-первых, мы должны иметь доступ к самому исходному коду приложения. Если наше приложение было передано на аутсорсинг или мы полагаемся на сторонний код, это может быть совсем не так просто.
И это всего лишь одно из человеческих препятствий, которые я слышал в качестве оправдания для того, чтобы не исправить дефект безопасности. Есть много других.
Но давайте, ребята, мы заслуживаем лучшего, чем статус-кво. Наши компании заслуживают лучшего; наши пользователи заслуживают лучшего; действительно, наши клиенты заслуживают лучшего. Давайте перестанем искать оправдания и начнем искать причины. Поставьте себе целью пройти через ваши веб-приложения прямо сейчас и искоренить каждую слабость SQL-инъекции. И пока вы этим занимаетесь, обязательно научите каждого из ваших разработчиков программного обеспечения делать безопасные вызовы SQL.
Больше никаких SQL-инъекций. Больше никаких оправданий.
Дата публикации: Атаки SQL-инъекций по-прежнему остаются одними из самых плодотворных против веб-сайтов и приложений. А почему бы и нет? С точки зрения злоумышленника, база данных, стоящая за многими веб-приложениями, является местом, где живут действительно сочные цели. Вот где вы найдете записи клиентов, номера кредитных карт и другие хорошие вещи.
И теперь злоумышленники начали использовать SQL инъекции для установки вредоносных программ на веб-сайтах, так что посетители этих сайтов получают свои компьютеры зараженными вредоносными программами. Базы данных находятся не только там, где находятся сочные цели; они созрели для посадки вредоносных данных, которые заражают компьютеры других людей.
Это повышает ставки и делает еще более убедительным аргументом для искоренения всех существующих дефектов SQL-инъекций. Мы должны убедиться, что ни одно из будущих приложений не имеет дефектов SQL-инъекции. Давайте посмотрим поближе, чтобы увидеть, что происходит.
SQL, или язык структурированных запросов, - это интерпретируемый язык баз данных, который обычно используется серверами приложений при общении с серверами баз данных. Базы данных-это то место, где, как я уже сказал, Мы храним такие вещи, как записи клиентов. Запись может состоять из имени клиента, адреса, адреса электронной почты, номера телефона и информации об оплате кредитной картой.
Как это работает
Чтобы просмотреть данные одного клиента в базе данных, на сервере приложений создается SQL-запрос и отправляется в базу данных, которая должна возвращать информацию этого клиента и ничего больше. Запрос может выглядеть примерно так:
выберите * из клиентов, где last_name= 'Smith'
Так в чем же дело? Ну, на серверах приложений имя клиента обычно представляется в виде переменной со значением, которое вводится в приложение через веб-форму - с данными, поступающими от пользователя приложения. Таким образом, в Java запрос может быть построен примерно следующим образом:
String query = " Select * from customers where last_name=' " + req.getParameter ("фамилия")+"'";
Видишь, в чем проблема? Ну, в обычном функциональном случае пользователь вводит в это поле фамилию, такую как "Смит", но злоумышленник может так же легко ввести значение "' или '1'='1'-". Это приведет к тому, что на сервер будет отправлен запрос, подобный следующему:
выберите * из клиентов, где last_name= " или ' 1 ' = '1'
Это логическое выражение (last_name=" или '1'='1') всегда будет истинным, что приведет к тому, что сервер базы данных ответит всем содержимым таблицы данных клиента. То есть наш злоумышленник, скорее всего, просто преуспел в извлечении клиентских данных каждого из наших клиентов. Не хороший.
Но я сказал, что эту проблему легко исправить. Видите ли, основная проблема в приведенном выше сценарии заключается в том, что намерение логики SQL может быть изменено злонамеренно сформированными пользовательскими данными. Но Java и большинство веб-языков предоставляют нам простое решение, называемое параметризованными запросами.
В параметризованном запросе данные передаются в SQL-запрос как фактические данные, а не как часть самого синтаксиса SQL. Требуется лишь немного больше усилий, чтобы настроить запрос, но затем это делается, и любые данные, предоставленные злоумышленником, не изменят намерения нашего запроса.
Как это исправить
Вот как выглядел бы наш запрос выше, если бы мы использовали параметризованный механизм запросов Java, известный как подготовленные операторы:
Строка фамилия = req.getParameter ("фамилия"); String query = " Select * from customers where last_name = ?"PreparedStatement pstmt = соединение.prepareStatement (запрос); pstmt.setString(1, фамилия); try { ResultSet results = pstmt.выполнять( ); }
Итак, это еще пара строк кода, но это простой шаблон, которому нужно следовать. И результаты функционально идентичны уязвимой форме - но без уязвимости.
Если мы просто пройдем через наши веб-приложения и изменим все наши SQL-запросы в форму готового оператора, мы сможем полностью уничтожить все слабые места SQL-инъекций в мире. Серьезно.
У нас все еще будет много других проблем, таких как межсайтовые сценарии (также известные как "XSS"), но мы полностью исключим эту проблему с SQL-инъекцией.
Я знаю, что вы, должно быть, думаете: это не может быть так просто, иначе мы бы покончили с SQL-инъекцией много лет назад. Это было бы правдой лишь отчасти. На техническом уровне все очень просто. Но на человеческом уровне-не так уж и много.
Чтобы решить проблему SQL-инъекции, должно существовать несколько предварительных условий. Во-первых, мы должны иметь доступ к самому исходному коду приложения. Если наше приложение было передано на аутсорсинг или мы полагаемся на сторонний код, это может быть совсем не так просто.
И это всего лишь одно из человеческих препятствий, которые я слышал в качестве оправдания для того, чтобы не исправить дефект безопасности. Есть много других.
Но давайте, ребята, мы заслуживаем лучшего, чем статус-кво. Наши компании заслуживают лучшего; наши пользователи заслуживают лучшего; действительно, наши клиенты заслуживают лучшего. Давайте перестанем искать оправдания и начнем искать причины. Поставьте себе целью пройти через ваши веб-приложения прямо сейчас и искоренить каждую слабость SQL-инъекции. И пока вы этим занимаетесь, обязательно научите каждого из ваших разработчиков программного обеспечения делать безопасные вызовы SQL.
Больше никаких SQL-инъекций. Больше никаких оправданий.
Автор: Keylogger.Org Команда
