Vorwahlbot

L'inscription en ligne des informations à Düsseldorf fait mauvaise impression

Il n'était pas clair ce que les données personnelles peuvent passer sur le bureau d'enregistrement à qui. Je suis après quelques recherches sur cette action a poussé les Pirates, qui appelle à vous pour s'opposer à la divulgation de leurs données au bureau d'enregistrement. De nombreux bureaux d'enregistrement fournissent les données qui sont maintenant tous! Pays. Ce ne peut être évité par une contradiction.

Les données du bureau d'inscription sera transmis à:

 Autorités de l'État, dans le cas d'un intérêt légitime dans le cadre de l'assistance

Ainsi, par exemple, la police, les procureurs, les bureaux de statistiques, etc

 La GEZ

Les frères, nous savons déjà que trop bien.

 Parties, les groupes d'électeurs et d'autres sources de candidatures dans
 Relative aux élections législatives et locales, § 35 al.1 MG NRW

Pour obtenir le campagne de publicité très brillant.

 aux demandeurs et aux parties dans le cadre de pétitions et de
 Avec les référendums et les citoyens de décider, § 35 de l'article 2 MG NRW

Afin d'obtenir de haute brillance vous aidera à faire des référendums fréquents.

 dans la voie de la consultation automatisée sur Internet; § 34 Abs.1b MG NRW

C'est le point que je n'étais pas encore connu. Peut avoir un portail Internet
toute personne qui connaît quelques caractéristiques d'une personne automatiquement sur Internet
Rassemblez rapports de renseignement. La requête coûte actuellement 4 € par dossier à Düsseldorf.

La Loi sur l'enregistrement NRW dit à ce moment:

 § 34 Abs.1b MG NRW
 (1b) Si l'appel est rendu possible grâce à l'Internet, s'assurer que les procédures de demande et la fourniture d'informations effectuée sous forme cryptée.  L'ouverture de l'accès doit être connue du public.  Un appel n'est pas autorisée si la personne s'est opposée à cette forme d'échange d'informations.  Le service d'enregistrement de noter plus tard un mois avant l'ouverture de l'accès à Internet par un avis public sur le droit de s'opposer.  En outre, § 35, paragraphe 6, la phrase 2 s'applique.

Un recours contre le transfert de données est possible en remplissant un formulaire. Pour Düsseldorf, c'est ici: https://formulare.duesseldorf.de/forms/frm/7PRPfAZH5gQA8Ja8AkNGaH1rNpDcHR3 Cela peut être délivré gratuitement dans les bureaux publics. Par la suite, pas d'accès en ligne est possible de posséder plus de données. Apparemment, les demandes de données des villes et des comtés régionaux respectifs organisée.

Quand j'ai demandé au greffier (très sympathique) back office dans la fonction publique, pourrait
Je n'étais pas fâché de dire l'URL de la requête du portail. Une recherche rapide m'a alors conduit rapidement à la place, mais la ville de Düsseldorf:

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

Le portail était techniquement très douteux de dire la moindre impression.
Tout d'abord, il ne semble pas captcha ou similaire à donner. Une requête au sol semble être possible avec les scripts appropriés.

En outre, l'application Web approuvés par mes requêtes de test avec le message d'erreur Tomcat parce que je n'avais pas activé les cookies:

Dies lies mich dann doch zunehmend an der Professionalität einer Anwendung zweifeln, die Zugriff auf die Daten aller Bürger der Stadt bietet. Ein Skript sollte nicht abstürzen, wenn Voraussetzungen am Rechner des Benutzers nicht gegeben sind (in diesem Fall mein fehlender Cookie). Skript-Fehlermeldungen von Webservern, die sich im produktiven Einsatz befinden nicht zu deaktivieren ist fahrlässig , da sie viel über die verwendete Systemumgebung verraten können. Zumal man bei jsp (wie im Screenshot oben) je nach Konfiguration des Servers auch noch Kommentare des Programmierers und Quelltextschnippsel dazu bekommt. Hier wurde geschlampt. An einer Schnittstelle zu persönlichen Daten sollte das nicht passieren.

