Ofuscamento ou Não de Codigo JavaScript

[abalad]

Pessoal tenho uma duvida que nunca consegui uma resposta concreta:

• A Ofuscação do Código é Realmente necessária ?
• Como proteger a arquitetura do projeto ?
• Como esconder como esta criado sua API quando a mesma é utilizada dentro do seu Código JavaScript(Ex: Angular, Ajax, etc.)

[kivervinicius]

boa questão, apesar que eu acredito que uma minificação é o suficiente

[abalad]

@kivervinicius Tambem achava isto, porem mesmo assim a arquitetura de sua API fica exposta.

Sendo que a mesma dentro da aplicação é feita via Texto. Simplesmente visualizando a Aba Network no chrome você ja consegue visualizar de onde esta sendo requisitado seus dados.

Sendo assim você pode fazer uma busca interna nos JS de sua aplicação via o DEBUG mesmo dos navegadores.

[kivervinicius]

acredito que se o browser consegue visualizar qualquer programa consegue "descriptografar" infelizmente não vejo muitas alternativas.

[gabrieldarezzo]

Mais ou menos neh...

Quem minifica, desminifica (existe essa palavra? kkkk)
http://unminify.com/

De qualquer forma lembra sempre assim, a segurança da sua aplicação não pode depender do JavaScript (browser) e sim do que está no servidor.

Da uma lida nisso:
https://en.wikipedia.org/wiki/JSON_Web_Token

A minificação tmb tem o fator de performasse e velocidade, arquivos minificados diminuem muito o seu tamanho, e em um mundo onde o acesso cada vez mais é Mobile/Dados moveis esses Kbs fazem a diferença:)

Tem processos automatizados que fazem isso.
Grunt é um que funciona lindamente.

[wmartins]

Idealmente, a "lógica" (quando falado de consistência e manipulação de dados) da tua aplicação tem que estar no backend.

Se existe alguma lógica (algum cálculo que é enviado para o banco, alguma lógica de negócio, etc.) que é enviada diretamente para o backend e aceita sem nenhuma validação, é um sinal que o backend não está cumprindo o seu papel completamente e que o frontend está com mais responsabilidades do que deveria.

Com o backend bem desenvolvido e com todas as validações do negócio, ter o código "ofuscado" ou não não vai fazer diferença, visto que as chamadas de API vão ser "confiáveis" e vão representar o negócio (e suas restrições/validações/etc.) corretamente. Caso a pessoa fique "brincando" com as tuas APIs no devtools, ela só vai ter sucesso nas chamadas que o backend permite, o que não é um problema, visto que é um comportamento que, provavelmente, está mapeado na UI.

Complementando, existem alguns outros pontos que também são importantes de se preocupar quando se trata de segurança, sugiro as seguintes leituras:

• https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
• https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet#Data_Validation

[fabioassuncao]

@abalad Cara, não vejo o ofuscamento como algo imprescindível, mas a concatenação e minificação é importante, pelo menos para o desempenho.

Ofuscar teu código no front pode até dificultar que alguém consiga copiar/usar, mas não impedirá que isso aconteça quando a outra parte estiver determinada. Se estiver fazendo consumo de dados de alguma API e estiver usando credenciais/tokens no código, independente dos arquivos estarem minificados e ofuscados, ainda sim será possível obter os mesmos!

[abalad]

@fabioassuncao Então mas ae que esta minha duvida. Pois você pega por exemplo o Site do NuBank ele tambem trabalha com chamadas a API... porem eles fizeram um negocio bem bacana que esconde qual é a url do recurso que é chamado.

[fabioassuncao]

@abalad Conheço o NuBank, já olhei o site deles, mas foi bem superficial. Não sei falar a respeito de como eles ocultam isso. Cara, de qualquer maneira, se uma página fizer requisição, seja apara o mesmo servidor ou outra fonte de dados, tem como saber e olhar os detalhes de cada requisição pelo próprio navegador. No Chrome você olha isso na aba Network do Dev Tools.

[bernardodiasc]

quando voce entrega o código pro client (browser), é impossivel que seja invulneravel, todas essas camadas de criptografia nada mais fazem que dificultar o trabalho de quem ta tentando fazer engenharia reversa. vai colocando mais camadas pra deixar mais dificil mas nunca vai ser seguro. por isso a parte importante da preocupaçao com seguranca fica no código do server nao do client.

[abalad]

@fabioassuncao Então amigo por isso que falei.. pois facilmente pelo Dev Tools você consegue ver as chamadas a api e assim conseguindo compreender certa parte da arquitetura.

@bernardodiasc Eu compreendo que no Server deve ter a validação, o maior problema/preocupação é a pessoa mal intencionada visualizar como seu software foi desenvolvido e assim conseguir aplicar engenharia reversa como que você disse, pois Tanto a API quanto Seu código fica exposto.

Pois hoje com o surgimento de Aplicações SPA onde toda a renderização fica por conta do cliente e o servidor somente fica responsável por gerir uma API e controlar as regras de negocio, creio que fique muito desprotegido esse tipo de aplicações compreenderam ?

[bernardodiasc]

Qualquer código que voce manda pro computador do usuario é desprotegido, esse que é o lance. Criptografia vai aumentar a dificuldade da engenharia reversa, mas nao vai impedir alguem que queira muito ver como funciona. Sua aplicação só fica vulnerável mesmo se o lado do server conter falhas, e piora se as falhas forem aparentes ao realizar a engenharia reversa. O caso é evitar mandar código sensitivo pro usuário. Ao pé da letra pense assim, imagina o código do client open source, se isso for algo impraticável por partes sensitivas que afetam a segurança, pode ser o caso de ter que rever a arquitetura. O código do server por outro lado somente quem tem acesso direto a ele ou à maquina onde ele esta hospedado conseguiria fazer qualquer coisa a respeito, desse modo existem outras barreiras, é bem diferente do código que o usuario faz download.