Надежность обработки исключений поврежденного состояния

В настоящее время я изучаю функции надежности и обработки исключений C # / .NET

Это, в частности, атрибут HandleProcessCorruptedStateExceptions и CER s с PrepareConstrainedRegions.

Теперь я читал справочный исходный код класса SecureString, так как это место, где очень важно сохранять данные в зашифрованном виде даже в исключительных ситуациях, и нашел такие места, как это:

[HandleProcessCorruptedStateExceptions]
//...

    RuntimeHelpers.PrepareConstrainedRegions();
    try
    {
        Unprotect();
        // ...
    }
    catch(Exception)
    {
        Protect();
        throw;
    }
    finally
    {
        Protect();
        // ...
    }

В чем причина блокировки catch? Разве блока finally недостаточно для повторной защиты данных?

Или эти исключения поврежденного состояния могут повлиять только на catch, а затем завершить работу приложения?


.net c# reliability try-catch-finally
person ordag    schedule 23.01.2012    source источник
comment
Без блока finally, если не генерируется исключение, Protect() никогда не вызывается. (Если он не вызывается в конце блока try, но вы пропустили строку.)   -  person millimoose    schedule 23.01.2012
comment
Верно, но как насчет catch, вот в чем вопрос.   -  person George Duckett    schedule 23.01.2012
comment
В случае исключения, я полагаю, что Protect на самом деле вызывается дважды (поймать и наконец) - интересно, имеет ли это какое-то значение ...   -  person Blorgbeard    schedule 24.01.2012
comment
@Blorgbeard Эти множественные Protect не делают ничего особенного. (Второй ничего не делает, потому что знает, что он уже находится в защищенном состоянии)   -  person ordag    schedule 24.01.2012
comment
это ответ stackoverflow.com/a/62843347/1704458   -  person T.S.    schedule 11.07.2020

Ответы (2)


arrow_upward
1
arrow_downward

Дублирование кода в блоке catch необходимо из-за нарушения безопасности в функции фильтрации исключений (не предоставляется C #, но Visual Basic и другие предлагают это). Это позволяет злоумышленнику выполнить свой код в вашем блоке try-catch-finally после того, как исключение будет обнаружено и до того, как блок finally будет выполнен.

Угроза выглядит так: пользователь Visual Basic вашей библиотеки вызывает исключение после Unprotect () (даже OutOfMemoryException из-за нехватки памяти), CLR не находит блока catch, затем CLR выполняет код фильтра исключений пользователя, этот код крадет данные Unprotect (). , и только тогда CLR выполняет Protect () в блоке finally.

Итак, поместите код очистки безопасности в блоки catch и finally, обычная очистка останется только в конце.

person anvish    schedule 05.09.2013

arrow_upward
0
arrow_downward

Finally блоки вызываются почти всегда, за исключением нескольких случаев. Видеть

ВСЕГДА ли блокирует C #, наконец,? для большего.

Так что да, защита всегда вызывается в Finally.

person msarchet    schedule 23.01.2012
comment
Значит, в предложении о перехвате нет необходимости? - person ordag; 23.01.2012