Aufhorchen ließ mich auch die benutze Tomcat Version, welche in der Fehlermeldung auch unten auftaucht. (Apache Tomcat/6.0.24) Dies ist eine ältere Version des Webservers vom 21.01.2010. Aktuell ist die Version 6.0.33. Der Melderegister-Server wurde 4 Versionen lang nicht aktualisiert. Schaut man sich die Sicherheitslücken an, die in diesen letzten Versionen behoben wurden, wird es langsam ungemütlich. Der Server befindet sich offensichtlich nicht im bestmöglichen Zustand:

http://tomcat.apache.org/security-6.html

Fixed in Apache Tomcat 6.0.33 released 18 Aug 2011

    Moderate: Multiple weaknesses in HTTP DIGEST authentication CVE-2011-1184

    The implementation of HTTP DIGEST authentication was discovered to have several weaknesses:

        replay attacks were permitted
        server nonces were not checked
        client nonce counts were not checked
        qop values were not checked
        realm values were not checked
        the server secret was hard-coded to a known string

    The result of these weaknesses is that DIGEST authentication was only as secure as BASIC authentication.

    This was fixed in revision 1158180.

    This was identified by the Tomcat security team on 16 March 2011 and made public on 26 September 2011.

    Affects: 6.0.0-6.0.32

    Low: Information disclosure CVE-2011-2204

    When using the MemoryUserDatabase (based on tomcat-users.xml) and creating users via JMX, an exception during the user creation process may trigger an error message in the JMX client that includes the user's password. This error message is also written to the Tomcat logs. User passwords are visible to administrators with JMX access and/or administrators with read access to the tomcat-users.xml file. Users that do not have these permissions but are able to read log files may be able to discover a user's password.

    This was fixed in revision 1140071.

    This was identified by Polina Genova on 14 June 2011 and made public on 27 June 2011.

    Affects: 6.0.0-6.0.32

    Low: Information disclosure CVE-2011-2526

    Tomcat provides support for sendfile with the HTTP NIO and HTTP APR connectors. sendfile is used automatically for content served via the DefaultServlet and deployed web applications may use it directly via setting request attributes. These request attributes were not validated. When running under a security manager, this lack of validation allowed a malicious web application to do one or more of the following that would normally be prevented by a security manager:

        return files to users that the security manager should make inaccessible
        terminate (via a crash) the JVM

    Additionally, these vulnerabilities only occur when all of the following are true:

        untrusted web applications are being used
        the SecurityManager is used to limit the untrusted web applications
        the HTTP NIO or HTTP APR connector is used
        sendfile is enabled for the connector (this is the default)

    This was fixed in revision 1146703.

    This was identified by the Tomcat security team on 7 July 2011 and made public on 13 July 2011.

    Affects: 6.0.0-6.0.32

    Important: Information disclosure CVE-2011-2729

    Due to a bug in the capabilities code, jsvc (the service wrapper for Linux that is part of the Commons Daemon project) does not drop capabilities allowing the application to access files and directories owned by superuser. This vulnerability only occurs when all of the following are true:

        Tomcat is running on a Linux operating system
        jsvc was compiled with libcap
        -user parameter is used

    Affected Tomcat versions shipped with source files for jsvc that included this vulnerability.

    This was fixed in revision 1153824.

    This was identified by Wilfried Weissmann on 20 July 2011 and made public on 12 August 2011.

    Affects: 6.0.30-6.0.32

Fixed in Apache Tomcat 6.0.32 released 03 Feb 2011

    Note: The issue below was fixed in Apache Tomcat 6.0.31 but the release vote for the 6.0.31 release candidate did not pass. Therefore, although users must download 6.0.32 to obtain a version that includes a fix for this issue, version 6.0.31 is not included in the list of affected versions.

    Important: Remote Denial Of Service CVE-2011-0534

    The NIO connector expands its buffer endlessly during request line processing. That behaviour can be used for a denial of service attack using a carefully crafted request.

    This was fixed in revision 1066313.

    This was identified by the Tomcat security team on 27 Jan 2011 and made public on 5 Feb 2011.

    Affects: 6.0.0-6.0.30

