Безопасное приложение с сервером Api со статическим токеном jwt - PullRequest
Новая
       5

Безопасное приложение с сервером Api со статическим токеном jwt

0 голосов
/ 23 декабря 2018

Это, возможно, спросили, но, возможно, 2018 год есть лучший способ.Я пытаюсь защитить свой сервер api и предоставить доступ только к созданным мной клиентским приложениям. Мобильные / веб-клиентские приложения, использующие vue.js для клиентского приложения и express.js на узле для api-сервера.

Было бы целесообразно создать статический токен с кодом в клиентском приложении. Он будет отправляться при каждом вызове API. Затем на сервере API хранится мой секрет токена. Проверьте токен до того, как вызов API будет отправлен обратно.

Есть ли лучший способ? Кажется, он работает нормально, но, может быть, есть кое-что, чего я не знаю. Может быть, раз и навсегда замените статический токен и секрет? Сеть наверняка будет https.отправка токена при каждом вызове API req.body.clientAppToken

Что вы думаете? Спасибо всем!

Обновите это промежуточное ПО Express API ниже.

Приложение отправляет вручнуюПри каждом запросе на каждый сервер создается токен. Токен одинаков для всех приложений. Я проверяю токен с секретом, хранящимся на сервере. Если он проходит, они получают данные, если онне они не делают. 

const jwt = require('jsonwebtoken')
const config = require('../config/config')

module.exports = {
  authClientAppToken (req, res, next) {
    // start see if client app jwt is correct
    /* eslint-disable */
    console.log('req.body.clientAppToken', req.body.clientAppToken)
    try {
        let decoded = jwt.verify(req.body.clientAppToken, config.jwtAppSecret)
        next()
    } catch (err) {
        res.status(400).send({
            error: 'We got problems'
        })
    }
    /* eslint-enable */
    // end see if client app jwt is correct
  }
}

1 Ответ

0 голосов
/ 02 января 2019

Я пытаюсь защитить свой сервер api и предоставить доступ только к созданным мной клиентским приложениям. Мобильные / веб-клиентские приложения, использующие vue.js для клиентского приложения и express.js на узле для api-сервера.

Жестокая правда в том, что вы не можете по-настоящему защитить веб-приложение, потому что любой вид секрета, будь то токен JWT, токен JWT со знаком, ключ API или все, что вам может понадобитьсяИспользование очень легко восстановить на стороне клиента, просто используя инструменты разработчика браузера, такие как F12.

На мобильных приложениях разработчики могут подумать, что после того, как они выпустят бинарный файл, он сможет спрятать секрет и сохранить его в безопасности.Что ж, мобильные приложения не так просты для просмотра, как использование F12 в браузере, но их достаточно просто перепроектировать с помощью таких инструментов, как Mobile Security Framework , которые будут извлекать весь код в двоичном виде,тем самым раскрывая все секреты, хранящиеся на нем, но даже если секреты вычисляются во время выполнения, этот инструмент способен выполнять интроспекцию во время выполненияn о том, что делает ваше мобильное приложение, таким образом, может извлекать также динамические вычисленные секреты.

Было бы целесообразно создать статический токен-код в клиентском приложении.Это будет отправлено с каждым вызовом API.Тогда на сервере api есть мой секретный токен.Проверьте токен до того, как вызов API будет отправлен обратно.

Таким образом, как уже говорилось ранее, любой секрет, сгенерированный или сохраненный на стороне клиента, может быть извлечен и повторно использован за пределами области, для которой он предназначен.Несмотря на это, я все еще рекомендую использовать их как еще один слой защиты.

Кажется, это работает нормально, но, возможно, есть кое-что, чего я не знаю.

Я бы порекомендовал вам прочитать эту серию статей о методах Mobile Api Security, чтобы понять, как https, закрепление сертификатов, ключи API, токены, HMAC можно использовать для защиты сервера API и как их можно обойти,Хотя статья написана в контексте мобильного API, почти все применимо к API, обслуживающему веб-приложение.

Может быть, каждый раз на время заменяют статический токен и секрет?

Использование кратковременных периодов истечения срока действия на токенах целесообразно и рекомендуется, но они просто сокращают окно, в котором они могут быть использованы повторно, но не предотвращают злоупотребление API.

Сеть будет https наверняка.

Хотя https должен всегда использоваться сам по себе, он гарантирует только то, что передаваемые данные зашифрованы и не могут быть прочитаны третьими лицами, что защищает передаваемые секреты, но не препятствует их обратному проектированию.само приложение.

Есть ли лучший способ?

Для веб-приложений вы можете сделать это сложно, используя javascript obfuscation tool , реализуйте reCaptcha V3 и, если вы хотите продвинуться дальше, используйте программное решение для анализа поведения пользователей на своем сервере API.

Что касается мобильных приложений, то их можно создавать так, чтобы не было необходимости хранить в них секреты, чтобы они передавались при каждом обращении к серверу API.Этот метод называется Mobile App Attestation и состоит из мобильного SDK и облачной службы, которые работают вместе, чтобы гарантировать, что мобильное приложение будет загружено в Google Play или в App Store.Мобильный SDK работает в фоновом режиме и обменивается данными с облачной службой, которая будет выдавать действительный токен JWT, если приложение является исходным и не работает на взломанном или рутованном устройстве или является объектом человека, находящегося в середине атаки.Действительный токен JWT - это тот, который подписан секретом, известным только облачной службе и API-серверу, мобильное приложение не знает его в любой момент, поэтому невозможно выполнить обратный инжиниринг или подделать его.Недопустимый токен JWT отличается от действительного только тем, что подписан секретом, неизвестным серверу API, что делает его неотличимым от действительного.Этот тип решения безопасности можно найти по адресу Approov , и именно здесь я сейчас работаю.

...