Кодер ошибается один раз, программист постоянно. (о безопасности скриптов)

Как Вы быстро поделили всех (как же их вместе назвать?) на кодеров и программистов. Сами придумали? А то могу еще подкинуть - на заре АСУнизации были разные специалисты: постановщики, алгоритмисты, кодировщики... Это сейчас в целях экономии такое разделение упразднили. Выиграли или проиграли... Вообще к чему вся эта философия?

Rassmus, вообще от задачи зависит.

В некоторых проектах без постановщика, аналитика, десятка внедренцев и т.п. не обойтись..

а еще бывают инженеры по интерфейсам.

Правда справедливости ради надо упомянуть, что Дуров от такой парадигмы ушел, и не так много потерял. Соизмеримо с тем что приобрел :) Но там кодеров нет как класса.

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

Вторая цель - банально поделиться частыми ошибками в коде. Молодежи на заметку так сказать.

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

Так лучше оформите в статью, где распишите где возникают уязвимости, и как их устранять при получении через POST и GET данных. Потому что написать что вот есть XSS каждый может.

Fearful, полностью согласен.

Алгоритмист... ммм, как много... в этом звуке... а ведь действительно. Его задача, грубо, оччччень грубо, блок схема, затем. вступали в силу другие структуры, не поверите... СБ..., сейчас, грубо, очччень грубо - тестеры... потом кодеры, но тогда и таких слоВей не было - техники.

И... опять тестеры, но... с подачи ПОСТАНОВЩИКА задач...

зы... в сторону... эх молодеЖь :)

Статья ни о чём.

Если говорить коротко: Программисты, задумывайтесь о безопасности в проектах.

Я поместил всю статью в 4 слова.

Вообще то для таких вещей есть тестировщики, задача которых находить подобные косяки.

А когда программист и проектировщик и дизайнер интерфейса и верстальщик и саппорт - имел он эти уязвимости с большой колокольни. Пока ты будешь продумывать безопасное и в то же время функциональное редактирование темплейтов из админки - конкуренты выпустят и будут вовсю продавать продукт.

Фигня все это, все знают что надо делать безопасно. Но не все готовы тратить на это дополнительное время и финансы. Особенно с учетом того, что в админке редактируют как правило доверенные пользователи, поэтому ждать от них эксплойтов не очень логично.

Так и не понял топик ))))

Это не грешение - это в большинстве своём стандарт, ибо зачастую использование шаблонизаторов просто не оправдано (особенно смешит аргумент, что это позволит облегчить изучаемость дизайнером :) ).

В большинстве современных фреймворков, которые мне попадались - View идут как чистый пхп, а уже как второстепенное - есть возможность прикрутить смарти и т.д.

Статей на тему уязвимостей много. Но читают их мало. :)

Ну еще надо добавить "вебмастера, заказывайте кодинг у кодера, а программирование у программиста" это еще девять слов :)

Ну а если серьезно, то сокращенный вариант не для людей, а для роботов.

Совсем недавно отписал человеку (кодеру), что у него XSS. Он сказал, что это ерунда.

Еще слышал от одного разработчика, что увод его куков это мелочи.

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

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

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

Вот собственно об этом и статья :)

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

Так и не понял комментарий :)

Зачастую, но не всегда. И принимая такое решение, нужно четко отдавать себе отчет о преимуществах и недостатках такого выбора. Можно даже банально не давать доступ к редактированию шаблонов из админки. Разные есть варианты. Но реально это как правило не делают. Ну и шаблоны такие тоже надо как-бы проверять после модификации. Тоже никто не делает обычно. А вдруг дизайнер сверставший тебе дизайн за "отзыв" туда вирус внедрил? Или тупо $_GET использовал? Да мало ли чего он там начудить мог....

Вообще поколупав с десяток чужих скриптов я пришел к трем выводам:

1 - Ой, а ведь это и у меня есть...

2 - Надо таки доводить свой движок до публичного релиза. Задолбался исправлять чужие ошибки.

3 - Стоит поделиться мыслями об этом в популярной форме.

Есть ещё быдлокодеры. Это я так, подбросить говнеца на вентилятор :) Они такие же как быдлофотографы, быдлодиджеи и прочие модные хипстеры.