Ответы пользователя по тегу Информационная безопасность
  • Есть ли здесь реальная reflected XSS или это false positive (безопасно ли включать URL запроса в код страницы)?

    На практике в современных браузерах этот вектор в XSS не эксплуатируется из-за URI энкода. Последними популярными браузерами где этот вектор был эксплуатируем были IE 6/7, они не URI-енкодили GET-параметры при редиректе. Однако вставка URI без HTML-енкода в любом случае является ошибкой, даже если не приводит к XSS, например по стандарту должен HTML-енкодиться символ &, который может присутствовать в урлах.
    Ответ написан
    2 комментария
  • Нормально ли, что ip сайта торчит наружу?

    Желательно отфильтровать весь трафик к защищаемому хосту сделав исключение для cloudflare, особенно если высока вероятность DDoS атак. Это есть в рекомендациях Cloudflare. Если этого не сделать, то действительно высока вероятность что IP адрес можно будет обнаружить и атаковать в обход Cloudflare. Например shodan или аналогичные сканеры могут идентифицировать хост по SSL-сертификату или ответу по дефолтному хостнейму, или на сайте может быть функциональность которая делает запрос с сайта наружу (наприме загрузка картинки по URL) с его реального IP в обход Cloudflare.
    Ответ написан
    Комментировать
  • Как проверить надежность доменных паролей?

    Windows хранит NT-хеши паролей, "расшифровать" их в открый текст нельзя, можно только сбрутить. Сравнить их с базой haveibeenpwned не получится, т.к. формат хешей разный. А если вы их сбрутите, то сравнивать не имеет смысла - раз вы смогли сбрутить, значит пароль заведомо плохой, поэтому можете их просто побрутить.

    Смотрите не в сторону дампа паролей, а в сторону механизма passfilt.dll - он позволяет проверять пароль в открытом тексте в момент когда его меняет пользователь, в этот момент вы можете проверить стойкость пароля в т.ч. по базе haveibeenp0wned и по словарям. Напишите свою библиотечку passfilt.dll или поищите готовую, подключите и инициируйте смену пароля пользователям.
    Ответ написан
    Комментировать
  • Сайт с доступом только по https. Плюсы и минусы?

    Текущая общепринятая практика это редирект в https на 80м порту и HSTS на 443м. Использование HSTS приводит к тому, что клиент никогда не будет использовать HTTP с сайтом, даже если явно указать http в URL. Дополнительно, можно отправить домен в список HSTS preload В США практика официально закреплена в документе The HTTPS-Only Standard, обязательном для правительственных агентств, в нем есть отдельное упоминание что:

    Allowing HTTP connections for the sole purpose of redirecting clients to HTTPS connections is acceptable and encouraged. HSTS headers must specify a max-age of at least 1 year.
    .

    т.е. разрешать подключения к 80му порту с целью редиректа не толко допустимо, но и желательно.

    Закрытие 80го порта не обеспечивает более высокой защиты чем редирект + HSTS, т.к. в случае MitM атаки атакующий может перехватить запрос к 80му и подменить ответ независимо от того открыт он или нет на сервере назначения. Т.е. закрытие 80го порта приводит к нежелательным эффектам без какого-либо повышения уровня защищенности.
    Ответ написан
    Комментировать
  • Как обеспечить/установить "доверие" между двумя сервисами?

    Вариантов довольно много, например JWS - каждый сервис выдает пользователю подписанный токен в который "зашита" информация о пользователе в сервисе. Схема может быть, например, такой
    Сервис 1 выдает JWS1 авторизованному пользователю
    Пользователь приходит с JWS1 в сервис 2, сервис 2 видит что пользователь авторизован в Сервис 1 и те данные которые сервис 1 подписал, дополнительного межсервисного взаимодействия при этом не требуется.
    При необходимости межсервисного взаимодействия между сервисами дополнительно делается разделяемый секрет
    Сервис 2 делает межсерверный запрос в Сервис 1 с секретом сервиса и JWS1. Таким образом сервис 2 может делать запросы только по тем пользователям, которые в него пришли
    Ответ написан
    Комментировать
  • Есть ли российские SSL или почему их нету?

    Есть два вида отечественных сертификатов:
    1. Сертификаты с криптографией по ГОСТ (признаются как криптографическая защита) - сертификат выдается одним из аттестованных центров, поддерживается в Яндекс Браузер с установленным CryptoPro, криптография не совместима с международными стандартами.
    2. Сертификаты Национального Удостоверяющего Центра - можно получить через Госуслуги, совместимы с международными стандартами и поддерживаются в любых браузерах, но только в российских браузерах (Яндекс Браузер, Атом) корневой удостоверяющий центр добавлен в доверенный, в остальных придется это сделать вручную.
    Ответ написан
    Комментировать
  • Как будет взломан алгоритм с генерацией бесконечного ключа шифрования?

    Такой подход нарушает принцип Кергофса. Взломать ваш алгоритм можно двумя способами:
    1. Подобрав алгоритм генерации, это можно сделать, например, перебирая функционалы составляющие функцию вашего алгоритма.
    2. В вашем варианте алгоритм к тому же не устойчив к known plaintext атакам. Предположим Алиса передает Бобу сообщение которое известно атакующему - тогда зная это сообщение и проксорив его с "шифрованым" текстом можно получить сгенерированную последовательность и в дальнйшем дешифровать любое сообщение, поэтому в современные алгоритмы обязательно вносится обратная связь и/или какой-нибудь nonce.

    P.S. предположу, что вы пытаетесь переизобрести потоковый шифр
    Ответ написан
    Комментировать
  • Почему CORS не защищает отправку формы?

    CORS не препятствует выполнению запроса, за исключением тех случаев когда требуется preflight (например если вы хотите добавить заголовок запроса между сайтами), CORS не дает читать данные ответа. Этого вполне хватает чтобы защититься в случае немодицирующих запросов, но не хватает чтобы защититься в случае модицифирующих запросов, поэтому CORS сам по себе не заменяет CSRF защиту (но можно делать CSRF защиту основанную на CORS, например проверять наличие кастомного заголовка). Если у вас есть AJAX методы которые что-то меняют на сайте (например что-то удаляют) и вы разрешаете их делать через GET или POST request надеясь только на CORS - у вас уже есть уязвимость. Внешний сайт не сможет прочитать ответ, но выполнить запрос он может. Поэтому обычно дополнительно к CORS требуют кастомный заголовок или делают все модицифирующие методы через PUT (PUT и другие методы отличные от GET/POST кроссайтово могут быть сделаны только с префлайтом). Иногда вообще весь API делают через PUT, чтобы не думать о модицифирующих/немодифицирующих запросах и CSRF атаках.
    Ответ написан
    Комментировать
  • Что может случиться после перехода по вредоносной ссылке?

    Сайт может запустить код на компьютере пользователя, например через уязвимости самих браузеров или DLL planting.

    Сайт может манипулировать другими сайтами через их уязвимости, например если где-то есть XSS уязвимость - он может эту уязвимость эксплуатировать.

    Сайт может маскироваться под легитимный сайт. Он может это делать так, что визуально невозможно найти отличия. Проще научить людей не переходить по ссылкам чем отличать фишинг от не фишинга, надежно распознать фишинг в общем случае невозможно.
    Ответ написан
    Комментировать
  • Безопасно/правильно ли передавать логин и пароль в заголовке по HTTPS протоколу?

    Никогда не городите самопальной криптографии и методов авторизации, если вы не криптограф и не appsec-специалист соответственно, используйте стандартные подходы и проверенные библиотеки. В вашем случае надо использовать HTTP basic-авторизацию и стандартные механизмы которые ее реализуют.
    Ответ написан
    2 комментария
  • Реально ли иметь субдомен от домена без уведомления владельца домена?

    Вы (или атакующий) можете сконфигурировать себе в качестве PTR или указать в запросе к серверу любой домен/поддомен/имя, в т.ч. не существующие.
    Ответ написан
    Комментировать
  • Возможно ли сделать прозрачную MITM атаку (без промежуточного ip)?

    - Прозрачная MitM атака возможна, для этого необходимо чтобы у вас был доступ к одному из маршрутизаторов или каналов на пути прохождения трафика
    - Сам со себе перехват трафика в общем случае не дает вам возможности дешифровать или подменить TLS трафик, для этого необходим доступ к приватному ключу
    - Если вы можете перехватывать трафик рядом с сервером. вы можете выпустить себе сертификат от имени сервера, т.к. процедура выпуска сертификата в публичных CA не защищена от MitM атак. Такая атака может быть обнаружена через Certificate Transparency.

    Поэтому в целом, ответ на ваш вопрос - Да, использование публичных CA без extended validation и/или certificate pinning не устраняет все возможности полностью прозрачных MitM атак в TLS. Но скорей всего, ваше представление о MitM атаках на TLS и их механизмах сейчас не верно.
    Ответ написан
    1 комментарий
  • Как организовать использование одного USB-токена несколькими пользователями?

    Не изобретайте велосипед, выпустите второй токен. Смысл использования токена для подписи - то, что к нему должен быть физический доступ, да и зачем давать менеджерам доступ к токену, с которым можно денежные операции проводить.
    Ответ написан
    Комментировать
  • Переполнение буфера с точки зрения безопасности ИС, внешняя или внутренняя уязвимость?

    Переполнение буфера это класс программных ошибок, который может приводить к уязвимости. Приводит ли он к уязвимости и к какой зависит от того, где именно это переполнение буфера возникает и кем, как и через какой вектор оно может быть проэксплуатировано.
    Ответ написан
    Комментировать
  • Firefox показывает некоторые HTTPS сайты как недоверенные. MITM атака провайдера?

    Скорей всего, у вас нет доверию к сертификатам ISRG Root X1 / ISRG Root X2, обновите системный список корневых сертификатов или вручную установите корневые сертификаты Let's encrypt в корневые доверенные.

    DST Root CA X3 экспайрится в сентябре, поэтому для новых сертификатов его больше не используют.
    Ответ написан
  • Как надёжно зашифровать папку?

    NTFS поддерживает шифрование файлов и можно поставить галочку "шифрованная" на папку, тогда все файлы в этой папке будут шифроваться.
    Но то, какой метод для вас лучший зависит от того, как вы работаете с файлами и папками и от каких атак вы хотите защититься. Если порнуху спрятать от мамы, это одно, если какие-то данные от госструктур которые могут диск изъять - совсем другое, и одним шифрованием папок скорей всего не устраняется.
    Ответ написан
  • О чем хочет сказать Suricata? Безопасники тут?

    Вроде все написано. Эта сигнатура требует поддержки JA3, которая не включена. JA3 must be enabled in the Suricata config file (set ‘app-layer.protocols.tls.ja3-fingerprints’ to ‘yes’).
    Ответ написан
    Комментировать
  • Как узнать формулу, по которой считается время для взлома пароля?

    Вот вам пароль, ломайте: qwerty23457823

    Пароль нельзя сломать, можно сломать либо хеш пароля (восстановив пароль)с, либо шифрование, где пароль используется как ключ либо сервис или оборудование, где пароль используется для аутентификации. В первых двух случаях все зависит от уникальности и энтропии ("случайности") пароля и от криптографического алгоритма, например подбор хеша scrypt, argon2, yescrypt даже по словарю может быть затратным и требовать такой конфигурации оборудования, которую дорого собрать дома и практически невозможно получить в облаке или хостинге. В случае аутентификации все зависит от реализуемых алгоритмов защиты от перебора и credentials stuffing.

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