Carregando relatórios em front-end desvinculado.

Avelino Sampaio, o Mister M do Access!

Amigos, não estou aqui para apresentar-lhes um recurso sobre o tema, pois, não uso dessa técnica nos meus projetos e muito menos estou ao nível dos senhores para debater o assunto.

Mas não poderia deixar de dizer o quanto já aprendi e continuo aprendendo desde que me registrei neste conceituado Fórum. Agora estou maravilhado com este tópico que tem apresentado idéias inteligentes e que, ainda assim, estão vulneráveis à pessoas mal intensionadas.

Contudo, gostaria de parabenizar o Avelino por esta iniciativa, pois, vejo que seu objetivo não é apenas revelar os segredos e vulnerabilidades das técnicas apresentadas até agora, mas sim, conhecer esses "pontos fracos" para elaborar uma defesa mais eficaz e, claro, compartilha-la conosco.

Parabéns a todos que estão participando deste tópico. Acredito que só temos a ganhar.

Att.
Roni Lupe

Bem, de minha parte, por ainda não ter necessitado ir muito a fundo nessa questão, não tenho nada pronto. Apenas ideias que vão surgindo, e uma delas seria passar os dados por um receptor anterior, depois passar para o relatório e limpar o recordsource. Ou seja, um elemento recebe esses dados, passa-os para o relatório e limpa o recordsource. Estou sem tempo para poder testar mas acredito ser possível por aí. Caso alguem já não o tenha feito até eu me desocupar, voltarei com alguma coisa.

Opa, que grande lição este tópico, só nos enche de conhecimentos, parabéns a todos.

Bom dia,

Gostei muito também, o interessante deste tópico foi de abordar um tema novo,

onde até então o conveniente é criar relatórios usando o método RecordSource.

O mestre avelino nos proporcionou as falhas de segurança que podem ocorrer, justamente

porque a senha fica exposta se não tomarmos os devidos cuidados.

Ontem a noite ao pesquisar sobre o tema, cheguei a conclusão de que podemos criar sim, um

relatório sem o uso do RecordSource e usando a string de conexão em um módulo.

A primeira alternativa seria de fazer a conexão com o Banco e carregar uma tabela temporária,

então poderiamos criar o relatorio com todas as propriedades necessárias.

A segunda alternativa seria de criar um relatório sem as TextBox ou Labels, salvá-lo na pasta

do projeto .rpt, e usá-lo como (template).

As TextBox e Labels para as listas seriam criadas em tempo de execução.

Se se for preciso campos calculados, estes campos poderiam ser pré-definidos no template e

carregados com instruções SQL.

A criação das TextBox e Labes são possíveis com uso da classe "access.Control" e a propriedade

CreateReportControl.

Sds,

Bom dia a todos, também estou gostando muito deste tópico.

Estou trabalhando em formatar as informações diretamente em um textbox desacoplado no relatório, além de trabalhar com dados encriptados na base de dados, até amanhã quero colocar a qui para os mestres testarem.

Olá amigo avelino
Em primeiro lugar quero dizer que não sou programador, apenas tenho o obby de programação, e em ptpt creio que já não se usa access para gestão de empresas poderá sim ainda haver banco de dados em access, mas com tendência a desaparecerem. Creio que aqui apenas se usa para complemento numa situação ou outra.


[quote]ô pá, tu estais completamente enganado! Nós é que permitimos a vulnerabilidade!

Interpretei isto como um sorriso, mas sorriso não é sinónimo de inteligência.


Dito isto vamos ao que interessa:
No ponto 1. Você em parte tem razão, o shift dá para bloquear,
http://office.microsoft.com/pt-br/access-help/propriedade-allowbypasskey-HA001232717.aspx?CTT=3 ,
mas terá que usar a construção ou update de tabelas ou banco via código, senão como você entra outro entra também. É só descobrir a pass.
http://www.macoratti.net/cria_sql.htm

No ponto 2.
Poderia esplicar melhor? Esconder senha no servidor para que? Que senha seria essa ?

A minha ideia não é esconder a senha no servidor mas sim coloca-la na db.
Aí já contaríamos com a segurança do servidor mais a da db e acrescento agora incluindo o tal bloqueamento do shift .
Para segurança do vba utilizaríamos o hash ( sha1, md5 ou outro) eu foquei o sha1, mas poderia ter dito o md5 que é a mesma coisa mas com grau de segurança diferente.
http://www.mabesi.com/aplicativos-office/9-access/55-sistema-de-login-e-senha-no-accessvba-parte-5-5.html?showall=1
cumps
acao

Deixo aqui um pequeno exemplo para os amigos descobrirem a senha e me enviar por MP informando como conseguiu descobri-la. Peço por MP para dar a chance de todos tentarem e podermos ver as diferentes formas de se chegar até a senha.

Olá amigos! Obrigado pela excelente colaboração de vocês!

Bom, no meu artigo vou utilizar o RecordSource (risos) para o carregamento dos relatórios.

