Atualmente estou enfrentando um problema ao criar um iFrame para meu ChatBot.
A situação é a seguinte. O usuário A deseja incorporar meu ChatBot em seu site www.websiteUserA.com . O usuário A é reconhecido pelo meu backend quando acessa myapp.com e faz login com segurança usando o Google Auth.
O problema agora é que os clientes do Usuário A, que estão acessando www.websiteUserA.com , também precisam ser identificados como clientes do Usuário A. Para isso, pensei em introduzir um jwt, que eu pudesse usar as declarações de configuração que Posteriormente posso verificar e validar ao fazer uma solicitação.
O problema agora é que se eu expor o Token de qualquer forma para o frontend. Qualquer um, um "Hacker", seria então capaz de se identificar como "Cliente do Usuário A" e poderia, teoricamente, usar o ChatBot em seu próprio site, enquanto o Usuário A seria responsabilizado por todo o uso.
Infelizmente, isso não é possível em nenhuma circunstância, para permitir uma representação tão fácil.
Para resolver isso, pensei em introduzir domínios permitidos que o usuário A possa definir. Portanto, www.websiteUserA.com deve ser o único domínio com permissão para me enviar este token jwt. Infelizmente, as referências de solicitação podem ser facilmente falsificadas.
Outra solução era talvez se comunicar apenas com o back-end do usuário A. O usuário A receberia uma chave de API minha, responsável por gerenciar e reemitir esses tokens JWT. Isso garantiria que o token nunca chegaria ao frontend. No entanto, a configuração pode ser bastante intuitiva devido às diferentes arquiteturas que podem ser usadas para hospedar e gerenciar www.websiteUserA.com , sem falar no aumento da carga no servidor back-end do usuário A para tratar todas essas solicitações.
Também pensei em uma última solução. Que consiste em incluir o token jwt nas sessões do flask (eu uso o flask para meu webAPP). A sessão Flask é protegida com estes parâmetros:
app = Flask(__name__)
csrf = CSRFProtect(app)
app.config['SECRET_KEY'] = SECRET_KEY
app.config['PERMANENT_SESSION_LIFETIME'] = timedelta(minutes=30)
app.config['SESSION_COOKIE_SECURE'] = True
app.config['SESSION_COOKIE_HTTPONLY'] = True
app.config['SESSION_COOKIE_SAMESITE'] = 'None'
O objetivo é tornar um pouco “mais difícil” a extração do token jwt. Não deveria ser impossível, mas esses parâmetros ajudariam a proteger o token contra ataques de JavaScript e XSS.
Você pode por favor me ajudar? Não sei como devo proteger meu aplicativo, pois qualquer que seja a abordagem escolhida, ainda me encontro vulnerável. Alguém pode me recomendar uma abordagem melhor? Como as grandes empresas de tecnologia fazem isso? Imagino que o Google, o Facebook ou qualquer outra grande empresa descobriria isso facilmente.
Eu só quero fornecer um serviço o mais seguro e protegido possível: D.
Não existe 100%. Por exemplo, se o seu usuário estiver navegando em um café e sair para ir ao banheiro, um invasor poderá se passar por esse usuário. Portanto, não existe defesa perfeita e precisamos de encarar qualquer solução que possamos propor com cautela.
A primeira coisa a fazer é HTTPS . Dessa forma, suas solicitações usam criptografia por questão de segurança. Portanto, se JWT for um parâmetro POST ou um token de portador em HTTPS, você terá uma quantia de segurança.
A seguir, em vez de enviar JWT a cada solicitação, você poderia torná-lo um token único, ou seja, você teria uma lista negra de JWTs que ainda não expiraram, mas já foram usados. Dessa forma, se o seu usuário autenticar usando um JWT que era válido no momento, então em virtude de usar esse JWT, o JWT se tornará inválido e, se um invasor conseguir roubá-lo, ele não será mais útil.
Claro, você terá um ID de sessão real em vez de JWT que servirá como identificador de sessão e o JWT será usado apenas para autenticação.
Essa abordagem tornaria muito difícil para um invasor roubar o JWT e nenhuma recompensa para ele se ele conseguisse fazê-lo, porque no momento em que ele o usasse, o JWT já seria inválido.
Um JWT geralmente contém uma data de expiração, portanto, quando um JWT válido se esgota, você pode colocá-lo na lista negra e usar um cron job que remove regularmente o JWT expirado do JWT na lista negra para evitar acumular muitos dados úteis.
Porque, se o seu JWT tem uma vida útil de quatro horas e você o usa agora, seu JWT está na lista negra, então ninguém vai reutilizá-lo, então depois de 4 horas ele pode ser removido da lista negra, porque nesse ponto é simplesmente desinteressante que o O JWT foi esgotado, pois expirou de qualquer maneira.