введение
Некоторое время назад компания провела проверку безопасности работающей системы с помощью инструмента AppScan, предоставленного IBM.
Как говорится, не беда, что не просканируешь, а когда просканируешь, то в шоке, и в результате такая проблема выметается.
Одна из наших старых и неисправных внутренних систем была просканирована на наличие потенциальных угроз безопасности при входе в систему.Я не могу вспомнить точное научное название.Грубо, когда мы отправляли запрос на вход, имя поля было паролем, который AppScan посчитал это. небезопасно, вероятно, следующим образом:
Моей первой реакцией было изменить название этого поля.Ведь его легко решить, если его можно решить легко.Конечно, результат - пощечина.
Независимо от того, поменяю ли я имя на aaa или bbb, при повторном сканировании будет сообщено об одной и той же проблеме.Единственное отличие состоит в том, что имена полей в отчете о безопасности изменены.
Вот это интересно.Эта проблема в том,что пришедший не годится.После того как я его обыскал(не спрашивайте как я это проверял,я просто догадался)я нашел причину.
Поскольку наша система является внутренней системой, человек, который вошел в систему в то время, был ленив, поэтому он просто сделал отправку формы на странице, например:
Когда-то я писал этот код на большом задании в колледже, не ожидал, что увижу такой код через много лет, и это вызывало у меня особое чувство от встречи с односельчанами.
Конкретная причина этой проблемы заключается в том, что AppScan напрямую определяет поле ввода type='password' на странице, а затем проверяет, есть ли соответствующее поле в запросе. Не спрашивайте меня, откуда я это знаю, потому что у меня есть изменил его на type='text', не сообщит об ошибке, единственный недостаток в том, что поле пароля на странице будет четко отображать пароль.
Хотя я могу использовать js для динамической замены значения в поле ввода на все, что захочу, например точки, звездочки и некоторые другие стили, это всегда немного неэтично.
Проблема обнаружена, так как ее исправить?
Вот контент, который я хочу поговорить сегодня, как обеспечить безопасность интерфейса API?
Прежде всего, мы разделим эту проблему на две части: клиентскую и серверную.
Сервер
Поскольку я сам занимаюсь серверной разработкой, конечно, эту проблему нужно обсуждать со стороны сервера.
Лично меры безопасности в основном отражаются в двух аспектах: во-первых, как обеспечить безопасность данных во время передачи, а во-вторых, как идентифицировать данные после того, как данные достигли сервера, чтобы гарантировать, что они не будут атакованы.
Давайте обсудим один за другим:
1. Идентификация происхождения в HTTP-запросах
Идентификация источника в HTTP-запросах — это то, как сервер распознает, что текущий запрос инициирован его собственным клиентом, а не запросом, смоделированным третьей стороной.
Давайте сначала посмотрим, что будет в заголовке следующего нормального HTTP-запроса:
Я открыл домашнюю страницу Baidu, взял случайный запрос из сети и проверил заголовок запроса. Поля, о которых я хочу рассказать, обведены красными рамками:
- Происхождение: используется для указания того, с какого сайта исходит текущий запрос.
- Referer: используется для указания, с какой страницы связан текущий запрос.
- User-Agent: некоторая информация, используемая для идентификации текущего запрашивающего браузера или системы. Обычно мы проверяем имя домена в белом списке Origin и Referer в заголовке HTTP-запроса, сначала определяем, отправлен ли запрос из нашего собственного домена, а затем проверяем User-Agent, чтобы убедиться, что текущий запрос отправлен браузером, а не каким-то разным эмулятором.
В настоящее время, поскольку передний конец полностью ненадежный, вышеуказанные поля могут быть подделаны и смоделированы (я определенно написал его в предыдущей статье на скаколе), но мы можем сделать как можно больше подтверждения, мы не можем закрыть все лазейки сразу, но, по крайней мере, некоторые из них.
2. Шифрование данных
Данные легко перехватываются при передаче, при прямой передаче, например, по протоколу http, данные, передаваемые пользователем, могут быть получены кем угодно, поэтому данные должны быть зашифрованы.
Распространенной практикой является шифрование ключевых полей, таких как пароли пользователей, непосредственно через шифрование md5, сейчас основной практикой является использование протокола https и добавление уровня шифрования (SSL-уровня) между http и tcp, который отвечает за шифрование и расшифровку данных.
3. Подпись данных
Добавление подписи означает, что когда мы отправляем HTTP-запрос, мы добавляем строку, которую невозможно подделать, чтобы гарантировать, что данные не будут подделаны во время передачи.
Наиболее часто используемый алгоритм подписи данных — алгоритм MD5.Этот алгоритм каким-то образом объединяет данные, которые должны быть отправлены, в строку, а затем генерирует подпись с помощью алгоритма MD5.
Я использую предыдущий интерфейс входа в качестве простого примера:
srt：name={参数1}&password={参数2}&$key={用户密钥} MD5.encrypt(str)
Ключ здесь — это ключ, который хранится у клиента и сервера.Данные json, которые будут отправлены окончательным запросом на вход, будут следующими:
{ "name": "test", "password": "123", "sign": "098f6bcd4621d373cade4e832627b4f6"}
Ключ не участвует в отправке данных.В противном случае после перехвата запроса третья сторона может сгенерировать подпись через ключ.Конечно, если вы чувствуете, что чистый MD5 недостаточно безопасен, вы также можете добавить соль и хэш в MD5 для дальнейшего снижения Существует риск олицетворения после перехвата запроса.
4. Отметка времени
Механизм временных меток в основном используется для борьбы с незаконными DDOS-атаками.После того, как наш запрос зашифрован и подписан, его трудно обратно взломать.Однако некоторые злоумышленники не заботятся о конкретных данных после захвата пакета, а напрямую атакуют захваченными пакетами. это пресловутая DDOS-атака.
В параметр можно добавить временную метку текущего запроса.После получения запроса сервер будет сравнивать текущее время со временем в запросе.Например, в течение 5 минут оно уйдет на последующую бизнес-обработку.Ошибка код возвращается сразу после 5 минут.
Здесь следует отметить, что время клиента и время сервера в принципе невозможно согласовать, а передача запроса в провинции требует времени, поэтому порог ограничения времени не может быть установлен слишком маленьким, чтобы предотвратить законные запросы.
Я по-прежнему беру в качестве примера приведенный выше логин.На данный момент данные нашего запроса будут выглядеть так:
{ "name": "test", "password": "123", "timestamp": 1590334946000, "sign": "098f6bcd4621d373cade4e832627b4f6" }
5. AppID
Во многих случаях наш интерфейс API может вызываться не только одним клиентом, но и вызывающими абонентами может быть много.Чтобы проверить законного вызывающего пользователя, наш сервер может добавить AppID.
Если вы хотите вызвать наш интерфейс API, вы должны подать заявку на AppID в автономном режиме, как и я. Только после того, как этот AppID будет активирован, я смогу легально получить доступ к своему интерфейсу. При доступе к интерфейсу этот AppID необходимо добавить в параметры запроса. представлены вместе с другими данными.
На данный момент входящие параметры нашего интерфейса входа в систему, приведенные выше, стали следующими:
{ "appid": "geekdigging", "name": "test", "password": "123", "timestamp": 1590334946, "sign": "098f6bcd4621d373cade4e832627b4f6" }
6. Параметр общего шифрования
Мы выполнили ряд обработок по параметрам запроса выше.Общая идея состоит в том, чтобы предотвратить перехват и взлом пакетов третьими лицами, но если я не третье лицо, например, я перехватываю пакеты в сети браузер. В этом запросе я вижу данные четко и ясно. Злоумышленник может получить к ним доступ сначала по формальным каналам. Проанализировав нашу рутину, мы можем подделать запрос и начать атаку. В настоящее время наши предыдущие усилия, кажется, в напрасно. .
Не говорите что никто этого делать не будет, приведу пример, платный веб клиент, интерфейс входа в клад, если вы сможете разобраться в правилах, по которым отправляется запрос, злоумышленник может использовать купленную пользователем базу данных, библиотечный тест пакет попал по запросу результат ответа может проверить пакет пароля учетной записи Alipay (конечно, не так просто Ха, мой сын просто пример).
Затем мы можем зашифровать запрос в целом.Теперь основные методы шифрования включают симметричное шифрование и асимметричное шифрование.
Симметричное шифрование: Симметричные ключи используют один и тот же ключ в процессе шифрования и дешифрования.Распространенные алгоритмы симметричного шифрования включают DES, AES, RC4, Rabbit, TripleDes и т. д. Преимущество в том, что скорость вычислений высокая. Недостаток в том, что перед передачей данных отправитель и получатель должны согласовать секретный ключ, после чего обе стороны могут сохранить секретный ключ. утечка, зашифрованная информация не будет в безопасности.
Асимметричное шифрование: сервер генерирует пару ключей, закрытый ключ хранится на сервере, а открытый ключ может быть передан любому. Преимущество заключается в том, что оно более безопасно, чем симметричное шифрование, но скорость шифрования и дешифрования намного ниже, чем у симметричного шифрования. Широко используется алгоритм RSA.
Делаем шифрование DES на данных, которые мы предоставили выше, ключ 123456, можем получить такой результат:
U2FsdGVkX18D+FiHsounFbttTFV8EToywxEHZcAEPkQpfwJqaMC5ssOZvf3JJQdB/b6M/zSJdAwNg6Jr8NGUGuaSyJrJx7G4KXlGBaIXIbkTn2RT2GL4NPrd8oPJDCMky0yktsIWxVQP2hHbIckweEAdzRlcHvDn/0qa7zr0e1NfqY5IDDxWlSUKdwIbVC0o mIaD/dpTBm0=
Затем мы помещаем эту строку в запрос, чтобы сделать запрос, и наш запрос на вход только что станет таким:
Я считаю, что таким образом более 99% злоумышленников сдадутся, когда увидят в сети такой запрос на захват пакета, но оставшийся 1% будет открывать инструменты разработчика, предоставляемые Chrome, для отладки построчно. , О том, как с ними бороться, мы поговорим в разделе клиента ниже.
7. Ограничение тока
Много раз в некоторых сценариях с высокой степенью параллелизма, основанных на защите бизнес-системы, нам необходимо ограничить скорость доступа к запросам, чтобы предотвратить слишком высокую скорость доступа и взрыв бизнес-системы.
Особенно для некоторых внешних интерфейсов, интерфейсов, используемых клиентами или поставщиками, потому что мы не можем контролировать вызывающую сторону, Бог знает, как будет написан код другой стороны.
Я видел, как поставщики использовали предоставленный нами интерфейс для изменения данных в качестве пакетного интерфейса для запуска пакетов, и они могут запускать и останавливать эту службу каждую ночь.Позже, пока мы не спросили, поставщик сказал, что они будут использовать этот интерфейс каждую ночь. Выполняя синхронизацию десятков миллионов данных, я тоже пьян.
С точки зрения безопасности очень нужно ограничивать ток на стороне сервера.
Существует несколько распространенных алгоритмов ограничения тока на стороне сервера: ограничение тока корзины маркеров, ограничение тока дырявой корзины и ограничение тока счетчика.
-
Текущий лимит корзины токенов: принцип работы алгоритма ведра токенов заключается в том, что система с определенной скоростью кладет токены в ведро, и сбрасывает токен, когда оно заполняется; при поступлении запроса токен извлекается из ведра первым, а если токен может быть извлечен, завершение может быть продолжено.Запросить, в противном случае подождать или отказать в обслуживании;сегмент токенов допускает определенную степень всплеска трафика, пока есть токены, он может быть обработан, и несколько токенов поддерживаются одновременно .
-
Ограничение тока дырявого ведра: принцип алгоритма дырявого ведра заключается в том, чтобы отправлять запросы с фиксированной постоянной скоростью, а скорость входящих запросов произвольна. Когда количество запросов превышает емкость ведра, новые запросы будут ждать или откажутся обслуживаться; он может видно, что алгоритм дырявого ведра может принудительно ограничить скорость передачи данных.
-
Ограничение противотока: Счетчик — это относительно простой и грубый алгоритм, который в основном используется для ограничения общего количества параллелизма, такого как пул соединений с базой данных, пул потоков и количество всплесков; текущее ограничение счетчика, пока общее количество запросов превышает установленное значение. установить порог в течение определенного периода времени Ограничение тока.
Что касается реализации, Guava предоставляет класс инструментов RateLimiter, основанный на алгоритме корзины маркеров, и учащиеся, которым он нужен, могут помочь сами себе.
8. Черный список
Механизм черного списка уже является чем-то вроде концепции управления рисками, и мы можем определить незаконные операции.
Например, запишите частоту обращений каждого AppID.Если в течение 30 минут 5 и более разогнанных обращений и количество обращений превышает 10 раз, то этот AppID может быть занесен в черный список, через 24 часа или Звонящий может получить это AppID только при обращении в автономном режиме.
Другим примером является запись количества доступов по тайм-ауту AppID. Обычно доступ по тайм-ауту не происходит часто. Если в течение определенного периода времени происходит большое количество доступов по тайм-ауту, должна быть проблема с этим AppID, и он также может быть сначала занесите в черный список.Это круто и круто.
Черный список на самом деле больше применяется на уровне бизнеса, Например, вы могли столкнуться с контролем рисков Ping Daddy, который напрямую бросает учетную запись в черный список и запрещает этой учетной записи размещать заказы на определенные субсидируемые продукты.
клиент
В сегодняшнюю эпоху Интернета веб-страницы и приложения стали основными носителями информации.
Среди них APP может быть усилен некоторыми технологиями армирования, чтобы предотвратить растрескивание других от грубой силы.
Веб-страница сложнее, динамика веб-страницы дополняется JavaScript, логика реализуется JavaScript, а JavaScript имеет следующие характеристики:
Код JavaScript выполняется на стороне клиента, что означает, что он должен быть загружен и запущен на стороне браузера пользователя. Код JavaScript открыт и прозрачен, что означает, что браузер может напрямую получить исходный код работающего JavaScript. Основываясь на этих двух моментах, код JavaScript небезопасен, и любой может прочитать, проанализировать, украсть и изменить код JavaScript.
Поэтому, если JavaScript не выполняет какую-либо обработку, независимо от того, насколько изощренная схема шифрования и дешифрования используется, после того, как кто-то найдет логику, ее симуляция или копирование станет неизбежным.
Существует несколько распространенных схем защиты внешнего интерфейса JavaScript: сжатие, обфускация и шифрование.
1. Сжатие
Сжатие кода заключается в удалении ненужных пробелов, новых строк и т. д. в коде JavaScript, обработке и совместном использовании некоторых возможных общих кодов и, наконец, сжатии результатов вывода в одну или несколько строк содержимого, при этом читабельность кода становится очень плохой. время, это также может улучшить скорость загрузки веб-сайта, например:
Это js-клип, который я случайно нашел на странице Baidu.
Если код сжат с точки зрения удаления пустых строк и пробелов, защиты почти нет, потому что этот метод сжатия только снижает непосредственную читабельность кода.
Мы можем отформатировать код через различные инструменты, включая сам браузер Chrome предоставляет эту функцию.
В настоящее время основные интерфейсные технологии будут использовать Webpack для упаковки.Webpack будет компилировать и сжимать исходный код и выводить несколько упакованных файлов JavaScript.Среди них мы видим, что имя выходного файла JavaScript содержит несколько неправильных строк, а файл Содержимое может состоять всего из нескольких строк, а имена переменных — простые буквы.
Это включает в себя технологию сжатия JavaScript.Например, некоторые общедоступные библиотеки выводятся в виде файлов пакетов, а некоторая логика вызовов сжимается и экранируется в несколько строк кода, все из которых относятся к сжатию JavaScript. Кроме того, он также включает некоторые очень простые методы запутывания JavaScript, такие как замена имен переменных и имен методов некоторыми простыми символами для уменьшения читабельности кода.
В целом, сжатие JavaScript может играть защитную роль лишь в незначительной степени, и чтобы действительно улучшить эффект защиты, необходимо использовать технологию обфускации и шифрования JavaScript.
2. Путаница
Обфускация JavaScript полностью реализована в JavaScript. Ее цель — затруднить чтение и анализ JavaScript, что значительно снижает читаемость кода. Это очень практичная схема защиты JavaScript.
Существует примерно два типа обфускаторов JavaScript:
Обфускатор, реализуемый обычной заменой. Первый вид обфускатора, реализованный заменой синтаксического дерева, имеет низкую стоимость реализации, но эффект также является общим, что подходит для сценариев с низкими требованиями к запутыванию. Стоимость второй реализации выше, но она более гибкая, безопасная и больше подходит для враждебных сценариев.
Обфускатор реализован заменой синтаксического дерева, реализация этого метода обфускации немного сложна, и я не буду ее здесь обсуждать.
Что касается способа изменения синтаксического дерева для запутывания, то есть одна компания, которая лучше справляется со своей задачей и предоставляет коммерческие услуги, — это jscrambler.
Короче говоря, все вышеперечисленные решения являются реализациями обфускации JavaScript, которые могут в разной степени защитить код JavaScript.
В общих сценариях нам достаточно первого метода обфускации. Сейчас основной реализацией обфускации JavaScript является библиотека javascript-obfuscator. С ее помощью мы можем легко обфускировать страницы. В сочетании с Webpack мы можем, наконец, сжать вывод. И обфусцированный код JavaScript значительно снижает читабельность и его трудно обратить вспять.
3. Шифрование
В отличие от технологии обфускации JavaScript, можно сказать, что технология шифрования JavaScript является дальнейшим обновлением защиты технологии обфускации JavaScript.Основная идея состоит в том, чтобы написать некоторую основную логику на таких языках, как C/C++, а затем вызывать и выполнять ее через JavaScript, чтобы играть на двоичном уровне защитный эффект.
Его методы шифрования теперь включают Emscripten и WebAssembly, среди которых последний становится все более и более популярным.
Заинтересованные студенты могут узнать об этом самостоятельно.
резюме
Столько всего было введено выше, только для того, чтобы наша программа работала более безопасно и стабильно, а также для уменьшения потерь (сверхурочных) из-за атак.
Много контента взято из информационной системы после Du Niang, я надеюсь, что вы сможете эффективно использовать инструмент поисковой системы.