Если дело только в экранировании запросов, то возможно легче, да. Но вот, например, у меня есть мегабайт сорцов, написанных разными людьми. Можно ли легко проверить, что все запросы там экранированы? Вопрос опять же сводится к простому API, которое будет гарантировать «экранированность», и это API отделяет «безопасную» часть системы от обычной.
Я бы расставил приоритеты данным по важности и разделял на уровни в зависимости от приоритета. Количество уровней, конечно, зависит от проекта, но не иметь ни одного такого уровня и поиметь возможность залезть в базу данных непосредственно из поля ввода данных — это жесть. Ну я думаю мы друг друга поняли, вон у хабра уже ширина кончилась :)
Финансы — это отдельный вопрос. Мои рассуждения всё же относились к «простым» сайтам, где не так много существенно важной информации. Но и в общем, подход тот же — выделить из сложной системы простые компоненты, которые можно тщательно проверить. Произвольный доступ к базе данных с финансовыми транзакциями нормальные люди давать не будут. А тщательно проверить всё-всё-всё никаких денег не хватит.
Дык это только для аутентификации не нужно всю базу читать, а для других действий может и нужно. Чем меньше ответственность, тем проще сделать надёжно, не очень понимаю зачем всю базу пытаться спрятать а не только важную информацию.
Я не очень понимаю ваших аргументов, поэтому попробую ещё раз объяснить, на примере линкедин — можете указать, где я неправ?
Почему у них утекла база? Наверняка где-нибудь в одном из скриптов на сайте профейлили инъекцию или что-нибудь в это роде. Почему это позволило получить всю базу данных? Потому что есть возможность прочитать всю базу из любого скрипта. В случае, если такой возможности нет, а можно только для данного «токена аутентификации» получить результат да/нет, базу слить так просто не получится. Налицо качественная разница, не? :)
Поэтому я и говорю про отдельный внутренний сервис. Его легко проверить, т.к. у него очень ограниченная ответственность, и после проверки заморозить и не трогать больше.
Уводят потому, что доступ к базе данных есть у любого скрипта. Вот и получается, что любая ошибка в любом скрипте огромного сайта приводит к уязвимостям. Когда скрипты не имеют прямого доступа к бд с паролями, проблемы и нет.
Помешает то, что не должно быть технической возможности это сделать :) Например, API к сервису принимает имя пользователя и пароль, и возвращает флаг 0/1 говорящий, правильный пароль или нет. Каким образом через такой API можно увести всю базу? (естественно, доступа к базе данных не через этот API нет, разве что физический доступ но это уже другой вопрос)
Соли, хеши… Ну ладно маленькие стартапы, но большой компании-то какие проблемы сделать отдельный внутренний сервис для валидации пароля, доступ к которому будет только через простой API, не позволяющий получить доступ к базе данных?
Так язык к этому располагает. Как только нужно что-то чуть более сложное, чем простое копирование, нужно ручками всё остальное почленно скопировать… Возможно, оттуда и иллюзия.
Причины могут быть разные. Компилятором установлено значение по умолчанию, что не значит, что оно в любой ситуации будет оптимальным. Кроме того, не гарантируется что оно будет одинаковое для всех компиляторов даже под данную платформу, а значит для интерфейсов нужно явно указывать выравнивание.
Есть libclang, и к ней питонячие биндинги. Я его как раз колупаю, но похоже там маловато информации выдают через интерфейс библиотеки, в частности не видно информации о типах параметров функций (либо я не умею его готовить).
Проблема мануалов в том, что они оторваны от контекста. Обычно, в отдельно взятый момент юзеру неинтересно читать про все возможности программы, ему нужно найти как сделать что-то конкретное. Так что на мой взгляд контексный хелп и подсказки более осмысленны, чем мануалы.
Решать наверное можно по-разному, я просто привёл пример когда «быстрее и удобнее» мэппингом приводит к проблемам. В моём случае запихнуть в кэш оказалось достаточно, что можно сказать эквивалентно рамдиску.
Как раз если чтение подряд, то всё равно. А если бегать по файлу туда-сюда, то может возникнуть разница как между последовательным и случайным доступом. Я это наблюдал на примере майкрософтовского линкера и лечил предварительным кешированием файлов, ускорение вышло в разы.
Я бы расставил приоритеты данным по важности и разделял на уровни в зависимости от приоритета. Количество уровней, конечно, зависит от проекта, но не иметь ни одного такого уровня и поиметь возможность залезть в базу данных непосредственно из поля ввода данных — это жесть. Ну я думаю мы друг друга поняли, вон у хабра уже ширина кончилась :)
Почему у них утекла база? Наверняка где-нибудь в одном из скриптов на сайте профейлили инъекцию или что-нибудь в это роде. Почему это позволило получить всю базу данных? Потому что есть возможность прочитать всю базу из любого скрипта. В случае, если такой возможности нет, а можно только для данного «токена аутентификации» получить результат да/нет, базу слить так просто не получится. Налицо качественная разница, не? :)
Уводят потому, что доступ к базе данных есть у любого скрипта. Вот и получается, что любая ошибка в любом скрипте огромного сайта приводит к уязвимостям. Когда скрипты не имеют прямого доступа к бд с паролями, проблемы и нет.