Implementação da página WEB – Sistema de login

Uma parte essencial do projeto é a apresentação de relatório para o cliente final, e foi escolhido exibir esse relatório por meio de um site. Para primeira entrega foi pensado em entregar o sistema de login completo, esse objetivo foi alcançado com sucesso, porém como já foi estudado parte do sistema de host então isso também será discutido nesse post.

Nas imagens é possível ver a página de login já implementada, funcionando tanto em ambientes Desktop e Mobile. O foco na implementação desse sistema foi a segurança, portanto foram estudados os métodos mais comuns de quebra de segurança em sites. Os métodos em questão são: SQL Injection, Session Hijacking, Network Eavesdropping, Cross site scripting e Ataques por força bruta.

Desses métodos estudados foram utilizadas ferramentas para evitar os quatro primeiros, porém não foi implementado nada para evitar força bruta, vários estudos indicam que a melhor forma de evitar esse ataque é o uso de CAPTCHA, isso pode ser implementado no futuro, na etapa de refinamento do site, porém não há é nenhuma certeza que isso será feito, é possível que haja detalhes mais importantes para se investir tempo.

login3

login4

login5

Nessas imagens é possível ver como acessar o Logout do site e as mensagens de erro e sucesso no login, novamente, completamente responsivo e funcional em diferentes resoluções e plataformas.

Sobre o que já foi citado até esse ponto do post é necessário fazer algumas observações.

  • Não possuímos conhecimento de nenhum especialista em segurança, tudo que foi utilizado nesse sistema são ferramentas já existentes, a maioria já inclusa na linguagem PHP, portanto claramente há chances do sistema ser quebrado, porém foi trabalhado de forma a reduzir essas chances.
  • O layout foi produzido utilizando a ferramenta Bootstrap 3 e um template livre.

Discutido a implementação do login foi necessário começar a pensar como será hospedado esse site, e foi nesse momento que começou a ocorrer problemas, inicialmente foi pensado em fazer uma hospedagem caseira, na residência de dois integrantes (Gustavo e Lucas) os motivos dessa escolha foram a proximidade da universidade caso ocorra algum problema, e a alta velocidade de upload (isso torna o tempo de resposta do site menor), e normalmente o Raspberry se encontra na residência em questão tornando mais fácil testes. O problema é que nessa residência é utilizada a internet da empresa COPEL Telecom, e essa empresa atualmente não utiliza o sistema de distribuição de IP mais comum (IpV4) e sim o mais moderno (IpV6) portanto seria necessário uma série de alterações, que poderiam se tornar um problema e foi pensado outra solução.

A outra solução foi o uso de serviços de hospedagem pagos, isso iria proporcionar a confiança de funcionamento e garantir que o site mesmo na fase de prototipação já estaria online, mesmo que ainda não implementado completamente. O problema nessa solução é o simples aumento no custo, por mais que seja interessante já testar o sistema na sua forma final (para ser um sistema implementado será necessário um serviço de hospedagem confiável) ainda é um custo desnecessário e isso nos levou a solução atual: fazer um meio termo entre as duas soluções, montar um servidor de hospedagem caseiro em um local que sabemos que utiliza IpV4, e acessar o mesmo remotamente simulando um servidor confiável. E isso foi feito, quando precisamos testar o site utilizamos um computador que se encontra na casa de um integrante (Pedro), neste computador foi implementado o sistema mais simples possível de hospedagem utilizando o serviço Apache, não houve problemas uma vez que a prestadora da internet utilizada neste computador (NET) utiliza o IpV4.

O único problema dessa implementação é a possível instabilidade na internet do host e a necessidade de ligar o computador e colocar o servidor online quando necessário, porém isso não é um problema muito grande para apresentação/desenvolvimento de um protótipo como é o caso, e ainda sim a vantagem de simular um sistema de hospedagem real gera a garantia que conseguimos fazer uma migração tranquila entre servidores.

Apresentação de resultados

Com o sistema de login já implementado e o site hospedado temporariamente em um lugar apropriado, foi possível começar a trabalhar no recebimento de informações processadas e na exibição dessas de forma clara para o usuário final do projeto, esses pontos serão expostos nessa sessão do texto.

Começando pelo recebimento dos dados, não será abordado nesse texto como os dados são processados/gerados (visite a seção Servidor para mais informações), considerando os dados já gerados e processados foram pensadas duas formas principais de envio de dados para o servidor WEB. O primeiro modo é uma solução clássica para quem já usou qualquer serviço de hospedagens de site, esse modo é a transmissão por FTP (File Transfer Protocol).

