Online registration information in Dusseldorf makes bad impression

It was not clear what personal data may pass on the registration office to whom. I'm after some research on this action pushed the PIRATES, which calls for you to object to the disclosure of their data at the registration office. Many registration offices provide the data that is now all! Pays. This can only be avoided by a contradiction.

Data from the registration office will be forwarded to:

 State authorities, in case of legitimate interest in the context of assistance

So for example, police, prosecutors, statistical offices, etc.

 The GEZ

The brothers, we already know all too well.

 Parties, groups of voters and other sources of nominations in
 Relating to parliamentary and local elections, § 35 para.1 MG NRW

To get the pretty glossy campaign advertising.

 to claimants and parties in connection with petitions and
 With referendums and citizens decide, § 35 section 2 MG NRW

In order to obtain high-gloss will help you make the frequent referenda.

 in the way of automated searching on the Internet; § 34 Abs.1b MG NRW

That is the point that I was not yet known. Can have an Internet portal
anyone who knows some characteristics of a person automatically over the Internet
Gather intelligence reporting. The query currently costs € 4 per record in Dusseldorf.

The Registration Act NRW says at this point:

 § 34 Abs.1b MG NRW
 (1b) If the call be made possible through the Internet, ensure that the application procedures and the provision of information carried in encrypted form.  The opening of access should be publicly known.  A call is not allowed if the individual has objected to this form of information exchange.  The registration authority to note the latest one month before the opening of Internet access by public notice on the right to object.  Moreover, § 35 paragraph 6, sentence 2 applies.

An appeal against the transfer of data is possible by filling out a form. For Düsseldorf, this is here: https://formulare.duesseldorf.de/forms/frm/7PRPfAZH5gQA8Ja8AkNGaH1rNpDcHR3 This can be delivered free of charge in public offices. Thereafter, no online access is possible to own more data. Apparently, the data requests of the respective regional cities and counties organized.

When I asked the (very friendly) back office clerk in the civil, could
I was not sorry to tell the URL of the portal query. A quick search then led me quickly to the site but the city of Düsseldorf:

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

The portal was technically a very dubious to say the least impression.
First of all, there seems no captcha or similar to give. A ground query seems to be possible with appropriate scripts.

In addition, the web application approved by my test queries with the Tomcat error message because I had not enabled cookies:

I read this but then increasingly doubt the professionalism of an application that provides access to the data of all citizens of the city offers. A script should not crash if conditions do not exist on the user's machine (in this case, my lack of cookie). Script error messages from Web servers that are in production use not to deactivate is negligent because it can reveal a lot about the system environment used. Especially when one jsp (as in the screenshot above), depending on the configuration of the server also comments of the programmer and Quelltextschnippsel to get. Here was a sloppy job. At an interface to personal data should not happen.

Let me sit up and use the Tomcat version, which also appears in the error message below. (Apache Tomcat/6.0.24) This is an older version of the web server on 21/01/2010. The current version is 6.0.33. The server has four registers long versions are not updated. If you look at the vulnerabilities that were fixed in this latest version, it's getting uncomfortable. The server is obviously not in the best condition:

 http://tomcat.apache.org/security-6.html Fixed in Apache Tomcat 6.0.33 released August 18, 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 only what DIGEST authentication as secure as BASIC authentication.  This was fixed in revision 1158180th  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 Memory User Database (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 then 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.  Not that these users do have permissions but are able to read log files may be able to discover a user's password.  This was fixed in revision 1,140,071th  This was identified by Polina Genova on 14 June 2011 and made public on 27 June 2011th  Affects: 6.0.0-6.0.32 low: information disclosure CVE-2011-2526 Tomcat provides support for sendfile with the HTTP and NIO HTTP connectors in April.  sendfile is used for content automatically served via the DefaultServlet and deployed applications may use it directly via web setting request attributes.  These attributes were not validated request.  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 Security Manager is used to limit the untrusted web applications the HTTP NIO or HTTP April connector is used sendfile is enabled for the connector (this is the default) This was fixed in revision 1,146,703th  This was identified by the Tomcat security team on 7 July 2011 and made public on 13 July 2011th  Affects: 6.0.0-6.0.32 Important: information disclosure CVE-2011-2729 due to a bug in the code capabilities, 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 when all of the OCCURS following are true: Tomcat is running on a Linux operating system was compiled with libcap jsvc-user parameter is used Affected Tomcat versions shipped with source files for jsvc that included this vulnerability.  This was fixed in revision 1153824th  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 February 3, 2011 Note: The issue below was fixed in Apache Tomcat 6.0.31 release but the vote for the 6.0.31 release candidate did not pass.  Therefore, users must download 6.0.32 Although 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 endlessly buffer request line during processing.  That behavior can be used for a denial of service attack using a carefully crafted request.  This was fixed in revision 1066313th  This was identified by the Tomcat security team on January 27, 2011 and made public on 5 Feb 2011.  Affects: 6.0.0-6.0.30 Fixed in Apache Tomcat 6.0.30 released January 13, 2011 Low: Cross-site scripting CVE-2011-0013 The HTML Manager web application interface provided data displayed, analyzed 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 1057270th  This was identified by the Tomcat security team on November 12, 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 and sort orderBy directly without filtering THEREBY permitting cross-site scripting.  This was fixed in revision 1037779th  This was first reported to the Tomcat security team on November 15, 2010 and made public on 22 Nov 2010.  Affects: 6.0.12-6.0.29 Low: Security Manager file permission bypass CVE 2010-3718 When running under a security manager, 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 investigated 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 attributes before Tomcat Applies the file permissions.  This can be used to grant read / write permissions to any area on the filesystem Which a malicious web application may then take advantage of.  This vulnerability is only applicable when hosting web applications from untrusted sources examined as shared hosting environments.  This was fixed in revision 1022560th  This was discovered by the Tomcat security team on 12 May 2010 and made public on 5 Feb 2011.  Affects: 6.0.0-6.0.29 Fixed in Apache Tomcat 6.0.28 released July 9, 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 Prevented that the recycling of a buffer.  A remote attacker could trigger this flaw Which would cause subsequent requests to fail and / or to leak information between requests.  This flaw is mitigated if Tomcat is behind a reverse proxy (Apache httpd 2.2 as tested) as the proxy should reject the invalid transfer encoding header.  This was fixed in revision 958,977th  This was first reported to the Tomcat security team on June 14, 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 release but the vote for the 6.0.27 release candidate did not pass.  Therefore, users must download 6.0.28 Although 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 in web.xml for the application 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 936,540th  This was first reported to the Tomcat security team on 31 May 2009 and made public on 21 Apr 2010.  Affects: 6.0.0-6.0.26 

All this is very uncertain and it is for me an example of the lived privacy will of the state. The data is sold and there is hardly anyone known. The technical implementation leaves much to be desired and runs on very technical systems that are known to be faulty and need to be updated urgently. Also seems to be a final inspection and acceptance qualified in IT projects (known to the State are usually quite expensive) do not always take place.

As the only plus point I can note that there seems to be no central nationwide portal with online reading for all the reporting data. Then we would certainly not far removed from what the Israelis happened recently .

I'm glad I've held me, but if someone is not something with criminal energy and technical knowledge could still occur (free) to me (and everyone else), I think at least questionable. At first glance, the Düsseldorf system not hardened against attack.