Основные приемы предотвращения временных атак

Я не очень знаком с вопросами безопасности, но столкнулся с этой функцией постоянного времени для предотвращения атак по времени:

// shortcutting on type is necessary for correctness
if (!Buffer.isBuffer(a) || !Buffer.isBuffer(b)) {
  return false;
}

// buffer sizes should be well-known information, so despite this
// shortcutting, it doesn't leak any information about the *contents* of the
// buffers.
if (a.length !== b.length) {
  return false;
}

var c = 0;
for (var i = 0; i < a.length; i++) {
  /*jshint bitwise:false */
  c |= a[i] ^ b[i]; // XOR
}
return c === 0;

https://github.com/salesforce/buffer-equal-constant-time/blob/master/index.js

Хотите знать, есть ли стандартные вещи, на которые стоит обратить внимание, и методы, подобные приведенным выше, для их решения при рассмотрении времени атаки. Что-то вроде шпаргалки OWASP XSS. Спасибо!

2 ответа

Одна из самых важных вещей, которую вы можете сделать для защиты от временных атак, - это использовать надлежащие криптографические библиотеки и предоставляемые ими вспомогательные функции (например, если вы используете библиотеку bcrypt.js, используйте предоставляемую ею функцию сравнения, а не делать свои собственные сравнения строк). Каждый раз, когда вы пытаетесь реализовать свою собственную криптографию, она, вероятно, будет уязвима к атакам таймингов.

Подобные атаки могут быть очень сложными, хотя (как правило) существуют очень небольшие различия во времени, например, для сравнения строк, которые будет сложнее обнаружить по Интернету (хотя вы можете обойти это с большими выборками),

Атаки, которые легче использовать, часто связаны с внешним видом вашего кода. Например, функция сброса пароля может потребоваться отправить электронное письмо (которое может быть медленным), если имя пользователя является действительным, и может просто немедленно вернуться, если это не так. Здесь могут помочь асинхронные внешние вызовы (и, вероятно, они лучше для пользователя).

Большинство временных атак основаны на том, что злоумышленник может выполнять большое количество запросов по сценарию и анализировать время отклика, поэтому все, что вы можете сделать, чтобы сделать это сложнее (например, ограничение скорости или CAPTCHA), также обеспечит вам определенную степень защиты., Это не обязательно решит их, но это усложнит их выполнение.

Реально, если вы не делаете что-то связанное с криптографией, вероятно, есть более серьезные угрозы, о которых стоит беспокоиться.

Хотя ваша реализация должна быть безопасной по времени (рядом с утечкой правильной длины, однако это может быть неуместным в зависимости от контекста), все еще существует ловушка: оптимизация.

Это может произойти во время компиляции (т.е. C/++/#) или в случае java просто во время или во время выполнения через JVM. К сожалению, оптимизация может (повторно) ввести побочные каналы синхронизации — поэтому я настоятельно рекомендую вам полагаться на проверенные криптографические библиотеки/функции, такие как hash_equals для PHP или MessageDigest.isEqual для Java (после Java SE 6 U17).

Вообще говоря, не только сравнение строк может привести к тайминговым атакам. Многие другие операции могут привести к различиям во времени отклика/выполнения.

Если вас интересуют дополнительные примеры атак по времени и возможные способы их смягчения, обратитесь к:https://zgheb.com/i?v=blog&amp;amp;pl=81#05.11.2021_-_When_timing_matters .

Примечание: я являюсь автором указанного блога.

Другие вопросы по тегам