Como o próprio nome já diz o FTP é um protocolo de transmissão de arquivos, que pode ser utilizado no projeto quando o software do servidor local (servidor responsável pelo processamento dos dados) gera um arquivo de texto com os dados, e envia esse arquivo para o servidor de hospedagem por FTP, e a linguagem PHP (linguagem em que o site está programado) interpreta esse arquivo.

Porém, o uso desse protocolo iria aumentar a complexidade do algoritmo, que já é bem complexo, e nenhuma pessoa da equipe tem experiência com o FTP, então procuramos outra forma de enviar essas informações para o servidor de hospedagem. A solução encontrada foi fazer inserções e updates direto no banco de dados sendo uma solução muito prática para a exibição pois o PHP lida muito bem com banco de dados.

Portanto foi utilizado o acesso ao banco de dados online do site para transmitir as informações já processadas, essa informações foram armazenadas em quatro tabelas diferentes (uma para produtos, uma para alertas, uma para padrões e uma para o indicador OEE). Após a criação das tabelas, os dados foram obtidos por meio da execução do projeto, isto é, foram colocados objetos na esteira e foi gerado os comandos de inserção no banco de dados automaticamente.

Tabela de alertas:

alertbd.PNG

Tabela de configuração:

patternbd.PNG

Tabela de produtos:

productsbd.PNG

Tabela do indicador OEE:

tabela_OEE.png

Esses comandos foram executados, e com isso foi possível implementar os gráficos e alertas na página WEB, porém isso foi apenas um teste para verificação do funcionamento do projeto no estado atual, as informações coletadas ainda eram poucas para analisar a qualidade dos gráficos gerados, então foram gerados dados baseados nos dados obtidos na prática.

Os gráficos já feitos (produção diária, produção mensal e indicador OEE) podem ser vistos nas imagens a seguir, assim como os alertas nas três formas de visualização (visualização rápida na página inicial, visualização na página de todos alertas, e detalhes em um alerta específico).

homeComGrafico.PNG

graph1.gif

graph2.gifalertas1.PNG

alertas2.PNG

oee_graph.jpeg

alertas3.PNG

WhatsApp Image 2017-05-17 at 12.51.46.jpegWhatsApp Image 2017-05-17 at 12.51.39.jpegWhatsApp Image 2017-05-17 at 12.50.17.jpegWhatsApp Image 2017-05-17 at 12.50.16.jpegWhatsApp Image 2017-05-17 at 12.50.15 (1).jpegWhatsApp Image 2017-05-17 at 12.50.15.jpeg

Configurações do usuário

Nesse ponto do projeto a pagina WEB já estava quase concluída, faltando apenas opções para que o usuário consiga configurar a linha de produção manualmente, pode parecer um choque com o objetivo do projeto implantar essa funcionalidade, mas por que decidimos que essa ferramenta ?

Bom por mais que o foco do projeto seja obter os valores padronizados automaticamente por meio da analise da produção, pode ocorrer alterações nessa produção depois da implementação do sistema e isso iria gerar inúmeros alertas inconvenientes portanto é interessante o usuário ter uma opção de reiniciar(zerando todos os valores padrões) ou colocar novos valores. Para mostrar como é feita essa interação com usuário ver a imagem a seguir e também há imagens mostrando como essa tela é apresentada em plataformas mobile.

aaaaaaaaaa2.gif

Reparos finais

Em teoria a página WEB já estária terminada nesse ponto, porém o grupo já havia reservado algumas horas no cronograma para reparar erros desde o inicio, e portanto foram melhoradas algumas funcionalidades, esses reparos serão citados rapidamente na forma de tópicos.

O calendario de escolha de datas agora está mais responsivo, o antigo tinha alguns problemas de não funcionar de forma suave e rápida em todas as plataformas, segue uma imagem da nova feramenta de escolha de data, em plataformas mobile está sendo chamado o proprio calendario padrão instalado.

calendario.png

Foram implementados mais campos para os alertas, durante a apresentação dessa funcionalidade o grupo sentiu falta de uma descrição mais completa e portanto foi adicionado mais um campo de informações no banco de dados e na exibição.

Referências:

http://php.net/manual/pt_BR/pdo.prepare.php

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

https://www.w3schools.com/sql/sql_injection.asp

https://pt.wikipedia.org/wiki/Injeção_de_SQL

https://en.wikipedia.org/wiki/Session_hijacking

https://www.owasp.org/index.php/Session_hijacking_attack

https://pt.stackoverflow.com/questions/33740/prevenção-session-hijacking

http://blog.inurl.com.br/2012/06/o-que-e-session-hijacking.html

https://pt.wikipedia.org/wiki/Ataque_de_força_bruta

https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks

https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

https://www.owasp.org/index.php/Network_Eavesdropping

https://startbootstrap.com/template-categories/all/