Como já havia mencionado, de todas as propostas aqui apresentadas, a que mais me agradou foi a de usar as tabelas, para então carregar os relatórios. No RecordSource será indicada a tabela e não a consulta.

Montar as tabelas e populalas está fora de cogitação, a não ser que ocorra uma situação especial. O que irei demonstrar é o uso das consultas(SQL) comuns, configuradas para criar consultas de ação "Geradora de Tabelas".

Entendeu? Vamos assim gerar as tabelas em tempo de execução. Ao abrir o relatório a tabela será criada, ao fechar o relatório a tabela será delatada.

Minha outra visão aqui é que devemos mensurar o tempo gasto no projeto e vejo nesta minha proposta, uma boa economia de tempo.

Todas as formas aqui apresentadas são válidas e vai depender do caso. Creio que para maioria dos relatórios a construção de tabelas em tempo de execução é um bom caminho.

Sobre a questão Segurança:

Se vc utiliza front-end desvinculado, preste atenção no seguinte:

1) Reveja suas funções PÚBLICAS, para não oferecer algum recurso importante ao invasor. Teste todas elas, chamando pela janela imediata e veja os resultados
2) Muito cuidado também com as variáveis públicas. É outra porta de acesso.
3) atento no uso do RecordSource dos seu relatórios.
4) Vamos supor que o invasor chegue ao seu Painel de Controle (isso é muito simples). Você terá que criar um defesa, dependendo do seu projeto, para que ele não cosiga abrir certos formulários e relatórios. Para isto sugiro este meu artigo:

http://www.usandoaccess.com.br/dicas/dica21.asp?id=1#inicio

5) Esconder tabelas locais é válido para dificultar invasores inesperientes. Não é garantia plena de segurança. Avalie bem os riscos! Se não tiver jeito, use então dados criptografados.
6) Neste caso, qualquer tabela vínculada usada vc perderá sua senha para o invasor.

Estou a disposição para mais testes.

Olá meus amigos!

Mudou TUDO! (risos). Criei uma ferramenta ESPETACULAR!!! Até o meio de semana devo liberar uma versão gratuita para vcs testarem.

Irei montar um vídeo e demonstrar qual é a idéia. Esta ferramenta será estremamente valiosa, não só para front-end desvinculas, como também para front-end vinculados.

Para o front-end desvinculados, vai poder usar a consulta direta no RecordSource e SEM precisar indicar a senha. Tente imaginar a economia de tempo nas montagens dos relatórios, em especial!

Para o frond-end vinculado vc poderá usar sem vincular uma tabela se quer! Estranho isso! Vai poder usar as consultas (EM SQL) normalmente e sem senha alguma. Fiz um teste aqui muito louco!

Vinculei tabelas sem a senha no back-end.
Depois de vinculado, criei a senha no back-end.
Obviamente que as tabelas, antes vinculadas sem a senha, pararam de funcionar.
Pois bem, com esta minha ferramenta TODAS voltam a funcionar, SEM A PRESENÇA DA SENHA. Só mostrando o vídeo para vc verem o que consegui!!!

Valdino, irei testar seu exemplo esta semana e continuamos nossa conversa por aqui.

LEMBRANDO QUE TUDO ISSO É PARA CASOS EM QUE DEFENDER A SENHA DO BACK-END SEJA PRIORIDADE MÁXIMA.

Muito bem. Mas no caso do meu exemplo, eu consegui acessar a senha dele utilizando uma ferramenta externa mesmo ela sendo passada via Recordset e não Recordsource. Nosso colega Charles Sestrem tambem conseguiu, acredito que utilizando algo semelhante. Mas eu já desenvolvi outra variação pela qual a ferramenta que tenho aqui não conseguiu enxergar a senha. Estou aguardando mais para poder colocar o novo exemplo aqui, tendo em vista que das pessoas que fizeram o download do exemplo anterior, apenas o Charles deu um feedback até o momento. Após seus testes, caso ninguem mais tenha conseguido, eu posto o novo exemplo para novos testes

Grande Valdino

Finalmente hoje pela manhã pude avaliar o seu projeto.

Grau de segurança de 0 a 10, ficou em 9

Não usou nada em módulo global que pudesse oferecer uma dica
não usou nada no recordsource dos objetos
não usou nada no rowSource da lista

Porém esqueceu de usar a ....

Sua senha: gjk258

Amigos, acompanhando a vídeo-aula, da ferramenta que acabo de desenvolver, irei demostrar TODAS AS TECNICAS DE INVASÃO que eu conheço.

Sucesso!

Opa Avelino! Agora fiquei mais curioso em ver seu artigo!!

Conforme falei, estou deixando à disposição mais um sisteminha para vossas maestrias descobrirem a senha do backend.

Favor informar como fez para descobri-la.

Pensei em algo... Mas para isso me digam se é possivel com o banco aberto, altarar a senha por VBA?

Não compreendi acao...

eu estou falando de definir a nova senha por vba...
se isto fosse possível talvez fosse possível uma forma cíclica de alterar a senha a cada utilização do be..

Foi apenas uma ideia que me ocorreu.

