forum.opennet.ru - "Опасные уязвимости в платформе электронной коммерции Magento " (61)

"Опасные уязвимости в платформе электронной коммерции Magento "

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Опасные уязвимости в платформе электронной коммерции Magento "	+/–
Сообщение от opennews (??), 28-Мрт-19, 23:09
В открытой платформе для организации электронной коммерции Magento (https://github.com/magento), которая занимает около 20% (https://pagely.com/blog/top-ecommerce-platforms-2018-compared/) рынка систем для создания интернет-магазинов, выявлены (https://blog.sucuri.net/2019/03/sql-injection-in-magento-cor...) уязвимости, позволяющие выполнить код на сервере и осуществить подстановку SQL-запроса. Проблемы устранены (https://magento.com/security/patches/magento-2.3.1-2.2.8-and...) в выпусках Magento 2.1.17, 2.2.8 и 2.3.1, в которых также исправлено 30 менее опасных уязвимостей, таких как межсайтовая подделка запроса (CSRF) и межсайтовый скриптинг (XSS). Наиболее опасная проблема позволяет добиться подстановки своего SQL-кода через отправку специального запроса к обработчику "/catalog/product/frontend_action_synchronize". Атака может быть проведена неаутентифицированным пользователем. Через манипуляции с содержимым БД атакующий может добиться выполнения своего кода на стороне сервера или загрузить конфиденциальные данные из БД, включая хэши паролей пользователей. Ещё 5 уязвимостей позволяют выполнить свой код на сервере, но ограничены атаками со стороны аутентифицированных пользователей, снабжённых дополнительными привилегиями. Например, пользователь с правом создания уведомлений и шаблонов писем может выполнить код через создание специально оформленных шаблонов, а пользователи с правами администратора магазина могут выполнить PHP-код через манипуляции с шаблонами писем или загрузку phar-файла под видом картинки (проведение (https://www.opennet.ru/opennews/art.shtml?num=49746) атаки (https://www.opennet.ru/opennews/art.shtml?num=49641) "Phar deserialization"). URL: https://blog.sucuri.net/2019/03/sql-injection-in-magento-cor... Новость: https://www.opennet.ru/opennews/art.shtml?num=50413
Ответить \| Правка \| Cообщить модератору

Оглавление

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (1), 23:09 , 28-Мрт-19, (1) –1
Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 23:17 , 28-Мрт-19, (2) –3

Опасные уязвимости в платформе электронной коммерции Magento..., Crazy Alex (ok), 23:45 , 28-Мрт-19, (3)

Опасные уязвимости в платформе электронной коммерции Magento..., vedronim (?), 00:43 , 29-Мрт-19, (6) +5

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (7), 01:07 , 29-Мрт-19, (7) –1

Опасные уязвимости в платформе электронной коммерции Magento..., vedronim (?), 09:48 , 29-Мрт-19, (31) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Онаним (?), 08:43 , 29-Мрт-19, (25) –2

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 01:08 , 29-Мрт-19, (8) –2

Опасные уязвимости в платформе электронной коммерции Magento..., vitalif (ok), 01:17 , 29-Мрт-19, (10) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 01:33 , 29-Мрт-19, (11) –1

Опасные уязвимости в платформе электронной коммерции Magento..., Crazy Alex (ok), 02:58 , 29-Мрт-19, (15)

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 04:16 , 29-Мрт-19, (16) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Онаним (?), 08:47 , 29-Мрт-19, (26) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (39), 12:09 , 29-Мрт-19, (39) –2

Опасные уязвимости в платформе электронной коммерции Magento..., Crazy Alex (ok), 17:35 , 29-Мрт-19, (52)
Опасные уязвимости в платформе электронной коммерции Magento..., Борщдрайвен бигдата (?), 20:29 , 29-Мрт-19, (55)

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 13:25 , 29-Мрт-19, (44)

Опасные уязвимости в платформе электронной коммерции Magento..., Crazy Alex (ok), 17:34 , 29-Мрт-19, (51)

Опасные уязвимости в платформе электронной коммерции Magento..., Sw00p aka Jerom (?), 16:17 , 29-Мрт-19, (48) –1

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 19:28 , 29-Мрт-19, (54)

Опасные уязвимости в платформе электронной коммерции Magento..., freehck (ok), 02:00 , 29-Мрт-19, (13)

Опасные уязвимости в платформе электронной коммерции Magento..., freehck (ok), 01:57 , 29-Мрт-19, (12) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 05:04 , 29-Мрт-19, (22)

Опасные уязвимости в платформе электронной коммерции Magento..., Онаним (?), 08:53 , 29-Мрт-19, (27)

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 13:50 , 29-Мрт-19, (46)

Опасные уязвимости в платформе электронной коммерции Magento..., freehck (ok), 13:24 , 30-Мрт-19, (62)

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 23:39 , 30-Мрт-19, (63)

Опасные уязвимости в платформе электронной коммерции Magento..., Crazy Alex (ok), 02:22 , 29-Мрт-19, (14)

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 04:28 , 29-Мрт-19, (17)
Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 05:32 , 29-Мрт-19, (23)

Опасные уязвимости в платформе электронной коммерции Magento..., Онаним (?), 08:58 , 29-Мрт-19, (29) +3

Опасные уязвимости в платформе электронной коммерции Magento..., vedronim (?), 09:51 , 29-Мрт-19, (33)
Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 13:27 , 29-Мрт-19, (45) +1
Опасные уязвимости в платформе электронной коммерции Magento..., Sw00p aka Jerom (?), 16:21 , 29-Мрт-19, (49)

Опасные уязвимости в платформе электронной коммерции Magento..., Sw00p aka Jerom (?), 01:10 , 29-Мрт-19, (9) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (39), 12:11 , 29-Мрт-19, (40) –1

Опасные уязвимости в платформе электронной коммерции Magento..., Онаним (?), 08:38 , 29-Мрт-19, (24) +2

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 13:24 , 29-Мрт-19, (43)

Опасные уязвимости в платформе электронной коммерции Magento..., конь в пальто (?), 08:55 , 29-Мрт-19, (28) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Sw00p aka Jerom (?), 16:24 , 29-Мрт-19, (50)

Опасные уязвимости в платформе электронной коммерции Magento..., _ (??), 14:46 , 29-Мрт-19, (47) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Ordu (ok), 19:25 , 29-Мрт-19, (53)

Опасные уязвимости в платформе электронной коммерции Magento..., zzz (??), 23:55 , 28-Мрт-19, (4) –1

Опасные уязвимости в платформе электронной коммерции Magento..., tsifra (?), 11:29 , 29-Мрт-19, (36)

Опасные уязвимости в платформе электронной коммерции Magento..., Andrey Mitrofanov (?), 11:47 , 29-Мрт-19, (38) +2

Опасные уязвимости в платформе электронной коммерции Magento..., tsifra (?), 23:28 , 29-Мрт-19, (57)
Опасные уязвимости в платформе электронной коммерции Magento..., tsifra (?), 23:45 , 29-Мрт-19, (59)

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (39), 12:24 , 29-Мрт-19, (41) –2

Опасные уязвимости в платформе электронной коммерции Magento..., tsifra (?), 23:27 , 29-Мрт-19, (56)

Опасные уязвимости в платформе электронной коммерции Magento..., пох (?), 23:41 , 29-Мрт-19, (58)

Опасные уязвимости в платформе электронной коммерции Magento..., tsifra (?), 23:56 , 29-Мрт-19, (60)

Опасные уязвимости в платформе электронной коммерции Magento..., пох (?), 09:56 , 30-Мрт-19, (61) +1

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (5), 00:10 , 29-Мрт-19, (5) +3

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (32), 09:48 , 29-Мрт-19, (32) +1

Опасные уязвимости в платформе электронной коммерции Magento..., sin (??), 12:58 , 29-Мрт-19, (42)

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (18), 04:50 , 29-Мрт-19, (18)

Опасные уязвимости в платформе электронной коммерции Magento..., Онаним (?), 09:02 , 29-Мрт-19, (30) +1

Опасные уязвимости в платформе электронной коммерции Magento..., нах (?), 10:34 , 29-Мрт-19, (35)

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (18), 04:54 , 29-Мрт-19, (19)

Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (18), 04:55 , 29-Мрт-19, (20)
Опасные уязвимости в платформе электронной коммерции Magento..., Аноним (18), 04:57 , 29-Мрт-19, (21)

Сообщения [Сортировка по времени | RSS]

1. "Опасные уязвимости в платформе электронной коммерции Magento..." –1 +/–

Сообщение от Аноним (1), 28-Мрт-19, 23:09

1.9 подвержены?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Опасные уязвимости в платформе электронной коммерции Magento..." –3 +/–

Сообщение от Ordu (ok), 28-Мрт-19, 23:17

> Наиболее опасная проблема позволяет добиться подстановки своего SQL-кода через отправку специального запроса
Шёл 2019 год, а php всё не мог справиться с sql-injection. Блин, КАК ТАК МОЖНО?
Не, ну ладно C и C++ продолжают десятилетиями ходить по граблям нулевых и висящих указателей, там особенности языка вынуждают. Но sql -- это внешняя сущность для php, и всё что надо -- дать веб-макаке safe-API, который не позволит ей создать условий для sql-инъекции.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Crazy Alex (ok), 28-Мрт-19, 23:45

Попытайтесь. И удивитесь, как много странных случаев, которые в красивые ограничения не укладываются - разного рода генерация имён таблиц на лету и тому подобное. Если проект крупнее hello world - никуда не денетесь, будете время от времени собирать запрос строкой, со всеми вытекающими рисками.
В плюсах, кстати, тоже можно в 99% случаев обойтись без каких-либо "граблей нулевых и висящих указателей", тем они от C и отличаются.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Опасные уязвимости в платформе электронной коммерции Magento..." +5 +/–

Сообщение от vedronim (?), 29-Мрт-19, 00:43

Динамически собирать запрос можно и в безопастном виде.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Опасные уязвимости в платформе электронной коммерции Magento..." –1 +/–

Сообщение от Аноним (7), 29-Мрт-19, 01:07

Нет, нельзя. В SQLite, например, нельзя создавать таблицы и триггерить прагмы используя prepared statements.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

31. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от vedronim (?), 29-Мрт-19, 09:48

> Нет, нельзя. В SQLite, например, нельзя создавать таблицы и триггерить прагмы используя
> prepared statements.
Скклайт это крайний случай. На нем е-коммерцию нормальные люди не делают. Уже в майскуеле все делается без проблем.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

25. "Опасные уязвимости в платформе электронной коммерции Magento..." –2 +/–

Сообщение от Онаним (?), 29-Мрт-19, 08:43

Два золотых правила, забывая которые, получают все эти грабли:
1) Весь - повторюсь - ВЕСЬ user input считается untrusted и при необходимости внутреннего использования - 100% валидируется в обязательном порядке, при любых условиях, даже если это увеличит объём и сложность кода в разы
2) При передаче каких либо untrusted данных в среду, использующую специальные символы в наборе данных, в обязательном порядке делаем полноценный escape согласно требованиям среды

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Опасные уязвимости в платформе электронной коммерции Magento..." –2 +/–

