Comments 22
UFO just landed and posted this here
Правда несколько сумбурно. Не отделены безусловные вещи от конкретных приёмов, которые могут быть и дургими. Например можно не использовать исключения вообще, а GetValidPassword описывать как
int GetValidPassword(string &pwd) __attribute__ ((warn_unused_result));
В этом случае проблемы, описанной в CheckLogin быть не может. Имеет такое решение право на существование? Да, несомненно. Лучше ли оно станартного решения? Ну это зависит от библиотек, которые вы используете. Если там всё завязано на исключения (скажем это вообще Java) - ситуация одна, если исключений нет (-fno-exceptions для надёжности) - совсем другая.
int GetValidPassword(string &pwd) __attribute__ ((warn_unused_result));
В этом случае проблемы, описанной в CheckLogin быть не может. Имеет такое решение право на существование? Да, несомненно. Лучше ли оно станартного решения? Ну это зависит от библиотек, которые вы используете. Если там всё завязано на исключения (скажем это вообще Java) - ситуация одна, если исключений нет (-fno-exceptions для надёжности) - совсем другая.
Ага при чем это еще детский лепет:) Почитайте книги по безопасности и узнаете много чего интересного:)
Пост актуален не только для веб-разработки.
> 1. возврат методом кодов ошибок, вместо вызова исключения – это зло
Не совсем согласен с данным утверждением. Вполне возможно использовать возврат кодов ошибок.
Однако при этом необходимо соблюдать следующие требования:
1. Коды должны быть информативными, а не просто pass/fail.
2. Коды должны быть унифицированными в рамках единого проекта.
3. Если коды ошибок wrapp'ятся в коды более высокого уровня, никакая информация об ошибке не должна теряться.
4. Если жизненно необходимо взаимодействие методов обработки ошибок и на базе кодов ошибок, и на основе исключений, то для каждого вызова исключения должна быть функция-обертка, возвращающая код ошибки, и для каждой функции возврата кода ошибки должна быть функция-обертка, вызывающая исключение.
> 1. возврат методом кодов ошибок, вместо вызова исключения – это зло
Не совсем согласен с данным утверждением. Вполне возможно использовать возврат кодов ошибок.
Однако при этом необходимо соблюдать следующие требования:
1. Коды должны быть информативными, а не просто pass/fail.
2. Коды должны быть унифицированными в рамках единого проекта.
3. Если коды ошибок wrapp'ятся в коды более высокого уровня, никакая информация об ошибке не должна теряться.
4. Если жизненно необходимо взаимодействие методов обработки ошибок и на базе кодов ошибок, и на основе исключений, то для каждого вызова исключения должна быть функция-обертка, возвращающая код ошибки, и для каждой функции возврата кода ошибки должна быть функция-обертка, вызывающая исключение.
И сразу рекомендации для использования обработки ошибок на основе исключений:
1. Если используются исключения, они должны использоваться повсеместно.
2. Любая сколько-нибудь нетривиальная сущность должна быть объектом.
3. Если жизненно необходимо взаимодействие методов обработки ошибок и на базе кодов ошибок, и на основе исключений, то см. п.4 предыдущего комментария.
1. Если используются исключения, они должны использоваться повсеместно.
2. Любая сколько-нибудь нетривиальная сущность должна быть объектом.
3. Если жизненно необходимо взаимодействие методов обработки ошибок и на базе кодов ошибок, и на основе исключений, то см. п.4 предыдущего комментария.
UFO just landed and posted this here
1. private-обработчики невозможно использовать в ASP.NET, так как страница является, по сути, динамически создаваемым классом, наследующим от объявленного в codebehind. Соответственно, чтобы из кода страницы можно было вызвать обработчик, необходимо его «видеть». Вот и остается только protected. В WinForms такой проблемы нет, и все обработчики по умолчанию создаются с модификатором private.
2. Согласен
3. Использование explicit cast'а от описанной в статье проблемы не избавит, так как Button ссылочный тип и вполне может быть null. Здесь поможет только проверка входных параметров (раз уж метод protected, ее совершенно точно нужно добавить).
2. Согласен
3. Использование explicit cast'а от описанной в статье проблемы не избавит, так как Button ссылочный тип и вполне может быть null. Здесь поможет только проверка входных параметров (раз уж метод protected, ее совершенно точно нужно добавить).
UFO just landed and posted this here
Связка is и explicit cast два раза проверят соответствие типу. as - только один раз. Для того он и придуман.
1. Если так то да. Я имел ввиду умолчальный .
3. Я использую as, как правило, как раз вместо is + explicit cast (XaocCPS уже написал про это). Это нужно, когда на входе мы имеем некий базовый объект, а работать предстоит со специфическими. Как раз, чтобы не делать преобразование дважды.
3. Я использую as, как правило, как раз вместо is + explicit cast (XaocCPS уже написал про это). Это нужно, когда на входе мы имеем некий базовый объект, а работать предстоит со специфическими. Как раз, чтобы не делать преобразование дважды.
По поводу авторизации лучше вообще использовать подход от обратного. Никогда не стоит выдавать Granted сразу же, сначала Restricted и только в случае успешного прохождения проверки должен быть Granted. А пихать "вставьте свой код сюда, не вызывайте return" - во первых, следующей строкой Вы сами же результат этой функции возвращаете в вызвавший ее код, почему же не заботитесь об эксепшне вне ее? Давайте тогда вообще откажемся от процедур, функций, классов и всего остального? Все свалим в одну кучу и вернем goto =) Не правильный это подход.
Самые главные 3 правила:
1. строить конструкции, которые не предполагают двойственного поведения;
2. запрещено все, что не разрешено (а не наоборот);
3. каждый пользователь (скрипт/метод) - либо полный идиот с синдромом чего-нибудь, либо злостный хакер => нужно фильтровать все входящие данные, даже если это кажется паранойей и в данных обстоятельствах какие-то из них могут "автоматически" отсеяться на будущих этапах (как пример - далее идет insert в mysql данных, не проходящих по типу. Даже если известно, что эта строка не вставится и mysql вернет ошибку. лучше проверить валидность данных до этого запроса, так как в следующей версии mysql или вообще при переходе на другую DB это правило может измениться как из-за человеческих ошибок, так и по каким-то идеологическим).
Самые главные 3 правила:
1. строить конструкции, которые не предполагают двойственного поведения;
2. запрещено все, что не разрешено (а не наоборот);
3. каждый пользователь (скрипт/метод) - либо полный идиот с синдромом чего-нибудь, либо злостный хакер => нужно фильтровать все входящие данные, даже если это кажется паранойей и в данных обстоятельствах какие-то из них могут "автоматически" отсеяться на будущих этапах (как пример - далее идет insert в mysql данных, не проходящих по типу. Даже если известно, что эта строка не вставится и mysql вернет ошибку. лучше проверить валидность данных до этого запроса, так как в следующей версии mysql или вообще при переходе на другую DB это правило может измениться как из-за человеческих ошибок, так и по каким-то идеологическим).
По поводу метода CheckLogin. В первую очередь нельзя оставлять пустые cacth. Оставив пустой catch вы сами провоцируете ситуацию с которой же потом и боретесь.
> Код всегда вызывается «злым» кодом
Чесно говоря - бред. Если в каждом методе проверять параметры то никаких Гигагерц не хватит. Проверка должна производиться только в одном месте.
> код читает содержимое файла, но в некоторый момент не может прочитать блок и завершается, возвращая булево значение либо значение какого-то перечисления;
> необходимо переделать на вызов исключения, отказавшись от возврата какого-либо значения.
Вообще дибилизм. Такое впечатление что вы не в курсе о том, что пишете.
В остальном, в целом, правильно.
Чесно говоря - бред. Если в каждом методе проверять параметры то никаких Гигагерц не хватит. Проверка должна производиться только в одном месте.
> код читает содержимое файла, но в некоторый момент не может прочитать блок и завершается, возвращая булево значение либо значение какого-то перечисления;
> необходимо переделать на вызов исключения, отказавшись от возврата какого-либо значения.
Вообще дибилизм. Такое впечатление что вы не в курсе о том, что пишете.
В остальном, в целом, правильно.
Пост полезный, но полезный для тех кто любит лепить кастыли. Он лишний раз показывает кривость ASP.NET в чистом виде. Костылей можно сразу избежать, если использовать, скажем MVC. Там как раз можно принять, что все методы контроллеров (точнее сказать методы в данном случая имеет значение "actions") вызываються пользователем, и не морочить себе голову. Тем более что уже есть такая вещь как ASP.NET MVC.
было бы интересно послушать в статье о web безопасности о краже cookies или фильтрации и енкодинге инпута пользователя а не про то, как полезно кидать исключения.
Вставлю и свои пять копеек - вместо new EventArgs() есть EventArgs.Empty.
Интересный материал, но я бы сказал, что есть 2 минуса - имхо, безопасный код может означать разное. В статье речь идёт про защитное программирование и хороший код вообще. Во-вторых, почти все выводы я недавно читал в "Совершенном коде" МакКоннелла. Но всё равно автору плюс в карму за старания:)
Действительно позновательно. Спасибо, 
XaocCPS
Особенно заставил задуматься параграф "Все ответы – отрицательные". На памяти подобных ошибко не делал, но и не дооценивал их "злобные" возможности...
XaocCPSОсобенно заставил задуматься параграф "Все ответы – отрицательные". На памяти подобных ошибко не делал, но и не дооценивал их "злобные" возможности...
Sign up to leave a comment.
Несколько мыслей по поводу безопасного кода