Fixed in Apache Tomcat 6.0.30 released 13 Jan 2011

    Low: Cross-site scripting CVE-2011-0013

    The HTML Manager interface displayed web application provided data, such as display names, without filtering. A malicious web application could trigger script execution by an administrative user when viewing the manager pages.

    This was fixed in revision 1057270.

    This was identified by the Tomcat security team on 12 Nov 2010 and made public on 5 Feb 2011.

    Affects: 6.0.0-6.0.29

    Moderate: Cross-site scripting CVE-2010-4172

    The Manager application used the user provided parameters sort and orderBy directly without filtering thereby permitting cross-site scripting.

    This was fixed in revision 1037779.

    This was first reported to the Tomcat security team on 15 Nov 2010 and made public on 22 Nov 2010.

    Affects: 6.0.12-6.0.29

    Low: SecurityManager file permission bypass CVE-2010-3718

    When running under a SecurityManager, access to the file system is limited but web applications are granted read/write permissions to the work directory. This directory is used for a variety of temporary files such as the intermediate files generated when compiling JSPs to Servlets. The location of the work directory is specified by a ServletContect attribute that is meant to be read-only to web applications. However, due to a coding error, the read-only setting was not applied. Therefore, a malicious web application may modify the attribute before Tomcat applies the file permissions. This can be used to grant read/write permissions to any area on the file system which a malicious web application may then take advantage of. This vulnerability is only applicable when hosting web applications from untrusted sources such as shared hosting environments.

    This was fixed in revision 1022560.

    This was discovered by the Tomcat security team on 12 Oct 2010 and made public on 5 Feb 2011.

    Affects: 6.0.0-6.0.29

Fixed in Apache Tomcat 6.0.28 released 9 Jul 2010

    Important: Remote Denial Of Service and Information Disclosure Vulnerability CVE-2010-2227

    Several flaws in the handling of the 'Transfer-Encoding' header were found that prevented the recycling of a buffer. A remote attacker could trigger this flaw which would cause subsequent requests to fail and/or information to leak between requests. This flaw is mitigated if Tomcat is behind a reverse proxy (such as Apache httpd 2.2) as the proxy should reject the invalid transfer encoding header.

    This was fixed in revision 958977.

    This was first reported to the Tomcat security team on 14 Jun 2010 and made public on 9 Jul 2010.

    Affects: 6.0.0-6.0.27

    Note: The issue below was fixed in Apache Tomcat 6.0.27 but the release vote for the 6.0.27 release candidate did not pass. Therefore, although users must download 6.0.28 to obtain a version that includes a fix for this issue, version 6.0.27 is not included in the list of affected versions.

    Low: Information disclosure in authentication headers CVE-2010-1157

    The WWW-Authenticate HTTP header for BASIC and DIGEST authentication includes a realm name. If a  element is specified for the application in web.xml it will be used. However, a  is not specified then Tomcat will generate realm name using the code snippet request.getServerName() + ":" + request.getServerPort(). In some circumstances this can expose the local host name or IP address of the machine running Tomcat.

    This was fixed in revision 936540.

    This was first reported to the Tomcat security team on 31 Dec 2009 and made public on 21 Apr 2010.

    Affects: 6.0.0-6.0.26

Das alles wirkt sehr unsicher und steht für mich exemplarisch für den gelebten Datenschutzwillen des Staates. Die Daten werden verkauft und es ist kaum jemandem bekannt. Die technische Umsetzung lässt sehr zu Wünschen übrig und läuft über technische Systeme, die bekanntermaßen fehlerhaft sind und dringend aktualisiert werden müssten. Auch scheint eine Endkontrolle und qualifizierte Abnahme bei IT-Projekten (die bekanntermaßen für den Staat meistens recht teuer sind) nicht immer stattzufinden.

Als einzigen Pluspunkt kann ich vermerken, dass es kein zentrales bundesweites Portal mit Online-Fernabfrage für alle Meldedaten zu geben scheint. Dann wären wir sicherlich nicht mehr weit entfernt von dem, was den Israelis vor Kurzem geschehen ist .

Ich bin froh, dass ich mich ausgetragen habe, aber ob jemand mit etwas krimineller Energie und technischem Verständnis nicht trotzdem (kostenlos) an meine Daten (und alle anderen) kommen könnte, halte ich zumindest für fragwürdig. Auf den ersten Blick wirkt das Düsseldorfer System nicht abgehärtet gegen Angriffe.