Что Роберт С. Мартин подразумевает под ненужностью SQL? [закрыто]


45

Я читал / смотрел много контента Роберта С. Мартина. Я сталкивался с ним, говоря, что SQL не нужен из-за твердотельных накопителей. Когда я ищу другие источники, чтобы поддержать это, я получаю кучу случайных статей, описывающих разницу производительности SQL между жесткими дисками и твердотельными накопителями (что связано, но не то, что я пытаюсь исследовать).

В конечном счете, я не понимаю, к чему он стремится. Он говорит заменить SQL технологиями без SQL? Он говорит хранить данные в файлах в файловой системе? Или он просто хочет, чтобы люди прекратили использовать SQL / реляционные базы данных из-за SQLi-атак? Боюсь, мне не хватает того, что он пытается сделать.

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

  1. Бобби Столы
  2. Лекция «Чистая архитектура»

Во-первых, он заявляет, что SQL должен быть полностью удален из системы.

Решение. Единственное решение. Это исключить SQL из системы полностью. Если нет механизма SQL, тогда не может быть никаких атак SQLi.

И хотя он говорит о замене SQL на API, я НЕ думаю, что он имеет в виду поместить SQL за API из-за этой предыдущей цитаты и того, что он сказал ранее в этой статье.

Рамки не решают проблему; ...

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

Если SQL не используется для сохранения данных, то что мы должны использовать?

Прежде чем ответить на это, я должен также отметить. Роберт подчеркивает, что твердотельные накопители должны изменить инструменты, которые мы используем для сохранения данных. Ответ Сёрена Д. Птюса указывает на это.

Я также должен ответить на группу «но целостность данных». После некоторых дальнейших исследований Роберт говорит, что мы должны использовать транзакционные базы данных, такие как datomic . Затем CRUD превращается в CR (создание и чтение), и транзакции SQL вообще исчезают. Целостность данных, конечно, важна.

Я не могу найти вопрос, который охватывает все это. Я думаю, я ищу альтернативы, которые соответствуют рекомендациям Роберта. Datomic один, но это так? Какие другие варианты соответствуют этим рекомендациям? И действительно ли они лучше работают с твердотельными накопителями?


5
@ christo8989 - «Что он подразумевает под заменой SQL на API?». Я понимаю, что он означает, что у вас нет текстового языка запросов (который передается в движок SQL) по всей вашей кодовой базе. Вы скрываете это за API, который предоставляет только безопасные механизмы для описания запросов. Внутренняя к API - то должен генерировать команды на SQL двигатель, но это меньшая площадь поверхности , в которой можно принудительно использовать параметр связывания и т.д., контроль , который вносит изменения и т.д.
андрей

42
Но, но, но ... SQL - это API. Это API для СУБД. Это просто очень мощный API, который можно легко использовать неправильно.
Барт ван Инген Шенау

25
При создании API DB , который не имеет текстовый интерфейс, рано или поздно какой - то бедный программист будет писать код , который выглядит следующим образом : eval(request.GET["table_name"] + ".get(pk=" + request.GET["pk"] + ")")). В этом виноват не SQL, а бедные, невежественные программисты.
Ли Райан

6
@JimmyJames SQL - это язык да, но это не значит, что это не API. SQL - это язык, который предоставляет API для доступа к некоторому базовому хранилищу.
Куб

5
@nocomprende SQL всегда разрабатывался для использования в приложениях. В противном случае это было бы практически бесполезно. Смысл всегда состоял в том, чтобы дать приложениям какой-то способ хранения и извлечения данных, не связываясь со странными пользовательскими форматами или даже не заботясь о том, как хранятся данные.
Куб

Ответы:


74

Боб Мартин явно преувеличивает, чтобы прояснить свою точку зрения. Но в чем его смысл?

Он просто хочет, чтобы люди прекратили использовать SQL / реляционные базы данных из-за SQLi-атак?

Насколько я понимаю, в этом посте (ваша первая ссылка) Мартин пытается убедить людей прекратить использовать SQL, а не реляционные базы данных. Это две разные вещи .

