nicht angemeldet dedlfix
Gunnar Bittersmann
dedlfix
dedlfix
Matthias Apsel
dedlfix
Rolf B
Moin,
weil meine Programme zu lange durchlaufen, erfasse ich Durchlaufzeiten.
Was normalerweise unter 1 s läuft, lief mit diesem QUERY_STRING 88 s
Tabellenkalk
MudGuardORT=9628&KM=259&lg=en+AND+1=2+UNION+SELECT+0x6461726b31636f6465,0x6461726b32636f6465,0x6461726b33636f6465,0x6461726b34636f6465,0x6461726b35636f6465,0x6461726b36636f6465,0x6461726b37636f6465,0x6461726b38636f6465,0x6461726b39636f6465,0x6461726b3130636f6465,0x6461726b3131636f6465,0x6461726b3132636f6465,0x6461726b3133636f6465--
Wer weiss, was das ist?
Tja. Das ist definitiv ein (wohl ziemlich häufiger) Angriffsversuch.
Google mal danach…
Server prüft jetzt die Länge des QUERY_STRING. Was über 50 ist, wird nicht beantwortet.
Mal schauen, ob das für legale Aufrufe reicht.
Gruß Linuchs
Server prüft jetzt die Länge des QUERY_STRING. Was über 50 ist, wird nicht beantwortet.
Nein. Du bist auf der sicheren Seite, wenn Du via HTTP übergebene Werte tatsächlich nur als Werte (nicht auch: Schlüsselwörter) in einer Abfrage verwendest. Erwartest Du eine Zahl dann stelle sicher, dass Du eine übergibst und behandle Strings wie vorgesehen.
Server prüft jetzt die Länge des QUERY_STRING. Was über 50 ist, wird nicht beantwortet.
Ganz schlechter Plan. Besser ist es, die Parameter zu prüfen. Der Parser erzeugt:
Array
(
[ORT] => 9628
[KM] => 259
[lg] => en AND 1=2 UNION SELECT 0x6461726b31636f6465,0x64..
)
Und Dein Programm macht was? Richtig, es prüft, ob derjenige Parameter gesetzt ist, welcher die Aktion "Datenbankabfrage" veranlasst. Welcher Parameter soll das sein, ORT, KM, lg???
Wahrscheinlich eher nicht und schon ist die Frage, was mit dem Request passieren soll beantwortet: weg damit.
Außerdem musst Du damit rechnen das solche unbekannten Parameter auch per POST oder PUT reinkommen können.
MfG
Tach!
Server prüft jetzt die Länge des QUERY_STRING. Was über 50 ist, wird nicht beantwortet.
Ganz schlechter Plan. Besser ist es, die Parameter zu prüfen. Der Parser erzeugt:
Array ( [ORT] => 9628 [KM] => 259 [lg] => en AND 1=2 UNION SELECT 0x6461726b31636f6465,0x64.. )Und Dein Programm macht was? Richtig, es prüft, ob derjenige Parameter gesetzt ist, welcher die Aktion "Datenbankabfrage" veranlasst. Welcher Parameter soll das sein, ORT, KM, lg???
Wahrscheinlich eher nicht und schon ist die Frage, was mit dem Request passieren soll beantwortet: weg damit.
lg wie in language klingt nach einem möglichen Parameter für die Datenbankabfrage. Auch die beiden anderen Parameter klingen in dem Kontext dessen, was Linuchs entwickelt, nach gültigen Parametern. Das Verwerfen von Anfragen mit unbekannten Parameteren kann also nicht die alleinige Lösung sein, weil dann immer noch die Aufrufe mit gültigen Parametern durchkommen, die Angriffsversuche enthalten können. Solange man seine Daten stets kontextgerecht ausgibt/verwendet, hat man zwar vielleicht Müll irgendwo stehen, der aber nichts ausführen kann, weil er als harmlose Zeichen maskiert wurde. Kontextgerechte Behandlung ist in jedem Fall notwendig, auch harmlose Eingaben können Sonderzeichen enthalten, die zumindest zu Syntaxfehlern führen, wenn man sie nicht richtig behandelt.
Außerdem musst Du damit rechnen das solche unbekannten Parameter auch per POST oder PUT reinkommen können.
Was ignoriert wird kann keinen Schaden anrichten. Da man für den Rest sowieso kontextgerechte Behandlung benötigt, braucht man im Prinzip keine weitere spezielle Abwehrmaßnahme gegen Injectionversuche. Eingabemüll aus der Datenbank löschen muss generell, das hat nichts mit der Art des Angriffs zu tun.
Unabhängig von dieser Betrachtung kann man zusätzlich gezielte Gegenmaßnahmen für bestimmte Angriffsmuster einbauen, das aber lediglich mit dem Ziel, weniger Müllbereinigung durchführen zu müssen, oder das System zu entlasten, indem man ihm unerwünschte Abfragen erspart.
Eine generelle Längenbegrenzung für den Querystring halte ich aber auch nicht unbedingt für eine allgemein gute Lösung. Da muss man schon seine Anwendung gut genug kennen, um nicht doch irgendwelche Kollateralschäden mit dieser Maßnahme zu erzeugen. Besser fände ich, die erwarteten Parameter auf fachlich gültige Inhalte zu prüfen. Wenn zu, Beispiel das Sprachkürzel immer zwei Zeichen lang ist, könnte man das prüfen, oder auch gegen eine Liste der gültigen Werte.
dedlfix.
@@dedlfix
Wenn zu, Beispiel das Sprachkürzel immer zwei Zeichen lang ist
Falsche Annahmen sind falsch.
LLAP 🖖
Tach!
Wenn zu, Beispiel das Sprachkürzel immer zwei Zeichen lang ist
Falsche Annahmen sind falsch.
Bezogen auf den Kontext der Anwendung. Dass es anderswo andere Sprachkürzel gibt, ist für die Aussage nicht grundsätzlich relevant und muss auch erst dann berücksichtigt werden, wenn diese anderen Sprachangaben verwendet werden.
dedlfix.
@@dedlfix
… muss auch erst dann berücksichtigt werden, wenn diese anderen Sprachangaben verwendet werden.
Das ist das Gegenteil von Internationalisierung.
LLAP 🖖
Tach!
… muss auch erst dann berücksichtigt werden, wenn diese anderen Sprachangaben verwendet werden.
Das ist das Gegenteil von Internationalisierung.
Und weiter? Ich kann das Problem nicht erkennen, das du da zu sehen scheinst. Wenn die Anwendung in 5 Sprachen daherkommt, die alle mit zweistelligen Sprachkürzeln gekennzeichnet sind, was für ein Problem gibt es denn dann, andere Sprachen und deren Kürzel(länge) unberücksichtigt zu lassen?
dedlfix.
@@dedlfix
Das ist das Gegenteil von Internationalisierung.
Und weiter? Ich kann das Problem nicht erkennen, das du da zu sehen scheinst. Wenn die Anwendung in 5 Sprachen daherkommt, die alle mit zweistelligen Sprachkürzeln gekennzeichnet sind, was für ein Problem gibt es denn dann, andere Sprachen und deren Kürzel(länge) unberücksichtigt zu lassen?
Dann konntest du wohl auch das Y2K-Problem nicht erkennen‽ Wenn die Anwendung mit zweistelligen Jahreszahlen daherkommt, was für ein Problem gibt es denn dann?
LLAP 🖖
Tach!
Das ist das Gegenteil von Internationalisierung.
Und weiter? Ich kann das Problem nicht erkennen, das du da zu sehen scheinst. Wenn die Anwendung in 5 Sprachen daherkommt, die alle mit zweistelligen Sprachkürzeln gekennzeichnet sind, was für ein Problem gibt es denn dann, andere Sprachen und deren Kürzel(länge) unberücksichtigt zu lassen?
Dann konntest du wohl auch das Y2K-Problem nicht erkennen‽ Wenn die Anwendung mit zweistelligen Jahreszahlen daherkommt, was für ein Problem gibt es denn dann?
Doch, das ist ja ein konkretes Problem der Anwendung beim Jahrhundertwechsel, zumindest wenn man mit den Jahreszahlen rechnet oder Vergleiche anstellt. Aber ich sehe den Zusammenhang nicht. Der OP wird ja wohl nicht mit den Sprachkürzeln rechnen wollen oder andererseits die Länge von Jahreszahlen für eine Entscheidung heranziehen.
dedlfix.
@@dedlfix
Das ist das Gegenteil von Internationalisierung.
Und weiter? Ich kann das Problem nicht erkennen, das du da zu sehen scheinst. Wenn die Anwendung in 5 Sprachen daherkommt, die alle mit zweistelligen Sprachkürzeln gekennzeichnet sind, was für ein Problem gibt es denn dann, andere Sprachen und deren Kürzel(länge) unberücksichtigt zu lassen?
Dann konntest du wohl auch das Y2K-Problem nicht erkennen‽ Wenn die Anwendung mit zweistelligen Jahreszahlen daherkommt, was für ein Problem gibt es denn dann?
Doch, das ist ja ein konkretes Problem der Anwendung beim Jahrhundertwechsel, zumindest wenn man mit den Jahreszahlen rechnet oder Vergleiche anstellt. Aber ich sehe den Zusammenhang nicht. Der OP wird ja wohl nicht mit den Sprachkürzeln rechnen wollen oder andererseits die Länge von Jahreszahlen für eine Entscheidung heranziehen.
Die Annahme, 2 Zeichen würden für Sprachkürzel reichen, ist genauso trügerisch wie die Annahme, 2 Zeichen würden für Jahreszahlen reichen. Früher oder später wird sie sich als falsch erweisen.
BTW, auch die Annahme, 3 Zeichen würden für Sprachkürzel reichen, ist trügerisch.
LLAP 🖖
Tach!
Die Annahme, 2 Zeichen würden für Sprachkürzel reichen, ist genauso trügerisch wie die Annahme, 2 Zeichen würden für Jahreszahlen reichen. Früher oder später wird sie sich als falsch erweisen.
Dann wird man früher oder später Anpassungen am Programm vornehmen. Meine Aussage war nur ein Beispiel für eine Längenprüfung. Dass es dabei um Sprachkürzel ging, war mehr oder weniger irrelevant. Natürlich muss man das an die Gegebenheiten der jeweils zu verarbeitenden Daten anpassen. Eine längenunabhängige Lösung, wenn dafür aber die Liste der erlaubten Werte bekannt ist, hab ich ja auch angeführt.
dedlfix.
@@dedlfix
Die Annahme, 2 Zeichen würden für Sprachkürzel reichen, ist genauso trügerisch wie die Annahme, 2 Zeichen würden für Jahreszahlen reichen. Früher oder später wird sie sich als falsch erweisen.
Dann wird man früher oder später Anpassungen am Programm vornehmen.
„Vornehmen“ ist hier wohl ein Euphemismus‽
Internationalisierung bedeutet, die technischen Voraussetzungen zu schaffen, damit Lokalisierung möglich ist – ohne nachträgliche Anpassungen.
LLAP 🖖
Hallo Gunnar,
reicht nicht - warum? ISO 639-3 ist 3-stellig und hat noch viel Luft.
Wenn Du auf „de-DE“ Bezug nimmst, das ist mMn kein Sprachkürzel, sondern ein locale - also Sprache + Anwendungsraum.
Update: Hätte wohl mal erst besser alles gelesen. Portugiesisch in den Varianten Portugal und Brasilien wird vom ISO nicht unterschieden. Grmpf
Rolf
Hallo Gunnar Bittersmann,
… muss auch erst dann berücksichtigt werden, wenn diese anderen Sprachangaben verwendet werden.
Das ist das Gegenteil von Internationalisierung.
Ein Entwickler, der intern mit drei Sprachen arbeitet, kann diese für sich mit Kürzeln seiner Wahl bezeichnen. d wie deutsch, e wie englisch, f wie französisch. Wenn dann schweizerdeutsch und schwedisch hinzukommen, muss sich der Entwickler intern was neues überlegen.
Der Unterschied zwischen intern und Internationalisierung ist größer als der zwischen Java und JavaScript.
Bis demnächst
Matthias
@@Matthias Apsel
Ein Entwickler, der intern mit drei Sprachen arbeitet, kann diese für sich mit Kürzeln seiner Wahl bezeichnen. d wie deutsch, e wie englisch, f wie französisch.
dedlfix mag da nickend zustimmen: „Kann man so machen.“
Aber nur ein dummer Entwickler wird das tun.
Schon ein mittelmäßig begabter Entwickler wird bestehende Standards verwenden.
Der Unterschied zwischen intern und Internationalisierung ist größer als der zwischen Java und JavaScript.
Du sagst es. Intern – Eigenbrödelei; Internationalisierung – Standards verwenden.
LLAP 🖖
@@Matthias Apsel
d wie deutsch, e wie englisch, f wie französisch. Wenn dann schweizerdeutsch und schwedisch hinzukommen, muss sich der Entwickler intern was neues überlegen.
s wie schweizerdeutsch, s wie … – oh, s ist ja schon vergeben. Na dann nehmen wir halt q wie schwedisch!
LLAP 🖖
Hallo Gunnar Bittersmann,
s wie schweizerdeutsch, s wie … – oh, s ist ja schon vergeben. Na dann nehmen wir halt q wie schwedisch!
c wie Confoederatio Helvetica, s wie schwedisch. 😝
Bis demnächst
Matthias
@@Matthias Apsel
s wie schweizerdeutsch, s wie … – oh, s ist ja schon vergeben. Na dann nehmen wir halt q wie schwedisch!
c wie Confoederatio Helvetica, s wie schwedisch. 😝
Nein, c wie schweizerdeutsch wäre vorausschauend, dass man s ja später für was anderes gebrauchen könnte. Und vorausschauen wollen wir ja nicht!
LLAP 🖖
@@Gunnar Bittersmann
Die Bewertungsfunktion ist buggy. Sie erkennt offensichtliche Ironie nicht. Und sie überhäuft Unsinn wie „kann diese für sich mit Kürzeln seiner Wahl bezeichnen. d wie deutsch, e wie englisch, f wie französisch“ mit Pluspunkten.
LLAP 🖖
Hallo Gunnar Bittersmann,
Die Bewertungsfunktion ist buggy. Sie erkennt offensichtliche Ironie nicht.
In diesem Fall stimme ich dir zu.
Und sie überhäuft Unsinn wie „kann diese für sich mit Kürzeln seiner Wahl bezeichnen. d wie deutsch, e wie englisch, f wie französisch“ mit Pluspunkten.
Ich sage ja nicht, dass man das so machen soll. Aber nicht alles, was man besser machen kann, ist automatisch Unsinn.
Bis demnächst
Matthias
Hallo,
Die Bewertungsfunktion ist buggy. Sie erkennt offensichtliche Ironie nicht.
Das stimmt nicht. Mindestens die Hälfte meiner Punkte hab ich für offensichtliche Ironie erhalten…
Gruß
Kalk
Hallo Gunnar Bittersmann,
c wie Confoederatio Helvetica, s wie schwedisch. 😝
Nein, c wie schweizerdeutsch wäre vorausschauend, dass man s ja später für was anderes gebrauchen könnte. Und vorausschauen wollen wir ja nicht!
schwedisch war zuerst da. 😝
Aber mit finnisch gabs dann ein Problem: f geht nicht und s wie Suomi auch nicht mehr.
Bis demnächst
Matthias
Hi,
Aber mit finnisch gabs dann ein Problem: f geht nicht und s wie Suomi auch nicht mehr.
für Finnisch kann man ja ä nehmen. Das wird im Finnischen besonders oft benutzt (ich hab ne Kollegin aus Finnland, der Nachname hat 6 Buchstaben, nur der 1. und der 4. sind KEIN ä)
cu,
Andreas a/k/a MudGuard
@@MudGuard
für Finnisch kann man ja ä nehmen. Das wird im Finnischen besonders oft benutzt
Für Hindi kann man ja ॐ nehmen. Das wird im Hindi besonders oft benutzt. Ommm…
LLAP 🖖
hallo
… muss auch erst dann berücksichtigt werden, wenn diese anderen Sprachangaben verwendet werden.
Das ist das Gegenteil von Internationalisierung.
Und ich frage mich, was Sprachkürzel mit Internationalisierung zu tun hat. Ich sollte wohl meine Sprache mit CH-de angeben, wenns wirklich darum geht Rechtszuständigkeiten anzugeben.
Ein Entwickler, der intern mit drei Sprachen arbeitet, kann diese für sich mit Kürzeln seiner Wahl bezeichnen. d wie deutsch, e wie englisch, f wie französisch. Wenn dann schweizerdeutsch und schwedisch hinzukommen, muss sich der Entwickler intern was neues überlegen.
Normalerweise haben wir es im Web damit zu tun, dass User bei bestehenden Alternativen die für sie beste Sprach-Version wählen können. Hierbei können Browser konfiguriert werden, die Präferenzen anzugeben und Browser bedienen sich hier in der Tat eines Standards, der allein Sprachgruppen bezeichnet, ohne dass darüber hinaus irgendetwas bezüglich ihrem locale ausgesagt werden kann oder soll.
Bei einem Betriebssystem ist das anders. Da erwarte ich dass das System als GANZES konsequent einem locale zuzuordnen ist.
Tach!
Und ich frage mich, was Sprachkürzel mit Internationalisierung zu tun hat.
Jetzt wo du es sagst, fällt mir das auch auf. Internationalisierung ist eigentlich genausowenig ein zutreffender Begriff, wenn es darum geht, Anwendungen für den Umgang mit mehreren Sprachen zu befähigen, wie Länderflaggen bei Sprachen. Nationen lassen sich schließlich nicht 1:1 auf Sprachen abbilden. Oder spricht man beispielsweise in der Schweiz, ohne ins Grübeln zu kommen, von Internationalisierung, wenn man eine Anwendung für die Verwendung der 4 Amtssprachen befähigt?
dedlfix.
Oder spricht man beispielsweise in der Schweiz, ohne ins Grübeln zu kommen, von Internationalisierung, wenn man eine Anwendung für die Verwendung der 4 Amtssprachen befähigt?
dedlfix.
Ich kann dich beruhigen. Wir sprechen da noch nicht mal von Foederalisierung sondern von Lernplätzen.
@@dedlfix
Internationalisierung ist eigentlich genausowenig ein zutreffender Begriff, wenn es darum geht, Anwendungen für den Umgang mit mehreren Sprachen zu befähigen
Internationalisierung ist genau der richtige Begriff, wenn es darum geht, Anwendungen für den Umgang mit mehreren Sprachen zu befähigen.
Wobei Sprache natürlich nur ein Aspekt von Internationalisierung ist. Es geht auch darum, Anwendungen für den Umgang mit mehreren Datumsformaten zu befähigen. Und Währungen. Und Rechtsgrundlagen. Und wenn wir von Webseiten und Software mal wegkommen und allgemeiner denken, auch verschiedene Stromnetze. Rechts- oder Linksverkehr.
Nationen lassen sich schließlich nicht 1:1 auf Sprachen abbilden. Oder spricht man beispielsweise in der Schweiz, ohne ins Grübeln zu kommen, von Internationalisierung, wenn man eine Anwendung für die Verwendung der 4 Amtssprachen befähigt?
Sicher tut man das. Liegt hier eine Unklarheit vor, was der Begriff Internationalisierung bedeutet?
Zuvor sagtest du noch völlig richtig, dass Nationen und Sprachen verschiedene Dinge sind, um gleich danach die Viersprachigkeit einer Anwendung auf die Nation Schweiz zu begrenzen?
LLAP 🖖
hallo
Internationalisierung ist genau der richtige Begriff, wenn es darum geht, Anwendungen für den Umgang mit mehreren Sprachen zu befähigen.
jaja, es heisst intercode, nicht unicode.
Sprache ist Glücksache.
Tach!
Internationalisierung ist eigentlich genausowenig ein zutreffender Begriff, wenn es darum geht, Anwendungen für den Umgang mit mehreren Sprachen zu befähigen
Internationalisierung ist genau der richtige Begriff, wenn es darum geht, Anwendungen für den Umgang mit mehreren Sprachen zu befähigen.
Mir ist schon klar, dass sich dieser Begriff für genau das Thema etabliert hat. Das stelle ich nicht grundsätzlich infrage. Ich habe ihn nur mal wörtlich auseinandergenommen. Inter = zwischen und -isierung = in einen bestimmten Zustand bringen, also: zwischen Nationen in einen Zustand bringen. (Oder so ähnlich, bin kein Sprachwissenschaftler.) Was hat es mit "zwischen" und Nation zu tun, wenn man etwas für mehrere Sprachen (und weitere damit zusammenhängende Dinge) erstellt?
Wobei Sprache natürlich nur ein Aspekt von Internationalisierung ist. Es geht auch darum, Anwendungen für den Umgang mit mehreren Datumsformaten zu befähigen. Und Währungen. Und Rechtsgrundlagen. Und wenn wir von Webseiten und Software mal wegkommen und allgemeiner denken, auch verschiedene Stromnetze. Rechts- oder Linksverkehr.
Das ist alles klar, nur wo ist da der Bezug zu Nationen, der es rein sprachlich rechtfertigen würde, von "etwas zwischen Nationen zu bringen" zu sprechen?
Nationen lassen sich schließlich nicht 1:1 auf Sprachen abbilden. Oder spricht man beispielsweise in der Schweiz, ohne ins Grübeln zu kommen, von Internationalisierung, wenn man eine Anwendung für die Verwendung der 4 Amtssprachen befähigt?
Sicher tut man das. Liegt hier eine Unklarheit vor, was der Begriff Internationalisierung bedeutet?
Ja. Wenn man die Schweiz als eine Nation betrachtet, wo ist da das "zwischen"?
Zuvor sagtest du noch völlig richtig, dass Nationen und Sprachen verschiedene Dinge sind, um gleich danach die Viersprachigkeit einer Anwendung auf die Nation Schweiz zu begrenzen?
Schon wieder eine pauschalisierende Unterstellung. Das war ein Beispiel, keine Aussage, die eine uneingeschränkte allgemeine Gültigkeit haben sollte.
dedlfix.
hallo
Mir ist schon klar, dass sich dieser Begriff für genau das Thema etabliert hat. Das stelle ich nicht grundsätzlich infrage.
Auf den User bezogen sollten wir von Individualisierung sprechen; auf die Website bezogen von Universalisierung ihrer Methoden.
In der Praxis interessiert die Eigenart des Users, nicht die seines Wohnsitzes. Wenn wir Inhalte besser zugänglich machen wollen, dann sprechen wir von Accessibility.
Es haben sich durchaus nebst der Internationalisierung andere Begriffe etabliert. Nur leidet Sprach-Versionierung tatsächlich von einer falschen Assoziation.
Aber das kann man ja korrigieren, wenn man nur beharrlich genug darauf verweist.
@@beatovich
Auf den User bezogen sollten wir von Individualisierung sprechen;
Damit meinst du wohl Lokalisierung.
(Mir ist bewusst, dass der Begriff im Deutschen doppeldeutig ist. Lokalisierung ist hier nicht im Sinne von Ortung gebraucht.)
auf die Website bezogen von Universalisierung ihrer Methoden.
Damit meinst du wohl Internationalisierung.
Wenn wir Inhalte besser zugänglich machen wollen, dann sprechen wir von Accessibility.
Der Begriff bezeichnet die Zugänglichkeit für Menschen mit körperlichen oder geistigen Einschränkungen.
andere Begriffe […] Aber das kann man ja korrigieren, wenn man nur beharrlich genug darauf verweist.
Du willst jetzt aber nicht den Hotti machen und Begriffe mit einer allgemeinhin verwendeten Bedeutung mit deiner eigenen Bedeutung versehen und für diese Bedeutung eigene Begriffe einführen?
LLAP 🖖
hallo
Auf den User bezogen sollten wir von Individualisierung sprechen;
Damit meinst du wohl Lokalisierung.
Nein!
(Mir ist bewusst, dass der Begriff im Deutschen doppeldeutig ist. Lokalisierung ist hier nicht im Sinne von Ortung gebraucht.)
auf die Website bezogen von Universalisierung ihrer Methoden.
Damit meinst du wohl Internationalisierung.
Nein!
Wenn wir Inhalte besser zugänglich machen wollen, dann sprechen wir von Accessibility.
Der Begriff bezeichnet die Zugänglichkeit für Menschen mit körperlichen oder geistigen Einschränkungen.
Nein!
@@beatovich
Nein! Nein! Nein!
Sondern? Sondern? Sondern?
LLAP 🖖
@@beatovich
Und ich frage mich, was Sprachkürzel mit Internationalisierung zu tun hat.
Sprache ist ein Aspekt von Internationalisierung.
Es macht keinen Sinn, Sprachen in verschiedenen Anwendungen anders zu bezeichnen, bspw. Deutsch mal Deutsch, mal German, mal d. Sinvoll ist, immer dieselben Bezeichner zu verwenden – die standardisierten [BCP47, IANA], für Deutsch also de.
Ich sollte wohl meine Sprache mit CH-de angeben
Andersrum: de-CH.
Die Abgrenzung kann sinnvoll sein, denn in der Schweiz gelten ja andere orthographische (kein ß) und typographische Regeln (Anführungszeichen andersrum: «» wie im Französischen, nur ohne Leerraum).
Die Unterschiedung von de-DE und de-AT hingegen ist kaum sinnvoll.
LLAP 🖖
hallo
@@beatovich
Sprache ist ein Aspekt von Internationalisierung.
Sprache ist ein Aspekt des Menschen. Egal wo dieser sich gerade befindet!
Als solches gehört die Sprachbehandlung in die Accessibility.
@@beatovich
Als solches gehört die Sprachbehandlung in die Accessibility.
Is’ ja gut, Hotti. 😈
LLAP 🖖
Tach!
Mensch Gunnar, jetzt lass doch mal die Standardisierungsgeschichte außen vor und versuch zu verstehen, was die eigentliche Aussage ist.
Ich sollte wohl meine Sprache mit CH-de angeben
Andersrum:
de-CH.
Wenn du den wichtigsten Teil der Aussage rauskürzt, ist es auch sinnlos darauf zu antworten. Nochmal der Satz in voller Schönheit:
Ich sollte wohl meine Sprache mit CH-de angeben, wenns wirklich darum geht Rechtszuständigkeiten anzugeben.
So wie ich das verstanden habe, wollte er nicht zum Ausdruck bringen, dass er Deutsch mit schweizer Ausprägung spricht, sondern ein Schweizer ist, der Deutsch spricht. Die Zugehörigkeit zu einem Land stand bei der Aussage im Vordergrund, nicht die Zugehörigkeit zu einer Sprache und auch nicht die korrekte Auszeichnung derselben nach irgendeinem Standard.
Themenwechsel.
Es macht keinen Sinn, Sprachen in verschiedenen Anwendungen anders zu bezeichnen, bspw. Deutsch mal
Deutsch, malGerman, mald. Sinvoll ist, immer dieselben Bezeichner zu verwenden – die standardisierten [BCP47, IANA], für Deutsch alsode.
Ein Sinn muss sich für mich nicht lediglich aus einer Standardkonformität und daraus folgender Einheitlichkeit ergeben. Vielmehr sehe ich es so, dass dazu vorrangig die Gegebenheiten des Anwendungsfalles zu berücksichtigen sind.
Es ist sehr wohl sinnvoll, auch in neu zu schreibenden Programmen, Kürzel wie DEU und ENU oder Werte wie 0x0407 und 0x0409 zu verwenden, wenn der Anwendungsfall ist, mit Systemen zusammenzuarbeiten, die diese Kürzel/Werte bereits verwenden. Ich sehe es eher als nicht sinnvoll an, in solch einem Fall auf (anderen) Standards zu bestehen und dann im Programm sowie gedanklich ständig zwischen den Systemen hin- und herzukonvertieren, solange sich die Notwendigkeit der Verwendung dieses Standards nicht aus Aspekten des Anwendungsfalls selbst ergibt. Da hilft dann auch kein Blick in die Zukunft, wenn der Blick in die Vergangenheit sagt, dass der Hersteller des Systems wohl kaum an der Stelle irgendwelche Änderungen einbringt, die außer Inkompatibilitäten zwischen Datenbeständen und ungerechtfertigtem Umstellungsaufwand beim Anwender keinen Vorteil versprechen.
dedlfix.
@@dedlfix
So wie ich das verstanden habe, wollte er nicht zum Ausdruck bringen, dass er Deutsch mit schweizer Ausprägung spricht, sondern ein Schweizer ist, der Deutsch spricht.
Das wäre dann eher nicht CH-de, sondern sowas wie { "nationality": "CH", "speaks": ["de"] }
Es ist sehr wohl sinnvoll, auch in neu zu schreibenden Programmen, Kürzel wie DEU und ENU oder Werte wie 0x0407 und 0x0409 zu verwenden, wenn der Anwendungsfall ist, mit Systemen zusammenzuarbeiten, die diese Kürzel/Werte bereits verwenden. Ich sehe es eher als nicht sinnvoll an, in solch einem Fall auf (anderen) Standards zu bestehen und dann im Programm sowie gedanklich ständig zwischen den Systemen hin- und herzukonvertieren, solange sich die Notwendigkeit der Verwendung dieses Standards nicht aus Aspekten des Anwendungsfalls selbst ergibt.
Es scheint ein beliebtes Spiel von dir zu werden, dir zu allem, was ich allegemeingültig nenne, ein Gegenbeispiel auszudenken. Nur ist das desöfteren nicht bis zu Ende gedacht.
Die Notwendigkeit der Verwendung der standardisierten Sprachkennzeichnungen ergibt sich hier (wir reden von einer Webanwendung, nicht wahr?) aus Aspekten des Anwendungsfalls selbst. Die Sprachkennzeichnungen de, en-US usw. sind erforderlich für die Angabe im lang-Attribut.
In dem Fall würde ich anwendungsintern die standardisierten Sprachkennzeichnungen verwenden – das gibt besser lesbaren Code. Die Umwandlung in anderswo verwendete Kürzel/Werte erfolgt bei der Übergabe an jene Teile der Anwendung, wo die anderen Kürzel/Werte verwendet werden. Kontextwechsel – genau dann, wenn nötig, nicht früher.
LLAP 🖖
Tach!
Es ist sehr wohl sinnvoll, auch in neu zu schreibenden Programmen, Kürzel wie DEU und ENU oder Werte wie 0x0407 und 0x0409 zu verwenden, wenn der Anwendungsfall ist, mit Systemen zusammenzuarbeiten, die diese Kürzel/Werte bereits verwenden. Ich sehe es eher als nicht sinnvoll an, in solch einem Fall auf (anderen) Standards zu bestehen und dann im Programm sowie gedanklich ständig zwischen den Systemen hin- und herzukonvertieren, solange sich die Notwendigkeit der Verwendung dieses Standards nicht aus Aspekten des Anwendungsfalls selbst ergibt.
Es scheint ein beliebtes Spiel von dir zu werden, dir zu allem, was ich allegemeingültig nenne, ein Gegenbeispiel auszudenken. Nur ist das desöfteren nicht bis zu Ende gedacht.
Es scheint ein beliebtes Spiel zu sein, dass du dir Dinge als allgemeingültig ausmalst, die so aber nicht sind. Zudem denke ich mir das nicht aus, sondern erlebe sie in der Form in der Praxis. Und es ist mir auch klar, dass du das nicht bis zu Ende denken kannst, weil dir die Fakten dazu fehlen.
Die Notwendigkeit der Verwendung der standardisierten Sprachkennzeichnungen ergibt sich hier (wir reden von einer Webanwendung, nicht wahr?) aus Aspekten des Anwendungsfalls selbst. Die Sprachkennzeichnungen
de,en-USusw. sind erforderlich für die Angabe imlang-Attribut.
Nein, wir reden nicht von einer Webanwendung. Deine Argumentation war ja allgemeingültig, nicht aufs Web beschränkt. In diesem Beispiel bezog ich mich auf Dynamics NAV, ein sogenanntes ERP-System. Hat auch im Laufe seiner Entwicklung einen Webclient spendiert bekommen, der spielt aber eigentlich keine große Rolle (bei den Anwendern, die ich kenne). Die meisten Anwender nehmen das Desktop-Programm. Wenn er jedoch eingesetzt wird, ist es firmenintern und kein öffentlicher Crawler oder Besucher hat diesen Intranet-Seiten einen Besuch abzustatten. Selbst wenn ein Admin so leichtfertig ist, der ERP-Anwendung uneingeschränkten Internetzugang zu gewähren, kommt der normale Besucher/Crawler nicht weiter als bis zur Anmeldeseite. Der Anwenderkreis ist genau vorherbestimmt und auch durch die Anzahl der erworbenen Lizenzen eingeschränkt. Also ist es auch egal, ob da für das Web standardisierte lang-Attribute vorhanden sind oder nicht. Lediglich die Mitarbeiter müssen damit umgehen können. Die Sprache für den Anwender wird traditionell über einen Dialog in der Anwendung eingestellt. Da muss der Webclient auch keine Extrawurst mit Language-Negotiation kochen für einen unscheinbaren Komfortvorteil. Es geht ja nicht darum, möglichst viele Besucher anzulocken, sondern die Mitarbeiter müssen ihre Arbeit erledigen können. Und das ist hier vollumfänglich gegeben durch die Spracheinstellung in der Anwendung.
In dem Fall würde ich anwendungsintern die standardisierten Sprachkennzeichnungen verwenden – das gibt besser lesbaren Code. Die Umwandlung in anderswo verwendete Kürzel/Werte erfolgt bei der Übergabe an jene Teile der Anwendung, wo die anderen Kürzel/Werte verwendet werden. Kontextwechsel – genau dann, wenn nötig, nicht früher.
Wenn nötig. Das ist der Punkt, an dem du dir eine andere Meinung bildest, obwohl du das System nicht kennst. Nötig ist es erst dann, wenn man zum Beispiel eine öffentlich erreichbare Website erstellen möchte, die auf die Daten des ERP-Systems zugreift, beispielsweise einen Shop. Erst dann beim Übergang zu diesem Shop ist es nötig, eine Übersetzung der Kürzel vorzunehmen. Vielleicht auch erst, wenn man die View erstellt. Das zu beurteilen hängt vom Shop ab, den man da verwendet oder erstellt. Programme und Plugins hingegen, die nur mit dem ERP-System arbeiten und keine Schnittstelle nach anderswo bedienen müssen, brauchen keine Übersetzung. Da hat es mehr Nachteile als Nutzen. Jeder Code kann potentiell Fehler enthalten. Code, den man nicht schreiben muss, hat dieses Potential nicht. Warum sollte ich mir Fehlerpotential ins Programm einbauen, für einen nicht vorhandenen Nutzen?
dedlfix.
@@dedlfix
Nein, wir reden nicht von einer Webanwendung.
Doch, das tun wir.
Im Stein des Anstoßes: „Querystring“, „POST“, „PUT“. Webanwendung.
Im SELFHTML-Forum geht es üblicherweise um Webanwendungen. Wenn nicht, dann ist das gesondert zu erwähnen.
Wenn ich was allgemein zu Webanwendungen sage, kommst du mit Gegenbeispielen, die mit Webanwendungen nichts zu tun haben? Böses Foul.
LLAP 🖖
Hi,
Die Abgrenzung kann sinnvoll sein, denn in der Schweiz gelten ja andere orthographische (kein ß) [...] Die Unterschiedung von
de-DEundde-AThingegen ist kaum sinnvoll.
Wieso nicht? Auch hier gibt es ortographische Unterschiede (z.B. Geschoss -> Geschoß[1]). Und wenn man Karfiol, Fisolen, Marillen usw. schreibt statt Blumenkohl, Bohnen, Aprikosen usw., rechtfertigt das nicht de-AT?
cu,
Andreas a/k/a MudGuard
Danke, Rechtschreibdeform (früher war's einheitlich, weil damals zwei s in einer Silbe zum ß wurden, jetzt hängt's von der Aussprache ab) ↩︎
@@MudGuard
Die Unterschiedung von
de-DEundde-AThingegen ist kaum sinnvoll.Wieso nicht?
Die Unterschiede innerhalb Deutschlands (innelhalb von de-DE) sind wohl größer als die Unterschiede zwischen Süddeutschland und Österreich (zwischen de-DE und de-AT).
Auch hier gibt es ortographische Unterschiede (z.B. Geschoss -> Geschoß).
Sowas gibt’s auch innerhalb Deutschlands, z.B. gucken vs. kucken.
Und wenn man Karfiol, Fisolen, Marillen usw. schreibt statt Blumenkohl, Bohnen, Aprikosen usw., rechtfertigt das nicht de-AT?
Nicht unbedingt. Verschiedene Wörter für ein Ding gibt’s auch innerhalb von de-DE. Mohrrübe vs. Möhre. Es gibt sogar Leute, die Karotte sagen (seltsame Marotte).
LLAP 🖖
hallo
Die Abgrenzung kann sinnvoll sein, denn in der Schweiz gelten ja andere orthographische (kein ß) [...] Die Unterschiedung von
de-DEundde-AThingegen ist kaum sinnvoll.
Wieso nicht? Auch hier gibt es ortographische Unterschiede (z.B. Geschoss -> Geschoß[^1]). Und wenn man Karfiol, Fisolen, Marillen usw. schreibt statt Blumenkohl, Bohnen, Aprikosen usw., rechtfertigt das nicht de-AT?
IANA-Sprachkürzel bezeichnen Sprechergruppen, nicht Wörterbücher, Orthographie- oder Sortierregeln. Dass man mit CSS Anführungszeichen oder anderes gestalten kann, ist eines der irrelevanten Details. Dass Sortieralgorithmen darauf reagieren, ein anderes.
Hallo Gunnar,
Die Unterschiedung von de-DE und de-AT hingegen ist kaum sinnvoll.
lass uns das im nächsten Jänner bei einem Karfiol-Auflauf und Topfenstrudel mit Marillen zum Nachtisch nochmal diskutieren, vielleicht beim Apsel Matthias (wobei - die Namensstellung könnte auch bar-DE/bar-AT sein) 😉
de-DE und de-AT sind nicht so verschieden wie en-GB und en-US, aber es ist doch vorhanden.
Update - Argh, dieser Thread ist zu lang; dass dieser Nachklapperer schon lief hatte ich nicht gesehen.
Rolf
hi
lg wie in language klingt nach einem möglichen Parameter für die Datenbankabfrage. Auch die beiden anderen Parameter klingen in dem Kontext dessen, was Linuchs entwickelt, nach gültigen Parametern. Das Verwerfen von Anfragen mit unbekannten Parameteren kann also nicht die alleinige Lösung sein, weil dann immer noch die Aufrufe mit gültigen Parametern durchkommen,
Um solche Dinge in den Griff zu bekommen, hat es sich bewährt, sog. Schlüsselparameter (Aktionparameter) von denjenigen Parametern zu trennen welche die für den Request benötigten Daten transportieren. Und da haben wir wieder das leidige Thema einer Parameterkontrollstruktur die an sich so einfach zu realisieren ist:
if(Parameter für DB Abfrage){
Nimm die restlichen Parameter die dazugehören
Prüfe die übergebenen Daten
Maskiere unsichere Zeichen
Execute SQL
Response
}
elsif(Parameter für etwas Anderes){
Tu dies und gib Response aus
}
else{
Bad Request
}
Aus dieser Kontrollstruktur fällt schon mal ne Menge raus was unsinnig ist und auf gar keinen Fall ist es dann noch möglich, daß ein Request mit bestimmten Parametern lange Antwortzeiten braucht oder gar den Server lahmlegt.
Also ich hätte schon gerne gewusst, was fürn Code zu solch Verhalten führt wie beschrieben.
Du weißt es auch nicht oder?
MfG
Tach!
Um solche Dinge in den Griff zu bekommen, hat es sich bewährt, sog. Schlüsselparameter (Aktionparameter) von denjenigen Parametern zu trennen welche die für den Request benötigten Daten transportieren.
Eben nicht, hier war ja nicht das Problem, dass unerwartete Parameter ankamen, sondern das in einem erwarteten ein unerwarteter Inhalt war.
Und da haben wir wieder das leidige Thema einer Parameterkontrollstruktur die an sich so einfach zu realisieren ist:
Für mich ist es eher das leidige Thema selbsterfundener Begrifflichkeiten. Wenn du damit Code meinst, der lediglich auf die Existenz bestimmter Parameter prüft, löst der das Problem mit dem unerwünschten Inhalt jedenfalls nicht.
Aus dieser Kontrollstruktur fällt schon mal ne Menge raus was unsinnig ist und auf gar keinen Fall ist es dann noch möglich, daß ein Request mit bestimmten Parametern lange Antwortzeiten braucht oder gar den Server lahmlegt.
Na das halte ich für eine sehr gewagte Aussage.
Also ich hätte schon gerne gewusst, was fürn Code zu solch Verhalten führt wie beschrieben.
Du weißt es auch nicht oder?
Ich kenne seine Anwendung nicht, nein. Ein simples UNION SELECT x,y,z wie im gezeigten Code sollte jedenfalls keine auffallend längere Laufzeit ergeben. Zumindest falls das als Code interpretiert wird. Bei ordentlicher Maskierung ist es ja lediglich ein etwas längerer String als 'en'. Da müsste dann schon ein Index auf dem Feld fehlen und ein Full-Table-Scan in einer Tabelle mit vielen Datensätzen ausgeführt werden, beispielsweise. Andere Stellen im Script können ebenfalls Ursache sein. Profiling müsste man da mal ansetzen. Es kann aber auch Zufall sein, dass gerade dieser Request auffällt, weil vielleicht grad ein Backup oder ähnlicher ressourcenbeanspruchender Prozess lief und den Rest vom System generell ausgebremst hat. Auch Suchmaschinen-Crawler können zu Lastproblemen führen. Die großen halten ja Abstand zwischen den Requests, aber sie sprechen sich auch nicht untereinander ab und belasten dann das System gleichzeitig. Ganz zu schweigen von den Kandidaten, die ohne Pause feuern.
Abgesehen davon würden mich soche Anfragen nicht weiter stören, solange sie ihr Ziel nicht erreichen und das System nicht dauerhaft auslasten.
dedlfix.
Tach!
Du weißt es auch nicht oder?
Ich kenne seine Anwendung nicht, nein. Ein simples
UNION SELECT x,y,zwie im gezeigten Code sollte jedenfalls keine auffallend längere Laufzeit ergeben.
Und das ist das nächste Problem: Ein SQL Statement über HTTP zu schleifen ist geradezu idiotisch. Tut mir leid für diesen Fachbegriff aber besser kann man das nicht ausdrücken.
MfG
Tach!
Und das ist das nächste Problem: Ein SQL Statement über HTTP zu schleifen ist geradezu idiotisch. Tut mir leid für diesen Fachbegriff aber besser kann man das nicht ausdrücken.
Es handelte sich dabei um einen augenscheinlichen Angriff, keine reguläre Verwendung. Geplant war wohl nur das en zu übertragen. Und solche Parameter zwischen Client und Server zu transportieren ist alles andere als ungewöhnlich.
dedlfix.
Tach!
Und das ist das nächste Problem: Ein SQL Statement über HTTP zu schleifen ist geradezu idiotisch. Tut mir leid für diesen Fachbegriff aber besser kann man das nicht ausdrücken.
Es handelte sich dabei um einen augenscheinlichen Angriff, keine reguläre Verwendung.
Genau!
Geplant war wohl nur das
enzu übertragen. Und solche Parameter zwischen Client und Server zu transportieren ist alles andere als ungewöhnlich.
Ja sicher doch und genau das sollte und kann man prüfen und wie das geht hab ich doch beschrieben: Über eine Parameterkontrollstruktur.
Auch wenn das jetzt nicht ein Fachbegriff sein sollte der 100%ig auf irgendwelche IT-Doktorarbeiten passen muss, ist es doch im Kontext klar worum es geht.
Und das heißt eben daß ein per HTTP eingereichtes Statement schon aus der Kontrollstruktur herausfallen muss und gar nicht erst am DB-Server ankommen darf. Vielmehr muss das Statement auf dem Server liegen und wird allenfalls mit Platzhaltern gefüttert die diesem Kontext entsprechend geprüft und behandelt wurden.
MfG
Tach!
Und das heißt eben daß ein per HTTP eingereichtes Statement schon aus der Kontrollstruktur herausfallen muss und gar nicht erst am DB-Server ankommen darf.
Das würde bedeuten, dass man erst noch einen SQL-Parser schreiben müsste, um den ankommenden Wert als SQL-Statement-Teil zu erkennen. Das wäre zu viel Aufwand.
Für mich gibt es zwei generelle Lösungswege. Der eine wäre das Prüfen der Parameter auf fachlich gültige Werte. Das geht bei Sprachen und anderen Arten von Daten noch recht gut, wenn diese in der Anwendung einen festgelegten Werteumfang haben, gegen den man prüfen kann. Musterprüfungen und Prüfungen auf Datentyp oder andere konkret formulierbare Kriterien sind da inbegriffen. Bei freien Eingaben, zum Beispiel wenn nach beliebigen Suchbegriffen gesucht werden können soll, kann man eine Prüfung nur beschränkt vornehmen, wenn überhaupt. Da bleibt dann als zweite Variante, dass man sich nur auf die korrekte Maskierung (oder Prepared Statement) verlässt. Die Abfrage wird dann syntaktisch einwandfrei durchlaufen und nur kein (gescheites) Ergebnis liefern. Aber daran war der Angreifer ja sowieso nicht interessiert.
Vielmehr muss das Statement auf dem Server liegen und wird allenfalls mit Platzhaltern gefüttert die diesem Kontext entsprechend geprüft und behandelt wurden.
Ja, so war das ja auch vorgesehen. Angriffe halten sich aber nicht daran und probieren es trotzdem mit Statementbestandteilen über reguläre Parameter.
dedlfix.
Tach!
Und das heißt eben daß ein per HTTP eingereichtes Statement schon aus der Kontrollstruktur herausfallen muss und gar nicht erst am DB-Server ankommen darf.
Das würde bedeuten, dass man erst noch einen SQL-Parser schreiben müsste, um den ankommenden Wert als SQL-Statement-Teil zu erkennen. Das wäre zu viel Aufwand.
Unsinn. Den Parameter Sprachen zu prüfen beschränkt sich auf einen String. Und mit Sicherheit ist die Anzahl der Sprachen nicht unendlich groß. Und mit den anderen Parametern verhält es sich ganz ähnlich.
Vielmehr muss das Statement auf dem Server liegen und wird allenfalls mit Platzhaltern gefüttert die diesem Kontext entsprechend geprüft und behandelt wurden.
Ja, so war das ja auch vorgesehen. Angriffe halten sich aber nicht daran und probieren es trotzdem mit Statementbestandteilen über reguläre Parameter.
Eben. Und genau dagegen kann man was tun: Stichwort SQL Injektion, prepared Statements.
MfG
Tach!
Was ignoriert wird kann keinen Schaden anrichten.
Fataler Trugschluss! Auf jeden Fall sollte man die Länge eines Request message Body grundsätzlich immer prüfen und auf einen sinnvollen Wert begrenzen. Unabhängig davon ob die Anwendung nur mit GET Parametern arbeitet und idealerweise für jede Seite einzeln konfigurierbar.
MfG
Was ignoriert wird kann keinen Schaden anrichten.
Nun ja... Stellt sich die Frage, ob man nicht auf offensichtliche Angriffsversuche (es kann hier übrigens auch eine DDOS-Attacke vorliegen) reagieren sollte, in dem man die IP des Angreifers eine Weile lang sperrt.
Immerhin muss ein solcher dann erst mal eine Stunde warten oder die IP (oder den Tor-Exit) wechseln.
Sowas geht mit fail2ban und einem Eintrag im z.B. Error-Log, der ja durch PHP leicht zu bewältigen ist. Verwaltet man nicht den Server, dann schiebt man eben etwas wie:
# 2017-04-14 10:54
Require not ip 10.252.46.165
in die .htaccess. Und löscht immer mal.
Tach!
Was ignoriert wird kann keinen Schaden anrichten.
Nun ja... Stellt sich die Frage, ob man nicht auf offensichtliche Angriffsversuche (es kann hier übrigens auch eine DDOS-Attacke vorliegen) reagieren sollte, in dem man die IP des Angreifers eine Weile lang sperrt.
Das habe ich im weiteren Verlauf der Antwort angedeutet, dass man solcherart Maßnahmen ergreifen kann. Aus Sicht der Anwendung jedenfalls schadet ein ignorierter Parameter nicht. Dass der Server ihn nicht ignoriert, sondern ihn zum Client durchzustellen versucht, ist ein Problem des Servers. Wenn ich den Parameter erst innerhalb der Anwendung registriere, wurde bereits auf dem Server sinnlose Arbeit verrichtet.
Ob es Aufgabe der Anwendung ist, bei derartigen Angriffen ins System zu greifen, um eine Fail2ban-Sperre oder dergleichen einzulegen, darf hinterfragt werden. Fail2ban kann das jedenfalls auch selbständig durch entsprechend konfigurierte Logfile-Analyse. Ein Kompromiss wäre, dass die Anwendung ein Audit-Log oder ähnliches führt, das dann vom Fail2ban ausgewertet wird. Damit trennt man die Zuständigkeiten und kann das Wissen der Anwendung über erlaubte und nicht erlaubte Inhalte oder Zugriffe nutzen.
dedlfix.
Fail2ban kann das jedenfalls auch selbständig durch entsprechend konfigurierte Logfile-Analyse. Ein Kompromiss wäre, dass die Anwendung ein Audit-Log oder ähnliches führt, das dann vom Fail2ban ausgewertet wird.
Einfach das error-Log missbrauchen:
<?php
error_log ("mutmasslicher angriff:sql-injection");
Resultierender Eintrag:
[Sat Apr 14 12:44:12.611511 2018] [:error] [pid 25477] [client 77.178.32.244:34114] mutmasslicher angriff:sql-injection, referer: https://home.fastix.org/Tests/
Der passende Regex für apache-overflows.conf wäre dann wie folgt hinzuzufügen: (ungetestet)
failregex = ^%(_apache_error_client)s ((AH0013[456]: )[…]
^%(_apache_error_client)s .*mutmasslicher angriff.*$
Außerdem ist apache-overflows in der jail.conf zu aktivieren und das Limit für die Duldung recht gering anzusetzen:
[apache-overflows]
enabled = true
port = 0:65535
# während der Testphase:
# port = http,https
logpath = %(apache_error_log)s
maxretry = 1
bantime = 36000
Wenn zum Beispiel das Sprachkürzel immer zwei Zeichen lang ist, könnte man das prüfen, oder auch gegen eine Liste der gültigen Werte.
Sprachkürzel werden nach ISO bis zu drei Stellen erwartet, z.B. nds (plattdeutsch, eher als Gag).
Bei mehr als drei Stellen kommt eine Fehlermeldung wie lg=[spanisch] too long, Verarbeitung startet nicht.
Linuchs
Hallo Linuchs,
z.B. nds (plattdeutsch, eher als Gag).
Europäische Charta der Regional- oder Minderheitensprachen
Bis demnächst
Matthias
Hallo Matthias,
wieso die Minusbewertung mit dem Verweis auf die Charta?
ISO 639-6 (4-stellige Kürzel) ist zurückgezogen worden, die übrigen ISOs sind 2- und 3-stellig. ISO 639-3 kann über 17000 Sprachen codieren und nutzt lt. Wikipedia derzeit um die 6000 Codes. Ebenfalls laut Wikipedia gibt es derzeit zwischen 2000 und 8000 Einzelsprachen.
Der von Dir verlinkten Wikiartikel verweist auf einige Sprachen der EU-Charta, dort war aber jeweils ein 3-stelliger ISO-Code hinterlegt. Diese Sprachen sind also erfasst.
Angesichts der wegen Globalisierung eher abnehmenden Zahl von Sprachen sollte ISO 639-3 eigentlich noch einige Zeit reichen; und wenn Sprachen wie Arkonidisch oder Wookie mal relevant werden, wird ISO 639 eh gegen irgend ein GOO[1] oder IRR[2] ausgetauscht, die in 37-bittigem Galacode geschlüsselt wird. Bis dahin fließen noch viele Sonnenwinde die Galaxis entlang. Und tlh ist ja eh schon im ISO 639-3 drin, das wäre eine der wichtigeren extraterrestrischen Sprachen.
Update: Vermutlich habe ich mich da verrannt - siehe mein Update bei Gunnar...
Rolf
Hallo Rolf B,
wieso die Minusbewertung mit dem Verweis auf die Charta?
wegen „plattdeutsch, eher als Gag“
Bis demnächst
Matthias
Tach!
Wenn zum Beispiel das Sprachkürzel immer zwei Zeichen lang ist, könnte man das prüfen, oder auch gegen eine Liste der gültigen Werte.
Sprachkürzel werden nach ISO bis zu drei Stellen erwartet, z.B. nds (plattdeutsch, eher als Gag).
Es ging mir nicht um die konkrete Länge von Sprachkürzeln. Das war nur ein Beispiel, wie man Daten testen kann. Was und wie du es konkret testen kannst, musst du anhand deiner konkreten Situation entscheiden. Es ist ja nicht nur der Sprachkürzel-Parameter, der missbraucht werden wird.
dedlfix.
@@Linuchs
Sprachkürzel werden nach ISO bis zu drei Stellen erwartet, z.B. nds (plattdeutsch, eher als Gag).
Drei Stellen reichen nicht, wie ich schon sagte. Denn hier geht’s eigentlich nicht um Sprachkürzel (language subtags) wie ich den Begriff in Zweibuchstabige oder dreibuchstabige Sprachcodes verwendet habe, sondern um Sprachkennzeichnungen (language tags).
Man will bspw. portugiesisches pt-PT von brasilianischem Portugiesisch pt-BR unterscheiden können. Und Chinesisch in traditioneller zh-Hant und in vereinfachter Schreibweise zh-Hans.
LLAP 🖖
Tach!
Drei Stellen reichen nicht, [...]
Man will bspw. portugiesisches
pt-PTvon brasilianischem Portugiesischpt-BRunterscheiden können. Und Chinesisch in traditionellerzh-Hantund in vereinfachter Schreibweisezh-Hans.
Was "man" will, ist nicht relevant. In der konkreten Anwendung geht es darum, was die konkrete Anwendung braucht. Diese Ansprüche und Anforderungen müssen nicht unbedingt mit denen der Ersteller der Spachkürzellisten übereinstimmen. Man kann sich ruhig am Wertebereich dieser Listen orientieren. Dies nicht zu tun, führt aber nicht zwangsläufig zu Problemen im konkreten Fall. So empfinde ich zumindest immer diese Art deiner Argumentation: Wenn man nicht jede kleinste Kleinigkeit beachtet, die es in irgendeiner Ecke auf der Rückseite des Mondes gibt, bekommt man ein komplett unbrauchbares Ergebnis. Punkt. Argumente sind zwecklos, keine Kompromisse.
dedlfix.
@@dedlfix
Was "man" will, ist nicht relevant. In der konkreten Anwendung geht es darum, was die konkrete Anwendung braucht.
Und was die konkrete Anwendung zukünftig braucht.
Man kann sich ruhig am Wertebereich dieser Listen orientieren. Dies nicht zu tun, führt aber nicht zwangsläufig zu Problemen im konkreten Fall.
Mit „im konkreten Fall“ meinst du in der Vergangenheit und in der Gegenwart. Du verschließt den Blick vor der Zukunft.
Man kann bei der Softwareentwicklung leichtfertig von Annahmen ausgehen und Entscheidungen treffen, die die Erweiterbarkeit des Systems unmöglich machen.
Oder man kann vorausschauend denken.
So empfinde ich zumindest immer diese Art deiner Argumentation: Wenn man nicht jede kleinste Kleinigkeit beachtet, die es in irgendeiner Ecke auf der Rückseite des Mondes gibt
Du gleitest in Polemik ab.
Argumente sind zwecklos, keine Kompromisse.
Argumente?
Die Diskussion dreht sich darum, dass ich sage, dass es unklug ist, die Sprachkennzeichnung auf 2 Zeichen zu beschränken. Hast du irgendein Argument vorgebracht, dass diese Beschränkung klug wäre?
Also was ist dein Punkt?
LLAP 🖖
Hallo Gunnar Bittersmann,
Die Diskussion dreht sich darum, dass ich sage, dass es unklug ist, die Sprachkennzeichnung auf 2 Zeichen zu beschränken. Hast du irgendein Argument vorgebracht, dass diese Beschränkung klug wäre?
Es ist unstrittig, dass es besser wäre, die Sprachkennzeichnung nicht auf zwei Zeichen zu beschränken. Und jeder, der jetzt mit der Entwicklung einer solchen Software beginnt und diesen Thread kennt, wäre gut beraten, dies zu beachten.
Es ist aber nicht zwingend notwendig, das zu tun.
Mögliche Szenarien hast du geschildert. Ob und mit welcher Wahrscheinlichkeit sie eintreten werden, muss der Entwickler prüfen und danach unter Berücksichtigung des Aufwandes entscheiden, ob er die Software dahingehend updaten möchte.
Bis demnächst
Matthias
Tach!
Was "man" will, ist nicht relevant. In der konkreten Anwendung geht es darum, was die konkrete Anwendung braucht. Und was die konkrete Anwendung zukünftig braucht.
Ach, woher nimmst du das Wissen über die Zukunft dieser Anwendung? Weißt du das generell zu jeder Anwendung? Besteht die Möglichkeit, dass du mich in das konkrete Wissen über die Zukunft einweihst? Oder wie man solche Aussagen ohne den Gebrauch des Konjunktivs treffen kann, ohne dass Zweifel an ihrem Wahrheitsgehalt auftreten können? OK, den letzten Punkt kann ich streichen, denn das ist dir in diesem Satz jedenfalls mir gegenüber nicht gelungen. Ernst beiseite.
Mit „im konkreten Fall“ meinst du in der Vergangenheit und in der Gegenwart. Du verschließt den Blick vor der Zukunft.
Nein, das meine ich nicht. Ich sehe es nicht als meine Aufgabe oder Kompetenz an, über konkrete Fälle, die ich nicht weiter kenne, Aussagen über deren Vergangenheit, Gegenwart oder gar Zukunft treffen zu können. Für den konkreten fall muss dessen Inhaber die Entscheidungen treffen. Ich mache mir nur nicht zu viele Gedanken, über Eier, die vorraussichtlich oder möglicherweise nie gelegt werden, noch dazu in Projekten, in die ich keinen Einblick habe. Damit verschließe ich aus meiner Sichtweise nicht die Augen, sondern ich treffe lediglich keine konkreten aber pauschalen Aussagen zu einer mir nicht bekannten Zukunft einer mir nicht bekannten Anwendung.
Man kann bei der Softwareentwicklung leichtfertig von Annahmen ausgehen und Entscheidungen treffen, die die Erweiterbarkeit des Systems unmöglich machen.
Das kann durchaus sein. Diese Unmöglichkeit trifft aber nicht auf alle Projekte zu. Projekte sind nicht per se nicht mehr änderbar, wenn man heute die Zukunft nicht zu voller Gänze voraussagen kann. Dass man für die Zukunft plant, heißt auch nicht pauschal, dass man nichts mehr ändern oder korrigieren muss, wenn es denn mal soweit sein sollte. Es ist eigentlich nur eine Frage des Aufwands, und vor allem ob der Aufwand heute sein soll und sich vielleicht nie rentiert, oder ob man ihn zur gegebenen Zeit auf sich nimmt. Die Entscheidung darüber kann man auch nicht pauschal treffen, schon gar nicht als Außenstehender.
Die Diskussion dreht sich darum, dass ich sage, dass es unklug ist, die Sprachkennzeichnung auf 2 Zeichen zu beschränken. Hast du irgendein Argument vorgebracht, dass diese Beschränkung klug wäre?
Hab ich nicht. Ob oder welche konkrete Beschränkung für die Länge von Sprachkennzeichnungen sinnvoll ist, war auch gar nicht mein Thema, zu dem ich mich äußern wollte. Weder in irgendeiner Allgemeinheit noch im konkreten Fall.
Also was ist dein Punkt?
Mein Punkt ist, dass du mal wieder kompromisslos über einen nebensächlichen Punkt diskutierst, und aus meiner Sicht keine andere Meinung gelten lässt. Es hat dich anscheinend noch nicht einmal interessiert, was ich konkret aussagen wollte. Stattdessen reitest du anscheinend unbeirrt auf der Zahl 2 herum.
dedlfix.
@@dedlfix
Ernst beiseite.
OK, Polemik beiseite. Geschenkt.
Ich sehe es nicht als meine Aufgabe oder Kompetenz an, über konkrete Fälle, die ich nicht weiter kenne, Aussagen über deren Vergangenheit, Gegenwart oder gar Zukunft treffen zu können.
Du siehst es nicht als deine Zufgabe an, vorausschauend zu denken?
keine konkreten aber pauschalen Aussagen zu einer mir nicht bekannten Zukunft einer mir nicht bekannten Anwendung.
Für Standards wie Sprachkennzeichnungen muss man nicht eine spezielle Anwendung kennen. Die gelten allgemein. Deshalb sind es ja Standards.
(Und zu den allgemein gültigen Dingen gehört auch, bestehende Standards zu verwenden.)
Dass man für die Zukunft plant, heißt auch nicht pauschal, dass man nichts mehr ändern oder korrigieren muss, wenn es denn mal soweit sein sollte. Es ist eigentlich nur eine Frage des Aufwands, und vor allem ob der Aufwand heute sein soll und sich vielleicht nie rentiert, oder ob man ihn zur gegebenen Zeit auf sich nimmt.
Ja-ha.
Der Aufwand, mal kurz nachzudenken und für Sprachkennzeichnungen von vornherein eine variable Länge vorzusehen: so gut wie null.
Der Aufwand, die Fehlentscheidung einer auf 2 Zeichen begrenzten Sprachkennzeichnung später zu korrigieren: erheblich größer.
Ob oder welche konkrete Beschränkung für die Länge von Sprachkennzeichnungen sinnvoll ist, war auch gar nicht mein Thema, zu dem ich mich äußern wollte.
Was tust du seit heute Morgen?
Mein Punkt ist, dass du mal wieder kompromisslos über einen nebensächlichen Punkt diskutierst, und aus meiner Sicht keine andere Meinung gelten lässt.
Ich lasse immer andere Meinungen gelten, wenn sie denn durch Argumente begründet sind.
Es hat dich anscheinend noch nicht einmal interessiert, was ich konkret aussagen wollte.
Ich konnte deinen Postings nur entnehmen, dass man ohne genaue Kenntnis einer konkreten Anwendung nicht entscheiden kann, ob es sinnvoll ist, allgemeingültige Standards zu verwenden.
Und dies halte ich für falsch. Ich sage: doch, das kann man entscheiden.
Stattdessen reitest du anscheinend unbeirrt auf der Zahl 2 herum.
?? Nein. Ich wollte die Zahl 2 von Anfang an loswerden.
LLAP 🖖
Hallo Gunnar Bittersmann,
Der Aufwand, mal kurz nachzudenken und für Sprachkennzeichnungen von vornherein eine variable Länge vorzusehen: so gut wie null.
Richtig. Genau das ist aber vor n Jahren, als die Software entstand, nicht geschehen. Das kann man dem Entickler heute nicht zum Vorwurf machen.
Bis demnächst
Matthias
Tach!
Ich sehe es nicht als meine Aufgabe oder Kompetenz an, über konkrete Fälle, die ich nicht weiter kenne, Aussagen über deren Vergangenheit, Gegenwart oder gar Zukunft treffen zu können.
Du siehst es nicht als deine Zufgabe an, vorausschauend zu denken?
Das empfinde ich als sinnentstellend gekürzt. Aber wenn du so willst, stimmt es trotzdem. Niemand gab mir eine solche Aufgabe, mich eingeschlossen, schon gar nicht für Fälle, die ich nicht beurteilen kann.
keine konkreten aber pauschalen Aussagen zu einer mir nicht bekannten Zukunft einer mir nicht bekannten Anwendung.
Für Standards wie Sprachkennzeichnungen muss man nicht eine spezielle Anwendung kennen. Die gelten allgemein. Deshalb sind es ja Standards.
Diese Aussage kann ich nicht nachvollziehen. Standards haben nicht per se Gesetzescharackter (weder juristisch noch physikalisch) und gelten schon in diesem Sinne nicht überall. Wenn eine Anwendung einen Standard, aus welchen Gründen auch immer, nicht berücksichtigt, gilt für sie auch nicht dessen Inhalt. Außerdem gibt es sich widersprechende oder gegenseitig ausschließende Standards.
Davon unabhängig ist die Frage, ob es für die eine oder andere Lebenslage günstig ist, sich an bestimmte Standards zu halten. Eine Verpflichtung oder eine unumgängliche Notwendigkeit für konkrete Fälle ergibt sich daraus jedoch für mich nicht.
(Und zu den allgemein gültigen Dingen gehört auch, bestehende Standards zu verwenden.)
Nö, das ist schon physikalisch unmöglich (zum Beispiel bei sich ausschließenden Standards), sich allgemein, also ohne Berücksichtigung der konkreten Umstände, an bestehende Standards zu halten. Oder welche Bedeutung haben in deinem Fall die Wörter allgmein und gültig?
Der Aufwand, mal kurz nachzudenken und für Sprachkennzeichnungen von vornherein eine variable Länge vorzusehen: so gut wie null.
Ja, mach doch, mein Thema war nur nicht korrekte Sprachauszeichnung.
Der Aufwand, die Fehlentscheidung einer auf 2 Zeichen begrenzten Sprachkennzeichnung später zu korrigieren: erheblich größer.
Auf welche Fakten stützt sich diese Aussage? Im konkreten Fall kann ich lediglich für die Prüfung der Eingabedaten in einem Beispiel sprechen. Da wäre die Änderung von 2 auf 3 oder noch etwas mehr vorzunehmen. Das ist jetzt nicht gerade erheblicher Aufwand. Und auch nur dann, wenn man den ersten Teil mit der sowieso schon nicht alle ungewollten Eingaben ausschließenden Längenprüfung als gegeben annimmt und nicht die Alternative mit der Whitelist. Worauf also beziehst du dich?
Ob oder welche konkrete Beschränkung für die Länge von Sprachkennzeichnungen sinnvoll ist, war auch gar nicht mein Thema, zu dem ich mich äußern wollte.
Was tust du seit heute Morgen?
"Det jeht dir 'n …dreck an", würde ein mir bekannter Berliner auf eine solche Frage antworten. Abgesehen davon stimmt es weiterhin, dass ich beim Verfassen meiner ersten Antwort diesen Punkt nicht als Thema hatte.
Ich lasse immer andere Meinungen gelten, wenn sie denn durch Argumente begründet sind.
Sehr schöne Einschränkung. Man muss nur für sich definieren, dass etwas kein Argument sei, und schon hat sich der erste Teil erledigt.
Es hat dich anscheinend noch nicht einmal interessiert, was ich konkret aussagen wollte.
Ich konnte deinen Postings nur entnehmen, dass man ohne genaue Kenntnis einer konkreten Anwendung nicht entscheiden kann, ob es sinnvoll ist, allgemeingültige Standards zu verwenden.
Da verknüpfst du gerade einen Teil meiner Aussagen mit einem Teil deines Themas. Auf diese Weise habe ich mich aber nicht geäußert.
Und dies halte ich für falsch. Ich sage: doch, das kann man entscheiden.
Das kannst du gern für falsch halten, und wem auch immer widersprechen, das war jedenfalls nicht meine Aussage.
Stattdessen reitest du anscheinend unbeirrt auf der Zahl 2 herum.
?? Nein. Ich wollte die Zahl 2 von Anfang an loswerden.
Ich formuliere anders: Stattdessen reitest du anscheinend unbeirrt wegen einer beispielhaften 2 auf einem anderen Thema herum.
dedlfix.
@@dedlfix
Standards haben nicht per se Gesetzescharackter
Und best practices schon gar nicht. Dennoch sollten man sie i.d.R. befolgen.
Außerdem gibt es sich widersprechende oder gegenseitig ausschließende Standards.
(Quelle: xkcd)
Im Fall Sprachkürzel wurde aber tatsächlich aufgeräumt. Das ist die gute Nachricht.
mein Thema war nur nicht korrekte Sprachauszeichnung […] dass ich beim Verfassen meiner ersten Antwort diesen Punkt nicht als Thema hatte […] das war jedenfalls nicht meine Aussage.
Dann haben wir wohl den ganzen Tag aneinander vorbei geredet. Gute Nacht.
LLAP 🖖
Wenn zum Beispiel das Sprachkürzel immer zwei Zeichen lang ist, könnte man das prüfen, oder auch gegen eine Liste der gültigen Werte.
Sprachkürzel werden nach ISO bis zu drei Stellen erwartet, z.B. nds (plattdeutsch, eher als Gag).
Die Länge ist doch nebensächlich, Leerzeichen und Interpunktionszeichen dürfen nicht. Eine Expression /[-\w]{2,8}/ (unter Vorbehalt) dürfte die Problematik zu diesem Parameter entschärfen und die anderen Parameter haben /^\d+$/ zu genügen.
Dann ist es auch nicht mehr möglich über legacy Parameter ein SQL Statement einzuschleusen.
MfG
Tja. Das ist definitiv ein (wohl ziemlich häufiger) Angriffsversuch, scheinbar ein Defacement. Offenbar will jemand damit eine Datenbankabfrage provozieren, bei welchem alles nach dem UNION SELECT ausgegeben wird.
Google mal danach…
Zu "0x6461726b32636f6465"
64 - d
61 - a
72 - r
6b - k
32 - 2
63 - c
6f - o
64 - d
65 - e
"dark2code"
Ist wohl ein ziemlich dummes Skript-Kid. Allerdings eines, das bei manchen "Webmastern" unerhoffte Erfolge feiert.
Moin,
weil meine Programme zu lange durchlaufen, erfasse ich Durchlaufzeiten.
Was normalerweise unter 1 s läuft, lief mit diesem QUERY_STRING 88 s
Da läuft wohl einiges schief mit Deinen Programmen. Abgesehen von einer derart abartigen Antwortzeit, die wohl primär den Requester betrifft, solltest Du mal schauen was da bei Dir an Prozessen losgetreten wird bzw. was da wirklich passiert. Normal ist das nicht, normal wäre daß bei gleichen Antwortzeiten allenfalls eine Fehlermeldung "Unbekannter Parameter" und ggf. ein Status 400 Bad Request ausgegeben wird.
MfG
Ich habe das mal (nach gründlicher Überlegung) in der Datenbank getestet:
MariaDB [test]> SELECT+0x6461726b31636f6465,[…]0x6461726b3133636f6465--\G
*************************** 1. row ***************************
+0x6461726b31636f6465: dark1code
0x6461726b32636f6465: dark2code
0x6461726b33636f6465: dark3code
0x6461726b34636f6465: dark4code
0x6461726b35636f6465: dark5code
0x6461726b36636f6465: dark6code
0x6461726b37636f6465: dark7code
0x6461726b38636f6465: dark8code
0x6461726b39636f6465: dark9code
0x6461726b3130636f6465: dark10code
0x6461726b3131636f6465: dark11code
0x6461726b3132636f6465: dark12code
0x6461726b3133636f6465: dark13code
1 row in set (0.00 sec)
Das war offenbar ein Test, ob Du die Daten unbehandelt in eine Abfrage übernimmst. (Es scheint sich zu lohnen, das in der Breite zu testen.) Sollte auf der Webseite irgendwo irgendwas mit "/dark[0-9]{1,2}code/" erscheinen (was offenbar das Ziel der Aktion ist), dann würde darauf hin wohl die eigentliche Aktion erfolgen. (Und sei es der Verkauf der Info über die angreifbare Webseite an weitere solche netten Kerlchen.)
Das erklärt aber nicht, warum das 88 Sekunden gedauert haben soll. (Der Test lief trotzdem in einer lahm gemachten virtuellen Maschine...) Das UNION mit dem Subselect hat hier keinerlei weitere signifikante Auswirkung. Gab es parallel etwas wie eine DDoS-Attacke? Selbst ein gleichzeitig laufendes Backup der DB sollte nicht solche drastischen Auswirkungen haben.
Ich nehme ja an, Du hast auf ORT, KM, lg einen Index - Oder?
Tach!
Ich nehme ja an, Du hast auf
ORT,KM,lgeinen Index - Oder?
Wenn nicht, müssten eigentlich auch jede Menge reguläre Anfragen derartige Zeitprobleme bekommen.
dedlfix.
Ich nehme ja an, Du hast auf ORT, KM, lg einen Index - Oder?
Wenn nicht, müssten eigentlich auch jede Menge reguläre Anfragen derartige Zeitprobleme bekommen.
Gerade bei geringen Datenmengen (ein paar hundert oder tausend Datensätze) ist das nicht zwingend. Linuchs schreibt nichts dazu. Die Situation kann sich aber auch bei geringen Datenmengen ändern - wenn der Abfragecache überfordert oder der Server hoch belastet ist.
Ich habe das mal (nach gründlicher Überlegung) in der Datenbank getestet:
Danke.
Ich nehme ja an, Du hast auf
ORT,KM,lgeinen Index - Oder?
Auf ort_id ja. Die KM bedeuten, dass alle Orte mit Veranstaltungen im Umkreis ermittelt werden. KM ist nicht Bestandteil der Datensätze.
Da wird für jeden der ca. 1000 Termine die Entfernung zur ort_id berechnet. Der SELECT enthält die Zeile
,ROUND( 6366.19773095 * ACOS( SIN(".$rad_lat1.") *SIN(RADIANS(ort1.geo_breite)) +COS(".$rad_lat1.") *COS(RADIANS(ort1.geo_breite)) *COS(RADIANS(ort1.geo_laenge) -".$rad_lon1." ))) distanz_km";
sieht kompliziert aus, ergibt aber fast immer einen Durchlauf unter 1 s, siehe unten rechts auf der Seite http://remso.eu/?ORT=7140
Wenn der Parameter KM nicht kommt, wird standardmäßig 20 genommen.
siehe unten rechts auf der Seite http://remso.eu/?ORT=7140
daran habe ich gerade geschraubt, ist jetzt wieder okay.
Linuchs
> ,ROUND( 6366.19773095 * ACOS( SIN(".$rad_lat1.") *SIN(RADIANS(ort1.geo_breite)) +COS(".$rad_lat1.") *COS(RADIANS(ort1.geo_breite)) *COS(RADIANS(ort1.geo_laenge) -".$rad_lon1." ))) distanz_km";
Problem:
Lösung:
$b = floatval($_REQUEST['B']);
$l = floatval($_REQUEST['L']);
$umkreis = round(abs($_REQUEST['umkreis']));
$startTime = microtime(true);
$umkreis_l = $umkreis/71.12;
$umkreis_b = $umkreis/87.27;
$b_max = $b + $umkreis_b;
$b_min = $b - $umkreis_b;
$l_max = $l + $umkreis_l;
$l_min = $l - $umkreis_l;
$counter=0;
sql = "SELECT nr,ort,breite,laenge FROM geo WHERE laenge > \"$l_min \" AND laenge < \"$l_max \" AND breite > \"$b_min \" AND breite < \"$b_max \" order by ort";
include("open.inc.php");
$result = mysqli_query($conn, $sql);
echo mysqli_error($conn)."<br>";
while ($row = mysqli_fetch_assoc($result)) {
$b_diff = 87.27 * abs($b-$row['breite']);
$l_diff = 71.11 * abs($l-$row['laenge']);
$entfernung = round(sqrt( $l_diff * $l_diff + $b_diff * $b_diff));
if ($entfernung <= $umkreis) {
echo "<td><a href=\"ortsinfo.php?nr=".$row['nr']."\">".$row['ort']."</a></td>";
echo "<td>".$row['breite']."</td>";
echo "<td>".$row['laenge']."</td>";
echo "<td>".$entfernung." km</td>";
echo "</tr>\n";
$counter++;
}
}
Das habe ich vor über 10 Jahren mal programmiert (heute würde ich manches besser machen) - es geht aber auch heute richtig schnell:
Tach!
Lösung: Ermittle erst einmal ein Viereck, dann geht die Abfrage mit größer und kleiner (Länge und breite). Schließe dann die Werte, die außerhalb des Kreises liegen innerhalb von php aus.
Man kann statt PHP auch die HAVING-Klausel nehmen. Mit dem WHERE sollte man darauf abzielen, den Index verwenden zu können, um so bereits recht schnell die Menge einzudampfen. Berechnungen mit dem Werten von Feldern sind da also kontraproduktiv, weil das einen Full-Table-Scan benötigt, um die Kandidaten zu ermitteln. Das HAVING macht dann die Feinarbeit an den hoffentlich wenigen Datensätzen des Zwischenergebnisses.
dedlfix.
Man kann statt PHP auch die HAVING-Klausel nehmen.
Ja. Selbst ein AND geht (in SQL):
SELECT … WHERE ( im Viereck )
AND ( im Umkreis )
Wenn im Viereck negativ ausfällt wird im Umkreis gar nicht mehr berechnet…
Hallo Regina Schaukrug,
Wenn
im Vierecknegativ ausfällt wirdim Umkreisgar nicht mehr berechnet…
Ich würde gleich beim Quadrat bleiben. Was schadet es, wenn bei einem angegebenen Umkreis von 100 km auch Veranstaltungen angegeben werden, die 141 km entfernt sind?
Bis demnächst
Matthias
Was schadet es, wenn bei einem angegebenen Umkreis von 100 km auch Veranstaltungen angegeben werden, die 141 km entfernt sind?
Veranstalter 101 km östlich vom Hamburg (deren Events nicht erscheinen) könnten wirre Phantasien entwickeln, weil solche 140 km nordwestlich von Hamburg (deren Events erscheinen) also scheinbar bewusst bevorzugt werden.
Die ziehen dann vor das LG Hamburg…
Hallo Regina Schaukrug,
Veranstalter 101 km östlich vom Hamburg (deren Events nicht erscheinen) könnten wirre Phantasien entwickeln, weil solche 140 km nordwestlich von Hamburg (deren Events erscheinen) also scheinbar bewusst bevorzugt werden.
Ah ja.
Bis demnächst
Matthias
Hallo,
Was schadet es, wenn bei einem angegebenen Umkreis von 100 km auch Veranstaltungen angegeben werden, die 141 km entfernt sind?
Veranstalter 101 km östlich vom Hamburg (deren Events nicht erscheinen) könnten wirre Phantasien entwickeln, weil solche 140 km nordwestlich von Hamburg (deren Events erscheinen) also scheinbar bewusst bevorzugt werden.
Die ziehen dann vor das LG Hamburg…
d.h. man benötigt erstmal alle Ortsumrisse in der Datenbank und muss diese dann entsprechend der Suchentfernung erweitern. Ortslagen sind weder punkt- noch kreisförmig…
Gruß
Kalk
Tach!
d.h. man benötigt erstmal alle Ortsumrisse in der Datenbank und muss diese dann entsprechend der Suchentfernung erweitern. Ortslagen sind weder punkt- noch kreisförmig…
Nicht unbedingt. Es geht ja hier vermutlich um Linuchs' Veranstaltungskalender. Üblicherweise befindet sich der Nutzer an einem konkreten Punkt und die Veranstaltung ebenso, beziehungsweise die konkreten Areale der beiden sind gegenüber einem Punkt vernachlässigbar. Oder anders gesagt, die Umrisse von Gemeinden sind nicht weiter relevant. Voraussetzung ist, dass beide Punkte mit hinreichender Genauigkeit bestimmt sind und nicht zum Beispiel wahllos an einen wie auch immer ermittelten Mittelpunkt eines größeren Gebietes gesetzt werden.
dedlfix.
Ermittle erst einmal ein Viereck
So habe ich mal angefangen mit der ganzen Problematik, wie das Viereck am Äquator und am Pol an den Koordinaten festgemacht wird. Doch diese Entfernungsberechnung geht wirklich überraschend schnell.
Tach!
Doch diese Entfernungsberechnung geht wirklich überraschend schnell.
Immer, auch unter Last? Oder nur, wenn im Labor der Prozessor sowieso nichts zu tun hat und die Daten der Tabelle bereits im Cache liegen?
dedlfix.
und die Daten der Tabelle bereits im Cache liegen?
Es gibt auch einen für die Antworten.
Und gerade der geht, z.B. im Falle einer Attacke mit wechselnden Abfrageparametern in die Knie.
mit der ganzen Problematik, wie das Viereck am Äquator und am Pol an den Koordinaten festgemacht wird
"Deutscheland ist kleines Land. Mit viele Einwohner. Aber kleine Land."
Die "Problematik des Vierecks" ist lediglich "Genauheimerei". Man nehme einfach die Parameter vom Norden (da ist Grad/Kilometer am größten) und lebe damit, dass im Schritt 2 (Kreisberechnung) eben ein paar mehr ausgeschlossen werden müssen.
Hallo Linuchs,
der Injection-Versuch ging doch in den lg Parameter. Wird der denn in der Umkreissuche verwendet?
Kannst Du auf deinem Testsystem die lange Laufzeit nachstellen, wenn du die kritische Abfrage dort anwendest? Welches SQL Statement geht in die Knie - die Umkreissuche oder was anderes? Weißt Du das?
Rolf
hi Nachbar,
hab sowas auch in meinen Logs
"PUT /?ORT=9628&KM=259&lg=en+AND+1=2+UNION+SELECT+0x6461726b31636f6465,0x.. "GET /?ORT=9628&KM=259&lg=en+AND+1=2+UNION+SELECT+0x6461726b31636f6465,0x..
die IP Addr lässt sich zu p4FFE1505.dip0.t-example.com auflösen (Name geändert ab t-). Wird bei mir mit einem Status 400 Bad Request quittiert, ist nicht weiter tragisch.
GGA