О разработке веб-приложений

[gevaraweb]

Занимался одно время созданием приложений php+MySQL. Пленила легкость, с какой можно быстро создать работающее веб-приложение, без установки дополнительного ПО и пр. Но и пришло полное разочарование, от осознания того, что это приложение также легко взломать. Как я понял, создать защищенное многофункциональное приложение на голом коде практически невозможно. Нужно изучать фреймфорк или брать готовую CMS. И увязнуть в вопросах: в примере так, а мне нужно так...

С другой стороны, подумалось, что можно сделать клиент на ПК, который работает с удаленной СУБД и в котором взять и тупо шифровать все запросы. А на сервере расшифровывать. Тогда, кажется, почти 100 процентная защита, например, от sql-инъекций.
Только удобно ли будет пользователю? Сам не представляю, чтоб для каждого сайта качать клиент и в нем работать. Например, вы увидели конференцию. Вся информация на сайте есть. Решили принять участие, и тут - бац - вам сообщение - скачайте клиент для регистрации и общения. Будете качать?

Погуглил, можно использовать жава апплеты или Microsoft Silverlight. Но на сегодня Гугл Хром отказался их поддерживать. Тоже разочарование ).

Есть ли движок, достаточно простой в освоении, и позволяющий создавать легко и быстро веб-приложения? Или уж написать клиент под вин и андроид? Например, взять СУБД для научных трудов студентов и преподавателей. Чтение и разнообразные отчеты сделать возможным через браузер, а добаление статей - через клиент. Будет ли такое решение "хорошим"?

[arseniiv]

gevaraweb в сообщении #1397371 писал(а):

Тогда, кажется, почти 100 процентная защита, например, от sql-инъекций.

А что, проблема в достаточной степени с ними? Так в интерфейсе языка к СУБД должны же быть специальные функции, эскейпирующие всё что надо сами. Если действительно никаких нету — печаль, да.

[rockclimber]

gevaraweb в сообщении #1397371 писал(а):

С другой стороны, подумалось, что можно сделать клиент на ПК, который работает с удаленной СУБД и в котором взять и тупо шифровать все запросы. А на сервере расшифровывать. Тогда, кажется, почти 100 процентная защита, например, от sql-инъекций.

SQL-инъекции - это что, по-вашему? Не знаю, что вы о них думаете, но думаете на 100% неправильно. Их причина - не в отсутствии шифрования, и, следовательно, добавлением шифрования от них не избавиться.

gevaraweb в сообщении #1397371 писал(а):

Занимался одно время созданием приложений php+MySQL.

Ну, это практически диагноз. Как говорится, забудьте всё, чему вас учили в школе в php+MySQL и начните заново.

gevaraweb в сообщении #1397371 писал(а):

Только удобно ли будет пользователю?

О том, как сделать удобно пользователю, нужно гуглить по словам юзабилити, UI/UX и так далее. В целом, это скорее искусство, чем инженерная деятельность. Ну или я пока просто плохо его освоил.

gevaraweb в сообщении #1397371 писал(а):

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

Ну, приложения для разных сайтов под iOS/Андроид вполне существуют, и их даже качают. Другой вопрос, что часто это просто тупо копии сайтов, и тогда толку от них, как от козла молока.

gevaraweb в сообщении #1397371 писал(а):

Есть ли движок, достаточно простой в освоении, и позволяющий создавать легко и быстро веб-приложения?

Сейчас это называется "фреймворк". По запросу <мой_любимый_язык_программирования> фреймворк для веб-разработки можно найти просто тьму фреймворков под любой язык, включая экзотику типа Delphi и Haskell. А уж про всякие жабы/питоны/сишарпы и прочий мейнстрим и говорить нечего, их буквально десятки.

-- 02.06.2019, 20:50 --

arseniiv в сообщении #1397383 писал(а):

А что, проблема в достаточной степени с ними? Так в интерфейсе языка к СУБД должны же быть специальные функции, эскейпирующие всё что надо сами.

Помните рекламу про тётю Асю?
- Ася, почему, когда мой муж делает так [показывает], у него рвутся рубашки?
- А вы не делайте так!
https://www.youtube.com/watch?v=6y427yJfauo


Возможности для SQL-инъекции появляются, если собирать текст запроса конкатенацией кусков запроса. А если не собирать конкатенацией - то не появляются. Ваш Кэп

[gevaraweb]

rockclimber в сообщении #1397384 писал(а):

добавлением шифрования от них не избавиться

Разве? Дык, шифрование позволит вместо запросов вида

