Pull to refresh

Comments 34

UFO just landed and posted this here
А я как раз занимаюсь «этим делом», не имея в этом особых навыков.
А именно: как сделать, чтобы «отравленные» клиенты хотя бы не заглючивали сервер.
Самое страшное это конечно 1, 10 и 24. Особенно если все вместе. Я бы еще добавил undefined behavior, он тоже может привести к дыре в безопасности.
«сексуальность динамически генерированного кода» просто убило
сори, в оригинале и правда так написано…
Вы можете перечислить явные недочеты, которые бросаются в глаза?
Это поможет мне а) учесть на будущее б) улучшить английский.
Перевод нормальный, GJ автор. Заметно немного, что вы переводили так, чтобы не пропустить ни слова из оригинала, я и сам так перевожу, поэтому стараюсь, после того, как перевел, написать пересказ на русском своего же перевода. Оно как-то оживляет, что ли, текст.
«Жестко закодированный пароль» — не звучит.
раз на то пошло — Присутствие паролей в исходном коде
Двадцать пять причин использовать языки со строгой статической типизацией :)
как то c++ это не спасало от buffer overflow+shell code execution и как бе инъекции/CSRF/XSS — лекго появляются и в строго типизированных языках :)
В Си++ нестрогая типизация, а переполнение буфера возникает из-за прямого доступа к памяти (непроверяемая индексация массивов, etc.)
пардон, мой фейл. но таки она статическая. :)
Мне кажется, что статическая типизация языка в данном случае не слишком сильно влияет на возможность допустить ошибку, написав уязвимый код. Такого рода логические недочеты языком навряд ли смогут регулироваться без специальных средств. Так что нужно проверять себя, на каждом участке кода пытаясь узнать — возможно ли возникновение нештатной ситуации и каким образом её можно предотвратить.
> Так что нужно проверять себя, на каждом участке кода пытаясь узнать — возможно ли возникновение нештатной ситуации и каким образом её можно предотвратить.

Пишите чистые, полностью определенные функции и все будет замечательно.
двадцать пять причин не браться за работу, которую не можешь сделать хорошо(читать без ошибок).
Я бы не был настолько критичен. Вы никогда не можете быть уверены, что можете сделать работу без ошибок. Так что если рассуждать подобным образом, ни за какую работу браться нельзя.

Я бы сказал, это 25 причин проверить свою работу на предмет ошибок лишний раз. Как говорится, кто предупрежден, тот вооружен.
Спасибо за информацию. Жаль только, что не описаны основные методы предотвращения таких ошибок. Интересующимся могу предложить пролистать книгу «Защищенный код» из боекомплекта разработчика microsoft. Недавно видел её в Pdf на русском языке, где-то на torrents.ru. Но в этой книге, по большей части, ориентация на Windows и платформу .NET.
Без примеров не очень интересно, тем более, что куча пунктов дублируют друг-друга как, например, под пункт 2 попадают и пункты 3, 4, 5.
а Вы по ссылкам пройдите, там примеров хватает
Думаю, что примеры уже отдельная статья, а здесь просто список :).
Спасибо, все эти правила, конечно, знать нужно и так, но неплохо было все перечитать заново. Спасибо.
Почти ничего не понял.
Такое чувство, что это промт-перевод.
попробуйте перевести назад на английский этим же промтом, а потом самостоятельно перевести на русский :-)
Я это сказал не буквально, просто читать почему-то очень сложно.
Большинство указанных выше проблем можно свести к недостаточной проверке информации полученной от пользователя.
Sign up to leave a comment.

Articles