Vorwahlbot

Online påmelding informasjon i Düsseldorf gjør dårlig inntrykk

Det var ikke klart hva personopplysninger kan passere på registrering kontoret til hvem. Jeg er ute etter noen undersøkelser på denne handlingen presset piratene, som kaller for deg å protestere mot offentliggjøring av sine data ved registrering kontoret. Mange registrering kontorer gi data som nå er alt! Pays. Dette kan bare unngås ved en selvmotsigelse.

Data fra registrering kontoret vil bli videresendt til:

 Statlige myndigheter, i tilfelle legitim interesse i sammenheng med bistand

Så for eksempel, politi, påtalemyndighet, statistiske kontorer osv.

 Den GEZ

Brødrene, vi allerede vet alt for godt.

 Partier, grupper av velgere og andre kilder til nominasjoner i
 Knyttet til stortingsvalg og lokalvalg, § 35 para.1 MG NRW

For å få ganske blanke kampanjen annonsering.

 til fordringshavere og fester i forbindelse med begjæringer og
 Med folkeavstemninger og borgere bestemme, § 35 pkt. 2 MG NRW

For å oppnå høyglans vil hjelpe deg med å få hyppige folkeavstemningene.

 i veien for automatiserte søk på internett, § 34 Abs.1b MG NRW

Det er det punktet at jeg ennå ikke var kjent. Kan ha en Internett-portal
noen som vet noen kjennetegn ved en person automatisk over Internett
Samle intelligens rapportering. Spørringen tiden koster € 4 per rekord i Düsseldorf.

Den registreringsloven NRW sier på dette punkt:

 § 34 Abs.1b MG NRW
 (1b) Hvis samtalen gjøres mulig gjennom Internett, sikre at søknadsprosedyrene og formidling av opplysninger gjennomført i kryptert form.  Åpningen av tilgang bør offentlig kjent.  En samtale er ikke tillatt dersom den enkelte har protestert mot denne formen for informasjonsutveksling.  Registreringsmyndigheten å merke senest én måned før åpningen av Internett gjennom offentlig kunngjøring på rett til å protestere.  Videre § 35 nr. 6, gjelder setning to.

En klage mot overføring av data er mulig ved å fylle ut et skjema. For Düsseldorf, er ​​dette her: https://formulare.duesseldorf.de/forms/frm/7PRPfAZH5gQA8Ja8AkNGaH1rNpDcHR3 Dette kan leveres gratis på offentlige kontorer. Deretter er ingen online tilgang mulig å eie mer data. Tilsynelatende dataene forespørsler fra de respektive regionale byer og fylker organisert.

Da jeg spurte den (veldig vennlige) tilbake kontorist i det sivile, kunne
Jeg var ikke lei å fortelle nettadressen til portalen spørringen. Et raskt søk deretter ledet meg raskt til stedet, men byen Düsseldorf:

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

Das Portal machte technisch gelinde gesagt einen sehr zweifelhaften Eindruck.
Zunächst einmal scheint es keinerlei Captcha oder ähnliches zu geben. Eine Massenabfrage scheint also mit entsprechenden Skripten möglich zu sein.

Außerdem verabschiedete sich die Webapplikation bei meiner Testabfrage mit folgender Tomcat Fehlermeldung, da ich keine Cookies aktiviert hatte:

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.