SQL является чрезвычайно мощным языком, и он в некоторой степени стандартизирован. Это позволяет создавать сложные запросы и команды очень компактным образом, читаемым, понятным и простым в освоении способом. Он не зависит от другого языка программирования, поэтому его можно использовать большинству разработчиков приложений, независимо от того, предпочитают ли они Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP или что-то еще.

Тем не менее, эта возможность требует затрат : написание безопасных SQL-запросов / команд сложнее, чем написание небезопасных. Безопасный API должен облегчать создание безопасных запросов «по умолчанию». Потенциально небезопасным нужно больше умственных или, по крайней мере, больше печатных усилий. ИМХО, почему Мартин разглагольствует против SQL в его нынешнем виде.

Проблема не нова, и есть более безопасные API, чем стандартный SQL, для доступа к реляционной базе данных. Например, все известные мне операторы OR пытаются предоставить такой API (хотя обычно они предназначены для других основных целей). Варианты статического SQL затрудняют создание любых динамических запросов с неанизированными входными данными (и это не новое изобретение: встроенному SQL, который часто использует статический SQL, около 30 лет).

К сожалению, я не знаю ни одного API, который был бы таким же гибким, стандартизированным, зрелым, независимым от языка и мощным, как SQL, особенно динамический SQL. Вот почему у меня есть некоторые сомнения по поводу предложения Мартина «не использовать SQL» в качестве реалистичного способа решения упомянутых проблем. Поэтому читайте его статью как мысль в правильном направлении, а не как «лучшую практику», которой вы можете слепо следовать с завтрашнего дня.


2
По крайней мере, мы можем избежать его использования для любой операции записи, обычно с тем, что предоставляют ORM-подобные вещи. Что касается запросов к базе данных, вы уже можете делать некоторые вещи без написания собственного SQL. В настоящее время только "расширенное" использование возможностей базы данных должно требовать написания SQL или использования сложного типа данных (граф, географические данные, рекурсивные).
Вальфрат

7
Мартин особо утверждает, что используемый API не должен быть таким мощным, как SQL; Его аргумент, что сила SQL - это проблема, а не особенность. API, за который он спорит, должен быть специфичным для приложения и быть настолько гибким и мощным, насколько это абсолютно необходимо приложению, а не больше. Он специально спорит против изобретения другого языка запросов на основе строк.
Куб

3
@Cubic: любое решение проблем, упомянутых Мартином, вероятно, должно быть менее мощным или менее простым в использовании, чем SQL - это их благословение и проклятие.
Док Браун

1
@ Бармар: SQL почти настолько высок, насколько вы можете получить, и Боб утверждает, что он явно небезопасен.
Роберт Харви

3
@ christo8989: Я не думаю, что имеет смысл пытаться написать один ответ как ответ на все то, что Мартин когда-то написал или сказал в своей карьере. Мой ответ был один на вопрос, заданный в вашем заголовке, и объяснял главным образом, как сообщение в блоге в первой ссылке, которую вы дали, следует интерпретировать ИМХО.
Док Браун

57

Мнение Боба Мартина именно это; мнение одного человека.

Предполагается, что программист понимает систему, которую он пишет, достаточно хорошо, чтобы проявлять разумную заботу о ее безопасности и производительности. Это означает, что если вы говорите с базой данных SQL, вы делаете то, что говорит веб-сайт Bobby Tables : вы дезинфицируете свои входные данные. Это означает, что вы размещаете свою базу данных SQL на машине, которая обещает адекватную производительность. Есть очень хорошо известные и понятные способы сделать это, и хотя они не гарантируют абсолютную безопасность или идеальную производительность, они не делают ничего другого.

Утверждение, что нам больше не нужен SQL, потому что у нас теперь есть твердотельные накопители, является просто ложным. SQL не был изобретен, потому что высокоскоростных жестких дисков еще не было; он был изобретен, потому что нам нужен был стандартный для отрасли способ выражения концепций извлечения данных. Системы реляционных баз данных обладают многими другими качествами, помимо скорости и безопасности, что делает их идеальными для бизнес-операций; в частности, КИСЛОТА . Целостность данных, по крайней мере, так же важна, как скорость или безопасность, и если у вас ее нет, то какой смысл защищать плохие данные или извлекать их как можно быстрее?

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

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


