SQL inject

[ArtemPitov]

Доброго времени суток господа!

 

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

не ужели все так хорошо или может где-то есть лазейки ? 

 

Давайте же немного по холиварим на тему безопасности ОП

[chukcha]

Ну.. почему же

 

Если не сделать $this->db->escape, или (int) то возможны варианты

[markimax]

Доброго времени суток господа!

 

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

не ужели все так хорошо или может где-то есть лазейки ? 

 

Давайте же немного по холиварим на тему безопасности ОП

Да с безопасностью у opencart всё в порядке

Единая точка входа (правда видел пару модулей перлов со своей точкой входа, за такое по рукам надо давать), все "проверки" присутствуют. Вероятность закосячить минимальная.

[ArtemPitov]

это понятно, но для тут нужно быть совсем криворуким

[ArtemPitov]

Да с безопасностью у opencart всё в порядке

Единая точка входа (правда видел пару модулей перлов со своей точкой входа, за такое по рукам надо давать), все "проверки" присутствуют. Вероятность закосячить минимальная.

это какие модули если не секрет ?

 

Да, и зачем делать дополнительные точки входе, глупо же  

[vasilev86]

подпишусь

[chukcha]

это какие модули если не секрет ?

 

Да, и зачем делать дополнительные точки входе, глупо же  

Ну.. не совсем глупо.. Если нужен, например "быстрый" обрезанный функционал

 

А пример.. Популярная всплывающая корзина.

[ArtemPitov]

Ну.. не совсем глупо.. Если нужен, например "быстрый" обрезанный функционал

 

А пример.. Популярная всплывающая корзина.

да, это я видел 

Но иногда эти не совсем нужные "рюшечки" могут выйти боком 

[markimax]

да, это я видел 

Но иногда эти не совсем нужные "рюшечки" могут выйти боком 

Обычно и выходят

Стандарты нельзя нарушать

[Dotrox]

Да, и зачем делать дополнительные точки входе, глупо же  

 

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

 

А на счёт уязвимостей: первое, что приходит в голову - полное отсутствие защиты от CSRF на стороне витрины (в админке - токены).

[chukcha]

так и с кроном нужно быть уккарутным
Нормально если кронн запукать с wget
И проверять секруити код

[Dotrox]

так и с кроном нужно быть уккарутным

Нормально если кронн запукать с wget

И проверять секруити код

Я делаю похожим образом, но без wget, а ключ читаю из $argv.

 

Можно, кстати, ещё проверять, что php_sapi_name() содержит cli, но там есть нюансы с точным названием в разных окружениях.

[chukcha]

ну.. как вариант..,

 

но по сути,  $argv. нужно распихивать в  массив $_POST $_GET

 

Но.. нужно подключать полноценно весь стартап

 

 

в 2.2. это стало немного проще и логичней

 

наличие - "клиента"

[Dotrox]

но по сути,  $argv. нужно распихивать в  массив $_POST $_GET

 

Зачем? Если там только ключ для защиты от внешних запросов, то его можно сразу проверить и всё.

[ArtemPitov]

А на счёт уязвимостей: первое, что приходит в голову - полное отсутствие защиты от CSRF на стороне витрины (в админке - токены).

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

Можно что то свое написать с токенами солю и прочим ....

[chukcha]

Зачем? Если там только ключ для защиты от внешних запросов, то его можно сразу проверить и всё.

а если тебе понадобятся другие модели?

Или как ты получишь массив конфига - сам его будешь ансериализовать?

[snastik]

так и с кроном нужно быть уккарутным

Нормально если кронн запукать с wget

И проверять секруити код

 

Это не нормально запускать крон через WGET

 

Погуглите cli opencart, не смешите людей.

Не нужно никаких проверочных кодов, достаточно запретить доступ к скрипту из мира.

Запланированные задачи cli как правило не нужны для того чтобы они делались по расписанию через фронтенд - это можно эмулировать без проблем запуском ajax вызова на контроллер и проверкой пришло ли время его запускать или нет.

 

Cli скритпы необходимы для длительных операций, которые находятся за рамками time limit 30. К сожалению многие писатели модулей в корне не понимают что такое отказоустойчивая безопасная система и как один писатель обработчика CSV не буду тыкать пальцем, требуют тайм лимит 200. я бы расстреливал за такое.

[snastik]

Что касается ответа на вопрос топик стартера - предлагаю немножко покурить вот тут.

Я залип сам часа на четыре когда первый раз увидел.

[Dotrox]

а если тебе понадобятся другие модели?

Или как ты получишь массив конфига - сам его будешь ансериализовать?

 

Видимо, мы о разном говорим. Я имел ввиду, что в $argv только ключ, который сразу проверяется и всё. А остальной код уже по потребностям и в том числе может и не сильно отличаться от обычного входного скрипта, если есть необходимость.

 

 

Запланированные задачи cli как правило не нужны для того чтобы они делались по расписанию через фронтенд - это можно эмулировать без проблем запуском ajax вызова на контроллер и проверкой пришло ли время его запускать или нет.

 

Ну да, например, отправка почтовой рассылки - как раз пример работы через фронтенд. Когда в базе всего сотня покупателей - всё отлично, но когда их там тысячи - это превращается в полнейший маразм.

 

Ну, и вообще, смысл крон задач как раз в том, чтоб они делались без какого-либо человеческого участия и фронтенд тут никак не клеится.

 

 

 

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

Можно что то свое написать с токенами солю и прочим ....

Так в том и суть, что это магазин. В любом нормальном фреймворке это из коробки, а тут магазин и 10 лет движку, но до сих пор этого нет.

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

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

[snastik]

 

Видимо, мы о разном говорим. Я имел ввиду, что в $argv только ключ, который сразу проверяется и всё. А остальной код уже по потребностям и в том числе может и не сильно отличаться от обычного входного скрипта, если есть необходимость.

 

 

 

Ну да, например, отправка почтовой рассылки - как раз пример работы через фронтенд. Когда в базе всего сотня покупателей - всё отлично, но когда их там тысячи - это превращается в полнейший маразм.

 

Ну, и вообще, смысл крон задач как раз в том, чтоб они делались без какого-либо человеческого участия и фронтенд тут никак не клеится.

 

 

 

Так в том и суть, что это магазин. В любом нормальном фреймворке это из коробки, а тут магазин и 10 лет движку, но до сих пор этого нет.

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

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

 

Не готов с вами вступать в дискуссии, так как у вас такое количество HOW TO вопросов присутствует, что складывается ощущение что в гугле забанили!

[Dotrox]

Не готов с вами вступать в дискуссии, так как у вас такое количество HOW TO вопросов присутствует, что складывается ощущение что в гугле забанили!

 

Сколько пафоса :)

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

 

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