Не "высосана из пальца", а "вторая древнейшая информационная служба Хабра". Вы вот зашли в новость с очевидно нелепым заголовком? И я зашёл. Вы пишете объёмный комментарий про нелепость новости? И я пишу. Очень хорошо! Хайп, просмотры, пользовательский фактор.
А всего-то надо было превратить "добавили одну (одну) физическую кнопку" в "кнопочные гаджеты".
Типичная новость от второй древнейшей службы Хабра, после которой приходится всю информацию искать и проверять самому.
Речь, вроде бы, про хостинг, а на картинке почему-то домены. Плюс рейтинг, использованный в новости, явно показывает чепуху, опять же перемешивая домены и хостинг. Я, например, клиент reg.ru, но ни одного сервера у них не держу.
Я могу понять, когда для девочки контент-менеджера из Форбеса что домен, что хостинг, что роутинг - одинаково непонятные слова. Но здесь-то Хабр, вроде бы. Неужели нельзя было прокрутить те же тарифы руцентра на страницу ниже и взять цены на хостинг, раз статья именно о нём?
Ну или добавить в заголовок домены тоже, поскольку там рост даже ещё более конский.
Плюс не одну картинку, а две: "было - стало". Типа
Хоббихостинг "Сайт 1"
До повышения: 209 р./мес
После: 493 р./мес
VPS SSD-1
До повышения: 890 р./мес
После: 1335 р./мес
Ну, "может" только в теории. Пока планов на изменение правил кастинга нет. А так - да, тяжелое наследие царского режима. Можно настроить статический анализатор, чтобы не пропускал.
Просто идеальный комментарий, но тоже придерусь по мелочи :)
У меня пунктик на формулировках. Меня столько раз понимали неправильно, что выработался рефлекс на обнаружение таких мест.
везде надо валидировать любой входящий запрос
Эту фразу можно так понять, что валидация помогает защититься от взлома. Но в большинстве случаев это не так. Валидация - это хорошо и нужно, но к безопасности она почти никогда не имеет отношения (за исключением граничных случаев, таких как пурификация HTML). Я, собственно, это автору и пытался объяснить выше - что он пытается обезопасить SQL с помощью валидации входящих данных. А делать это не стоит, поскольку распыляет защиту и делает её в принципе ненадёжной. Плюс такой подход прибивает разные слои приложения друг к другу гвоздями: слой для работы с БД надеется, что слой обработки входящих данных сделает их безопасными для SQL. Ну это же полная бессмыслица.
Кроме того, обеспечивающая безопасность валидация зачастую в принципе невозможна (или неоправданно ресурсоёмка). Вот как в данном конкретном случае например. Валидировать SQL дамп с точки зрения безопасной передачи в командную строку - я не уверен, что эта задача в принципе выполнима. И в любом случае обойдётся довольно большой кровью. При этом чтобы экранировать тот же дамп для командной строки - вообще думать не надо, escapeshellarg() - и передавай что хочешь, хоть бинарную строку.
Поэтому валидацию я бы тут делал обычную - тип данных, длина. Но при этом независимо от её наличия всегда корректно экранировал данные при передаче в командную строку.
Я думаю, стоит всё-таки проверять принадлежность заказа владельцу телефона, а не отправлять статус всем подряд. Раз уж примеры такие приближенные к реальности, то почему бы не добавить ещё и такую проверку.
А вот про обновление статусов не очень понятно, зачем оно здесь - вроде бы, к отправке СМС оно не имеет отношения? Наверное, сюда планировалось добавить отправку нового статуса клиенту? И, кстати, в этом варианте было бы интересно почитать про использование очередей.
Также я наверное пропустил, за что отвечает параметр number со значением AlfaName.
А ещё интересно было бы почитать про альтернативные способы коммуникации, например звонок с определенного номера, поскольку СМС обходятся недёшево. И если в примере за гипотетическое получение статуса платит клиент, то в реальной жизни магазин, увы, информирует клиента об изменении статуса за свой счёт.
Во-первых, с чего вы взяли, что я "хочу помогать"? Вы не в Армию Спасения пришли, чтобы вам тут все кидались помогать. Я комментирую статью на Хабре. И если изначально отношение у меня было нейтрально-благожелательное, то вам удалось его сильно испортить. И ладно если бы это было просто невежество (прикрытое фиговым листком "вообще-то я маститый программист на Яве, а это так - левой пяткой нацарапал для нубов"). Но оно усугубляется вашим пофигизмом в отношении замечаний, которые вам делают. Вы даже не даёте себе труда подумать, перед тем как строчить комментарии. И выставляете себя дураком, выдавая элементарные вещи за какие-то сокровенные знания, которые можно не знать.
И начинаете рассказывать, будто "без выбора дб" SQL дамп не выполнится. Или показываете код, который до боли напоминает SQL инъекцию, и заявляете что с ним всё нормально. Вы реально мне сейчас хотите сказать, что mysql_query("SELECT * FROM table WHERE col='$input'"); - это плохо, а exec("command '$input'"); - это ОК? Или про первое вы тоже так и не поняли? И это я виноват что не объяснил с ложечки, почему это позор и профнепригодность?
Тут проблема на самом деле глубже, чем "менять сами обращения к базе". А в кривой архитектуре. У вас SQL торчит в контроллерах. Только вместо нормальных запросов вы туда высунули огрызки, типа "taskid = $id". Это такой очень наивный детский подход, "я в домике!".
Причём даже его можно было сделать нормально, в виде $ctx->taskDataDao->makeLookup('type', 'taskid', $id);. И хотя это всё равно нарушение границ - в контроллере надо знать название таблицы БД, такой код по крайней мере легко сделать безопасным. Но по-хорошему в контроллере длолжен вызываться метод модели/сервиса, который сам знает детали реализации - в какой таблице и по какому полю искать.
В том-то и дело, что вы не понимаете главного. Для вас защита принципиально сводится к латанию дыр. "Ну я сейчас поищу", "ну я заменю регулярку". Для того чтобы отбояриться от зануды на Хабре это может и сойдёт (нет). Но к реальной защите это не имеет никакого отношения.
Защита работает только тогда, когда она применяется системно. Переменные попадают в SQL запрос всегда с защитой. А не в надежде, что где-то другом месте кода кто-то не забудет провалидировать. Данные выводятся в HTML всегда с защитой, а не только там где "я поискал".
Причем такой подход помимо прочего ещё и упрощает код. Из него пропадают растущие там и сям бородавки типа "/[\'\;]/". Валидация - это хорошо и правильно. Но она не должна заменять защиту. Это две совершенно разные области, которые пересекаются только в головах у новичков.
С одной стороны не хочется брюзжать, поскольку дело, в целом, благое, да и пост не про код. С другой - на что ещё смотреть в хабе про РНР, кроме как на код? А он, к сожалению, довольно грустный. Выглядит так, будто писался глубоко в позапрошлом десятилетии.
Объект-бог, который содержит в себе весь код приложения целиком. Но при этом всё равно передаётся через global.
Защита от SQL инъекций фактически отсутствует, и заменяется забором из костылей. Где-то это проверка на числовое значение, где-то кромсание наивной регуляркой типа "/[\'\;]/",(заведомо дырявой причём), где-то проверка через функцию validUrlParam(?!). Я больше чем уверен, что автор и сам путается, где что применять. Про несчастных пользователей я уж и не говорю. И хотя я не нашёл готовую инъекцию, по поговорке "У семи нянек дитя без глазу", она где-то да вылезет. Просто потому что защита не обеспечивается там где должна - в слое для работы с БД.
Защиты от XSS не нашёл вообще, но допускаю что она есть, в каком-нибудь совершенно неожиданном месте.
Валидациия входящих данных в зачаточном состоянии
Зависимость от апача прибита гвоздями.
Вместо исправления динамических пропертей к каждому классу старательно подставлен костыль
Ну и так далее, тут можно долго удивляться.
Я понимаю, что проект разрабатывался давно, и ресурсов на переделку особо нет. Но в таком случае я бы на вашем месте ограничился хабами про вайти образование et al., а код скромно задвинул подальше за шкаф.
Идея конечно интересная, но не очень понятно, почему невозможность получить данные одного субреддита (ну или погоды, если на то пошло) оставляет без распечатки целиком. Я бы всё-таки при возникновении проблем печатал спецсимвол "нишмагла" ¯\_(ツ)_/¯и продолжал выполнение дальше.
Вы совершенно правы - ваши аналогии тут ни к селу ни к городу. А у меня никаких аналогий, а только суровая реальность. Когда родители подсовывают детям планшет, чтобы не ныли, там совсем не Хабр с комментариями.
Слова "дюжий" и "дюжина" не имеют ничего общего. А в данном контексте означают диаметрально противоположные понятия. Несуществующее слово "недюжий" может означать "недужный", "слабосильный", "заурядный". А автор, видимо, имел в виду слово "недюжинный", которое означает "выдающийся", "неординарный". Но не сдюжил.
С одной стороны, статья на интересную тему, и в неё явно вложено немало труда. С другой - такое ощущение, что она написана как бы с акцентом. Вроде бы по-русски, но глаз всё время спотыкается о корявые обороты (типа "узкой задачи"), тавтологии ("эстетический внешний вид"), несогласованные предложения, фактические не точности и кривые ссылки. Все эти огрехи легко мог бы исправить редактор средней руки.
Но против такого пафосного спича мне возразить нечего. Со своим пещерным, я бы сказал - потребительским отношением к ютубочке я тут оказываюсь белой вороной. Разумеется, нормальному человеку без лайков, подписок и комментариев любой видеосервис будет не в радость.
Ну то есть вы согласны с мыслью, что ютуб - это сервис для комментирования, и без возможности оставлять комментарии становится бесполезным. Тут мне возразить нечего. Продолжайте комментировать, сидеть ради этого под своим акком через впн, и надеяться, что пронесёт.
Не "высосана из пальца", а "
вторая древнейшаяинформационная служба Хабра". Вы вот зашли в новость с очевидно нелепым заголовком? И я зашёл. Вы пишете объёмный комментарий про нелепость новости? И я пишу. Очень хорошо! Хайп, просмотры, пользовательский фактор.А всего-то надо было превратить "добавили одну (одну) физическую кнопку" в "кнопочные гаджеты".
Типичная новость от второй древнейшей службы Хабра, после которой приходится всю информацию искать и проверять самому.
Речь, вроде бы, про хостинг, а на картинке почему-то домены. Плюс рейтинг, использованный в новости, явно показывает чепуху, опять же перемешивая домены и хостинг. Я, например, клиент reg.ru, но ни одного сервера у них не держу.
Я могу понять, когда для девочки контент-менеджера из Форбеса что домен, что хостинг, что роутинг - одинаково непонятные слова. Но здесь-то Хабр, вроде бы. Неужели нельзя было прокрутить те же тарифы руцентра на страницу ниже и взять цены на хостинг, раз статья именно о нём?
Ну или добавить в заголовок домены тоже, поскольку там рост даже ещё более конский.
Плюс не одну картинку, а две: "было - стало". Типа
и т.д.
Ну, "может" только в теории. Пока планов на изменение правил кастинга нет. А так - да, тяжелое наследие царского режима. Можно настроить статический анализатор, чтобы не пропускал.
Блин, зачем я стал читать это
Очередное "мы в это не можем и поэтому объявим плохим".
Кейс называется "Продвижение сервисов компании МТС" же :)
Просто идеальный комментарий, но тоже придерусь по мелочи :)
У меня пунктик на формулировках. Меня столько раз понимали неправильно, что выработался рефлекс на обнаружение таких мест.
Эту фразу можно так понять, что валидация помогает защититься от взлома. Но в большинстве случаев это не так. Валидация - это хорошо и нужно, но к безопасности она почти никогда не имеет отношения (за исключением граничных случаев, таких как пурификация HTML). Я, собственно, это автору и пытался объяснить выше - что он пытается обезопасить SQL с помощью валидации входящих данных. А делать это не стоит, поскольку распыляет защиту и делает её в принципе ненадёжной. Плюс такой подход прибивает разные слои приложения друг к другу гвоздями: слой для работы с БД надеется, что слой обработки входящих данных сделает их безопасными для SQL. Ну это же полная бессмыслица.
Кроме того, обеспечивающая безопасность валидация зачастую в принципе невозможна (или неоправданно ресурсоёмка). Вот как в данном конкретном случае например. Валидировать SQL дамп с точки зрения безопасной передачи в командную строку - я не уверен, что эта задача в принципе выполнима. И в любом случае обойдётся довольно большой кровью. При этом чтобы экранировать тот же дамп для командной строки - вообще думать не надо, escapeshellarg() - и передавай что хочешь, хоть бинарную строку.
Поэтому валидацию я бы тут делал обычную - тип данных, длина. Но при этом независимо от её наличия всегда корректно экранировал данные при передаче в командную строку.
Я думаю, стоит всё-таки проверять принадлежность заказа владельцу телефона, а не отправлять статус всем подряд. Раз уж примеры такие приближенные к реальности, то почему бы не добавить ещё и такую проверку.
А вот про обновление статусов не очень понятно, зачем оно здесь - вроде бы, к отправке СМС оно не имеет отношения? Наверное, сюда планировалось добавить отправку нового статуса клиенту? И, кстати, в этом варианте было бы интересно почитать про использование очередей.
Также я наверное пропустил, за что отвечает параметр number со значением AlfaName.
А ещё интересно было бы почитать про альтернативные способы коммуникации, например звонок с определенного номера, поскольку СМС обходятся недёшево. И если в примере за гипотетическое получение статуса платит клиент, то в реальной жизни магазин, увы, информирует клиента об изменении статуса за свой счёт.
Во-первых, с чего вы взяли, что я "хочу помогать"? Вы не в Армию Спасения пришли, чтобы вам тут все кидались помогать. Я комментирую статью на Хабре. И если изначально отношение у меня было нейтрально-благожелательное, то вам удалось его сильно испортить. И ладно если бы это было просто невежество (прикрытое фиговым листком "вообще-то я маститый программист на Яве, а это так - левой пяткой нацарапал для нубов"). Но оно усугубляется вашим пофигизмом в отношении замечаний, которые вам делают. Вы даже не даёте себе труда подумать, перед тем как строчить комментарии. И выставляете себя дураком, выдавая элементарные вещи за какие-то сокровенные знания, которые можно не знать.
И начинаете рассказывать, будто "без выбора дб" SQL дамп не выполнится. Или показываете код, который до боли напоминает SQL инъекцию, и заявляете что с ним всё нормально. Вы реально мне сейчас хотите сказать, что
mysql_query("SELECT * FROM table WHERE col='$input'");- это плохо, аexec("command '$input'");- это ОК? Или про первое вы тоже так и не поняли? И это я виноват что не объяснил с ложечки, почему это позор и профнепригодность?Вы правда, всерьёз думаете, что вот эта дырища позволяет выполнять только SQL команды? И предыдущая дискуссия вас ничему не научила?
Ваше невежество начинает начинает уже немного напрягать.
Тут проблема на самом деле глубже, чем "менять сами обращения к базе". А в кривой архитектуре. У вас SQL торчит в контроллерах. Только вместо нормальных запросов вы туда высунули огрызки, типа
"taskid = $id". Это такой очень наивный детский подход, "я в домике!".Причём даже его можно было сделать нормально, в виде
$ctx->taskDataDao->makeLookup('type', 'taskid', $id);. И хотя это всё равно нарушение границ - в контроллере надо знать название таблицы БД, такой код по крайней мере легко сделать безопасным. Но по-хорошему в контроллере длолжен вызываться метод модели/сервиса, который сам знает детали реализации - в какой таблице и по какому полю искать.В том-то и дело, что вы не понимаете главного. Для вас защита принципиально сводится к латанию дыр. "Ну я сейчас поищу", "ну я заменю регулярку". Для того чтобы отбояриться от зануды на Хабре это может и сойдёт (нет). Но к реальной защите это не имеет никакого отношения.
Защита работает только тогда, когда она применяется системно. Переменные попадают в SQL запрос всегда с защитой. А не в надежде, что где-то другом месте кода кто-то не забудет провалидировать. Данные выводятся в HTML всегда с защитой, а не только там где "я поискал".
Причем такой подход помимо прочего ещё и упрощает код. Из него пропадают растущие там и сям бородавки типа
"/[\'\;]/". Валидация - это хорошо и правильно. Но она не должна заменять защиту. Это две совершенно разные области, которые пересекаются только в головах у новичков.С одной стороны не хочется брюзжать, поскольку дело, в целом, благое, да и пост не про код. С другой - на что ещё смотреть в хабе про РНР, кроме как на код? А он, к сожалению, довольно грустный. Выглядит так, будто писался глубоко в позапрошлом десятилетии.
Объект-бог, который содержит в себе весь код приложения целиком. Но при этом всё равно передаётся через global.
Защита от SQL инъекций фактически отсутствует, и заменяется забором из костылей. Где-то это проверка на числовое значение, где-то кромсание наивной регуляркой типа
"/[\'\;]/",(заведомо дырявой причём), где-то проверка через функциюvalidUrlParam(?!). Я больше чем уверен, что автор и сам путается, где что применять. Про несчастных пользователей я уж и не говорю. И хотя я не нашёл готовую инъекцию, по поговорке "У семи нянек дитя без глазу", она где-то да вылезет. Просто потому что защита не обеспечивается там где должна - в слое для работы с БД.Защиты от XSS не нашёл вообще, но допускаю что она есть, в каком-нибудь совершенно неожиданном месте.
Валидациия входящих данных в зачаточном состоянии
Зависимость от апача прибита гвоздями.
Вместо исправления динамических пропертей к каждому классу старательно подставлен костыль
Ну и так далее, тут можно долго удивляться.
Я понимаю, что проект разрабатывался давно, и ресурсов на переделку особо нет. Но в таком случае я бы на вашем месте ограничился хабами про вайти образование et al., а код скромно задвинул подальше за шкаф.
Идея конечно интересная, но не очень понятно, почему невозможность получить данные одного субреддита (ну или погоды, если на то пошло) оставляет без распечатки целиком. Я бы всё-таки при возникновении проблем печатал спецсимвол "нишмагла"
¯\_(ツ)_/¯и продолжал выполнение дальше.del
Вы совершенно правы - ваши аналогии тут ни к селу ни к городу. А у меня никаких аналогий, а только суровая реальность. Когда родители подсовывают детям планшет, чтобы не ныли, там совсем не Хабр с комментариями.
Слова "дюжий" и "дюжина" не имеют ничего общего. А в данном контексте означают диаметрально противоположные понятия. Несуществующее слово "недюжий" может означать "недужный", "слабосильный", "заурядный". А автор, видимо, имел в виду слово "недюжинный", которое означает "выдающийся", "неординарный". Но не сдюжил.
С одной стороны, статья на интересную тему, и в неё явно вложено немало труда. С другой - такое ощущение, что она написана как бы с акцентом. Вроде бы по-русски, но глаз всё время спотыкается о корявые обороты (типа "узкой задачи"), тавтологии ("эстетический внешний вид"), несогласованные предложения, фактические не точности и кривые ссылки. Все эти огрехи легко мог бы исправить редактор средней руки.
Сорри, протупил сначала.
А вот это уже интересная информация.
Ютуб даёт рекомендации и без регистрации :)
Но против такого пафосного спича мне возразить нечего. Со своим пещерным, я бы сказал - потребительским отношением к ютубочке я тут оказываюсь белой вороной. Разумеется, нормальному человеку без лайков, подписок и комментариев любой видеосервис будет не в радость.
Ну то есть вы согласны с мыслью, что ютуб - это сервис для комментирования, и без возможности оставлять комментарии становится бесполезным. Тут мне возразить нечего. Продолжайте комментировать, сидеть ради этого под своим акком через впн, и надеяться, что пронесёт.