16
Я не интерпретирую статьи Мартина как выступающие за отказ от РСУБД, а скорее использую альтернативные способы взаимодействия с ними, например, LINQ-to-SQL или JPA Criteria API, вместо прямого кодирования или манипулирования строками SQL в нашем исходном коде.
Жюль

27
Поэтому мы не должны слепо следовать тому, что он говорит ... но что он говорит ?
TRiG

33
Одна вещь, которая мне действительно не нравится в сообществе, это то, что, как только вы задаете вопрос о том, как сделать что-то с Чистым Кодом / Дядей Бобом , люди говорят вам, как вы должны делать что-то другое . "Как рисовать, как Ван Гог?" - «Ван Гог был неправ, вы должны рисовать как Пикассо».
Р. Шмитц

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

17
Все технологии обречены и по сути ошибочны. Это только вопрос времени. Между тем, у нас есть вещи, которые нам нужно сделать, с нашими ошибочными и обреченными технологиями.

15

Что он на самом деле говорит?

Он говорит заменить SQL технологиями без SQL?

TL; DR: Да (вроде)

В более недавнем выступлении, чем тот, на который вы ссылались, в основном на ту же тему, он говорит: «База данных - это деталь. Зачем нам базы данных? ,

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

Далее он предсказывает, что реляционные базы данных в целом исчезнут из-за их новой конкуренции:

Если бы я был Oracle, я бы очень испугался, потому что причина моего существования испаряется из-под меня. [...] Причина существования базы данных исчезает.

Вероятно, будут некоторые выжившие реляционные таблицы, но теперь есть здоровая конкуренция .

Так что нет, для него речь идет не только об SQL-инъекции, хотя он полагает, что SQL изначально имеет недостатки в этом отношении .


Примечание автора:

Заявления в этом посте являются только цитатами, чтобы понять точку зрения Роберта С. Мартина на эту тему и не отражают мнение автора. Для более дифференцированной точки зрения см . Ответ Роберта Харви .


2
«Постоянное ОЗУ», по-видимому, предназначено только для использования баз данных для сериализации текущего состояния приложения без учета прямой или обратной совместимости. Конечно, некоторые базы данных используются таким образом, но далеко не все (я понимаю, что это говорит Мартин, а не вы).
Куб

7
Итак, Мартин на самом деле говорит, что единственная точка баз данных - это абстрагирование по медленному хранилищу? Ух ты. Тогда это подтверждает ответ Роберта Харви: его мнение следует воспринимать с огромной долей соли. Например, эта точка зрения не учитывает, что значение БД поддерживает согласованную и постоянную модель данных. Его идея структур данных в «постоянной памяти» (SSD?) Медленная и открывает возможность потери данных, даже базы данных NoSQL часто используют журналирование и неизменяемые структуры данных для безопасного обновления постоянных записей.
Амон

3
@amon Да, Роберт Харви прав, предлагая более дифференцированную точку зрения. Но поскольку ОП спросил конкретно о том, что Роберт С. Мартин пытается сказать, я расшифровал часть его «более новой» беседы.
Сёрен Д. Птюс

3
@amon - см. первое предложение ответа Дока Брауна выше. Мартин часто делает заявления, которые являются большими преувеличениями его пункта, чтобы объяснить это. Он не означает, что все операции с базами данных могут быть заменены хранилищами в памяти, более того, он просто подразумевает, что наличие компонента вашего приложения, который в той или иной форме касается SQL, является достаточно серьезным риском для безопасности, которого следует избегать во всех случаи, но на первый взгляд его слова могут быть истолкованы как высказывание этого. Но все, что он действительно пытается сделать, - это заставить всех задуматься: подходит ли SQL / RDBMS для моего приложения?
Жюль