mysite.com/script.php?id=3&color=red&ves=33&name=Ivan

отправлять запросы вида

mysite.com/script.php?query=r4ueu53b3hwdtb22rw723er3hqbq99urh3bwd

Инъекцию делать бесполезно, запрос при расшифровке испортится и не выполнится.

rockclimber в сообщении #1397384 писал(а):

А если не собирать конкатенацией - то не появляются.

Все запросы делать параметризованными? Проблема в том, что в Mysql параметризованные запросы выполняются много медленнее обычных. Может, и есть субд, заточенная под быстрое выполнение параметризованных запросов. Вы такую знаете? Хотя я привык к Mysql.

rockclimber в сообщении #1397384 писал(а):

Сейчас это называется "фреймворк".

Изучать Yii2 или Laravel ради простых СУБД типа "Отчет по науке" желания и сил нет

[arseniiv]

Это же не SQL-инъекции, это просто потенциально дырявый API сервера. Если сервер не будет принимать любую комбинацию посланных ему в запросе (к серверу, а не SQL-запросе самого сервера к СУБД, который никому виден быть ни в каком виде не обязан) аргументов за чистую монету, а будет что-то там проверять, перед тем как попробовать что-то выполнить в ответ на такую просьбу, а обычно всё так и есть, то не страшно, если кто-то нахимичит в аргументах. Клиент при этом можно хоть сто раз сломать, и

Часть атак XSS (может, вы их имели в виду?) тоже избегается аккуратностью работы со строками и не конкатенацией всего и вся без повода, и ещё некоторая их часть невозможна с современными браузерами.

gevaraweb в сообщении #1397394 писал(а):

Инъекцию делать бесполезно, запрос при расшифровке испортится и не выполнится.

А может быть и не испортится. Шифрование — это не магия, это наука. Если вы будете использовать security through obscurity (а в данном случае она и есть) на чём-то достаточно важном, найдётся кто-то, кто пожелает подобрать изменения в шифрованный запрос и имеющий достаточно ресурсов, чтобы это сделать.

gevaraweb в сообщении #1397394 писал(а):

Проблема в том, что в Mysql параметризованные запросы выполняются много медленнее обычных. Может, и есть субд, заточенная под быстрое выполнение параметризованных запросов.

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

-- Пн июн 03, 2019 02:18:41 --

arseniiv в сообщении #1397400 писал(а):

security through obscurity

Вероятно, стоит пояснить, что не так в подходе. Рассмотрим обращение к серверу. Он нам должен выдать страницу, которая должна уметь посылать зашифрованные запросы серверу. Притом странице должны быть известны метод и параметры (публичный ключ, например) шифрования. Они должны быть ей переданы открыто (если мы передаём их зашифрованно, потребуется информация уже о том как расшифровать их, тоже в конечном счёте открыто по аналогичному аргументу); сервер никак не сможет отличить недобросовестный клиент от добросовестного, и из первого анализом переданного можно будет слать какие угодно запросы, шифруя что хочешь.

-- Пн июн 03, 2019 02:23:26 --

Вероятно, вы могли эти «зашифрованные» штуки где-то подсмотреть. Насколько я в курсе, шифрование на таком уровне не используется, а используются случайные идентификаторы, порождаемые изначально сервером, и тут отличие разительное: о смысле идентификатора знает только сервер, он же управляет временем его жизни.

[rockclimber]

gevaraweb в сообщении #1397394 писал(а):

Проблема в том, что в Mysql параметризованные запросы выполняются много медленнее обычных.

"мы думали, что достигли дна, но тут снизу постучали" (с)

gevaraweb в сообщении #1397394 писал(а):

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

Любая другая СУБД В частности, в оракле и в постгресе параметризованные запросы точно выполняются быстрее - их для того и придумали, вообще-то. Там СУБД работает следующим образом: планировщик запроса получает текст запроса, парсит его и составляет план выполнения. Параметры при этом передаются отдельно и подставляются в запрос уже после разбора и составления плана. Если параметров нет, а значение подставляется прямо в текст запроса, планировщик каждый раз парсит запрос и составляет план заново (потому что он не может его опознать - текст-то другой! Хотя в простых случаях оракл, кажется, версии с 12-й, научился распознавать простые случаи, когда можно в похожих запросах разделить текст на текст + параметр), а если используются параметры, то планировщик просто берет готовый план из кэша, и это получается быстрее. Так работает СУБД здорового человека. Как работает СУБД курильщика, я не знаю и знать не хочу.

