Informações de registro on-line em Dusseldorf faz má impressão

Eu não estava muito claro o que os dados pessoais podem passar o serviço de registo para quem. Estou após alguma pesquisa sobre esta ação empurrou os piratas que chamam a opor-se a divulgação de seus próprios dados no escritório de registro. Muitos escritórios de registro fornecer os dados que agora todo mundo! Pays. Que só pode ser evitado por uma contradição.

Dados do escritório de registro será encaminhado para:

 Autoridades estaduais, em caso de interesse legítimo no contexto da assistência

Por exemplo: polícia, Ministério Público, os serviços de estatística, etc

 O GEZ

Os irmãos, que já conhecemos muito bem.

 Partidos, grupos de eleitores e outras fontes de nomeações em
 Relacionados com as eleições parlamentares e locais; § 35 parágrafo 1 MG NRW

Para obter a campanha publicitária muito brilhante.

 a requerentes e partes em conexão com as petições e
 Referendos com os cidadãos e tomada de decisões; § 35 para.2 MG NRW

A fim de obter alto brilho o ajudará a fazer os referendos freqüentes.

 na forma de consulta automatizada na Internet; § 34 Abs.1b MG NRW

Esse é o ponto que eu não era conhecida anteriormente. Pode ter um portal na Internet
qualquer um que conhece algumas características de uma pessoa automaticamente através da Internet
Obtenção de relatórios de informações. A consulta custa atualmente € 4 por registro em Dusseldorf.

A Lei de Registro NRW diz neste momento:

 § 34 Abs.1b MG NRW
 (1b) Se a chamada ser possível graças à Internet, garantir que os procedimentos de candidatura e prestação de informações transportadas de forma criptografada.  A abertura de acesso deve ser de conhecimento público.  A chamada não é permitida se o indivíduo se opôs a essa forma de troca de informações.  A autoridade de registro para nota mais tardar um mês antes da abertura do acesso à Internet através de um aviso público sobre o direito de se opor.  Além disso, n. º 35 § 6, frase 2 se aplica.

Um recurso contra a transferência de dados é possível através do preenchimento de um formulário. Düsseldorf para isso é aqui: https://formulare.duesseldorf.de/forms/frm/7PRPfAZH5gQA8Ja8AkNGaH1rNpDcHR3 Essa taxa pode ser liberado para cargos públicos. Então não tem acesso on-line é possível em seus próprios dados mais. Aparentemente, os pedidos de dados do respectivas cidades e condados regionais organizadas.

Quando perguntei ao atendente (muito simpática) no escritório para os cidadãos, poderia
Eu não estava arrependido de dizer a URL do portal consulta. Uma rápida pesquisa me levou, em seguida, mas rapidamente neste lado da cidade de Düsseldorf:

% https://www.duesseldorf.de/emra/emra.jsp?stadt=D FCsseldorf & tipo = cidade

O portal foi tecnicamente muito duvidosa para dizer o mínimo impressão.
Primeiro de tudo, parece não haver captcha ou similar para dar. Uma consulta chão parece ser possível com scripts apropriados.

Além disso, a aplicação web aprovado com a seguinte consulta na minha mensagem de erro de teste Tomcat porque eu não tinha ativado os cookies:

Eu li isso, mas depois cada vez mais duvidar do profissionalismo de um aplicativo que fornece acesso aos dados de todos os cidadãos da cidade oferece. Um script não deve falhar se as condições não existem na máquina do usuário (neste caso meu cookie em falta). Mensagens de erro de script a partir de servidores Web que não estão em uso produtivo para desativar é negligente , pois pode revelar muito sobre o ambiente do sistema utilizado. Especialmente quando um jsp (como na imagem acima), dependendo da configuração do servidor e também comentários do programador para obter Quelltextschnippsel. Este era descuidado. Em uma interface de dados pessoais não deveria acontecer.

