Безопасность и файлы JavaScript, содержащие логику сайта
Теперь, когда библиотеки JavaScript как jQuery более популярны чем когда-либо, .js файлы начинают содержать все больше логики сайта. Как и где это вытягивает данные/информацию из, как та информация обрабатывается и т.д. Это - не обязательно плохая вещь, но я задаюсь вопросом к тому, что расширяется, это могло бы быть проблемой безопасности.
Конечно, реальная обработка данных все еще происходит в бэкенде с помощью PHP или некоторого другого языка, и это является ключевым, что Вы удостоверяетесь, что ничего нежелательного не происходит в той точке. Но только путем рассмотрения .js сайта (который полагается в большой степени на, например, jQuery), он скажет человеку, возможно, больше, чем Вы, как разработчик, хотели бы. Тем более, что каждый браузер в наше время идет с довольно обширной средой веб-разработчика или дополнением. Даже для новичка, управляющего DOM, больше не является настолько большим из соглашения. И после того как Вы выясняете то, что код там, и как Вы смогли влиять на него путем редактирования DOM, 'забава' запускается.
Таким образом, мои основные проблемы:
Я не хочу, чтобы все смогли посмотреть на .js файл и видеть точно (или скорее: для значительной части), как мой сайт, веб-приложение или работы CMS — что там, что это делает, как это делает это и т.д.
Я волнуюсь, что путем 'обнародования' этой информации, люди, которые намного более умны, чем, я - фигура способ управлять DOM для влияния на функции JavaScript, они теперь знают, что использование сайта, возможно обходя бэкенд проверяет, что я реализовал (и таким образом неправильно предположение, что они были достаточно хороши).
Я уже использую различные .js файлы для различных частей, например, веб-приложения. Но всегда существует материал, который должен быть глобально доступным, и иногда это содержит больше, чем я хотел бы быть общедоступным. И так как это - все "там", кто должен сказать, что они не могут найти те другие файлы так или иначе.
Я иногда вижу огромный зажим JavaScript без разрывов строки и всего это. Как компактные файлы jQuery. Я уверен, что существуют приложения или приемы для преобразования нормального .js файла в одну длинную строку. Но если это может сделать это, не это столь же легкий повернуться спиной к чему-то более читаемому (создание его бессмысленный за исключением оставления свободного места)?
Наконец я думал о том, было ли возможно обнаружить, если запрос на .js файл прибывает из самого сайта (включением сценария в HTML) вместо прямой загрузки. Возможно, путем блокирования последнего использования, например, ModRewrite Apache, возможно использовать .js файл в HTML, но когда кто-то пытается получить доступ к нему, это заблокировано.
Каковы Ваши мысли об этом? Я слишком остро реагирую? Я должен разделить свой JS как можно больше или просто провести больше времени, трижды проверяющего (бэкенд) сценарии и включая большее количество проверок для предотвращения выполнения вреда? Или есть ли некоторые лучшие практики для ограничения воздействия JavaScripts и всей информации, которую они содержат?
5 ответов
Существует свободное ПО, которое выполняет Обфускацию JavaScript . Хотя нет безопасности, хотя и неясности. Это не предотвращает все атаки на систему. Это делает его более сложным, но не невозможным для других людей, чтобы сорвать ваш JavaScript и использовать его.
Существует также проблема доверия со стороны клиента. Имея много логики на стороне клиента, клиент получает возможность выбирать, что он хочет выполнить. Например, если вы избегаете кавычек в JavaScript для защиты от SQL Injection. Хакер собирается написать код-эксплойт, чтобы построить свой собственный HTTP-запрос в обход бегущих процедур вообще.
Данные и FireBug обычно используются хакерами для более глубокого понимания веб- Приложения.
Только код JavaScript CAN имеет уязвимости. Хорошим примером является XSS на базе DOM . Хотя я признаю, что это не очень распространенный тип XSS.
-121--4859419-Если он также будет выводиться в stderr, вы захотите замолчать это. Вы можете сделать это, перенаправив дескриптор файла 2:
# Send stdout to out.log, stderr to err.log
myprogram > out.log 2> err.log
# Send both stdout and stderr to out.log
myprogram &> out.log # New bash syntax
myprogram > out.log 2>&1 # Older sh syntax
# Log output, hide errors.
myprogram > out.log 2> /dev/null
Ничто в вашем JavaScript не должно представлять угрозу безопасности, если вы правилен набор ситуацию. При попытке доступа к конечной точке AJAX, найденной в файле JavaScript, необходимо проверить разрешения пользователя и не выполнить их, если у него нет нужных разрешений.
Просмотр вашего JavaScript представляет собой угрозу безопасности только в том случае, если вы делаете что-то нарушенное, как, например, звонки на что-то вроде /ajax/secret _ endpoint _, что _ требует _ no _ authentication.php , и в этом случае ваша проблема не является небезопасной JavaScript, это небезопасный код.
Иногда я вижу огромный чак JavaScript без разрывов линий и все такое. Как компактные файлы jQuery. Я уверен, что есть приложения или хитрости, чтобы преобразовать ваш обычный JS-файл в одну длинную последовательность. Но если он может это сделать, не так ли просто вернуть его к чему-то более читаемому (делая его бессмысленным, за исключением экономии места)?
Это, как правило, минификация (для уменьшения использования полосы пропускания), а не обфускация. Он легко обратимый. Есть методы обфускации, которые сделают все переменные и функции имена что-то бесполезное, как «aa», «bb» и т.д., но они обратимы с достаточным усилием.
Наконец, я думал о том, можно ли обнаружить, если запрос на файл .js поступает с самого сайта (путем включения сценария в HTML), вместо прямой загрузки. Возможно, блокируя последний с помощью, например, Apache's ModRewrite, можно использовать файл .js в HTML, но когда кто-то пытается получить к нему доступ, он блокируется.
Это возможно сделать, но это легко обойти любой наполовину компетентный злоумышленник. Итог: ничего, что вы отправляете непривилегированному браузеру пользователя, никогда не должно быть конфиденциальными данными.
Конечно, вам следует уделять больше времени проверке внутренних скриптов. Вы должны подойти к проблеме безопасности так, как если бы злоумышленник - один из ключевых разработчиков вашего сайта, кто-то, кто точно знает, как все работает. Каждый URL-адрес на вашем сайте, который что-то делает с вашей базой данных, должен быть защищен, чтобы гарантировать, что каждый параметр находится в допустимых ограничениях: пользователь может изменять только свои собственные данные, может вносить изменения только в пределах допустимых диапазонов, может изменять только вещи в состояние, позволяющее вносить изменения и т. д. и т. д. и т. д. Ничто из этого не имеет никакого отношения к тому, как выглядит ваш Javascript, или к тому, может ли кто-нибудь его прочитать, а jQuery не имеет никакого отношения к проблеме (если вы не сделали это все не так).
Помните: HTTP-запрос к вашему сайту может исходить откуда угодно и быть инициирован любым программным обеспечением во вселенной. У вас нет контроля над этим, и вы ничего не делаете, чтобы наложить ограничения на то, какие клиенты могут загружать, какие страницы будут иметь какое-либо влияние на это.Не беспокойтесь о проверках "REFERER", потому что значения могут быть подделаны. Не полагайтесь на процедуры очистки данных в Javascript, потому что их можно обойти.
Что ж, вы правы, что думаете об этом. Это нетривиальная и часто неправильно понимаемая область разработки веб-приложений.
На мой взгляд, ответ таков: да, это может создать больше проблем с безопасностью просто потому, что (как вы указываете) векторы атаки увеличиваются. По сути, небольшие изменения по сравнению с традиционным (не JS) веб-приложением и те же самые лучшие практики и подходы будут вам очень полезны. Например, наблюдение за SQL-инъекциями, переполнением буфера, разделением ответа и т. Д. У вас просто есть больше мест, где вам нужно следить за этим.
Что касается самих скриптов, проблемы, связанные с междоменной безопасностью, вероятно, являются наиболее распространенными. Изучите и узнайте, как избежать, в частности, XSS-атак, а также CSRF-атак.
Обфускация JavaScript обычно не выполняется из соображений безопасности, и вы правы в том, что ее довольно легко перепроектировать. Люди делают это частично для защиты интеллектуальной собственности, но в основном для уменьшения веса загружаемого кода.
Я бы порекомендовал книгу Кристофера Уэллса, опубликованную О'Рейли, под названием «Защита приложений Ajax».
Существует свободное программное обеспечение, которое делает Обфускацию JavaScript. Хотя нет никакой безопасности через неясность. Это не предотвращает все атаки на вашу систему. Это делает более трудным, но не невозможным для других людей содрать ваш JavaScript и использовать его.
Существует также проблема доверия на стороне клиента. При наличии большого количества логики на стороне клиента клиент получает право выбора того, что он хочет выполнить. Например, если вы экранируете кавычки в JavaScript для защиты от SQL Injection. Хакер напишет код эксплойта для создания собственного HTTP-запроса в обход процедур экранирования.
TamperData и FireBug обычно используются хакерами для более глубокого понимания веб-приложения.
JavaScript-код сам по себе МОЖЕТ иметь уязвимости. Хорошим примером является DOM Based XSS. Хотя я признаю, что это не очень распространенный тип XSS.