Что программисту нужно знать об ИБ и кто этим занимается в продакшене?
Только учусь программированию,и не знаю,стоит ли что-то читать по ИБ.Что программисту вообще нужно знать об этой области?Ну про переполнение кучи и стека знаю,это что касается именно программистской обязанности не допускать подобных ошибок.Тут же может быть тысячи угроз.Какое нибудь приложение работающее с сетью,что-то передающее и принимающее.Тут помимо ошибок локальных,могут быть еще и сетевые и базы данных.Обязан ли программист писать безопасный код?Ведь одни функции в какой нибудь библиотеке могут быть крайне эффективными например,но в то же время с помощью них можно будет провести какую нибудь атаку.А чтобы знать это,нужно быть не плохим безопасником.Или все куда проще?Кто вообще занимается построением архитектуры приложения с точки зрения безопасности?
Просто правильно проверяйте данные на входе и больше ничего не нужно !
Ну и желательно немножко следить на выпущеными експлоитами, что бы понимать откуда дует ветер перемен :)
Возможно для себя вы уже что то решили, тогда стоит немного подучиться !
Обязан ли программист писать безопасный код?
Стоит ли врачам спасать жизни пациентов ? - конечно да ! ! !
Твоя работа будет писать код, никому не нужно набор для сборки стула, всем нужен готовый, надежный стул, или ты любиш хлюпкие, что б никогда не знал когда упадеш?
Приведу примеры ошибок программиста и к чему они привели: https://dev.by/lenta/main/10-samyh-dorogih-oshibok...
Пример еще:
В 1962 году космический корабль "Mariner 1" должен был отправиться к Венере. Однако едва ракета успела оторваться от космодрома на мысе Канаверал, как угрожающе отклонилась от курса. Возникла угроза падения на землю. Инженеры NASA, управлявшие полетом с Земли, активировали систему самоуничтожения ракеты. Позже ревизионная комиссия пришла к выводу: авария возникла из-за того, что в программных инструкциях был пропущен дефис. В результате корабль получал неверные управляющие сигналы. Стоимость ракеты составляла 18 миллионов долларов без учёта инфляции.
Кто вообще занимается построением архитектуры приложения с точки зрения безопасности?
1.Главный программист инженер!
2.Программист!
3.QA тестировщик !
4.Пользователь на бета или альфатестировании!
5.Хакеры если не повезло! (Они тоже вносят лепту в защиту системы, тобиш один раз взломавший вас хакер заставит вас изучить вашу систему и улучшить параметры защиты)
Каждый из пунктов предельно важен!
А ниче что областей программирования мильоны?
А ниче что способов организации работ и видов/размер контор мильоны?
Где-то (крупные банки) - есть отдельные службы.
Где-то - ты все сам.
Где-то вообще забивают на это.
Какая бы область программирования не была, вы обязаны следить за всем что только можете успеть отфильтровать!
А ниче что способов организации работ и видов/размер контор мильоны?
Вообще бесмысленная фраза, не удивительно, вы наверняка до программирования не имеете отношения, любая контора следит за контролем качества и безопасности!
Где-то (крупные банки) - есть отдельные службы.
Где то :D Специальные службы))) Даже не знаете какие ?)))
Где-то - ты все сам.
В 100% случаев сопли тебе никто не станед подтирать на работе, потому ты будеш получать люлей пока сам не начнеш писать безопасный код, ну или тебя нафиг выкинут и бомжуя ты будеш говорить друзьям что ты фрилансер)))
Где-то вообще забивают на это.
Скинеш ссылку на такое место? Помойму оно есть только в школе и Вузах ! Во всех других местах вас будут бить плеткой, жестко бить и заставлять учить ADA )))
Вообще бесмысленная фраза, не удивительно, вы наверняка до программирования не имеете отношения, любая контора следит за контролем качества и безопасности!
Где-то вообще забивают на это.
В 90% - забивают. Нет, специально, конечно, не делают все плохо. Но никаких дополнительных мер не принимают. Заказчиков интересует минимизация цены. И необязательные для того, чтобы уже можно было пользоваться софтом вещи - они и остаются необязательными.
Профиль на Хабре не даст вам соврать.
У вас просто эффект Даннинга
Эффект Даннинга — Крюгера — когнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации (выделение мое, track). Это приводит к возникновению у них завышенных представлений о собственных способностях, в то время как действительно высококвалифицированные люди, наоборот, склонны занижать свои способности и страдать недостаточной уверенностью в своих силах, считая других более компетентными.
Программисту который не является спецом по ИБ не обязательно вообще знать что-то про ИБ.
Разве что для развития собственного кругозора.
Задача программиста - писать код соответствующий стандартам, по ТЗ.
А думать о безопасности будут другие, и когда придумают включат это в ТЗ.
Но тут есть такой момент - программист понятие растяжимое.
Где-то программист пишет код и все.
А в некоторых случаях программист пишет код, разрабатывает архитектуру приложения, прорабатывает вопросы безопасности, чинит компьютеры, заправляет принтеры, и подметает двор..
Тут конечно приходится немного разбираться в ИБ, и знать с какой стороны метлу держать надо.
Большинство угроз, таких как переполнение стека или кучи в современных ЯП выбрасывают исключения. Защиту от DDOS могут взять на себя хостеры или можно юзать готовые решения. Многие виды аттак и уязвимостей, которые можно было осуществить/эксплуатировать 10 лет назад, сегодня не сработают - используйте все самое современное. ИБ на поверхностном уровне необходиомо знать, иначе ваши приложения будут уязвимы для sqli, csrf, xss, ddos атак и прочего, хотя разрешить подобные проблемы безопасности сможет даже школьник.
В продакшене этим - внезапно - занимаются специалисты по ИБ :) Соответственно программисту об ИБ нужно знать ровно столько, сколько написано в корпоративной политике безопасности, если она есть или стольо сколько может рассказать местный спец по ИБ (если отдельного нет - то обычно админ). Если нет ни того, ни другого ни третьего - ну тогда значит всем просто по...й.
Почитай про написание безопасного кода. Для каждого языка есть свои стандарты (пример для С++).
Также рекомендую почитать про распространенные слабости безопасности в приложениях (Common Weakness Enumeration, CWE).
Ну и напоследок ознакомься с жизненным циклом разработки безопасных программ (Secure Software Development LifeCycle, SSDLC): Рекомендации в области стандартизации банка России РС БР ИББС-2.6-2014, MS SDL, OWASP Secure SDLC Cheat Sheet.
Средний
Простой
Средний
Простой
Простой
