Comments 34
UFO just landed and posted this here
А я как раз занимаюсь «этим делом», не имея в этом особых навыков.
А именно: как сделать, чтобы «отравленные» клиенты хотя бы не заглючивали сервер.
А именно: как сделать, чтобы «отравленные» клиенты хотя бы не заглючивали сервер.
Самое страшное это конечно 1, 10 и 24. Особенно если все вместе. Я бы еще добавил undefined behavior, он тоже может привести к дыре в безопасности.
В 20 опечатка: СамопальнаЯ.
Статья — супер, перевод — уж простите…
«сексуальность динамически генерированного кода» просто убило
Прощаю =)
Но я старался.
Но я старался.
Вы можете перечислить явные недочеты, которые бросаются в глаза?
Это поможет мне а) учесть на будущее б) улучшить английский.
Это поможет мне а) учесть на будущее б) улучшить английский.
Перевод нормальный, GJ автор. Заметно немного, что вы переводили так, чтобы не пропустить ни слова из оригинала, я и сам так перевожу, поэтому стараюсь, после того, как перевел, написать пересказ на русском своего же перевода. Оно как-то оживляет, что ли, текст.
«Жестко закодированный пароль» — не звучит.
раз на то пошло — Присутствие паролей в исходном коде
раз на то пошло — Присутствие паролей в исходном коде
спасибо за перевод отличной статьи :)
Двадцать пять причин использовать языки со строгой статической типизацией :)
как то c++ это не спасало от buffer overflow+shell code execution и как бе инъекции/CSRF/XSS — лекго появляются и в строго типизированных языках :)
Мне кажется, что статическая типизация языка в данном случае не слишком сильно влияет на возможность допустить ошибку, написав уязвимый код. Такого рода логические недочеты языком навряд ли смогут регулироваться без специальных средств. Так что нужно проверять себя, на каждом участке кода пытаясь узнать — возможно ли возникновение нештатной ситуации и каким образом её можно предотвратить.
двадцать пять причин не браться за работу, которую не можешь сделать хорошо(читать без ошибок).
Я бы не был настолько критичен. Вы никогда не можете быть уверены, что можете сделать работу без ошибок. Так что если рассуждать подобным образом, ни за какую работу браться нельзя.
Я бы сказал, это 25 причин проверить свою работу на предмет ошибок лишний раз. Как говорится, кто предупрежден, тот вооружен.
Я бы сказал, это 25 причин проверить свою работу на предмет ошибок лишний раз. Как говорится, кто предупрежден, тот вооружен.
Причем тут это?
Спасибо за информацию. Жаль только, что не описаны основные методы предотвращения таких ошибок. Интересующимся могу предложить пролистать книгу «Защищенный код» из боекомплекта разработчика microsoft. Недавно видел её в Pdf на русском языке, где-то на torrents.ru. Но в этой книге, по большей части, ориентация на Windows и платформу .NET.
Без примеров не очень интересно, тем более, что куча пунктов дублируют друг-друга как, например, под пункт 2 попадают и пункты 3, 4, 5.
Думаю, что примеры уже отдельная статья, а здесь просто список :).
Спасибо, все эти правила, конечно, знать нужно и так, но неплохо было все перечитать заново. Спасибо.
Спасибо, все эти правила, конечно, знать нужно и так, но неплохо было все перечитать заново. Спасибо.
А где остальные 75?!
Почти ничего не понял.
Такое чувство, что это промт-перевод.
Такое чувство, что это промт-перевод.
никакого разнообразия. tot_ra.habrahabr.ru/blog/49163/ — было на главной тоже.
Большинство указанных выше проблем можно свести к недостаточной проверке информации полученной от пользователя.
Теперь и анализтор PVS-Studio начинает смотреть в сторону CWE. PVS-Studio: поиск дефектов безопасности.
Sign up to leave a comment.
25 самых опасных ошибок в программировании