12
@ Джулс, я понимаю, что он часто преувеличивает. Но учитывая его охват и репутацию, совершенно бесполезно, что «дядя Боб» не дает понять, когда преувеличивает и где он на самом деле говорит, что имеет в виду. Если он должен что-то преподавать, невозможно переоценить и переосмыслить все, что он говорит, пока это не имеет никакого смысла , тем более что он сам не отражает и не критикует свои идеи. В какой-то момент легче сказать «не слушай его», или даже: дядя Боб считался вредным .
Амон

11

SQL это деталь. Знание детали не должно распространяться.

Поскольку SQL используется во все большем количестве мест в вашем коде, ваш код становится все более зависимым от него.

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

Вы сталкиваетесь с этим даже переключаясь между базами данных. Один предлагает необычную функцию whizzbang 5, поэтому вы можете использовать ее в ряде мест только для того, чтобы узнать, что причудливая функция whizzbang 5 проприетарна, и теперь у вас есть проблема с лицензированием, которая будет стоить больших денег. Таким образом, вы проделали большую работу, выискивая всюду, где использовали функцию 5, и решали проблему самостоятельно, чтобы потом выяснить, используете ли вы функцию whizzbang 3.

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

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

Тот факт, что SQL имеет проблемы с безопасностью и что мы переходим к постоянным моделям памяти, не означает, что SQL обречен. Это просто указывает на то, что это выбор. Если вы хотите сохранить за собой право сделать этот выбор, вы должны сделать эту работу.


Возможно, стоит отметить, что движение баз данных 80-х годов и дядя Боб имеют довольно неприятную историю. Все его проблемы были решены с помощью плоской файловой системы, когда управление заставило администратора базы данных войти в его жизнь. Это событие подтолкнуло его в его звездную консультационную карьеру. (Он рассказывает эту историю в одной из своих ранних чистых книг, забудьте, что). Он знает, как решать проблемы без БД, и у него мало терпения к тем, кто ведет себя так, будто их использование - само собой разумеющееся.

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


1
Гоша, Эйнштейн, конечно.

1
Ах, не знал, что Эйнштейн знал Боба. Или этот Боб был Богом. Хотя это звучит так, будто в нем есть что-то интересное.
candied_orange

9
@nocomprende вы живете на постоянной диете мотивационных плакатов?
candied_orange

2
Но Боб - это Бог. По крайней мере, для некоторых.
Питер Мортенсен

3
Я отказываюсь верить, что Бог так хорош в публичных выступлениях.
candied_orange

5

Цитата из вашей первой цитаты (выделено мной),

Решение. Единственное решение. Это исключить SQL из системы полностью. Если нет механизма SQL, тогда не может быть никаких атак SQLi.

Что бы заменить SQL? API конечно! И НЕ API, который использует текстовый язык. Вместо этого API, который использует соответствующий набор структур данных и вызовов функций для доступа к необходимым данным.

Разговор против того, чтобы позволить прикладным программистам использовать SQL.

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

ИМО, примеры таких API могут включать:

  • http://bobby-tables.com/csharp предлагает программистам C # использовать API ADO.NET.

    Это не идеальный пример, потому что ADO.NET - это широкий или глубокий (то есть мощный или универсальный) API, который также позволяет своим пользователям вводить необработанный (или необработанный) SQL.

  • Некоторые разработчики SQL или администраторы баз данных предлагают настроить базу данных таким образом, чтобы она разрешала доступ только через (ограниченное количество написанных экспертами) хранимых процедур , и чтобы разработчикам приложений не разрешалось писать свои собственные (опасные) запросы SQL.

  • Другой способ «исключить SQL из системы» - поместить базу данных (которая предоставляет SQL) в какую-то другую систему, доступ к которой осуществляется через REST API или аналогичный.

Таким образом, IMO, общее решение или системы все еще могут использовать базу данных (особенно если учесть, что ядро ​​базы данных реализует полезные свойства ACID, хорошо масштабируется и т. Д., Может быть глупо пытаться обходиться без такового или писать для конкретного приложения).

Требования rant удовлетворяются, если SQL API базы данных скрыт от разработчиков приложений за каким-либо другим API (например, ADO, возможно, ORM, веб-сервисом или чем-то еще).