Deixe-me sentar e usar a versão do Tomcat, que também aparece na mensagem de erro abaixo. (Apache Tomcat/6.0.24) Esta é uma versão mais antiga do servidor web em 21/01/2010. A versão atual é 6.0.33. O servidor tem quatro registros versões longas não são atualizados. Se você olhar para as vulnerabilidades que foram abordados nesta versão final, está ficando desconfortável. O servidor não é, obviamente, nas melhores condições:

 http://tomcat.apache.org/security-6.html fixo no Apache Tomcat 6.0.33 lançado 18 de agosto de 2011 Moderado: fraquezas múltiplas em HTTP autenticação DIGEST CVE-2011-1184 A implementação do HTTP autenticação DIGEST foi descoberto para ter várias fraquezas: ataques de repetição foram autorizados nonces servidor não foram verificados nonce conta do cliente não foram verificados valores qop não foram verificados valores reino não foram verificados o segredo servidor foi codificado em uma seqüência conhecida O resultado destas deficiências é que apenas o que a autenticação DIGEST como segura como a autenticação BASIC.  Isto foi corrigido na revisão 1158180  Isso foi identificado pela equipe de segurança Tomcat em 16 de Março de 2011 e tornado público em 26 de setembro de 2011.  Afeta: 6.0.0-6.0.32 baixo: a divulgação de informações CVE-2011-2204 Ao usar o banco de dados de memória do usuário (com base no tomcat-users.xml) e criação de usuários através de JMX, uma exceção durante o processo de criação do usuário pode disparar uma mensagem de erro O cliente JMX que inclui a senha do usuário.  Esta mensagem de erro é então gravada nos logs do Tomcat.  Senhas de usuários são visíveis para os administradores com JMX acesso e / ou administradores com acesso de leitura para o arquivo tomcat-users.xml.  Não que esses usuários têm permissões, mas são capazes de ler arquivos de log pode ser capaz de descobrir a senha de um usuário.  Isto foi corrigido na revisão 1.140.071 th  Esta foi identificado por Polina Genova em 14 de junho de 2011 e tornado público em 27 de Junho 2011th  Afeta: 6.0.0-6.0.32 baixa: divulgação de informações CVE-2011-2526 Tomcat fornece suporte para o envio de arquivo com o HTTP e HTTP conectores NIO em abril.  sendfile é usada para conteúdo automaticamente servido através do DefaultServlet e os aplicativos implementados podem usá-lo diretamente via web atributos configuração pedido.  Estes atributos não foram validados pedido.  Quando executando sob um gerente de segurança, essa falta de validação permitiu uma aplicação web maliciosas para fazer um ou mais dos seguintes que normalmente seria impedido por um gerente de segurança: arquivos de retorno aos usuários que o gestor de segurança deve fazer cessar inacessíveis (por um acidente ) a JVM Além disso, essas vulnerabilidades ocorrem somente quando todas as seguintes forem verdadeiras: as aplicações web não confiáveis ​​estão sendo utilizados o gerenciador de segurança é usado para limitar as aplicações web não confiável o NIO HTTP ou HTTP abril conector é usado sendfile está habilitado para o conector (esta é o padrão) Isto foi corrigido na revisão 1146703  Isso foi identificado pela equipe de segurança Tomcat em 07 de julho de 2011 e tornado público em 13 de Julho 2011th  Afeta: 6.0.0-6.0.32 Importante: Divulgação de informações CVE-2011-2729 Devido a um bug no código de capacidades, jsvc (o wrapper de serviço para Linux que faz parte do projeto Commons Daemon) não deixa cair capacidades Permitindo a aplicação para acessar arquivos e diretórios que pertencem superusuário.  Esta vulnerabilidade ocorre somente quando todas as seguintes forem verdadeiras: Tomcat está rodando em um sistema operacional Linux compilado com libcap que jsvc usuário tomcat parâmetro é usado As versões afetadas fornecido com arquivos de origem para jsvc que incluiu esta vulnerabilidade.  Isto foi corrigido na revisão 1153824  Esta foi identificado por Wilfried Weissmann em 20 de Julho de 2011 e tornado público em 12 de agosto de 2011.  Afeta: 6.0.30-6.0.32 fixo no Apache Tomcat 6.0.32 lançado 3 de fevereiro de 2011 Nota: O problema abaixo foi corrigido no Apache Tomcat 6.0.31 release, mas o voto para o candidato liberação 6.0.31 não passou.  Portanto, embora os usuários devem baixar 6.0.32 para obter uma versão que inclui uma correção para esse problema, a versão 6.0.31 não está incluído na lista de versões afetadas.  Importante: negação de serviço remoto CVE-2011-0534 O conector NIO expande sua linha de buffer durante o processamento do pedido sem parar.  Que o comportamento pode ser usado para um ataque de negação de serviço usando uma solicitação cuidadosamente elaborada.  Isto foi corrigido na revisão 1066313th  Isso foi identificado pela equipe de segurança Tomcat em 27 de janeiro de 2011 e tornado público em 5 de fevereiro de 2011.  Afeta: 6.0.0-6.0.30 fixo no Apache Tomcat 6.0.30 liberada janeiro 13, 2011 Baixa: site scripting Cross-CVE-2011-0013 O Gerente de HTML interface da aplicação web exibidos dados fornecidos, tais como nomes, sem filtragem.  Uma aplicação web malicioso pode provocar a execução do script por um usuário administrativo ao visualizar as páginas gerente.  Isto foi corrigido na revisão 1057270  Isso foi identificado pela equipe de segurança Tomcat em 12 de novembro de 2010 e tornado público em 05 de fevereiro de 2011.  Afeta: 6.0.0-6.0.29 moderada: site scripting Cross-CVE-2010-4172 O aplicativo Gerenciador usado eo usuário forneceu os parâmetros orderBy espécie diretamente, sem filtragem permitindo assim cross-site scripting.  Isto foi corrigido na revisão 1037779  Este foi relatada pela primeira vez para a equipe de segurança Tomcat em 15 de novembro de 2010 e tornado público em 22 de novembro de 2010.  Afeta: 6.0.12-6.0.29 Baixa: SecurityManager desvio de permissão de arquivo CVE 2010-3718 Quando executando sob um gerente de segurança, o acesso ao sistema de arquivos é limitada, mas as aplicações web são concedidos de leitura / gravação permissões para o diretório de trabalho.  Este diretório é usado para uma variedade de arquivos temporários, como os arquivos intermediários gerados ao compilar JSPs para servlets.  A localização do diretório de trabalho é especificado por um atributo ServletContect que é feito para ser lido somente para aplicações web.  No entanto, devido a um erro de codificação, a definição só de leitura não foi aplicada.  Portanto, um aplicativo web malicioso pode modificar o atributo antes Tomcat Aplica-se as permissões do arquivo.  Isto pode ser usado para conceder leitura / gravação permissões para qualquer área do sistema de arquivos que uma aplicação web malicioso pode então aproveitar.  Essa vulnerabilidade só é aplicável quando hospedagem de aplicações web de fontes não confiáveis, tais como ambientes de hospedagem compartilhada.  Isto foi corrigido na revisão 1022560  Isto foi descoberto pela equipe de segurança Tomcat em 12 de maio de 2010 e tornado público em 5 de fevereiro de 2011.  Afeta: 6.0.0-6.0.29 fixo no Apache Tomcat 6.0.28 lançado 09 de julho de 2010 Importante: negação de serviço remoto e Vulnerabilidade de Divulgação de Informações CVE-2010-2227 Várias falhas na manipulação de cabeçalho "Transfer-Encoding 'foram encontrados impediu que a reciclagem de um buffer.  Um atacante remoto pode provocar esta falha que faria com que os pedidos subsequentes ao fracasso e / ou vazamento de informações entre as solicitações.  Esta falha é atenuada se o Tomcat está por trás de um proxy reverso (como o Apache httpd 2.2), como o proxy deve rejeitar o cabeçalho codificação inválido transferência.  Isto foi corrigido na revisão 958.977 ª  Este foi relatada pela primeira vez para a equipe de segurança Tomcat em 14 de junho de 2010 e tornado público em 09 de julho de 2010.  Afeta: 6.0.0-6.0.27 Nota: O problema abaixo foi corrigido em Apache Tomcat 6.0.27 release, mas o voto para o candidato liberação 6.0.27 não passou.  Portanto, embora os usuários devem baixar 6.0.28 para obter uma versão que inclui uma correção para esse problema, a versão 6.0.27 não está incluído na lista de versões afetadas.  Baixa: Divulgação de informações em cabeçalhos de autenticação CVE-2010-1157 A WWW-Authenticate cabeçalho HTTP para o BASIC e autenticação DIGEST inclui um nome de domínio.  Se um   elemento é especificado no web.xml para a aplicação que será usada.  No entanto, uma   não é especificado, Tomcat irá gerar nome de realm usando o código snippet request.getServerName () + "" + request.getServerPort ().  Em algumas circunstâncias isso pode expor o nome do host local ou endereço IP da máquina rodando Tomcat.  Isto foi corrigido na revisão 936.540 ª  Este foi relatada pela primeira vez para a equipe de segurança Tomcat em 31 de Maio de 2009 e tornado público em 21 de abril de 2010.  Afeta: 6.0.0-6.0.26 

Isso tudo parece muito incerto, e para mim é um exemplo da vontade do Estado viveu privacidade. Os dados são vendidos, e quase ninguém tem conhecimento. A execução técnica deixa muito a desejar, e roda em sistemas muito técnicos que são conhecidos por estar com defeito e precisa ser atualizado com urgência. Também parece ser uma inspeção final e aceitação qualificados em projetos de TI (conhecidas para o estado são geralmente muito caros) nem sempre acontecem.

O único ponto mais posso notar que parece haver nenhum portal central em todo o país com a leitura on-line para todos os dados de relatório. Então nós certamente não muito longe do que os israelenses aconteceu recentemente .

Fico feliz que eu me segurava, mas se alguém não entende um pouco de energia criminal e conhecimento técnico ainda pode acontecer (gratuito) para mim (e todos os outros), eu acho, pelo menos, questionável. À primeira vista, não o sistema de Düsseldorf endurecido contra ataque.