Comments 51
UFO just landed and posted this here
UFO just landed and posted this here
Что не так?
UFO just landed and posted this here
UFO just landed and posted this here
Любой интерпретатор написан на компилируемом яп, если получится создать такую ситуацию, что где-то при интерпретации происходит переполнение буфера — <цензура типа> всему интернету.
Взять хотя бы это: CVE-2017-5340 или просто посмотреть статистику.
Насчет защищенного сайта вы правы, да. Это довольно хороший яп, но когда речь идет о стратегически важных объектах он неприемлим. А в статье именно говорится о таких вещах как ракеты, ага, давайте на php devel studio их писать. Чет не очень.
Взять хотя бы это: CVE-2017-5340 или просто посмотреть статистику.
Насчет защищенного сайта вы правы, да. Это довольно хороший яп, но когда речь идет о стратегически важных объектах он неприемлим. А в статье именно говорится о таких вещах как ракеты, ага, давайте на php devel studio их писать. Чет не очень.
UFO just landed and posted this here
К счастью, нет.
Но могу вас расстроить — большинство «разработчиков» не учатся даже по таким статьям ( если их так можно назвать ). Аудитория хабра ( мы с вами, например ) как не странно — меньшинство. Сейчас очень большое количество вышло со всяких гикбрейнс, джавараш и т.д. Вот это страшно.
Страшно, когда в мобильных пром. роботах это просто дипломат с ноутом и роутером внутри, с подключенными по COM-порту моторами.
Страшно, когда в автомобиле встроенный компьютер — десктопная ОС в режиме киоска.
Страшно, когда преподы в универе допускают ошибки типа переполнения буфера и целого.
Страшно, когда вообще смотришь на индустрию.
Мне — страшно. Лет через 5 будет вочдогс.
Но могу вас расстроить — большинство «разработчиков» не учатся даже по таким статьям ( если их так можно назвать ). Аудитория хабра ( мы с вами, например ) как не странно — меньшинство. Сейчас очень большое количество вышло со всяких гикбрейнс, джавараш и т.д. Вот это страшно.
Страшно, когда в мобильных пром. роботах это просто дипломат с ноутом и роутером внутри, с подключенными по COM-порту моторами.
Страшно, когда в автомобиле встроенный компьютер — десктопная ОС в режиме киоска.
Страшно, когда преподы в универе допускают ошибки типа переполнения буфера и целого.
Страшно, когда вообще смотришь на индустрию.
Мне — страшно. Лет через 5 будет вочдогс.
UFO just landed and posted this here
просто посмотреть статистику.
Законы ненадёжности Джилба
- Компьютеры ненадежны, но люди еще ненадежнее.
- В происхождении каждой ошибки, в которой винили компьютер, вы найдёте как минимум две человеческих ошибки, одна из которых — обвинение компьютера в ошибке.
- Любая система, зависящая от человеческой надежности, ненадежна.
- Единственная разница между дураком и преступником, атакующим систему, — в том, что дурак атакует непредсказуемо и по широкому фронту.
- Система имеет тенденцию скорее усложняться, нежели упрощаться, до тех пор, пока итоговая ненадёжность не станет неприемлемой.
- Система самопроверки стремится к усложнению пропорционально собственной ненадёжности системы, в которой она используется.
- Способность системы к поиску ошибок и коррекции может служить ключом к пониманию ошибок, которые не могут быть предсказаны.
- Все реальные программы содержат ошибки, пока не доказано иное, что невозможно.
- Число ошибок, которые нельзя обнаружить, бесконечно, в противовес числу ошибок, которые можно обнаружить — второе конечно по определению.
- В поиски повышения надежности будут вкладываться средства до тех пор, пока они не превысят величину убытков от неизбежных ошибок или пока кто-нибудь не потребует, чтобы была сделана хоть какая-то полезная работа.
UFO just landed and posted this here
Пойдите поломайте ВК или фейсбук, раз на то пошло.
Довод так себе… Их, в принципе, регулярно ломают, даже bounty-программы соответствующие есть.
Решето можно написать и на
… А у вас негров линчуют!
Пойдите поломайте ВК или фейсбук
Оба не на PHP.
Ожидал функционального программирования / контрактного программирования, формальной спецификации и верификации программ, детального юнит-тестирования.
По факту — пара советов из начала любой книги о «правильном и красивом» программировании.
По факту — пара советов из начала любой книги о «правильном и красивом» программировании.
Раз уж вы заговорили. Как вы делите ответсвенность между контрактами и юнит тестами?
К сожалению, я не пишу и не писал код с контрактами. Не сложилось.
А как стал бы использовать — контракты на отлавливание пограничных ситуаций вида
1) выбрасывание исключений
2) возврат/не возврат null
3) ограничение области определения закодированной функции до некоторого реального подмножества.
(Пример — не может в вашей модели сепаратор вращаться со скоростью >1кк оборотов в минуту.
Ну и отсеките нереалистичные цифры контрактом)
«u. тесты — верификация того, что ты написал то, что собирался написать, а не то, что получилось»
т.е. обязательно — happy path, ветвления программы, циклы. (дешево)
крайне желательно — таблицу истинности всех логических предикатов (дорого)
параллельное программирование — корректность состояния, действия при тупиках и гонках. (очень дорого)
По последнему пункту — полный отказ от состояния и реактивность бывают очень дороги по производительности/пониманию происходящего.
Состояние конечно зло, и функциональный подход крут, но от некоторых «точек синхронизации» тяжело отвязаться.
Как пример — почтовый ящик процесса в Erlang.
Как ни крути, это область памяти процесса, в которую возможна многопоточная вставка, и либо нужно предоставлять доступ к ней, как к критической секции — одному потоку, либо использовать какие-либо варианты синхронизации.
P.s. это моё мнение, оно явно подлежит дискуссии, но холивары на эту тему мне уже настолько надоели, что вызывают тошноту.
Используйте любой метод доказывания корректности программы, который может сработать автоматически. Чем раньше будет отловлена ошибка — тем лучше.
Если вы не используете никаких методов — начните использовать любой, вызывающий у вас меньше всего неприятных эмоций.
Не надо холиварить, какие тесты лучше — функциональные, юнит или регрессионные, сначала напишите любой, позволяющий доказать корректность и соответствие требованиям.
А как стал бы использовать — контракты на отлавливание пограничных ситуаций вида
1) выбрасывание исключений
2) возврат/не возврат null
3) ограничение области определения закодированной функции до некоторого реального подмножества.
(Пример — не может в вашей модели сепаратор вращаться со скоростью >1кк оборотов в минуту.
Ну и отсеките нереалистичные цифры контрактом)
«u. тесты — верификация того, что ты написал то, что собирался написать, а не то, что получилось»
т.е. обязательно — happy path, ветвления программы, циклы. (дешево)
крайне желательно — таблицу истинности всех логических предикатов (дорого)
параллельное программирование — корректность состояния, действия при тупиках и гонках. (очень дорого)
По последнему пункту — полный отказ от состояния и реактивность бывают очень дороги по производительности/пониманию происходящего.
Состояние конечно зло, и функциональный подход крут, но от некоторых «точек синхронизации» тяжело отвязаться.
Как пример — почтовый ящик процесса в Erlang.
Как ни крути, это область памяти процесса, в которую возможна многопоточная вставка, и либо нужно предоставлять доступ к ней, как к критической секции — одному потоку, либо использовать какие-либо варианты синхронизации.
P.s. это моё мнение, оно явно подлежит дискуссии, но холивары на эту тему мне уже настолько надоели, что вызывают тошноту.
Используйте любой метод доказывания корректности программы, который может сработать автоматически. Чем раньше будет отловлена ошибка — тем лучше.
Если вы не используете никаких методов — начните использовать любой, вызывающий у вас меньше всего неприятных эмоций.
Не надо холиварить, какие тесты лучше — функциональные, юнит или регрессионные, сначала напишите любой, позволяющий доказать корректность и соответствие требованиям.
UFO just landed and posted this here
Забавно, громкое такое название, громкие примеры с ракетами, а дальше код на пхп. Я ничего особого против пхп не имею, но это выглядит как-то смешно.
На мой взгляд, здесь правильней было бы рассказать о стандартах программирования для низкоуровневых языков, на которых и реализованы ответственные системы. Например, какие компании какие стандарты используют, как происходит верификация, тестирование и приемка таких программ. А в данной статье просто стандартные рекомендации для минимизации «выстрела себе в ногу».
«Не изобретайте велосипед» на этом месте защитное программирование кончилось
Дико извиняюсь за дикий оффтоп и возгласы «все пропало». Но доколе это будет? Все больше трешевых материалов приходит на хабр — то описание из pip вынесли в целую статью, то как нужно писать MVC на php сегодня появилось, теперь это. Раньше такого не было. У меня давно пылиться немного материалов для хабра, но никак не решаюсь опубликовать их ибо каждый раз думаю, что это не уровень для хабра, но сейчас вижу, что можно.
Я всегда считал, что defensive programming − это что-то вроде антипаттерна. Типа, как испортить читаемость кода и превратить поддержку в ад, предусматривая каждую исключительную ситуацию или перебирая все коды ошибок.
То, что вы описали — JSDD == Job Safety Driven Development :)
Во многих случаях правильная архитектура системы, надлежащая организация структур данных и дуракоустойчивые интерфейсы и настройки позволяют избежать весьма значимый процент проблем без ущерба читаемости кода и практически с полным отсутствием параноидальных проверок.
defensive programming − это что-то вроде антипаттерна
До первого случая потери денег > твоей зарплаты.
Или до первой человеческой жизни.
Интересненько, как это совместимо:
мы как разработчики должны не доверять коду других разработчиков
можно легко использовать то, что уже сделано
«Не изобретайте велосипед» как-то не вяжется с «Не доверяйте разработчикам».
получить 100% покрытие тестами кода.зачем? coverage это просто цифра, которая ни чего не говорит о качестве тестов. в пределе, 100% покрытие можно легко получить, написав кучу тестов без единого ассерта.
"Не делайте так": написание модуля обработки банковских операций на php.
А если серьезно, то вы правда полагаете, что ракеты взрываются, а рентгены выдают сверхдозы из таких примитивные ошибок? Случаи, конечно, реальные в начале статьи, но ни в одном из них и даже не думало пахнуть плохим юзер импутом и прочими базовыми ошибками — наверняка, там было все куда запущеннее.
В моей практике подобные ошибки (не такие эпические, пока еще никто не умер вроде, но реальный невосполнимый ущерб здоровью людей случался) чаще всего возникали из-за опечаток, которые не всегда заметны на code review. И спасает более формальный подход к написанию ТЗ и по ТЗ — приемочных тестовых сценариев и статический анализ кода. А призывы быть повнимательнее не особо спасают.
Прочитав примеры критических уязвимостей в начале статьи, ожидал программирования, связанного с железом: микроконтроллеры, обработка сигналов, регистры и память, RTOS…
А тут PHP и фреймворки (которые каждый день новые, не успеваешь название выучить)
А тут PHP и фреймворки (которые каждый день новые, не успеваешь название выучить)
У меня все более явное чувство, что статьи все чаще начинают повторяться. Про ариан и рентген уже точно было.
Помимо багов реализации еще бывают, как минимум, криптографические грехи и сетевые грехи, о которых тоже не плохо было бы упомянуть.
По поводу юнит тестов замечание интересное, но недостаточное. Юнит тесты должны быть написаны в контексте безопасности, т.е. тесты которые проверяют, что не аутентифицированному пользователю не досталась роль админа, при ошибке например.
А вообще помимо тестов не плохо практиковать Security Development Lifecycle, в котором, помимо юнит тестов, много чего еще есть.
По поводу юнит тестов замечание интересное, но недостаточное. Юнит тесты должны быть написаны в контексте безопасности, т.е. тесты которые проверяют, что не аутентифицированному пользователю не досталась роль админа, при ошибке например.
А вообще помимо тестов не плохо практиковать Security Development Lifecycle, в котором, помимо юнит тестов, много чего еще есть.
По поводу Message и Mailer пришлось перечитать три раза, прежде чем я въехал. Слава C++ и указателям! :)
Если честно, упоминание php и ракет вызывает когнитивный диссонанс. А тут еще и фреймворки. Как раз если писать ПО для ракеты, широко распространенные фреймворки использовать нельзя ни в коем случае. Тут лучше подходит самопальный «бронированный» велосипед, хотя это и дороже. Но в таких случаях на спичках не экономят.
Если честно, упоминание php и ракет вызывает когнитивный диссонанс. А тут еще и фреймворки. Как раз если писать ПО для ракеты, широко распространенные фреймворки использовать нельзя ни в коем случае. Тут лучше подходит самопальный «бронированный» велосипед, хотя это и дороже. Но в таких случаях на спичках не экономят.
Полёт №501 ракеты «Ариан-5» Европейского космического агентства был прекращён через 40 секунд после старта (4 июня 1996 г.). Экспериментальная ракета-прототип стоимостью 1 млрд. долларов США самоликвидировалась из-за ошибки в бортовом ПО управления.
Не самый удачный пример для этой статьи. В ПО для "Ариан-5" уже были использованы все возможные техники написания корректного кода, включая, разумеется, многократный ручной и автоматизированный code review. Для таких мегапроектов нужно использовать математическую верификацию кода (и железа), причём на всех уровнях (компьютер, как известно, имеет уровни транзисторов, вентилей, архитектуры процессора, ОС, user space машинного кода и кода на высокоуровневом языке программирования), причём так, чтобы математические доказательства правильности разных уровней были связаны между собой. Вот тогда действительно логических ошибок в компьютере удастся избежать (с некоторыми оговорками). Сошлюсь на свой же коммент на Geektimes для тех, кому интересно: https://geektimes.ru/post/282234/#comment_9672390, я ведь такой умняшка :)
Минимум 2/3 проблем решается выбором правильного языка.
Sign up to leave a comment.
Искусство оборонительного программирования