В более общем смысле я предполагаю, что это означает наличие DAL для конкретного приложения («уровень доступа к данным» или «уровень абстракции базы данных»). DAL изолирует приложение от деталей того, как и где данные хранятся и / или выбираются. DAL может или не может быть реализован с использованием базы данных SQL.


Я работал над продуктом, который сделал именно это 30 лет назад. И базовая база данных даже не поддерживала SQL (пока). И набор связанных таблиц был сохранен в (подождите это ...) базе данных. Парень, который придумал это, был действительно умным. Уже не программист.

Мне нравится этот ответ, но я думаю, что он может не говорить это. Он также заявляет: «Фреймворки не решают проблему ...». Из вашего ответа кажется, что вы говорите, что использование Linq-to-Sql - это нормально, но разве это не фреймворк, решающий проблему?
christo8989

@ christo8989 Я не знаю. Он упоминает Hibernate как пример структуры, которая не справится с этой проблемой. И действительно, OWASP говорит : «Hibernate не предоставляет иммунитет к SQL-инъекциям, можно использовать API по своему усмотрению. В HQL (подмножестве Hibernates SQL) нет ничего особенного, что делает его более или менее восприимчивым». В то время как некоторые из упомянутых мною API были бы лучшими изоляторами, вообще не выставляя SQL. Возможно, Hibernate - это то, что вы можете использовать для реализации DAL (но сам по себе он не является полностью изолирующим DAL).
ChrisW

1
@ christo8989 augustl.com/blog/2016/… предполагает, что Datomic (просто) является еще одной оболочкой / слоем вокруг (возможно, SQL) базы данных - «Datomic не записывает напрямую в файловую систему. Вместо этого вы можете использовать число различных баз данных в качестве хранилища данных для Datomic: любая база данных SQL JDBC и т. д. "
ChrisW

Следует отметить, что решение, позволяющее избежать внедрения SQL в ADO.NET , не так уж и сложно: используйте заполнители в SQL, используйте параметры в команде и установите значение этих параметров.
Зев Шпиц

3

Кажется, что каждый отвечает на этот вопрос с точки зрения безопасности или с помощью объектива SQL.

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

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


Что он может думать о многопользовательском параллельном чтении / записи данных?
ChrisW

1
@ChrisW Я не думаю, что это проблема реализации, а скорее идея высокого уровня - найти способ улучшить постоянное хранение данных.
Кинан

@ChrisW Он также говорит о транзакционных базах данных. Использование технологии управления исходным кодом в качестве инструмента сохранения. При этом вы только создаете и читаете, что гораздо более дружественно, чем транзакции и обновления.
christo8989

@Keenan Так что он не предлагает решения через реализацию. Он просто говорит, подумай, что может быть?
christo8989

1
@ christo8989 Имеет ли он личный опыт разработки кандидатских решений для постоянной проблемы хранения в компьютерной науке, я не знаю. Это выходит за рамки вопроса ОП. Дядя Боб - это плагин для архитектуры. Текущий отраслевой стандарт разработки приложений тесно связан с базой данных и строит приложение вокруг нее, приложение зависит от базы данных, когда база данных должна зависеть от приложения. Скорее, дядя Боб предлагает, чтобы «база данных была деталью», и она должна быть отделена и заменена.
Кинан

2

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

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

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

в отличие от

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

Это пример DBI Perl для кода ruby ​​on rails. Код рельсов, который он предоставляет, легко перепутать между безопасным и небезопасным. Как и многие ORM, скрывает то, что находится под SQL, и так часто вы имеете дело с интерфейсом, который создает и выполняет SQL для вас. Разве это не похоже на то, что API сделает для вас?

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

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

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

Да, вращающиеся диски остались в прошлом, и теперь мы используем твердотельные накопители. Диски работают с ~ 10 миллисекундами на передачу данных, SSD работают с ~ 0,5 миллисекундами (500 мкс) времени доступа к данным. Объем оперативной памяти составляет порядка 100 наносекунд, процессоры работают на порядка 100 секунд пико-секунд. Это суть того, почему нам нужны базы данных. Базы данных управляют передачей данных между вращающимися дисками или твердотельными накопителями с основной памятью. Появление SSD не устранило необходимость в базах данных.