Сообщение от Ordu (ok), 29-Мрт-19, 01:08

> Попытайтесь. И удивитесь, как много странных случаев, которые в красивые ограничения не
> укладываются - разного рода генерация имён таблиц на лету и тому
> подобное. Если проект крупнее hello world - никуда не денетесь, будете
> время от времени собирать запрос строкой, со всеми вытекающими рисками.
Это делается элементарно:
let field_name = get_one_more_field_name();
let result = query_builder()
    .select(["uid", "nickname", field_name])
    .from(USERS_TABLE)
    .where(less(length("nickname"), 5))
    .execute(SQL_CONNECTION);
Функции less и length, понятно, возвращают объекты, которые затем where компилирует в строчку. Или может не where, может стоит сначала собрать всё в один объект-запрос, проверив параллельно синтаксис, а затем всё за раз скомпилировать, чтобы не выделять память под строку с запросом, а непосредственно писать запрос в сокет sql.
Если напрягает то, что все эти "uid", "nickname" будут прогоняться через функцию экранирования каждый раз, дёргая каждый раз кучу и тормозя выполнение, то ничто не мешает объявить тип EscapedSqlString, который будет содержать в себе строку, а функция sql_escape_string, будет этот тип "разворачивать", возвращая строку изнутре не экранируя её, а обычный String она будет экранировать. Использование EscapedSqlString привносит возможностей скосячить, но так же оно привносит дополнительных трудностей, из-за чего самый простой способ использовать EscapedSqlString это:
const UID = EscapedSqlString::new("uid");
const NICKNAME = EscapedSqlString::new("nickname");
и затем:
    .select([UID, NICKNAME, field_name])
и
    .where(less(length(NICKNAME), 5))
Конечно, если мы говорим об интерпретируемом языке, то подобный подход всё равно добавит тормозов, потому что придётся собирать временный объект, но добавит оно не особо, а вот создать sql-инъекцию можно будет разве что злоумышленно.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

10. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от vitalif (ok), 29-Мрт-19, 01:17

...и учить ещё один язык в дополнение к SQL. А потом ой а как написать OR? Ой а как написать постгрес специфичный оператор? Ой а как вместо таблицы подзапрос? Ой а CTE написать?
Я лично вообще не понимаю, как можно такие баги (возможность sql-инъекции) допускать на любом языке. Рукожопу и Rust не помеха

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Опасные уязвимости в платформе электронной коммерции Magento..." –1 +/–

Сообщение от Ordu (ok), 29-Мрт-19, 01:33

> ...и учить ещё один язык в дополнение к SQL.
Это и есть sql. Тут ничего учить дополнительно не надо, достаточно понять идею, как синтаксис sql транслируется в это.
> А потом ой а как написать OR? Ой а как написать постгрес специфичный оператор? Ой а как вместо таблицы подзапрос? Ой а CTE написать?
Для того, чтобы таких вопросов не возникало, библиотека для создания sql запросов должна хоститься на github'е, чтобы её разработка велась бы несколькими заинтересованными разработчиками, и постоянно бы туда влетали бы feature и pull реквесты. Через полгода она будет уметь всё, что надо. Ещё через полгода-год, она стабилизируется.
> Я лично вообще не понимаю, как можно такие баги (возможность sql-инъекции) допускать
> на любом языке.
Это потому, что, видимо, нет опыта долгосрочной поддержки программ с параллельным их развитием.
> Рукожопу и Rust не помеха
Да. Как показывает опыт применения miri на std из rust'а, не проблема: https://github.com/rust-lang/miri#bugs-found-by-miri
Если тебе слова в тех багах мало что говорят, то я поясню, что последние четыре -- это прямые нарушения rust'овых инвариантов, которые можно использовать для того, чтобы получить, как минимум, data race. А в некоторых, случаях, возможно даже use after free или типа того. Точнее не скажу, что именно можно -- это надо смотреть описание багов.
Но здесь ты совершаешь очень распространённую ошибку. Если мы не можем решить проблему на 100%, это не повод отказываться от того, чтобы решить её на 90%. Проблема решённая на 90% лучше, чем проблема решённая на 0%.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

15. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Crazy Alex (ok), 29-Мрт-19, 02:58

Да блин, ормов сотоварищи написано уже море. Но используются в основном какой-нибудь джаве, где написать простыню (и ещё кусок xml впридачу) для выполнения чего-то тривиального - норма, как в том же Hibernate. И то вписанные руками SQL запросы - не то чтобы редкость. Потому что по дефолту либо с быстродействием проблемы, либо что-то требует больше динамики, чем может предоставить либа.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

16. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от Ordu (ok), 29-Мрт-19, 04:16

> Да блин, ормов сотоварищи написано уже море. Но используются в основном какой-нибудь
> джаве, где написать простыню (и ещё кусок xml впридачу) для выполнения
> чего-то тривиального - норма, как в том же Hibernate. И то
> вписанные руками SQL запросы - не то чтобы редкость. Потому что
> по дефолту либо с быстродействием проблемы, либо что-то требует больше динамики,
> чем может предоставить либа.
То что я предложил выше -- это не ORM. Не надо путать тёплое с мягким.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

26. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от Онаним (?), 29-Мрт-19, 08:47

Ну делал я себе такой генератор запросов ради эксперимента. Выкинул.
1) Неудобно - простыня вызовов, там, где надо скобки (вызов внутри вызова получается) - вообще швах, в вызовах начинаешь теряться.
2) Производительность сборки запроса выходит реально ниже плинтуса. Даже после достаточно низкоуровневой оптимизации.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

39. "Опасные уязвимости в платформе электронной коммерции Magento..." –2 +/–

Сообщение от Аноним (39), 29-Мрт-19, 12:09

Не, мужики, вы опять двинулись не в ту сторону. Вместо того, чтобы мечтать о каком-то волшебном эльфийско-единорожьем языке для составления безопасных SQL-запросов, в котором заранее предусмотрено всё для корректной отработки любых, самых заковыристых ситуаций, надо всего лишь начать пороть розгами кодеров, чтобы они научились делать простую вещь: вот здесь должен быть вот такой запрос, вот в этом месте (после "obrer by") него вставляется только "price" или "rating", любой другой вариант - bad request и пнх. А универсальный инструмент, стойкий к идиотам, всё равно сделать не получится.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

52. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Crazy Alex (ok), 29-Мрт-19, 17:35

ну не живёт оно. Хотелки всегда растут

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

55. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Борщдрайвен бигдата (?), 29-Мрт-19, 20:29

Не надо о них мечтать. Они есть, да, с проверкой корректности в compile time, типобезопасные и прочее. Но, увы, это не о php.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

44. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 29-Мрт-19, 13:25

> 2) Производительность сборки запроса выходит реально ниже плинтуса. Даже после достаточно
> низкоуровневой оптимизации.
А как ты мерял? Я просто нашёл такую библиотеку для php, и мне аж любопытно стало. У тебя есть тест для производительности? Я бы погонял его интереса ради.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

51. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Crazy Alex (ok), 29-Мрт-19, 17:34

Я знаю. поэтому и написал "ормов сотоварищи"

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

48. "Опасные уязвимости в платформе электронной коммерции Magento..." –1 +/–

Сообщение от Sw00p aka Jerom (?), 29-Мрт-19, 16:17

>Проблема решённая на 90% лучше, чем проблема решённая на 0%.
кхммм, во-первых, проблемы разрешают, а не решают, решают - задачи. Во-вторых, по определению у проблемы на данный момент не должно быть разрешений, на то и проблема. В третьих, в вашем утверждении проблему нужно заменить на задачу.
пс: не сочтите за придирания к словам, но лучше на не использовать то понятие, которое знаете на 90%, "незнайка, лучше недоучки".

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

54. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 29-Мрт-19, 19:28

>>Проблема решённая на 90% лучше, чем проблема решённая на 0%.
> кхммм, во-первых, проблемы разрешают, а не решают, решают - задачи.
Давайте теперь устроим тут урок русского языка?
> Во-вторых, по
> определению у проблемы на данный момент не должно быть разрешений, на
> то и проблема. В третьих, в вашем утверждении проблему нужно заменить
> на задачу.
Как вам будет угодно.
> пс: не сочтите за придирания к словам, но лучше на не использовать
> то понятие, которое знаете на 90%, "незнайка, лучше недоучки".
🙄

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

13. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от freehck (ok), 29-Мрт-19, 02:00

> Я лично вообще не понимаю, как можно такие баги (возможность sql-инъекции) допускать на любом языке.
Как-как. Надо спозиционировать язык как "язык для домохозяек", после чего нарастить соотвествующего уровня сознания комьюнити -- и вуаля, получите массу ошибок такого толка в тысячах проектов. =)

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от freehck (ok), 29-Мрт-19, 01:57

> let result = query_builder()
>     .select(["uid", "nickname", field_name])
>     .from(USERS_TABLE)
>     .where(less(length("nickname"), 5))
>     .execute(SQL_CONNECTION);
Ну с селектом-то всё просто. Если уж показывать, то джойны, агрегаты, вложенные запросы. =)

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

22. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 29-Мрт-19, 05:04

>> let result = query_builder()
>>     .select(["uid", "nickname", field_name])
>>     .from(USERS_TABLE)
>>     .where(less(length("nickname"), 5))
>>     .execute(SQL_CONNECTION);
> Ну с селектом-то всё просто. Если уж показывать, то джойны, агрегаты, вложенные
> запросы. =)
Мне сложно навскидку предложить решение для php. Там нужны ссылки на поля из разных таблиц, но как это представить в синтаксисе php, чтобы это было бы не совсем уродливо? В php есть tuple? Можно ли написать, что-то типа:
select([("table1", "id"), ("table2", "name")]), имея ввиду "SELECT table1.id, table2.name"?
Всё равно уродливо выходит?
А, или это не надо? Если наш escape_string, не будет искейпить точки из имени, и оставлять table1.id неизменным -- это будет дырой для злоумышленной веб-макаки, которая намеренно пишет код, который содержит sql-injection, или нет?
Вложенные запросы реализуются элементарно, просто надо научить тип QueryBuilder принимать Query в качестве аргумента. Немного ООП, и QueryBuilder'у даже не надо будет знать, что он получил Query в качестве аргумента from, а не EscapedSqlString.

Да блин, хочешь я тебе сейчас прямо здесь напидаю простейшую реализацию? Я не буду парится на тему того, чтобы писать на пхп -- я его не помню, я псевдокодом.
Смотри.
Во-первых, метод для наших объектов. Если встроенным типам php возможно этот метод добавить, то надо его добавить им, и тогда все встроенные типы должны преобразовываться к String, после чего полностью экранироваться.
method sql_escape(self) -> EscapedString;
EscapedString тоже должна иметь этот метод:
function EscapedString::sql_escape(self) -> EscapedString {
    return self;
}
Затем мы пишем функцию:
function my_sql_escape(obj) -> EscapedString {
    if obj.has_method("sql_escape") {
        return obj.sql_escape();
    } elseif obj.has_method("to_string") /* or maybe object is a string */{
        // я подразумеваю здесь, что метод from реально экранирует всё
        return EscapedString::from(obj.to_string());
    } else {
        // может быть нам надо ещё какие-то типы обработать, скажем int или float, но мне лень
        panic("I'm a stupid programmer, who cannot into program");
    }
}
И дальше пишется
class Query {
    query: String,
}
пачка функций вида:
function Query::select(self, obj) -> Query {
    // только эти функции будут писать в self.query нативные php-строки,
    // это ограниченный объём кода, и его возможно проверить вручную глазами, чтобы тут
    // не писалось бы ничего глупого в запрос
    self.query.append("SELECT ");
    self.query.append(my_sql_escape(obj).to_string());
    self.query.append(" ");
    return self;
}
Чтобы Query можно было бы втыкать подзапросом:
function Query::sql_escape(self) -> EscapedString {
    // тут мы вернём EscapedString, которая будет содержать реально non-escaped string
    return EscapedString::from_string_unchecked(self.query);
}
С функциями типа less, or, and и тп, надо подумать как сделать. Надо ли тут создавать тип NaryFunCall, который будет хранить имя функции ("<", ">=", "or", "and"), аргументы и флаг infix_notation, чтобы все эти less/or/and сделать конструкторами этого типа? Или может надо сделать как-то ещё?
Но, в общем, это ТУПЕЙШАЯ реализация, и она даже получилась лучше, чем я ждал от такой реализации. Строку Query::query придётся перевыделять постоянно в процессе конкатенаций, но это вероятно можно обойти, предвыделив килобайт памяти под строку, и может быть даже хранить такую строку от запроса к запросу, чтобы не выделять её каждый раз снова, а потом не удалять.
Эта ТУПЕЙШАЯ реализация не проверяет SQL синтаксис, и позволяет генерить невалидные запросы, скажем, "WHERE hello FROM world". Более глубокая проверка потребует кучи дополнительных усилий. Но sql-injection здесь либо вырезана уже, либо её возможно вырезать. Опять же утверждать не возьмусь, поскольку язык для этого псевдокода я придумывал по ходу дела.
В ней есть ещё косяк, связанный с тем, что она легко может позволять ситуацию, когда одно и то же значение имеет несколько mutable ссылок. Может я зря беспокоюсь, а может и нет.
Ещё она создаёт лишние и ненужные копии строк. Вероятно это можно победить, как-нибудь, если прокидывать везде строку Query::query, в которую надо дописывать значения, вместо того, чтобы создавать их в куче и возвращать, чтобы они тут же были сконкатенированы с Query::query и выброшены в мусор.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

27. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Онаним (?), 29-Мрт-19, 08:53

Ага. А теперь давай напишем
(
(SELECT a.x, (SELECT SUM(b.y) FROM b WHERE b.f IN (SELECT e.p FROM e)) AS c, CONCAT(a.z, a.abc) AS d INNER JOIN (SELECT g.h, g.j FROM g WHERE g.k = 1) AS l ON l.h = a.m)
UNION
(SELECT a.x, (SELECT SUM(b.y) FROM b WHERE b.f IN (SELECT e.p FROM e)) AS c, CONCAT(a.z, a.abc) AS d INNER JOIN (SELECT n.h, n.j FROM g WHERE g.k = 1) AS l ON l.h = a.m)
) LIMIT 50
Ну, ORDER, WHERE, GROUP и HAVING пропустил, можно ещё и там было побаловаться

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

46. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 29-Мрт-19, 13:50

>[оверквотинг удален]
> g.j FROM g WHERE g.k = 1) AS l ON l.h
> = a.m)
> UNION
> (SELECT a.x, (SELECT SUM(b.y) FROM b WHERE b.f IN (SELECT e.p FROM
> e)) AS c, CONCAT(a.z, a.abc) AS d INNER JOIN (SELECT n.h,
> n.j FROM g WHERE g.k = 1) AS l ON l.h
> = a.m)
> ) LIMIT 50
> Ну, ORDER, WHERE, GROUP и HAVING пропустил, можно ещё и там было
> побаловаться
Ты в курсе, что подзапросы можно собирать в переменные, делая таким образом этот код читабельнее?

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

62. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от freehck (ok), 30-Мрт-19, 13:24

> Да блин, хочешь я тебе сейчас прямо здесь напидаю простейшую реализацию?
А, так это не готовая реализация, это просто прожект? Сорри, я подумал, ты о какой-то уже существующей библиотеке говоришь.
Что мне накидывать, накидать-то я и сам могу. Но что ты хочешь от коммьюнити пхпшников, ну в самом деле... Это же пхпшники, ну камон.
Я помню, как я пытался одного пхпшника в проекте научить делать авторизацию через базу. Дал ему ссылки на все доки, все апи, вообще на всё. Без толку: он в итоге сделал худо-бедно по роликам на ютубе авторизацию посредством записи сессии в файл, и с чувством выполненного долга доложил о том, что справился. =/
И это, блин, всего лишь авторизация. А ты про правильные подходы к организации работы с базой.
Не, вебнику вебниково. Вся работа с базой должна быть вынесена в бэкенд, а вебнику предоставлены API работы с бэкендом. Это -- наиболее разумное решение, имхо. И не на php надо писать фронтенд, а на js. Jamstack не на пустом месте родился.
PS: и будем честны, вряд ли вебнику под силу писать запросы в базу сложнее селекта и апдейта значений одной конкретной таблицы.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

63. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 30-Мрт-19, 23:39

> И это, блин, всего лишь авторизация. А ты про правильные подходы к организации работы с базой.
Да, я из этого обсуждения уже понял. Они мыслят в узких рамках создания конкретной программы, а не в смысле создания среды для создания программы. Это мне напоминает: https://www.youtube.com/playlist?list=PLB00JHoTw1TeX82Qw8hoF...
Мужик купил за $1 сгнившую яхту и ремонтирует её, снимая всё на видео и заливая на ютуб. Ему приводить яхту в порядок чисто по фану, и это заражает людей. Они смотрят видяшки на ютубе, заражаются идеей и приезжают к нему помогать. И любопытно наблюдать, как люди создают техпроцессы: надо вырезать туеву хучу шпангоутов вместо сгнивших, причём вырезать надо точно, то есть нужен труд квалифицированного плотника. Он вырезал первый шпангоут пару дней, по-моему. Сейчас они меняют десяток пар шпангоутов в неделю, выдерживая точность до миллиметра, причём существенная часть работы выполняется энтузиастами, которые не уверены за какой конец надо держать молоток. Потому что техпроцесс. То есть созданные на месте специализированные инструменты, заточенные под специализированные задачи, инструменты с которыми справится любой после пяти минут обучения. (Ну, то есть, там не только наколенно созданные инструменты -- раритетную пилу, которая пилит криво, позволяя задать угол этой кривизны с точностью до градуса они не создавали, её подарили, но приспособа для выстругивания досок, с тем чтобы те были бы плоскими, а не дугой или ещё как, была создана там, или точилка для выстругивания деревянных пальцев -- она в какой-то из последних видяшек получила апгрейд и там теперь можно метр-два этих пальцев в минуту выстругивать).
Это другое мышление. Не "я ремонтирую яхту", а "я создаю среду для ремонта яхты". Не "чтобы вырезать шпангоут нужны прямые руки, и розгами пороть тех, у кого они недостаточно прямые", а "надо изменить техпроцесс так, чтобы вырезать шпангоут по лекалу мог бы любой школьник". Не стоит конечно переоценивать этого мужика -- я не думаю, что он рассчитывал на то, что к нему ломанутся энтузиастя и сделают за него существенную часть работы, но де факто получилось, что он создал не только технологическую среду, но и социальную среду, которая обеспечивает его бесплатной рабочей силой. И которая помимо него придумывает, как эту бесплатную рабочую силу применить -- большинство изобретений для этого было создано не им, а теми кто к нему приезжал. Он как раз сам больше похож на специалиста, который имеет достаточно прямые руки, чтобы вырезать шпангоут вручную перочинным ножиком, или топором, или безнопилой или даже консервной банкой, и поэтому имея бензопилу и рубанок он пытается сделать ими, вместо того, чтобы думать об изобретении способов, которые не будут требовать особой прямоты рук.

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

14. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Crazy Alex (ok), 29-Мрт-19, 02:22

Это у вас статически построенный запрос. Для простых случаев - так и делают, благо ормов написано - вагон. А теперь представьте, что оно генерируется динамически - надо - лишнее where добавили (или в него пару-тройку условий), надо - join докрутили, имя таблицы на лету сгенерировали, и так далее. Ну, то есть тоже можно реализовать, но получаются такие монстры, с котороыми связываться - только проблем искать. А если проще - то не выйдет всё эскейпить, оптому что там натурально не только данные подставляются, но и куски языковой конструкции генерируются.
В общем, поверьте, SQL - это настолько истоптанная тема, что абсолютно все подходы были перепробованы сотни если не тысячи раз. И используется то, что даёт оптимальный выхлоп.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

17. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 29-Мрт-19, 04:28

> Это у вас статически построенный запрос.
Динамически. Методы типа select, where и прочие вызываются динамически. Никто не мешает вызывать их в цикле.
> В общем, поверьте, SQL - это настолько истоптанная тема, что абсолютно все
> подходы были перепробованы сотни если не тысячи раз. И используется то,
> что даёт оптимальный выхлоп.
Я полагаю, что вы совершенно зря сейчас верите в здравомыслие тех, кто пилит язык начиная с 90-х годов. Люди очень часто залипают на каких-то идеях и забывают рассмотреть альтернативные. Вот как сейчас вы отмахиваетесь от идеи, даже не пытаясь выяснить, насколько она реализуема, путаете её с ORM'ом, хотя совершенно очевидно, что здесь даже и не пахнет никакими объектами и что код даже не представляет себе какая там модель у базы данных.
Вы не один такой, таких людей большинство. Подавляющее. В частности среди программистов.
Но, ладно, допустим, я не прав. Иногда так случается, что я оказываюсь излишне пессимистичен, оценивая способность других принимать и понимать новые идеи. Если это так, значит должны были быть попытки запилить подобное в PHP. Для того, чтобы выяснить, что этот подход не работает для php, надо попытаться его реализовать. Голословные рассуждения типа "это наверное будет сложно" голословны. Единственная проблема, которая на мой взгляд может возникнуть на этом пути -- это проблема производительности. Но чтобы в эту проблему впороться и придти к выводу, что она неустранима в пхп, надо написать, посмотреть как написанное работает под нагрузкой, и попытаться устранить бутылочные горлышки.
Если такие попытки были, то они должны были оставить следы на github'е, в блогах, на stackoverflow, reddit'е или ещё где-то. Просто обязаны были, потому что подобная проделанная работа -- это очень неплохое дополнение к CV любого разработчика, которое показывает, что он не просто обезьяна, способная лишь код со stackoverflow копипастить, но он ещё и разрабатывать код самостоятельно могёт, и исследовать этот код на производительность, и устранять проблемы с производительностью, и вообще это сформировавшийся специалист.
Вам известны такие попытки? Я вот только что сунулся в гугл, просмотрел штук двадцать результатов, нашёл ~15 библиотек, и это либо конкатенация строк оставленная в качестве упражнения веб-макаке, либо ORM. ORM -- это тоже ничё так метод, но у него есть свои ограничения, и по-хорошему, под него всё равно стоило бы подложить реализацию sql внутри языка. Из чего я делаю вывод, что веб-макаки настолько макаки, что они двадцать лет смотрят на cl-sql, и ни разу не попытались сделать что-то подобное в php. Им бы только сайтики клепать, а системное мышление у них намертво прилипло к идее CMS, и отлипнуть никак не может.
Хотя есть альтернативное объяснение: может быть проблема с производительностью настолько очевидна и настолько лежит на поверхности для любого разработчика на PHP, что он видит её заранее, а я не вижу, потому что PHP не знаю в достаточной мере? Ну? Если она лежит на поверхности, то значит её можно описать парой абзацев? Я готов их прочитать, если что.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

23. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 29-Мрт-19, 05:32

Я нашёл! https://github.com/nilportugues/php-sql-query-builder
Действительно я ошибался в отношении тупости php'шников. Простите.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

29. "Опасные уязвимости в платформе электронной коммерции Magento..." +3 +/–

Сообщение от Онаним (?), 29-Мрт-19, 08:58

Да нет, ты не ошибался. Только это не к PHP'шникам, а как раз к любителям "классических" подходов в PHP.
40 файлов и 100 килобайт кода. Только чтобы собрать SQL-запрос не конкатенацией.
Ещё раз: 40 СРАНЫХ ФАЙЛОВ и 100 СРАНЫХ КИЛОБАЙТ КОДА. Ради сборки запроса. В языке с динамической загрузкой и предтрансляцией. А потом эти же люди удивляются, почему их криворукие поделия еле ворочаются даже на шустрых VPS.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

33. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от vedronim (?), 29-Мрт-19, 09:51

> Да нет, ты не ошибался. Только это не к PHP'шникам, а как
> раз к любителям "классических" подходов в PHP.
> 40 файлов и 100 килобайт кода. Только чтобы собрать SQL-запрос не конкатенацией.
> Ещё раз: 40 СРАНЫХ ФАЙЛОВ и 100 СРАНЫХ КИЛОБАЙТ КОДА. Ради сборки
> запроса. В языке с динамической загрузкой и предтрансляцией. А потом эти
> же люди удивляются, почему их криворукие поделия еле ворочаются даже на
> шустрых VPS.
Всеми руками за, бро!

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

45. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от Ordu (ok), 29-Мрт-19, 13:27

> Да нет, ты не ошибался. Только это не к PHP'шникам, а как
> раз к любителям "классических" подходов в PHP.
> 40 файлов и 100 килобайт кода. Только чтобы собрать SQL-запрос не конкатенацией.
> Ещё раз: 40 СРАНЫХ ФАЙЛОВ и 100 СРАНЫХ КИЛОБАЙТ КОДА. Ради сборки
> запроса. В языке с динамической загрузкой и предтрансляцией. А потом эти
> же люди удивляются, почему их криворукие поделия еле ворочаются даже на
> шустрых VPS.
Хех. Ну тогда втoпку php, всё что я могу сказать.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

49. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Sw00p aka Jerom (?), 29-Мрт-19, 16:21

>Ещё раз: 40 СРАНЫХ ФАЙЛОВ и 100 СРАНЫХ КИЛОБАЙТ КОДА. Ради сборки запроса.
простите, а у вашей ОРМ разве не столько файлов? или вы их своими не считаете?

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

9. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от Sw00p aka Jerom (?), 29-Мрт-19, 01:10

да ладно, не удивлен, после новости с циской )))))
пс: адская капча 66637

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

40. "Опасные уязвимости в платформе электронной коммерции Magento..." –1 +/–

Сообщение от Аноним (39), 29-Мрт-19, 12:11

Зато у меня щас была кошерная - 24816

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

24. "Опасные уязвимости в платформе электронной коммерции Magento..." +2 +/–

Сообщение от Онаним (?), 29-Мрт-19, 08:38

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

43. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 29-Мрт-19, 13:24

> Это вопрос элементарной аккуратности. Тут надо не тормознющие и ограниченные safe API
> плодить для раздолбаев, а банально вправлять руки/мозги джунам до просветления.
Да, точно. Вон C/C++ программеры до сих пор правят. И опыт Magento тоже показывает, что это работает. Да.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

28. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от конь в пальто (?), 29-Мрт-19, 08:55

тут не в php дело, а конкретно в маженте - эталонного примера некомпетентности разработчиков.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

50. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Sw00p aka Jerom (?), 29-Мрт-19, 16:24

> тут не в php дело, а конкретно в маженте - эталонного примера
> некомпетентности разработчиков.
ругать ЯП - последнее дело!

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

47. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от _ (??), 29-Мрт-19, 14:46

Ну дык не истери, не плачь, не проси - а возьми И ДАЙ! Ты же типо умнее перечисленных в посте? Или такое же? 😉

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

53. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Ordu (ok), 29-Мрт-19, 19:25

> Ну дык не истери, не плачь, не проси - а возьми И
> ДАЙ! Ты же типо умнее перечисленных в посте? Или такое же?
> 😉
Так "возьми" или "дай"?
Я не понимаю, что ты имеешь в виду.

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

4. "Опасные уязвимости в платформе электронной коммерции Magento..." –1 +/–

Сообщение от zzz (??), 28-Мрт-19, 23:55

Кто-то до сих пор пользуется этим раздутым маркетинговым буллшитом?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от tsifra (?), 29-Мрт-19, 11:29

какие альтернативы?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

38. "Опасные уязвимости в платформе электронной коммерции Magento..." +2 +/–

Сообщение от Andrey Mitrofanov (?), 29-Мрт-19, 11:47

> какие альтернативы?
Бооо-о-ольше!!  БООООООЛЬШЕ раздувать маркетинг булш1том!  </очевидно>

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

57. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от tsifra (?), 29-Мрт-19, 23:28

Непонятно, что имелось в виду

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

59. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от tsifra (?), 29-Мрт-19, 23:45

Мне правда очень интересно. Знаком с платформой с первой версии. Недавно внедрял версию 2.3. Негатива очень много. Но проверенные мной альтернативы не смогли дать нужную гибкость. В итоге костылями и скриптами пришлось доводить magento

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

41. "Опасные уязвимости в платформе электронной коммерции Magento..." –2 +/–

Сообщение от Аноним (39), 29-Мрт-19, 12:24

Ну, начни отсюда: https://en.wikipedia.org/wiki/Category:Free_e-commerce_software

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

56. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от tsifra (?), 29-Мрт-19, 23:27

Вы насколько хорошо с предметной областью знакомы? Рассчитывал получить коментарии от профи. На мой взгляд magento это никак не меньше чем фреймфорк symfony

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

58. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от пох (?), 29-Мрт-19, 23:41

> Вы насколько хорошо с предметной областью знакомы?
когда вместо ответа дают ссылку на бессмысленные списки из викибредии - это означает, что подобным списком знакомство и исчерпывается.
> На мой взгляд magento это никак не меньше чем фреймфорк symfony
вообще-то они совершенно перпендикулярны.
мажента - готовый механизм для конкретной задачи. symphony - набор шестеренок, механизм надо собрать самостоятельно.

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

60. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от tsifra (?), 29-Мрт-19, 23:56

Я оцениваю мадженту больше как каркас с готовой веб-витриной и всеми ништяками для seo и cms, который задаёт определённые правила и даёт определённые инструменты. В отрыве от каких-то других систем(вроде odoo/самописных) она неприменима даже для мало-мальски малого бизнеса. Точнее применима, но это боль. Отсюда и сравнение с symfony

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

61. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от пох (?), 30-Мрт-19, 09:56

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

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

5. "Опасные уязвимости в платформе электронной коммерции Magento..." +3 +/–

Сообщение от Аноним (5), 29-Мрт-19, 00:10

Стоит уточнить, что Magento это компания Adobe.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от Аноним (32), 29-Мрт-19, 09:48

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

42. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от sin (??), 29-Мрт-19, 12:58

magento принадлежит адобу не более полугода, вряд ли они кого-то, кроме топов, успели поменять.
А так она каждые пару лет из рук в руки переходит

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

18. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Аноним (18), 29-Мрт-19, 04:50

Security module for php7 - Killing bugclasses and virtual-patching the rest!
https://github.com/nbs-system/snuffleupagus

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Опасные уязвимости в платформе электронной коммерции Magento..." +1 +/–

Сообщение от Онаним (?), 29-Мрт-19, 09:02

Suhosin уже был, спасибо, не надо.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

35. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от нах (?), 29-Мрт-19, 10:34

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

19. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Аноним (18), 29-Мрт-19, 04:54

https://chaneyoon.tistory.com/253
https://www.cdxy.me/?p=752
https://github.com/brianlam38/Sec-Cheatsheets/blob/master/We...
https://github.com/brianlam38/Sec-Cheatsheets/blob/master/We...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Аноним (18), 29-Мрт-19, 04:55

[Tutorial]Local File Include (LFI) https://underc0de.org/foro/bugs-y-exploits/(tutorial)local-file-include-(lfi)/

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "Опасные уязвимости в платформе электронной коммерции Magento..." +/–

Сообщение от Аноним (18), 29-Мрт-19, 04:57

Some common ways of upgrading from LFI to RCE
https://www.rcesecurity.com/2017/08/from-lfi-to-rce-via-php-.../

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Опасные уязвимости в платформе электронной коммерции Magento..."	–1 +/–
Сообщение от Аноним (1), 28-Мрт-19, 23:09
1.9 подвержены?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

