Comments 8
Сначала речь про то, что хорошая апишка не потребует каких то мутных nonce, а потом показывают апишку, которая их и требует.
В целом, статья выглядит сложной, тогда как начало статьи было логичным — удобное апи должно быть простым, чтобы шанс накосячить был минимальным. TLDR то есть? Чем пользоваться?
В целом, статья выглядит сложной, тогда как начало статьи было логичным — удобное апи должно быть простым, чтобы шанс накосячить был минимальным. TLDR то есть? Чем пользоваться?
К сожлению, «мопед не мой», поэтому скажу что вижу: суть в том, что «новая» апишка из свежего дотнета тоже мутная, и RSA не стоит пользоваться вообще. TLDR начинается со слов «В таком случае, чем заменить RSA? Я хотел бы познакомить вас с современными эллиптическими криптографическими примитивами.»
А какая апишка имеется ввиду? Libsodium приводится как плохой пример, после чего показывает SuiteB из Inferno, который не требует указывать MAC алгоритм, KDF, размер блока шифрования, режим шифрования, режим выравнивания.
Хорошо, что есть люди, которые не просто выкладывают видео, а делают из него текст. Спасибо.
Последний слайд про AntiCSRF без криптографии какой-то мутный. Если я правильно понял самую идею, то сломать такую AntiCSRF защиту вообще ничего не стоит.
Суть любого Anti CSRF механизма — отправлять уникальный токен или его часть альтернативным способом, например через параметры формы, URL или же в заголовках HTTP. Это по умолчанию предусматривает какие-то дополнительные телодвижения со стороны разработчика. И если все необходимые данные отправляются браузером полностью автоматически, то в такой защите нет никакого смысла, просто потому что тогда она просто не защищает от CSRF атак.
Суть любого Anti CSRF механизма — отправлять уникальный токен или его часть альтернативным способом, например через параметры формы, URL или же в заголовках HTTP. Это по умолчанию предусматривает какие-то дополнительные телодвижения со стороны разработчика. И если все необходимые данные отправляются браузером полностью автоматически, то в такой защите нет никакого смысла, просто потому что тогда она просто не защищает от CSRF атак.
На последнем слайде — типичный double submit cookie. Механизм работы описан в OWASP CSRF Prevention Cheat Sheet, имплементация для .Net с минимумом телодвижений и модификаций HTML описана у автора в «Application Security in .NET, Succinctly», в главе про CSRF (Вторая кука считывается джаваскриптом из засовывается в заголовок или в поле формы автоматически, через ajaxPrefilter/submitHandler, вставлять их руками не надо, защита обеспечивается cross-origin policy браузера — браузер не позволит JS коду с другого домена прочитать куку и модифицировать заголовки запросов. Конечно, эта защита может быть сломана через Subdomain hijacking, MiTM или XSS — только вот в этом случае CSRF то особо и не предотвратить).
Главная мысль — что для данная штука прекрасно работает без какой-либо дополнительной криптографической защиты токенов, хватает чистой энтропии.
Главная мысль — что для данная штука прекрасно работает без какой-либо дополнительной криптографической защиты токенов, хватает чистой энтропии.
Sign up to leave a comment.
Стэн Драпкин. Ловушки высокоуровневой криптографии в .NET