4
«ОСТАНОВИТЬ ИСПОЛЬЗОВАНИЕ SQL» (цитируется по первой ссылке) очень похоже на то, что он говорит, что не использует SQL, насколько я понимаю.
Док Браун

6
Это проблема порядка слов. На самом деле это была первоначально телеграмма: ИСПОЛЬЗОВАНИЕ SQL STOP

6
@nocomprende То есть ты говоришь, что он стал жертвой расы? Ну ой. Он мог бы избежать этого, используя транзакции SQL.
Конрад Рудольф

Может быть, это очень короткая смесь Visual Basic и Fortran. Где все это закончится?

1
@KonradRudolph: Ну, я думаю, мы бы согласились, что практически никто не будет использовать TSX прямо из сборки. Будут абстракции более высокого уровня. Будут ли эти абстрактные транзакции транзакциями SQL? Думаю, нет. Как интерпретируемый язык, SQL несет нагрузку на производительность. Это действительно не имело значения, когда вы обращались к данным на вращающихся жестких дисках. Однако это невозможно при доступе к данным в оперативной памяти.
MSalters

2

Ответ

он просто хочет, чтобы люди прекратили использовать SQL / реляционные базы данных из-за SQLi-атак?

Статья «Таблицы Бобби», кажется, предполагает, что это, само по себе является причиной не использовать SQL:

Решение. Единственное решение. Это исключить SQL из системы полностью. Если нет механизма SQL, тогда не может быть никаких атак SQLi.

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

отступление

Эта часть на самом деле не является ответом, но я думаю, что вопрос о значении SQL гораздо интереснее (как, впрочем, и другие).

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

Поскольку инъекция SQL является аргументом в пользу неиспользования SQL, это смешно. Это хорошо понятная проблема с довольно простым решением. Проблема с этим аргументом в том, что SQLi не единственная существующая уязвимость. Если вы думаете, что использование JSON API делает вас безопасным, вас ждет большой сюрприз.

Я думаю, что каждый разработчик должен посмотреть это видео под названием «Пятница, 13-е: атака на JSON - Альваро Муньос и Александр Мирош - AppSecUSA 2017»

Если у вас нет времени или желания просматривать его, вот суть: многие библиотеки десериализации JSON имеют уязвимости удаленного выполнения кода. Если вы используете XML, вам есть о чем беспокоиться. Запрет SQL в вашей архитектуре не сделает вашу систему безопасной.


Никто не утверждал, что запрет SQL сам по себе сделает вашу систему безопасной. Дядя Боб утверждает, что это делает вашу систему более безопасной, и учитывая, что внедрение SQL-кода остается самым большим риском для безопасности веб-приложений уже более десяти лет, я думаю, вам не следует пренебрегать необходимостью для отрасли улучшить способ взаимодействия с базами данных. ,
Меритон

@meriton Извините, но «решение, единственное решение» кажется довольно ясным. Решение проблемы SQLi известно и довольно просто. Люди, которые не могут быть обеспокоены использованием операторов подготовки, будут создавать небезопасные системы независимо от того, прекратят ли они использовать SQL. Это непрофессиональные люди, которые должны начать следовать базовым хорошим практикам или получить новую работу.
JimmyJames

2

Я хочу обратиться только к короткому заявлению:

Или он просто хочет, чтобы люди прекратили использовать SQL / реляционные базы данных из-за SQLi-атак?

Нет, это неверное предположение. Мы не можем сказать, что мы должны прекратить использование автомобилей, потому что они несут ответственность за людей, погибших в автомобильных авариях. Точно так же SQL / реляционные базы данных (или что-либо еще в этом контексте, например, RDBMS) не несут ответственности за вредоносную нагрузку SQL, которую злоумышленник может выполнить в вашем веб-приложении. Я уверен, что автор не имел это в виду, потому что для этой цели существует целый лист для предотвращения инъекций SQL .


2
Автоматизированные автомобили предотвратят около 98% автомобильных аварий. Мы должны доверять машине более , хе - хе - хе.