2. "Опасные уязвимости в платформе электронной коммерции Magento..."	–3 +/–
Сообщение от Ordu (ok), 28-Мрт-19, 23:17
> Наиболее опасная проблема позволяет добиться подстановки своего SQL-кода через отправку специального запроса Шёл 2019 год, а php всё не мог справиться с sql-injection. Блин, КАК ТАК МОЖНО? Не, ну ладно C и C++ продолжают десятилетиями ходить по граблям нулевых и висящих указателей, там особенности языка вынуждают. Но sql -- это внешняя сущность для php, и всё что надо -- дать веб-макаке safe-API, который не позволит ей создать условий для sql-инъекции.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Crazy Alex (ok), 28-Мрт-19, 23:45
	Попытайтесь. И удивитесь, как много странных случаев, которые в красивые ограничения не укладываются - разного рода генерация имён таблиц на лету и тому подобное. Если проект крупнее hello world - никуда не денетесь, будете время от времени собирать запрос строкой, со всеми вытекающими рисками. В плюсах, кстати, тоже можно в 99% случаев обойтись без каких-либо "граблей нулевых и висящих указателей", тем они от C и отличаются.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	6. "Опасные уязвимости в платформе электронной коммерции Magento..."	+5 +/–
	Сообщение от vedronim (?), 29-Мрт-19, 00:43
	Динамически собирать запрос можно и в безопастном виде.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	7. "Опасные уязвимости в платформе электронной коммерции Magento..."	–1 +/–
	Сообщение от Аноним (7), 29-Мрт-19, 01:07
	Нет, нельзя. В SQLite, например, нельзя создавать таблицы и триггерить прагмы используя prepared statements.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	31. "Опасные уязвимости в платформе электронной коммерции Magento..."	+1 +/–
	Сообщение от vedronim (?), 29-Мрт-19, 09:48
	> Нет, нельзя. В SQLite, например, нельзя создавать таблицы и триггерить прагмы используя > prepared statements. Скклайт это крайний случай. На нем е-коммерцию нормальные люди не делают. Уже в майскуеле все делается без проблем.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	25. "Опасные уязвимости в платформе электронной коммерции Magento..."	–2 +/–
	Сообщение от Онаним (?), 29-Мрт-19, 08:43
	Два золотых правила, забывая которые, получают все эти грабли: 1) Весь - повторюсь - ВЕСЬ user input считается untrusted и при необходимости внутреннего использования - 100% валидируется в обязательном порядке, при любых условиях, даже если это увеличит объём и сложность кода в разы 2) При передаче каких либо untrusted данных в среду, использующую специальные символы в наборе данных, в обязательном порядке делаем полноценный escape согласно требованиям среды
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "Опасные уязвимости в платформе электронной коммерции Magento..."	–2 +/–
	Сообщение от Ordu (ok), 29-Мрт-19, 01:08
	> Попытайтесь. И удивитесь, как много странных случаев, которые в красивые ограничения не > укладываются - разного рода генерация имён таблиц на лету и тому > подобное. Если проект крупнее hello world - никуда не денетесь, будете > время от времени собирать запрос строкой, со всеми вытекающими рисками. Это делается элементарно: let field_name = get_one_more_field_name(); let result = query_builder() .select(["uid", "nickname", field_name]) .from(USERS_TABLE) .where(less(length("nickname"), 5)) .execute(SQL_CONNECTION); Функции less и length, понятно, возвращают объекты, которые затем where компилирует в строчку. Или может не where, может стоит сначала собрать всё в один объект-запрос, проверив параллельно синтаксис, а затем всё за раз скомпилировать, чтобы не выделять память под строку с запросом, а непосредственно писать запрос в сокет sql. Если напрягает то, что все эти "uid", "nickname" будут прогоняться через функцию экранирования каждый раз, дёргая каждый раз кучу и тормозя выполнение, то ничто не мешает объявить тип EscapedSqlString, который будет содержать в себе строку, а функция sql_escape_string, будет этот тип "разворачивать", возвращая строку изнутре не экранируя её, а обычный String она будет экранировать. Использование EscapedSqlString привносит возможностей скосячить, но так же оно привносит дополнительных трудностей, из-за чего самый простой способ использовать EscapedSqlString это: const UID = EscapedSqlString::new("uid"); const NICKNAME = EscapedSqlString::new("nickname"); и затем: .select([UID, NICKNAME, field_name]) и .where(less(length(NICKNAME), 5)) Конечно, если мы говорим об интерпретируемом языке, то подобный подход всё равно добавит тормозов, потому что придётся собирать временный объект, но добавит оно не особо, а вот создать sql-инъекцию можно будет разве что злоумышленно.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	10. "Опасные уязвимости в платформе электронной коммерции Magento..."	+1 +/–
	Сообщение от vitalif (ok), 29-Мрт-19, 01:17
	...и учить ещё один язык в дополнение к SQL. А потом ой а как написать OR? Ой а как написать постгрес специфичный оператор? Ой а как вместо таблицы подзапрос? Ой а CTE написать? Я лично вообще не понимаю, как можно такие баги (возможность sql-инъекции) допускать на любом языке. Рукожопу и Rust не помеха
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	11. "Опасные уязвимости в платформе электронной коммерции Magento..."	–1 +/–
	Сообщение от Ordu (ok), 29-Мрт-19, 01:33
	> ...и учить ещё один язык в дополнение к SQL. Это и есть sql. Тут ничего учить дополнительно не надо, достаточно понять идею, как синтаксис sql транслируется в это. > А потом ой а как написать OR? Ой а как написать постгрес специфичный оператор? Ой а как вместо таблицы подзапрос? Ой а CTE написать? Для того, чтобы таких вопросов не возникало, библиотека для создания sql запросов должна хоститься на github'е, чтобы её разработка велась бы несколькими заинтересованными разработчиками, и постоянно бы туда влетали бы feature и pull реквесты. Через полгода она будет уметь всё, что надо. Ещё через полгода-год, она стабилизируется. > Я лично вообще не понимаю, как можно такие баги (возможность sql-инъекции) допускать > на любом языке. Это потому, что, видимо, нет опыта долгосрочной поддержки программ с параллельным их развитием. > Рукожопу и Rust не помеха Да. Как показывает опыт применения miri на std из rust'а, не проблема: https://github.com/rust-lang/miri#bugs-found-by-miri Если тебе слова в тех багах мало что говорят, то я поясню, что последние четыре -- это прямые нарушения rust'овых инвариантов, которые можно использовать для того, чтобы получить, как минимум, data race. А в некоторых, случаях, возможно даже use after free или типа того. Точнее не скажу, что именно можно -- это надо смотреть описание багов. Но здесь ты совершаешь очень распространённую ошибку. Если мы не можем решить проблему на 100%, это не повод отказываться от того, чтобы решить её на 90%. Проблема решённая на 90% лучше, чем проблема решённая на 0%.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	15. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Crazy Alex (ok), 29-Мрт-19, 02:58
	Да блин, ормов сотоварищи написано уже море. Но используются в основном какой-нибудь джаве, где написать простыню (и ещё кусок xml впридачу) для выполнения чего-то тривиального - норма, как в том же Hibernate. И то вписанные руками SQL запросы - не то чтобы редкость. Потому что по дефолту либо с быстродействием проблемы, либо что-то требует больше динамики, чем может предоставить либа.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	16. "Опасные уязвимости в платформе электронной коммерции Magento..."	+1 +/–
	Сообщение от Ordu (ok), 29-Мрт-19, 04:16
	> Да блин, ормов сотоварищи написано уже море. Но используются в основном какой-нибудь > джаве, где написать простыню (и ещё кусок xml впридачу) для выполнения > чего-то тривиального - норма, как в том же Hibernate. И то > вписанные руками SQL запросы - не то чтобы редкость. Потому что > по дефолту либо с быстродействием проблемы, либо что-то требует больше динамики, > чем может предоставить либа. То что я предложил выше -- это не ORM. Не надо путать тёплое с мягким.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	26. "Опасные уязвимости в платформе электронной коммерции Magento..."	+1 +/–
	Сообщение от Онаним (?), 29-Мрт-19, 08:47
	Ну делал я себе такой генератор запросов ради эксперимента. Выкинул. 1) Неудобно - простыня вызовов, там, где надо скобки (вызов внутри вызова получается) - вообще швах, в вызовах начинаешь теряться. 2) Производительность сборки запроса выходит реально ниже плинтуса. Даже после достаточно низкоуровневой оптимизации.
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	39. "Опасные уязвимости в платформе электронной коммерции Magento..."	–2 +/–
	Сообщение от Аноним (39), 29-Мрт-19, 12:09
	Не, мужики, вы опять двинулись не в ту сторону. Вместо того, чтобы мечтать о каком-то волшебном эльфийско-единорожьем языке для составления безопасных SQL-запросов, в котором заранее предусмотрено всё для корректной отработки любых, самых заковыристых ситуаций, надо всего лишь начать пороть розгами кодеров, чтобы они научились делать простую вещь: вот здесь должен быть вот такой запрос, вот в этом месте (после "obrer by") него вставляется только "price" или "rating", любой другой вариант - bad request и пнх. А универсальный инструмент, стойкий к идиотам, всё равно сделать не получится.
	Ответить \| Правка \| ^ к родителю #26 \| Наверх \| Cообщить модератору


	52. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Crazy Alex (ok), 29-Мрт-19, 17:35
	ну не живёт оно. Хотелки всегда растут
	Ответить \| Правка \| ^ к родителю #39 \| Наверх \| Cообщить модератору


	55. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Борщдрайвен бигдата (?), 29-Мрт-19, 20:29
	Не надо о них мечтать. Они есть, да, с проверкой корректности в compile time, типобезопасные и прочее. Но, увы, это не о php.
	Ответить \| Правка \| ^ к родителю #39 \| Наверх \| Cообщить модератору


	44. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Ordu (ok), 29-Мрт-19, 13:25
	> 2) Производительность сборки запроса выходит реально ниже плинтуса. Даже после достаточно > низкоуровневой оптимизации. А как ты мерял? Я просто нашёл такую библиотеку для php, и мне аж любопытно стало. У тебя есть тест для производительности? Я бы погонял его интереса ради.
	Ответить \| Правка \| ^ к родителю #26 \| Наверх \| Cообщить модератору


	51. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Crazy Alex (ok), 29-Мрт-19, 17:34
	Я знаю. поэтому и написал "ормов сотоварищи"
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	48. "Опасные уязвимости в платформе электронной коммерции Magento..."	–1 +/–
	Сообщение от Sw00p aka Jerom (?), 29-Мрт-19, 16:17
	>Проблема решённая на 90% лучше, чем проблема решённая на 0%. кхммм, во-первых, проблемы разрешают, а не решают, решают - задачи. Во-вторых, по определению у проблемы на данный момент не должно быть разрешений, на то и проблема. В третьих, в вашем утверждении проблему нужно заменить на задачу. пс: не сочтите за придирания к словам, но лучше на не использовать то понятие, которое знаете на 90%, "незнайка, лучше недоучки".
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	54. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Ordu (ok), 29-Мрт-19, 19:28
	>>Проблема решённая на 90% лучше, чем проблема решённая на 0%. > кхммм, во-первых, проблемы разрешают, а не решают, решают - задачи. Давайте теперь устроим тут урок русского языка? > Во-вторых, по > определению у проблемы на данный момент не должно быть разрешений, на > то и проблема. В третьих, в вашем утверждении проблему нужно заменить > на задачу. Как вам будет угодно. > пс: не сочтите за придирания к словам, но лучше на не использовать > то понятие, которое знаете на 90%, "незнайка, лучше недоучки". 🙄
	Ответить \| Правка \| ^ к родителю #48 \| Наверх \| Cообщить модератору


	13. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от freehck (ok), 29-Мрт-19, 02:00
	> Я лично вообще не понимаю, как можно такие баги (возможность sql-инъекции) допускать на любом языке. Как-как. Надо спозиционировать язык как "язык для домохозяек", после чего нарастить соотвествующего уровня сознания комьюнити -- и вуаля, получите массу ошибок такого толка в тысячах проектов. =)
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	12. "Опасные уязвимости в платформе электронной коммерции Magento..."	+1 +/–
	Сообщение от freehck (ok), 29-Мрт-19, 01:57
	> let result = query_builder() > .select(["uid", "nickname", field_name]) > .from(USERS_TABLE) > .where(less(length("nickname"), 5)) > .execute(SQL_CONNECTION); Ну с селектом-то всё просто. Если уж показывать, то джойны, агрегаты, вложенные запросы. =)
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	22. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Ordu (ok), 29-Мрт-19, 05:04
	>> let result = query_builder() >> .select(["uid", "nickname", field_name]) >> .from(USERS_TABLE) >> .where(less(length("nickname"), 5)) >> .execute(SQL_CONNECTION); > Ну с селектом-то всё просто. Если уж показывать, то джойны, агрегаты, вложенные > запросы. =) Мне сложно навскидку предложить решение для php. Там нужны ссылки на поля из разных таблиц, но как это представить в синтаксисе php, чтобы это было бы не совсем уродливо? В php есть tuple? Можно ли написать, что-то типа: select([("table1", "id"), ("table2", "name")]), имея ввиду "SELECT table1.id, table2.name"? Всё равно уродливо выходит? А, или это не надо? Если наш escape_string, не будет искейпить точки из имени, и оставлять table1.id неизменным -- это будет дырой для злоумышленной веб-макаки, которая намеренно пишет код, который содержит sql-injection, или нет? Вложенные запросы реализуются элементарно, просто надо научить тип QueryBuilder принимать Query в качестве аргумента. Немного ООП, и QueryBuilder'у даже не надо будет знать, что он получил Query в качестве аргумента from, а не EscapedSqlString. Да блин, хочешь я тебе сейчас прямо здесь напидаю простейшую реализацию? Я не буду парится на тему того, чтобы писать на пхп -- я его не помню, я псевдокодом. Смотри. Во-первых, метод для наших объектов. Если встроенным типам php возможно этот метод добавить, то надо его добавить им, и тогда все встроенные типы должны преобразовываться к String, после чего полностью экранироваться. method sql_escape(self) -> EscapedString; EscapedString тоже должна иметь этот метод: function EscapedString::sql_escape(self) -> EscapedString { return self; } Затем мы пишем функцию: function my_sql_escape(obj) -> EscapedString { if obj.has_method("sql_escape") { return obj.sql_escape(); } elseif obj.has_method("to_string") /* or maybe object is a string */{ // я подразумеваю здесь, что метод from реально экранирует всё return EscapedString::from(obj.to_string()); } else { // может быть нам надо ещё какие-то типы обработать, скажем int или float, но мне лень panic("I'm a stupid programmer, who cannot into program"); } } И дальше пишется class Query { query: String, } пачка функций вида: function Query::select(self, obj) -> Query { // только эти функции будут писать в self.query нативные php-строки, // это ограниченный объём кода, и его возможно проверить вручную глазами, чтобы тут // не писалось бы ничего глупого в запрос self.query.append("SELECT "); self.query.append(my_sql_escape(obj).to_string()); self.query.append(" "); return self; } Чтобы Query можно было бы втыкать подзапросом: function Query::sql_escape(self) -> EscapedString { // тут мы вернём EscapedString, которая будет содержать реально non-escaped string return EscapedString::from_string_unchecked(self.query); } С функциями типа less, or, and и тп, надо подумать как сделать. Надо ли тут создавать тип NaryFunCall, который будет хранить имя функции ("<", ">=", "or", "and"), аргументы и флаг infix_notation, чтобы все эти less/or/and сделать конструкторами этого типа? Или может надо сделать как-то ещё? Но, в общем, это ТУПЕЙШАЯ реализация, и она даже получилась лучше, чем я ждал от такой реализации. Строку Query::query придётся перевыделять постоянно в процессе конкатенаций, но это вероятно можно обойти, предвыделив килобайт памяти под строку, и может быть даже хранить такую строку от запроса к запросу, чтобы не выделять её каждый раз снова, а потом не удалять. Эта ТУПЕЙШАЯ реализация не проверяет SQL синтаксис, и позволяет генерить невалидные запросы, скажем, "WHERE hello FROM world". Более глубокая проверка потребует кучи дополнительных усилий. Но sql-injection здесь либо вырезана уже, либо её возможно вырезать. Опять же утверждать не возьмусь, поскольку язык для этого псевдокода я придумывал по ходу дела. В ней есть ещё косяк, связанный с тем, что она легко может позволять ситуацию, когда одно и то же значение имеет несколько mutable ссылок. Может я зря беспокоюсь, а может и нет. Ещё она создаёт лишние и ненужные копии строк. Вероятно это можно победить, как-нибудь, если прокидывать везде строку Query::query, в которую надо дописывать значения, вместо того, чтобы создавать их в куче и возвращать, чтобы они тут же были сконкатенированы с Query::query и выброшены в мусор.
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	27. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Онаним (?), 29-Мрт-19, 08:53
	Ага. А теперь давай напишем ( (SELECT a.x, (SELECT SUM(b.y) FROM b WHERE b.f IN (SELECT e.p FROM e)) AS c, CONCAT(a.z, a.abc) AS d INNER JOIN (SELECT g.h, g.j FROM g WHERE g.k = 1) AS l ON l.h = a.m) UNION (SELECT a.x, (SELECT SUM(b.y) FROM b WHERE b.f IN (SELECT e.p FROM e)) AS c, CONCAT(a.z, a.abc) AS d INNER JOIN (SELECT n.h, n.j FROM g WHERE g.k = 1) AS l ON l.h = a.m) ) LIMIT 50 Ну, ORDER, WHERE, GROUP и HAVING пропустил, можно ещё и там было побаловаться
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	46. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Ordu (ok), 29-Мрт-19, 13:50
	>[оверквотинг удален] > g.j FROM g WHERE g.k = 1) AS l ON l.h > = a.m) > UNION > (SELECT a.x, (SELECT SUM(b.y) FROM b WHERE b.f IN (SELECT e.p FROM > e)) AS c, CONCAT(a.z, a.abc) AS d INNER JOIN (SELECT n.h, > n.j FROM g WHERE g.k = 1) AS l ON l.h > = a.m) > ) LIMIT 50 > Ну, ORDER, WHERE, GROUP и HAVING пропустил, можно ещё и там было > побаловаться Ты в курсе, что подзапросы можно собирать в переменные, делая таким образом этот код читабельнее?
	Ответить \| Правка \| ^ к родителю #27 \| Наверх \| Cообщить модератору


	62. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от freehck (ok), 30-Мрт-19, 13:24
	> Да блин, хочешь я тебе сейчас прямо здесь напидаю простейшую реализацию? А, так это не готовая реализация, это просто прожект? Сорри, я подумал, ты о какой-то уже существующей библиотеке говоришь. Что мне накидывать, накидать-то я и сам могу. Но что ты хочешь от коммьюнити пхпшников, ну в самом деле... Это же пхпшники, ну камон. Я помню, как я пытался одного пхпшника в проекте научить делать авторизацию через базу. Дал ему ссылки на все доки, все апи, вообще на всё. Без толку: он в итоге сделал худо-бедно по роликам на ютубе авторизацию посредством записи сессии в файл, и с чувством выполненного долга доложил о том, что справился. =/ И это, блин, всего лишь авторизация. А ты про правильные подходы к организации работы с базой. Не, вебнику вебниково. Вся работа с базой должна быть вынесена в бэкенд, а вебнику предоставлены API работы с бэкендом. Это -- наиболее разумное решение, имхо. И не на php надо писать фронтенд, а на js. Jamstack не на пустом месте родился. PS: и будем честны, вряд ли вебнику под силу писать запросы в базу сложнее селекта и апдейта значений одной конкретной таблицы.
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	63. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Ordu (ok), 30-Мрт-19, 23:39
	> И это, блин, всего лишь авторизация. А ты про правильные подходы к организации работы с базой. Да, я из этого обсуждения уже понял. Они мыслят в узких рамках создания конкретной программы, а не в смысле создания среды для создания программы. Это мне напоминает: https://www.youtube.com/playlist?list=PLB00JHoTw1TeX82Qw8hoF... Мужик купил за $1 сгнившую яхту и ремонтирует её, снимая всё на видео и заливая на ютуб. Ему приводить яхту в порядок чисто по фану, и это заражает людей. Они смотрят видяшки на ютубе, заражаются идеей и приезжают к нему помогать. И любопытно наблюдать, как люди создают техпроцессы: надо вырезать туеву хучу шпангоутов вместо сгнивших, причём вырезать надо точно, то есть нужен труд квалифицированного плотника. Он вырезал первый шпангоут пару дней, по-моему. Сейчас они меняют десяток пар шпангоутов в неделю, выдерживая точность до миллиметра, причём существенная часть работы выполняется энтузиастами, которые не уверены за какой конец надо держать молоток. Потому что техпроцесс. То есть созданные на месте специализированные инструменты, заточенные под специализированные задачи, инструменты с которыми справится любой после пяти минут обучения. (Ну, то есть, там не только наколенно созданные инструменты -- раритетную пилу, которая пилит криво, позволяя задать угол этой кривизны с точностью до градуса они не создавали, её подарили, но приспособа для выстругивания досок, с тем чтобы те были бы плоскими, а не дугой или ещё как, была создана там, или точилка для выстругивания деревянных пальцев -- она в какой-то из последних видяшек получила апгрейд и там теперь можно метр-два этих пальцев в минуту выстругивать). Это другое мышление. Не "я ремонтирую яхту", а "я создаю среду для ремонта яхты". Не "чтобы вырезать шпангоут нужны прямые руки, и розгами пороть тех, у кого они недостаточно прямые", а "надо изменить техпроцесс так, чтобы вырезать шпангоут по лекалу мог бы любой школьник". Не стоит конечно переоценивать этого мужика -- я не думаю, что он рассчитывал на то, что к нему ломанутся энтузиастя и сделают за него существенную часть работы, но де факто получилось, что он создал не только технологическую среду, но и социальную среду, которая обеспечивает его бесплатной рабочей силой. И которая помимо него придумывает, как эту бесплатную рабочую силу применить -- большинство изобретений для этого было создано не им, а теми кто к нему приезжал. Он как раз сам больше похож на специалиста, который имеет достаточно прямые руки, чтобы вырезать шпангоут вручную перочинным ножиком, или топором, или безнопилой или даже консервной банкой, и поэтому имея бензопилу и рубанок он пытается сделать ими, вместо того, чтобы думать об изобретении способов, которые не будут требовать особой прямоты рук.
	Ответить \| Правка \| ^ к родителю #62 \| Наверх \| Cообщить модератору


	14. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Crazy Alex (ok), 29-Мрт-19, 02:22
	Это у вас статически построенный запрос. Для простых случаев - так и делают, благо ормов написано - вагон. А теперь представьте, что оно генерируется динамически - надо - лишнее where добавили (или в него пару-тройку условий), надо - join докрутили, имя таблицы на лету сгенерировали, и так далее. Ну, то есть тоже можно реализовать, но получаются такие монстры, с котороыми связываться - только проблем искать. А если проще - то не выйдет всё эскейпить, оптому что там натурально не только данные подставляются, но и куски языковой конструкции генерируются. В общем, поверьте, SQL - это настолько истоптанная тема, что абсолютно все подходы были перепробованы сотни если не тысячи раз. И используется то, что даёт оптимальный выхлоп.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	17. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Ordu (ok), 29-Мрт-19, 04:28
	> Это у вас статически построенный запрос. Динамически. Методы типа select, where и прочие вызываются динамически. Никто не мешает вызывать их в цикле. > В общем, поверьте, SQL - это настолько истоптанная тема, что абсолютно все > подходы были перепробованы сотни если не тысячи раз. И используется то, > что даёт оптимальный выхлоп. Я полагаю, что вы совершенно зря сейчас верите в здравомыслие тех, кто пилит язык начиная с 90-х годов. Люди очень часто залипают на каких-то идеях и забывают рассмотреть альтернативные. Вот как сейчас вы отмахиваетесь от идеи, даже не пытаясь выяснить, насколько она реализуема, путаете её с ORM'ом, хотя совершенно очевидно, что здесь даже и не пахнет никакими объектами и что код даже не представляет себе какая там модель у базы данных. Вы не один такой, таких людей большинство. Подавляющее. В частности среди программистов. Но, ладно, допустим, я не прав. Иногда так случается, что я оказываюсь излишне пессимистичен, оценивая способность других принимать и понимать новые идеи. Если это так, значит должны были быть попытки запилить подобное в PHP. Для того, чтобы выяснить, что этот подход не работает для php, надо попытаться его реализовать. Голословные рассуждения типа "это наверное будет сложно" голословны. Единственная проблема, которая на мой взгляд может возникнуть на этом пути -- это проблема производительности. Но чтобы в эту проблему впороться и придти к выводу, что она неустранима в пхп, надо написать, посмотреть как написанное работает под нагрузкой, и попытаться устранить бутылочные горлышки. Если такие попытки были, то они должны были оставить следы на github'е, в блогах, на stackoverflow, reddit'е или ещё где-то. Просто обязаны были, потому что подобная проделанная работа -- это очень неплохое дополнение к CV любого разработчика, которое показывает, что он не просто обезьяна, способная лишь код со stackoverflow копипастить, но он ещё и разрабатывать код самостоятельно могёт, и исследовать этот код на производительность, и устранять проблемы с производительностью, и вообще это сформировавшийся специалист. Вам известны такие попытки? Я вот только что сунулся в гугл, просмотрел штук двадцать результатов, нашёл ~15 библиотек, и это либо конкатенация строк оставленная в качестве упражнения веб-макаке, либо ORM. ORM -- это тоже ничё так метод, но у него есть свои ограничения, и по-хорошему, под него всё равно стоило бы подложить реализацию sql внутри языка. Из чего я делаю вывод, что веб-макаки настолько макаки, что они двадцать лет смотрят на cl-sql, и ни разу не попытались сделать что-то подобное в php. Им бы только сайтики клепать, а системное мышление у них намертво прилипло к идее CMS, и отлипнуть никак не может. Хотя есть альтернативное объяснение: может быть проблема с производительностью настолько очевидна и настолько лежит на поверхности для любого разработчика на PHP, что он видит её заранее, а я не вижу, потому что PHP не знаю в достаточной мере? Ну? Если она лежит на поверхности, то значит её можно описать парой абзацев? Я готов их прочитать, если что.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	23. "Опасные уязвимости в платформе электронной коммерции Magento..."	+/–
	Сообщение от Ordu (ok), 29-Мрт-19, 05:32
	Я нашёл! https://github.com/nilportugues/php-sql-query-builder Действительно я ошибался в отношении тупости php'шников. Простите.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору