デュッセルドルフでのオンライン登録情報は悪い印象を作る

それは、個人データが誰に登録事務所に渡すことが何明確ではありませんでした。 上のいくつかの調査後、私は私、このアクションは、登録事務所でそのデータの開示に反対するための呼び出しの海賊を、プッシュ。 多くの登録事務所は、すべて今あるデータを提供する！ロワール。 これは、矛盾することで回避できます。

登録オフィスからのデータが転送されます。

州当局、援助の文脈で正当な利益の場合

したがって、たとえば、警察、検察官、統計局など

 GEZ

兄弟は、我々はすでに、あまりにもよく知っている。

締約国は、有権者とのノミネートの他のソースのグループ
議会及び地方選挙に関連して、§35 para.1 MG NRW

かなり光沢のあるキャンペーンの広告を取得します。

嘆願書との接続で原告と第三者にと
国民投票と市民が決めることで、§35セクション2 MG NRW

高光沢を得るためにあなたが頻繁に国民投票を行うのに役立ちます。

 自動検索の方法で、インターネット上で、§34 Abs.1b MG NRW

それは私がまだ知られていなかったという点です。 インターネットポータルを持つことができます
インターネット経由で自動的に人のいくつかの特性を知っている人
インテリジェンス·レポートを収集します。 クエリは、現在デュッセルドルフでレコードごとに€4かかります。

登録法NRW州はこの時点で言います：

 §34 Abs.1b MG NRW
コー​​ルはインターネット経由で可能な限り行われる場合、（1b）は、申請手続や情報の提供が暗号化された形式で行われていることを確認します。 アクセスの開口部が公に知られている必要があります。 個々の情報交換のこの形式に反対している場合、呼び出しは許可されていません。 オブジェクトへの右側の公告によるインターネットアクセスの開会前に、最新の一ヶ月に注意する登録機関。 また、§35第6項、文2が適用されます。

データの転送抗告は、フォームに必要事項を記入して可能性があります。 デュッセルドルフでは、これはここにある： https://formulare.duesseldorf.de/forms/frm/7PRPfAZH5gQA8Ja8AkNGaH1rNpDcHR3これは公共機関で無料で配信することができます。 その後、オンラインアクセスは、より多くのデータを所有することが可能ではありません。 どうやら、それぞれの地方都市や郡のデータ要求が組織した。

私は市民で（非常に友好的）バックオフィスの店員に尋ねたときに、可能性
私は、ポータルクエリのURLを教えて申し訳ありませんでした。 クイック検索は、サイトがデュッセルドルフの街に迅速に私を​​導いた：

https://www.duesseldorf.de/emra/emra.jsp?stadt=D％FCsseldorf＆タイプ=市

ポータルには、少なくとも印象に言っても技術的に非常に疑わしいた。
まず第一に、CAPTCHAまたは与えるに似ては存在しないようです。 グラウンドクエリが適切なスクリプトで可能と思われる。

私はクッキーを有効にしていなかったので加えて、WebアプリケーションはTomcatのエラーメッセージが表示されて私のテストクエリによって承認された。

私はこれを読んだ後ますます街が提供するすべての市民のデータへのアクセスを提供するアプリケーションのプロ意識を疑う。 条件がユーザーのマシン（この例では、クッキーの私の欠如）に存在しない場合、スクリプトはクラッシュしないようにしてください。 無効化しないように生産に使用しているWebサーバーからスクリプトのエラーメッセージが過失がある 、それが使用されているシステム環境について多くのことを明らかにすることができますので。 つのJSP（上記スクリーンショットのように）、サーバの構成に応じて、特にするときにもプログラマとQuelltextschnippselのコメントは得られます。 ここでずさんな仕事でした。 個人データへのインタフェースで起こるべきではありません。

私が座っているし、また、以下のエラーメッセージに表示されるTomcatのバージョンを使用してみましょう。 （ApacheのTomcat/6.0.24）これは、21/01/2010のWebサーバの旧バージョンです。 現在のバージョンは6.0.33です。 サーバーは、長いバージョンが更新されていない4つのレジスタを持っています。 この最新バージョンで修正された脆弱性を見れば、それが不快になってきている。 サーバーは、最良の状態で明らかにではありません。

 http://tomcat.apache.org/security-6.html 8月18日リリースのApache Tomcat 6.0.33で修正された、2011中（Moderate）：HTTPダイジェスト認証CVE-2011から1184に複数の弱点HTTPダイジェスト認証の実装はいくつか持っているのを発見しました弱点：リプレイ攻撃が許可されたサーバの一回だけがチェックされていないクライアントにnonce数はQOP値がレルムの値は、サーバーの秘密は、これらの弱点の結果がその唯一のものDIGEST認証などの既知の文字列にハードコーディングされたチェックされていないがチェックされませんでしたがチェックされませんでしたBASIC認証と固定します。 これは改訂第百十五万八千百八十で修正されました これは2011年3月16日に、Tomcatのセキュリティチームによって識別され、2011年9月26日に公開されました。 影響を与えます。6.0.0-6.0.32低い：情報開示のCVE-2011から2204のメモリのユーザーデータベース（tomcat-users.xmlに基づく）を使用してJMXを経由してユーザーを作成する場合、ユーザー作成プロセス中に例外がでエラーメッセージを引き起こす可能性がありますユーザーのパスワードが含まれていますJMXクライアント。 このエラーメッセージは、Tomcatのログに書き込まれます。 ユーザーのパスワードはtomcat-users.xmlファイルに読み取りアクセス権を持つJMXアクセスおよび/または管理者と管理者に表示されます。 ているこれらのユーザーは、権限を持っていますが、ログファイルを読むことができますユーザーのパスワードを発見することができるかもしれないわけではありません。 これは、リビジョン1140071番目で修正されました これは2011年6月14日にポリーナジェノバによって識別され、6月2011th 27日に公開されました 影響を与えます。6.0.0-6.0.32低い：情報開示CVE-2011から2526のTomcatは、HTTP、4月のNIO HTTPコネクタを備えたsendfileのサポートを提供します。 はsendfileが自動的にデフォルトサーブレットを経由して提供し、展開されたコンテンツに使用されるアプリケーションは、要求属性を設定してWeb経由でそれを直接使用することができます。 これらの属性は、要求を検証していませんでした。 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.