gevaraweb в сообщении #1397394 писал(а):

Изучать Yii2 или Laravel ради простых СУБД типа "Отчет по науке" желания и сил нет

А ковыряться с тем, что у вас сейчас, силы и желание, стало быть, есть? Ну тогда в чем проблема?
Или возьмите M$ Access. Ну или почти то же самое, но для веба - Oracle APEX. Никогда не устану его нахваливать

gevaraweb в сообщении #1397394 писал(а):

ради простых СУБД типа "Отчет по науке"

Давайте называть вещи своими именами. СУБД - это система управления базами данных. Это Oracle, MySQL, PostgreSQL, MSSQL, DB2, Firebird и многие другие. Ваши данные, хранением и обработкой которых занимается СУБД, - это база данных, или БД.

gevaraweb в сообщении #1397394 писал(а):

rockclimber в сообщении #1397384 писал(а):

добавлением шифрования от них не избавиться

Разве? Дык, шифрование позволит вместо запросов вида

mysite.com/script.php?id=3&color=red&ves=33&name=Ivan

отправлять запросы вида

mysite.com/script.php?query=r4ueu53b3hwdtb22rw723er3hqbq99urh3bwd

Инъекцию делать бесполезно, запрос при расшифровке испортится и не выполнится.

Да, я погуглил фразу "SQL инъекция" и нашел статью на Хабре и статью в Википедии (они первыми ссылками идут в гугле). Стало понятно, откуда ноги растут. Ну что я могу сказать - и там, и там феерическая чушь от начала и до конца. (Ура! Ура! Наконец-то и мне попалась статья в Википедии, которую я могу назвать бредом и обосновать это со 100% уверенностью!) Кстати, а у статьи на Хабре рейтинг -5 - в этом месте должен прозвенеть тревожный звонок. Хорошей статье там столько минусов не налепят.

Короче, SQL-инъекция выглядит так.
Допустим, мы пишем информационную систему, где у пользователя есть возможность делать поиск информации. Но часть информации может иметь ограниченный доступ, и не все пользователи могут ее видеть. У нас есть поле user_status для проверки доступа и поле text, в котором пользователь ищет информацию. Тогда запрос для поиска будет выглядеть примерно так:

Используется синтаксис SQL

SELECT * FROM my_table WHERE user_status = 1 AND text LIKE '%some text%'

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

Используется синтаксис Java

sql_string = "select * from my_table where user_status = 1 and text like '%" + user_input + "%'"

Например, пользователь вводит куку, запрос получается такой:

Используется синтаксис SQL

SELECT * FROM my_table WHERE user_status = 1 AND text LIKE '%куку%' 

В результате пользователь видит все строки таблицы, в которых есть текст "куку".

А теперь пользователь вводит строку "%' or '%'='". В результате получается такой запрос:

Используется синтаксис SQL

SELECT * FROM my_table WHERE user_status = 1 AND text LIKE '%%' OR '%'='%' 

То есть пользователь видит вообще все строки, даже те, которые ему запрещено видеть (с user_status не равным 1) - потому что or '%'='%' всегда дает true!
Так вот: SQL-инъекция - это строка "%' or '%'='", введенная пользователем. А POST и GET запросы - это всего лишь средства доставки инъекции до базы данных. Вы берете строку, введенную пользователем, и вставляете ее прямо в текст запроса, этого достаточно. Вся эта философия про шифрование - это второстепенные мелочи. Они могут избавить вас только от части проблем в самом лучшем случае.
Особо талантливые люди собирают SQL прямо в браузере, но о грустном мы не будем сегодня.

-- 02.06.2019, 23:42 --

arseniiv
А, ну да. Так короче. Хотя там есть два момента. Во-первых, как они узнали, какое имя он ввел, если он дропнул таблицу учащихся? Они логируют отдельно все запросы? Логирование запросов они знают, а инъекции - не знают?
И второе. Касается выполнения нескольких запросов одним куском. Не знаю, к сожалению, на каком этапе это режется - кажется, обычно этим занимаются драйвера ODBС/JDBC. Через них пачку запросов выполнить нельзя, а с другими способами доступа к БД я дела не имел. Например, pgAdmin или любая IDE для оракла умеют выполнять запросы пачками, но я не знаю, как они это делают - то ли низкоуровневый доступ (легко может быть), то ли они парсят запросы и выполняют по одному (тоже легко может быть). Возможно, эта разновидность атаки имеет уже только историческую ценность.

[arseniiv]

(Пояснение: я запостил в дополнение к посту rockclimber ссылку на xkcd №327, а потом заскромничал и удалил пост.)