3
«Мы не можем сказать, что мы должны прекратить использование автомобилей [за исключением особых и / или тщательно контролируемых обстоятельств], потому что они несут ответственность за людей, погибших в автомобильных авариях». - Хм. Мы можем абсолютно сказать это. И многие разумные люди делают.
Конрад Рудольф

1
Вы в основном говорите: приложение, разработанное на Java, взломано, поэтому мы должны прекратить использовать Java . Достаточно понизить голосование, а в остальном я здесь не для того, чтобы учить вас здравому смыслу. @KonradRudolph
Билла Бегерадж

2
@BillalBEGUERADJ Это несколько ложная эквивалентность (поскольку взломать ничто не застраховано), но это также не так уж и далеко: существуют языки, которые, в конечном счете, не следует использовать, потому что есть лучшие альтернативы; например, если вы используете C вне контекста системного программирования, вы делаете это неправильно. Во всяком случае, я не downvote своего ответа , но это не так: потому , что вопреки тому , что вы утверждаете, что это именно то, что говорит Боб Мартин (как показывают другие ответы).
Конрад Рудольф

2

Проблема Мартина заключается в том, что программисты создают динамический SQL напрямую из пользовательского ввода, что-то вроде (простите, я в первую очередь программист на C и C ++):

sprintf( query, "select foo from bar where %s;", user_input );

что является абсолютным рецептом для изжоги (отсюда и полоса Бобби Столов ). Любой программист, который помещает подобный код в производственную систему, заслуживает веселья.

Вы можете смягчить (если не полностью устранить) проблему, используя подготовленные высказывания и должным образом дезинфицируя ваши входные данные. Если вы можете скрыть SQL за API, чтобы программисты не создавали напрямую строки запроса, тем лучше (что является частью того, что защищает Мартин).

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

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


Несмотря на то, sprintfчто в нем не предусмотрены методы очистки, необходимые для SQL, функции, разработанные специально для этой цели , являются абсолютно безопасными. Пример: SqlQuery в Entity Framework .
Роберт Харви

@ РобертХарви: Я бы предположил, что это так. Со своей стороны, я в основном выполняю работу на стороне сервера в C и C ++, поэтому я до сих пор иногда вижу (к счастью, редкие) примеры людей, просто использующих sprintfдинамический SQL, а не как вы это делаете.
Джон Боде

1

Два источника, на которые вы ссылаетесь, содержат разные сообщения

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

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

  • складские помещения увеличились примерно в 1 миллион раз - по сопоставимым ценам! Следовательно, меньше необходимости сохранять хранилище, и, в частности, больше нет необходимости удалять. Используя хранилище только для добавления, управление параллелизмом может быть упрощено, так как блокировки чтения не нужны. Это может устранить необходимость в транзакциях.
  • время доступа сократилось, поскольку большинство наборов данных теперь помещаются в оперативную память, что значительно снижает задержку чтения.

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

Существуют ли альтернативы?

Написание логики доступа к данным без строк вполне возможно. В среде Java вы можете использовать QueryDSL , где запросы описываются с использованием безопасного по типу API, сгенерированного из вашей схемы базы данных. Такой запрос может выглядеть следующим образом:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Как видите, логика запроса не выражается в виде строки, четко отделяющей доверенную структуру запроса от ненадежных параметров (и, конечно, QueryDSL никогда не включает параметры в текст запроса, но использует подготовленные операторы для разделения запроса для его параметров на уровне JDBC). Чтобы реализовать SQL-инъекцию с помощью QueryDSL, вам нужно написать собственный синтаксический анализатор для анализа строки и преобразования ее в синтаксическое дерево, и даже если вы это сделаете, вы, вероятно, не добавите поддержку для таких неприятных вещей, как select ... into file. Короче говоря, QueryDSL делает невозможным внедрение SQL-кода, а также повышает производительность труда программиста и повышает безопасность рефакторинга. Предотвращен самый большой риск для безопасности веб-приложений, который существует достаточно долго, чтобы порождать запущенные злоумышленникии повысил производительность разработчиков? Смею сказать, что если вы все еще пишете запросы в виде строк, вы делаете это неправильно.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.