Есть ли способ проверить целостность файлов JavaScript на клиенте?

Question

Я работаю над тем, чтобы стать безопасным методом регистрации и аутентификации пользователей, используя php и javascript, но не ssl / tls.

Я понимаю, что это вполне может считаться невыполнимой задачей, которую уже 1000 раз пытались выполнить, но я все равно попробую. Каждый пример, который я вижу в Интернете, который утверждает, что делает это, имеет огромный роковой недостаток!

В любом случае, моя текущая проблема - проверка javascript на клиенте. Проблема в том, что если моя реализация sha1 в javascript изменена каким-то человеком-посредником, это вообще не безопасно. Если бы я мог просто проверить, что полученный javascript не был подделан, то я думаю, что смогу это осуществить.

Реальная проблема заключается в том, что единственный способ сделать что-то на стороне клиента - это JavaScript. Просто: напишите javascript для проверки целостности других файлов javascript. Нету! Человек в середине может просто изменить этот файл.

Есть ли способ обойти это?

Answer 1

Чтобы обезопасить свой JavaScript, вы должны проверить его в гарантированной нетронутой среде. Поскольку вы не можете создать такую ​​среду в браузере, это невозможно. Лучший вариант - скачать JavaScript через HTTPS. Это не безопасно, но лучше. Возможные векторы атаки слева:

• Вирус может модифицировать браузер для загрузки вредоносного JavaScript для каждой страницы
• Кейлоггер может отслеживать, что пользователь печатает
• Прокси-сервер может действовать как посредник для HTTPS-соединения. Прокси фактически декодирует то, что вы отправляете через HTTPS, и снова кодирует его (с другим сертификатом) для браузера.
• Прокси-сервер может добавлять фреймы на отправляемые вами страницы

Answer 2

Matt Я верю (несмотря на скептиков), что то, что вы спрашиваете, не невозможно, просто чрезвычайно сложно. Вы спрашиваете, что код, который полностью доступен для злоупотребления, тем не менее, позволяет пользователю идентифицировать себя на сервере, и наоборот. Одним из возможных способов является использование доказательства с нулевым разглашением, которое не будет передавать информацию подслушивающему (Eve). Например, сервер может предоставить javascript, который рисует представление графика, который объединяет предоставленную пользователем информацию, не имеющую значения для Евы, с информацией, предоставленной сервером, также не имеющей значения. Javascript, возможно, был изменен, но либо не сможет предоставить правильный график (в этот момент пользователь прогуливается), либо преуспеет. В последнем случае пользователь аналогичным образом предоставляет «нулевое знание» свидетельство того, что у него есть изоморфное представление графа; опять же, это или успешно или неудачно. Также посмотрите на протокол SRP, но проблема в том, что это патентное минное поле. См. Практическая криптография Фергюсона и Шнайера. Jo

Answer 3

Вы говорите, что ваша единственная проблема - человек посередине, модифицирующий javascript, который вы используете для выполнения SHA1. Поэтому я предполагаю, что вы используете логин + пароль SHA1 для входа в систему ....

Это совершенно небезопасно даже без вмешательства в Javascript. Даже если человек посередине может не знать простой пароль, если javascript не изменен, он будет знать хеш, и он может прекрасно использовать этот хеш для самостоятельного входа в систему, просто воспроизведя его.

Даже если вы включите соль / одноразовый номер, человек посередине все еще сможет использовать эти токены в данный момент и даже украсть учетную запись, выполнив изменение пароля / электронной почты.

Даже игнорируя это и предполагая, что вы действительно можете обойти все это + на самом деле получить javascript для проверки целостности второго javascript, как бы вы предотвратили подделку этого «сценария проверки»? Вы по-прежнему зависите от сценария, отправляемого по незащищенному каналу, для обеспечения безопасности таких данных (и вы можете рекурсивно продолжать использовать сценарий, проверяющий целостность сценария, проверяющего целостность сценария ...), и все они будут полностью подделаны так как они отправляются по незащищенному каналу.

Единственный способ сделать это - это создать собственный защищенный канал поверх http, для чего потребуются некоторые дополнительные функции на стороне клиента (плагин Firefox / расширение ActiveX), но при этом будет иметь встроенную поддержку https, просто абсурд.

Answer 4

Обойти это невозможно. Как вы сказали: если вы не можете проверить источник, злоумышленник может заменить все, что получает клиент, то есть все, что клиент интерпретирует и выполняет.

Answer 5

Вы можете проверить целостность файлов Javascript на клиенте только в том случае, если сервер и клиент ранее совместно использовали секрет. Чаще всего это не так в Интернете. Если такой секрет недоступен, любая попытка проверить переданный Javascript может быть нарушена. Это уловка 22 ситуация.

Чаще всего люди хотят обеспечить целостность JS, потому что это заставляет их чувствовать, что они могут делегировать проверки безопасности на стороне клиента. В криптографии есть фундаментальное правило, которое не следует нарушать: никогда не доверяйте вводу удаленного пользователя. Всегда перепроверяйте.

SSL / TLS может затруднить атаки среднего уровня, но не является водонепроницаемым.

Answer 6

с помощью JavaScript можно защитить от пассивных сетевых атак (например, прослушивание трафика WiFi), но вы не можете защитить себя от активных сетевых атак, когда злоумышленник может контролировать заголовок ответа HTTP и данные тела.

Если вы не хотите платить за сертификат SSL, вместо этого вы можете создать самозаверяющий сертификат. Однако это предотвратит только пассивные сетевые атаки, но намного проще, чем некоторые хакерские реализации JavaScript, которые вы когда-либо создавали.

По сути, вам нужен подписанный CA сертификат SSL для предотвращения активных сетевых атак (человек посередине).

Answer 7

Если вашей архитектуре безопасности каким-то образом требуются функции для запуска в Javascript, то ваша безопасность имеет недостатки.

Answer 8

, поскольку они находятся в клиенте, вы не можете получить к ним доступ.

Такова природа веб-страниц ...

попробуйте использовать важные вещи на стороне сервера ...