[iifat]

Ну, не знаю. Как по мне, идея на данном этапе развития броузеров бредовая в принципе.

gevaraweb в сообщении #1397371 писал(а):

Пленила легкость, с какой можно быстро создать работающее веб-приложение

Это лёгкость создания на коленке какого-никакого прототипа. Вроде форума или даже электронного магазина.

gevaraweb в сообщении #1397371 писал(а):

создать защищенное многофункциональное приложение на голом коде практически невозможно. Нужно изучать фреймфорк или брать готовую CMS

А что, по-вашему, такое фреймворк или что вы там ещё назвали?
Работаю в конторе, где используется пара десятков таких вот web-приложений. Одни идут только на Эксплорере, другие только на Firefox, третьи только на Chrome. Слава богу, таки четвёртых ещё не написали, и трёх броузеров на одном компьютере пока таки хватает...

[aa_dav]

Взлом веб-приложений многогранен.

В юности лет 20 назад самолично ломал один популярный тогда движок форумов в интернете путём анализа его исходного кода (как опенсорц и PHP он был конечно весь доступен для анализа).
И вы знаете, нашёл уязвимость сам, своими собственными глазами после двух вечеров вглядывания, чем горжусь до сих пор.
Смысл был в том, чтобы внедрить на страницу HTML-код собственного изготовления, но все формы для постов и комментариев разумеется были наглухо прикрыты escape-оборачивающими функциями.
Но я таки нашёл как сделать желаемое - обратил внимание, что в момент логина логин _сперва_ добавляется в список "пользователи сейчас на сайте", причём без escape-обёртывания, а только потом проверяются на корректность.
Видимо программист когда писал код для страницы "пользователи на сайте" уже считал, что логин прошёл проверки и содержит только буквы и цифры и потому эксейпить его не надо, но в последовательности проверок была допущена серьёзная ошибка.
Поэтому удалось внедрить свой Java-скриптовый код как раз в ту самую страницу "люди на сайте" и этот код брал куку с сессией и незаметно посылал её в личный ящик подставного аккаунта, который периодически мониторился. И вот через несколько часов "рыбалки" там оказалась кука от аккаунта с правами администратора.

Так что веб-хакинг многогранен и SQL-inject вещь еще сравнительно простая. Прежде чем писать серьезные продукты надо почитать и хорошо понять про все известные методы атак.

[gevaraweb]

arseniiv в сообщении #1397400 писал(а):

Вероятно, вы могли эти «зашифрованные» штуки где-то подсмотреть. Насколько я в курсе, шифрование на таком уровне не используется, а используются случайные идентификаторы, порождаемые изначально сервером, и тут отличие разительное: о смысле идентификатора знает только сервер, он же управляет временем его жизни.

Я про обычную электронную подпись.

rockclimber в сообщении #1397406 писал(а):

Да, я погуглил фразу "SQL инъекция" и нашел статью на Хабре и статью в Википедии (они первыми ссылками идут в гугле). Стало понятно, откуда ноги растут. Ну что я могу сказать - и там, и там феерическая чушь от начала и до конца. (Ура! Ура! Наконец-то и мне попалась статья в Википедии, которую я могу назвать бредом и обосновать это со 100% уверенностью!) Кстати, а у статьи на Хабре рейтинг -5 - в этом месте должен прозвенеть тревожный звонок. Хорошей статье там столько минусов не налепят.

Короче, SQL-инъекция выглядит так.
Допустим, мы пишем информационную систему...

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

aa_dav в сообщении #1397448 писал(а):

Так что веб-хакинг многогранен и SQL-inject вещь еще сравнительно простая. Прежде чем писать серьезные продукты надо почитать и хорошо понять про все известные методы атак.

Поэтому я даже и не берусь научиться с ними бороться . Лучше сразу отрубить и зашифровать все запросы.

rockclimber в сообщении #1397406 писал(а):

Ну или почти то же самое, но для веба - Oracle APEX. Никогда не устану его нахваливать

Посмотрел. Дык, под него хостера даже не найдешь. Не.

rockclimber в сообщении #1397406 писал(а):

в постгресе параметризованные запросы точно выполняются быстрее

Тут пишут про sql-инъекции PostgreSQL. Не, тогда не подойдет

[Mental]

gevaraweb в сообщении #1397371 писал(а):