eu estou falando de definir a nova senha por vba...
se isto fosse possível talvez fosse possível uma forma cíclica de alterar a senha a cada utilização do be..

É possível sim. O Access tem instruções para isso. A questão é saber como e aonde definir isso para que não fique acessível ao bisbilhoteiro. Dependendo da forma como você escreve a rotina, é possível para ferramentas externas ler o código.

Dei uma viajada daquelas aqui...

Pensei de um código no be e uma tabela com senhas... onde ao abrir ja efetuasse a troca de senha....

Essa nova senha seria enviada para um arquivo de parametros txt e gravado em alguma pasta do windows...

ao abrir o relatorio leria essa senha para conexao... conectaria e em seguida o be ja mudaria asenha...

portanto a senha da variavel global ja nao seria a mesma...


Foi uma viajada grande... nao sei se me fiz entender Mestre dos Magos.. hehehe

Essa idéia do Hary é interessante, mas quem procurar arquivos txt ou mesmo por data de modificação achará o arquivo, então talvez se ao criar o arquivo e mudar a data do sistema para uma data bem inferior criar o arquivo e depois mudar novamente para a data atual talvez funcione.

E tambem a senha gravada no arquivo antes de ser gravada seria criptografada, e descriptografada no front...

assim mesmo com o acesso ao txt.. ainda assim nao teria a senha...

Olá Harysohn

Só é possivel a troca de senha se o back-end não estiver em uso. Isso numa rede seria complicado, pois todos teriam que compartilhar do mesmo arquivo txt.

Não gostei. O uso de criptografia já resolve bem, sem a necessidade de troca.

Olá Valdino

Baixe seu ultimo exemplo e agora não achei sua senha. Parabéns!

Algumas ponderações:

1) Por causa do não uso do RecorSource , vc teve que popular os campos do relatório, com uma técnica até bem interessante. Ao meu ver, continuamos aqui a "sacrificar" o que o Access tem de melhor, que é a mecânica interna dos relatórios, quando estes trabalham vinculados.

A perda de tempo em montar o CRUD para formulários já é imensa, e ainda temos que nos desgastar com a montagem dos relatórios. Cuidado então redobrado com o prazo passado para o cliente, se resolver utilizar front-end desvinculados.

2) Tudo bem , a senha foi bem protegida num abiante PRIVATE, que foi no forumlário e no relatório. Tendo que informar a senha(mesmo que criptografada) em cada um dos objetos (formulário e relatórios),que não seja capturando de um local "central", como fica se precisar trocar de senha ?

Valeu Valdino, pela sua ótima participação!

Acredito que hoje terminarei de montar o PROTEC. Um pequeno aplicativo, par ser usando junto com o front-end.

O PROTEC irá assegurar a senha do back-end e nos permitirá usar o RecordSource do relatórios sem a necssidade de indicar a senha na SQL. Isso era tudo que eu queria, pois irei aqui ganhar um tempo enorme nos meus projetos.

O PROTEC irá gerenciar os vínculos das tabelas, ou seja, poderemos utilizar as tabelas vinculadas sem que a senha seja exposta.

No final de semana montarei um vídeo e lanço aqui o protótipo para vcs massacrarem.

Grato!

Bom dia Avelino,
Por curiosidade: o PROTEC será
uma espécie de upgrade do OPEN?

Bom dia,

Excelente este topico abordado, um pequeno questionamento.
com a consumerização tão avançada que esta, computação em nuvem. Como seria a segurança de dados em acesso remoto com o PROTEC?

Olá Marcelo

Será um complemento, porque quero cobrar uma pequena quantia pela liberação da chave do PROTEC. O OPEN eu vou manter livre.

Ok!
Como tudo que fazes é da mais altíssima qualidade, sei que esse será
mais um sucesso!

Olá Danilo!

Ótima essa sua pergunta! Por enquanto só estou programando para lidar com ACCDBs

No uso do Mysql, SQl ou SharePoint não faço ideia ainda como seria. Tenho pouca experiência.

Quanto ao uso do RecorSource dos relatórios, para ter ganho de produtividade e qualidade, talvez a idéia que tive inicial, de transferir os dados para uma tabela local seja uma ótima opção.

Se não foi bem esta a sua questão, forneça mais detalhes.

Grato!

Estou quase terminando o PROTEC.

Ontém realizei vários testes, inclusive em rede e tudo parece funcionar muito bem!

Estou montando um BD de exemplo, com várias possíbilidades de uso, para vcs poderem analisar na prática.

Engraçado como uma coisa puxa por outra na nossa área! Ví a possibilidade de se montar um front-end híbrido, ou seja, trabalhar vinculado para partes que exigem pouco trafego de dados (assim ganhamos tempo na programação) e a parte que demanda grande trafego de dados trabalhar desvinculado. (isso para um back-end em ACCDB)

Obrigado pela participação de vocês aqui neste tópico

Mais um pequeno aplicativo para teste de front. favor me repassar o tempo e se possível a forma de como conseguiram a senha via MP.

Abraços.

Tópico encerrado, qualquer duvida mais, enviar MP para mim.