Есть ли движок, достаточно простой в освоении, и позволяющий создавать легко и быстро веб-приложения? Или уж написать клиент под вин и андроид? Например, взять СУБД для научных трудов студентов и преподавателей. Чтение и разнообразные отчеты сделать возможным через браузер, а добаление статей - через клиент. Будет ли такое решение "хорошим"?

По всей видимости нет. У WordPress и Joomla частенько бывает проблема Zero day. Клиент ваш вряд ли кто-нибудь будет качать. Чтобы написать что-нибудь неломаемое, нужно гораздо больше времени потратить, чем на изучение фреймворков упомянутых вами ранее.
Если у вас планируется большой объем статей + хорошая нагрузка на сервер, то лучше забыть об MySql.

[rockclimber]

gevaraweb в сообщении #1397371 писал(а):

Нужно изучать фреймфорк или брать готовую CMS. И увязнуть в вопросах: в примере так, а мне нужно так...

gevaraweb в сообщении #1397394 писал(а):

Изучать Yii2 или Laravel ради простых СУБД типа "Отчет по науке" желания и сил нет

gevaraweb в сообщении #1397485 писал(а):

Поэтому я даже и не берусь научиться с ними бороться

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

gevaraweb в сообщении #1397485 писал(а):

Раз мои познания оттуда, значит, я это уже знаю

То, что вы пишете дальше, ясно показывает, что не знаете.

gevaraweb в сообщении #1397485 писал(а):

rockclimber в сообщении #1397406 писал(а):

в постгресе параметризованные запросы точно выполняются быстрее

Тут пишут про sql-инъекции PostgreSQL. Не, тогда не подойдет

Простите, если вы не умеете читать, то я ничем не могу вам помочь. Еще раз: возможности для инъекции возникают, когда в вызывающем коде (не в СУБД!!!) текст запроса собирается с помощью конкатенации строк. А когда используются параметры - не возникают. Это не зависит от СУБД!
А самое смешное тут то, что ровно то же самое написано в этой самой статье, на которую вы ссылаетесь. Долистайте до конца и прочитайте сами:

Цитата:

Способы защиты
...
- используйте подготовленные выражения с привязанными переменными.

-- 03.06.2019, 14:48 --

gevaraweb в сообщении #1397485 писал(а):

Посмотрел. Дык, под него хостера даже не найдешь.

Если не пробовать искать - то да, конечно не найдешь.

[Geen]

gevaraweb в сообщении #1397485 писал(а):

Тут пишут про sql-инъекции PostgreSQL.
Не, тогда не подойдет

Феерично... Вам же сказали забыть про PHP.... А то, похоже, Вы не различаете где клиент, где сервер и где БД.
И не бывает СУБД "без инъекций" - все инъекции идут от плохо написанной серверной части.

[arseniiv]

gevaraweb в сообщении #1397485 писал(а):

Я про обычную электронную подпись.

Ну, в том способе, который вы предлагали выше с запросом, не важно, будет зашифрованное подписываться или нет — пока этим занимается клиент, всё напрасно. Злоумышленник сможет состряпать из переданных сервером данных свою уже не ограниченную функцию «одевания» любого запроса, который ему понадобится. Потому это в первую очередь security through obscurity. Этого не надо делать ещё и потому что некоторые люди захотят автоматизировать клиент, и если вы выдаёте прозрачный API, и сервер выдаёт явно ответ об ошибке (например, 400?), если API используется неверно, они только спасибо скажут.

gevaraweb в сообщении #1397485 писал(а):

Лучше сразу отрубить и зашифровать все запросы.

Я же выше написал, почему это не работает.

[rockclimber]

iifat в сообщении #1397412 писал(а):

Как по мне, идея на данном этапе развития броузеров бредовая в принципе.

На текущем этапе развития - уже не бредовая. Самый пик бредовости был лет 10 - 15 назад. Сначала MS со своим IE захватила монополию на браузеры, а потом (раз браузер у всех всё равно один) - забила на соблюдение стандартов. Потом другие браузеры начали отъедать значительную долю, но к реализации стандартов относились творчески, а какие-то вещи были недостандартизированы. В итоге в конце нулевых (судя по доходившим до меня рассказам причастных) разработка (и тестирование) кросс-браузерного сайта была адом, и я радовался, что мне не приходится этим заниматься. Многие действительно тупо писали под один браузер и чихать хотели на остальных. Потом разработчики браузеров взялись за ум, с начала 10-х даже стали в качестве конкурентного преимущества демонстрировать точность соблюдения стандартов, и, хоть и до сих пор не все гладко, но CSS и js последние лет пять более-менее одинаковые везде, так что жить уже можно.