it-swarm.com.de

Globale Variablen und Informationssicherheit

Ich habe den Eindruck, dass es eine bewährte Programmiermethode ist, Variablen in bestimmten Bereichen (wie einem Funktionsbereich) zu erstellen und einen globalen Bereich zu vermeiden, um die Dinge modularer und besser organisiert zu machen. Ich bin mir jedoch nicht sicher, ob es auch ein Sicherheitsproblem gibt.

Hier ist ein Beispiel für globale Variablen in Bash, die mehr als ein Jahr für mich funktioniert haben:

cat <<-EOF >> "$HOME"/.profile
    set -x
    complete -r
    export war="/var/www/html" # Web Application Root;
    export dmp="phpminiadmin" # Database Management Program;

    export -f war
    war() {
        cd $war/
    }
EOF

source "$HOME"/.profile 2>/dev/null

Ich hatte noch nie ein Problem mit globalen Variablen in Bash oder JavaScript, höchstwahrscheinlich, weil ich nur kleine Skripte für den persönlichen Gebrauch in minimalistischen Umgebungen geschrieben habe.

Warum vermeiden viele Programmierer die Verwendung globaler Variablen und gibt es Beispiele für Sicherheitsverletzungen, die durch die Verwendung globaler Variablen verursacht werden?

47
user123574

Boykottglobale!

Ich stehle von Steffen Ullrichs Kommentar , aber das Hauptproblem bei globalen Variablen ist, dass sie es schwierig machen, Code gut organisiert und wartbar zu halten. Sein Link ist in Ordnung, aber Sie werden keine Probleme haben, unzählige Artikel über die Probleme mit globalen Variablen online zu finden.

Wenn Sie globale Variablen verwenden, verlieren Sie leicht den Überblick darüber, wo in Ihrem Programm die Variable geändert wird, insbesondere wenn Sie keinen einfachen linearen Fluss haben. Infolgedessen können globale Variablen in kleinen Skripten einwandfrei funktionieren, aber massive Kopfschmerzen verursachen, wenn eine Anwendung zu skalieren beginnt.

Der Hauptgrund, warum ich Globals vermeiden würde, ist, dass sie automatisierte Unit-/Integrationstests zu einem Albtraum machen. Kleine Anwendungen können ohne Tests überleben, aber der Versuch, eine größere Anwendung ohne gute Tests zu verwalten, ist nur ein Albtraum (vertrauen Sie mir, ich habe es in meinen jungen und dummen Tagen versucht).

Dies könnte den Eindruck erwecken, dass Globals in sehr kleinen Anwendungen in Ordnung sind. Da Anwendungen jedoch normalerweise nur mit der Zeit wachsen und Dinge, die vorübergehend beginnen, dauerhaft werden, ist es wirklich nur eine schlechte Idee, sie überhaupt zu verwenden. Warum mit dem falschen Fuß beginnen, wenn es so einfach ist, Variablen mit richtigem Gültigkeitsbereich zu verwenden?

Sicherheit

Die Verwendung globaler Variablen hat keine direkten Auswirkungen auf die Sicherheit, erleichtert jedoch das Auftreten von Sicherheitsproblemen:

Wenn ein Programmierer eine Funktion in der Datei A ändert, aber nicht weiß oder vergisst, dass der Wert für eine bestimmte Variable in dieser Funktion von Benutzereingaben in der Datei B stammt, wird dies möglicherweise unsicher Dinge auf Benutzereingabe ohne angemessene Schutzvorrichtungen.

Globale Variablen == Tod

Ich kenne keine Verstöße, die speziell aufgrund globaler Variablen aufgetreten sind, aber es ist leicht zu argumentieren, dass die Verwendung globaler Variablen hat buchstäblich Menschen getötet , daher halte ich es für vernünftig, sie einfach nie zu verwenden.

78
Conor Mancone

In einigen Programmierumgebungen können Sie dem globalen Bereich nicht vertrauen, da andere Quellen lesen /damit herumspielen könnten.

Dies hat bereits zu einigen kritischen Schwachstellen in sicherheitsrelevanten Produkten geführt, wie z. B. eine Remotecodeausführung in der LastPass-Browsererweiterung .

10
Benoit Esnard

Sie können Code-Injektionen den Zugriff auf alles erleichtern

In PHP gibt es das Superglobal $GLOBALS; In Python gibt es die Funktion globals() und in Javascript gibt es das das Objekt window (oder in Node process). All dies macht es trivial, alle globalen Variablen aufzulisten.

Sobald Sie dies getan haben, können Sie sowohl die darin enthaltenen Informationen heraussaugen als auch sie böswillig ändern. Wenn beispielsweise vertrauliche Daten in einem globalen Speicher gespeichert sind, kann ein Angreifer sie leicht extrahieren . Wenn beispielsweise eine Datenbankverbindungs-URL in einer globalen URL gespeichert ist, kann ein Angreifer auf die URL verweisen, die stattdessen auf den Server des Angreifers verweist, und das Opfer versucht dann, eine Verbindung zu diesem Server herzustellen und Anmeldeinformationen zu senden.

Wenn Sie viele globale Objekte haben, können Sie deren Methoden problemlos aufrufen.

Sie verstoßen gegen das "Prinzip des geringsten Privilegs"

Dieses Prinzip der Sicherheitstechnik besagt im Grunde: "Geben Sie niemandem mehr Zugang, als er für seine Arbeit benötigt." Jede Funktion und Methode kann globale Variablen lesen und schreiben, auch wenn sie für ihren Job völlig irrelevant sind. Wenn dieser Code auch nur in begrenztem Umfang entführt wird, eröffnet sich eine größere Angriffsfläche.

(Natürlich haben die meisten Skriptsprachen schwache Kapselungsregeln, was ebenfalls eine Verletzung von POLP darstellt. Wenn Objekte jedoch außerhalb des Gültigkeitsbereichs liegen, ist es viel schwieriger, ihnen etwas anzutun.)

Sie sind ein Nährboden für Buggy-Code

Aus folgenden Gründen:

  • der Programmierer vergisst, dass eine der Variablen in einer Funktion global ist, und daher bleiben Änderungen daran wird bestehen, wenn die Funktion endet.
  • die nicht offensichtliche Empfindlichkeit des Programms gegenüber der Reihenfolge, in der Funktionen aufgerufen werden
  • die Leichtigkeit, mit der Kaskadenfehler auftreten können (z. B. wenn eine Funktion eine globale auf null setzt und später eine andere abstürzt)
  • die hochkomplexen Wechselwirkungen, die leicht auftreten können und schwer zu begründen sind

Sie sind einfach unordentlich

Wenn Sie an ein Geschäft denken, in dem überall Papiere verstreut sind, die Dinge nicht ordentlich organisiert und abgelegt sind, sondern nur herumliegen, wer wird es bemerken, wenn etwas verloren geht? Wenn ein Mitarbeiter Betrug begeht, wird niemand die Diskrepanz erkennen, da es überall Diskrepanzen gibt. Wenn ein Schlüsselpaar verloren geht, geht jemand einfach davon aus, dass er unter etwas begraben ist oder dass jemand es ausleihen musste.

Nun könnte man sagen, dass dies eine Übertreibung ist, aber wenn ja, bezweifle ich, dass Sie jemals mit einem großen Softwareprojekt gearbeitet haben. Globals sind in Ordnung, wenn Ihre Website klein genug ist, um in ein paar Tagen erstellt zu werden (und Sie wissen, was Sie tun). Sie können Zeit sparen, um etwas in Gang zu bringen.

Aber sie skalieren nicht.

8
Artelius

Bitte vergleichen Sie die folgenden Codeteile:

1)

/file.php:
    $newconn = new PDO('mysql:Host=localhost;charset=utf8mb4;','username','password');

2)

../secrets.php:
    $mysqlusername = 'username';
    $mysqlpassword = 'password';

/file.php:
    require_once('../secrets.php');
    $newconn = new PDO('mysql:Host=localhost;charset=utf8mb4;',$mysqlusername,$mysqlpassword);

3

../secrets.php:
    function pdoconn(i) {
        $mysqlusername = ['username1','username2'];
        $mysqlpassword = ['password1','password2'];
        $conn = new PDO('mysql:Host=localhost;charset=utf8mb4;',$mysqlusername[i],$mysqlpassword[i]);
        return $conn;
    }

/file.php:
    require_once('../secrets.php');
    $newconn = pdoconn(0);

Beispiel 1 kommt nicht in Frage - eine falsche Konfiguration auf Produktionsservern kann dazu führen, dass unbeabsichtigte Parteien vertrauliche Parameter anzeigen.

Beispiel 2 ist besser, aber diese Variablen sind in der gesamten Anwendung verfügbar und können geändert werden, was zu Fehlern führen kann.

Beispiel 3 hält die Dinge sehr organisiert und übertragbar.
Es kann geändert werden, um Globals zu verwenden, wenn ../secrets.php war stattdessen:

../secrets.php:
$mysqlusername = 'username';
$mysqlpassword = 'password';
function pdoconn()  {
    $conn = new
PDO('mysql:Host=localhost;charset=utf8mb4;',$GLOBALS['mysqlusername'],$GLOBALS['mysqlpassword']);
return $conn;
}

Und ich denke, das zeigt, warum ein Global meistens auf prägnante Weise keinen Sinn ergibt.


Zusammenfassung:

In Bezug auf Sicherheitsverletzungen mit globalen Variablen (und warum ich diese Beispiele in PHP geschrieben habe) gab es (zu der Zeit) ein ziemliches kontroverse Änderung in PHP 4.2. Ich kann derzeit keine Artikel finden, da diese Änderung im Jahr 2002 vorgenommen wurde, aber ich erinnere mich an die Tatsache, dass sie zu diesem Zeitpunkt für einige Verstöße verantwortlich war. Es gibt eine direkte Kopie aus dem Handbuch Ein sehr klares Beispiel für anfälligen Code:

<?php
// define $authorized = true only if user is authenticated
if (authenticated_user()) {
    $authorized = true;
}

// Because we didn't first initialize $authorized as false, this might be
// defined through register_globals, like from GET auth.php?authorized=1
// So, anyone can be seen as authenticated!
if ($authorized) {
    include "/highly/sensitive/data.php";
}
?>
6
LTPCGO

Weil die Verwendung globaler Variablen eine Reihe von Problemen und keine wirklichen Vorteile mit sich bringt.

Globale machen es schwierig, Ihren Code zu testen

Unit-Tests stehen zwar nicht in direktem Zusammenhang mit der Sicherheit, sind jedoch für die Entwicklung von entscheidender Bedeutung. Und um etwas richtig zu testen, müssen Sie in der Lage sein, den genauen Kontext zu steuern, in dem Code ausgeführt wird. Schauen Sie sich die beiden Codeteile an:

Mit Globals

public Money CalculateExpenses(int departmentId)
{
    Department department = (from d in global_db.Departments
    where d.Id = departmentId
    select d).Single();

    return (from ex in department.Expenses
            select ex).Sum();
}

Ohne Globals

public Money CalculateExpenses(int departmentId, Database database)
{
    Department department = (from d in database.Departments
    where d.Id = departmentId
    select d).Single();

    return (from ex in department.Expenses
            select ex).Sum();
}

Man könnte sagen, dass der Code fast identisch aussieht, außer wo die Daten tatsächlich herkommen. Sie könnten sogar denken, dass der Code mit Globals "sauberer" ist, da Sie die Datenbank nicht jedes Mal übergeben müssen.

Bis Sie einen Unit-Test schreiben müssen. Denn dann müssen Sie eine Logik einfügen, um keine Verbindung zur Produktionsdatenbank herzustellen, sondern eine lokale, möglicherweise testspezifische Datenbank. Jetzt sieht der nicht globale Code viel besser aus, da Sie einfach die Datenbank, die Sie verwenden möchten, an den Code übergeben können.

Zusammenfassend: Code ohne Globals ist einfacher zu testen.

Globals ändern das Verhalten, wenn Sie den Code nicht ändern

Wenn Ihr Code ungefähr 200 Codezeilen enthält, scheint die Verwendung von Globals nicht so schlecht zu sein. Tatsächlich scheint es eine vollkommen gültige Sache zu sein, wenn Sie überall denselben Code wiederverwenden (z. B. eine zufällige Datenquelle, Protokollierung usw.).

Sobald Ihre Codebasis jedoch ausreichend wächst, kann die Einführung von Globals absolut tödlich sein. Sie verlieren einfach die Kontrolle darüber, woher Ihre Daten stammen und wer Zugriff darauf hat.

Verwenden wir ein Beispiel in der Lieblingssprache aller: PHP 5. Beispiel von Eevee .

    @fopen('http://example.com/not-existing-file', 'r');

Was macht dieser Code? Sie wissen es nicht, weil es vom globalen Verhalten abhängt. Wenn PHP mit --disable-url-fopen-wrapper Kompiliert wurde, funktioniert es nicht. Gleiches gilt für die globale Konfiguration allow_url_fopen. Wir wissen nicht, was es tun wird.

Das @ Am Anfang deaktiviert Fehlermeldungen, es sei denn, scream.enabled Ist in der globalen PHP -Konfiguration) festgelegt. Es wird auch nicht gedruckt, wenn das globale error_reporting Level ist nicht festgelegt. Wo genau es gedruckt wird, hängt vom globalen display_errors Ab.

Wie Sie gesehen haben, hängt das Verhalten einer harmlosen Linie von 5 verschiedenen globalen Variablen ab. Stellen Sie sich dieses Szenario nun in einer Codebasis mit einer Million Zeilen und 100 verschiedenen Programmierern in verschiedenen Teams vor, und Sie werden schnell erkennen, warum die Verwendung von Globals abscheulich ist und zu allen möglichen Problemen führt.

Stellen Sie sich vor, Sie gehen eines Tages zur Arbeit und Ihr Code bricht plötzlich, obwohl Sie ihn nicht berührt haben. Das ist die Magie der Globals.

Es gibt weitere Beispiele dafür, warum die Verwendung von Globals schlecht ist, was in den anderen Antworten zu finden ist.

4
MechMK1

Pufferüberlaufangriffe

Obwohl sie ziemlich sprachspezifisch sind (C/C++ kommen in den Sinn) und schwer zu realisieren sind, sind sie ein potenzieller Angriff.

Computerphile hat ein großartiges Video darüber, das ich von ganzem Herzen empfehle, aber hier ist eine kurze Version der Mechanik dieser Angriffe und wie sie mit globalen Variablen interagiert.

Ein Pufferüberlauf tritt auf, wenn Daten, die in einen Puffer geschrieben werden, aufgrund unzureichender Grenzüberprüfung auch Datenwerte in Speicheradressen neben dem Zielpuffer beschädigen. Dies kann auftreten, wenn Daten von einem Puffer in einen anderen kopiert werden, ohne zuvor zu überprüfen, ob die Daten in den Zielpuffer passen. ( Wikipedia )

Bei globalen Variablen ist das Speicherlayout Ihres Programms ziemlich statisch, da (in den meisten Sprachen) beim Programmstart das Speichersegment zugewiesen wird. Dies gibt dem Angreifer Konsistenz: Es ist viel einfacher, die Speicherzone eines anderen Bereichs anzuvisieren, wenn Sie immer von derselben Stelle aus schießen (bei Globals), als wenn Sie sich zwischen den Schüssen immer bewegen.

Dies ist nicht spezifisch für globale Variablen, aber das Halten aussagekräftiger Informationen in solchen Strukturen erleichtert (nicht zu verwechseln mit dem Aktivieren!) Diese Art von Angriffen.

In acht nehmen!

Während globale Variablen möglicherweise ein geringes Sicherheitsrisiko darstellen, sollte Ihr Go-to-Defense-Mechanismus, wenn Sie Pufferüberlaufangriffe befürchten, die Eingabegröße überprüfen, nicht Refactoring-Code globale Variablen loszuwerden.

3
Mister Amen

Ich hatte noch nie ein Problem mit globalen Variablen in Bash oder JavaScript, höchstwahrscheinlich, weil ich nur kleine Skripte für den persönlichen Gebrauch in minimalistischen Umgebungen geschrieben habe.

Warum vermeiden viele Programmierer die Verwendung globaler Variablen und gibt es Beispiele für Sicherheitsverletzungen, die durch die Verwendung globaler Variablen verursacht werden?

In winzigen Projekten sind globale Variablen in Ordnung. Die meisten ihrer Probleme treten nicht auf. Und die oben genannte Anpassung der Bash-Umgebung ist in der Tat winzig.

Globale Variablen verursachen Probleme, wenn Ihr Programm skaliert ; Dies kann auf verschiedene Arten geschehen, aber der Kern des Problems ist die Menge an state, die für das Verständnis jedes Codeteils erforderlich ist.

Stellen Sie sich eine 10-Millionen-Zeilencode-Basis vor. Darin befinden sich 1 Million Variablen. Alle von ihnen sind global.
In einem bestimmten Code mit 100 Zeilen können Sie 20 Variablen verwenden.
Wann immer Sie eine Funktion aufrufen, wissen Sie nicht, welche dieser 20 Variablen diese Funktion ändern wird. Wenn Ihre Funktion gestartet wird, wissen Sie nicht, woher der Variablenstatus stammt.
Um zu verstehen, was Ihre 100 Codezeilen bedeuten, müssen Sie entweder alle 10 Millionen Codezeilen verstehen und im Kopf behalten, oder Sie benötigen eine Konvention darüber, woher Daten kommen und welche Daten können und kann nicht geändert werden, wenn Sie eine Hilfsfunktion usw. aufrufen.

Wenn Ihr Code dagegen fast ausschließlich von Funktionsargumenten, lokalen Variablen und Rückgabetypen angetrieben wird, müssen Sie nur Ihre Funktion verstehen, um zu verstehen, was er tut. Wenn diese Funktion eine andere Funktion aufruft, wissen Sie außerdem, welche Informationen Sie an sie weitergeben und welche Informationen sie zurückgeben.
Sie wissen vielleicht nicht, was es tut mit diesen Informationen, aber Sie wissen, was es nicht tut.
Zum Beispiel kann es integer x Nicht ändern, und Sie sind sicher, weil Sie x nicht an die Funktion übergeben oder ihr von ihrem Rückgabewert zugewiesen haben!

Es ist ein sehr wichtiges Ziel, den Code leichter über lokal zu argumentieren. Sie möchten in der Lage sein, eine Funktion zu lesen, zu wissen, was sie tut, und Fehler zu identifizieren.

Das Schreiben von Code ist weitaus einfacher und weitaus weniger wichtig als das Erstellen von Code, der klar und leicht zu begründen ist.
Fast der gesamte Code in einem großen, persistenten Projekt wird 100-mal häufiger gelesen als geändert und einmal geschrieben und entworfen.
Aus dieser Regel - machen Sie es einfacher, lokal zu argumentieren - erreichen wir die Regel "globalen Staat vermeiden".

Globale Variable versus Superobjekt

Gelesene/geschriebene globale Variablen sind ein Beispiel für den globalen Status. Aber so kann ein Superobjekt sein, dass alles in Ihrem Projekt einen Zeiger hat, der als erstes Argument übergeben wird.

Ein Superobjekt hat immer noch Vorteile gegenüber globalen Variablen. Globale Variablen haben oft verwirrende Mechanismen, wie sie initialisiert und bereinigt werden (ich sehe Sie, C/C++), und wenn Sie ein Superobjekt mit all Ihrem "globalen" Zustand haben, können Sie instanziieren zwei Versionen Ihres Superobjekts und führen Sie beide gleichzeitig im selben Prozess aus (dies funktioniert normalerweise nicht, aber das liegt normalerweise an einem impliziten globalen Status, den das Betriebssystem Ihnen aufzwingt).

Jede globale Variable, die Sie anstelle eines Parameters lesen, bedeutet, dass ein beliebiges Stück Code, überall sein Verhalten ändern kann. Jede globale Variable, in die Sie schreiben, bedeutet, dass Sie das Verhalten eines Codes beliebig weit entfernt ändern.

Und es sind nicht nur Menschen, die globale Zustände als Schmerz empfinden. Wenn Ihr Bundesstaat lokal ist, wird das Schreiben von Testgeschirren, die einen globalen Status oder eine globale Umgebung "vortäuschen", viel einfacher. Wenn es (sagen wir) ein globales "Maus" -Objekt gibt, wird es möglicherweise schwieriger, ein Makro zu schreiben, das eine aufgezeichnete Mausbewegung in einen Code wiedergibt. vor allem, wenn Sie dies beabsichtigen, während die Benutzeroberfläche mit einer Maus auf den tatsächlichen Menschen reagiert.

Sicherheit

Sicherheit ist eine Funktion, um zu verstehen, was Ihr Code tut. Sicherheit innerhalb eines Programms bedeutet "Ihr Code tut nur das, was er tun darf"; Mit globalen Variablen haben Sie eine schwächere Fähigkeit zu verstehen, was der Code tut, und somit weniger die Fähigkeit, zu steuern, was er tut.

3
Yakk

Aus Sicherheitsgründen besteht das Problem bei globalen Variablen darin, dass sie unerwartetes Verhalten erzeugen und die Lokalisierung unterbrechen können. Die allgemeinere Idee dahinter heißt "Fernwirkung" wobei ein Teil eines Programms einen unerwarteten Effekt auf einen anderen haben kann.

Da die Lokalisierung fehlerhaft ist, müssen Sie und jeder, der mit dem Programm arbeitet, jetzt nur einen Teil des Programms verstehen, der Ihre globale Variable betreffen könnte, anstatt nur einen Teil des Programms verstehen zu müssen. Dies erhöht die Komplexität des Entwurfs massiv, und im Allgemeinen sind komplexe Entwürfe eher fehlerhaft und daher unsicher. Wie der Informatiker Edsger Dijkstra einmal sagte: "Der kompetente Programmierer ist sich der streng begrenzten Größe seines eigenen Schädels voll bewusst.".

Programme neigen dazu, mit der Zeit an Größe und Umfang zu wachsen. Auch wenn Ihr einfaches Skript, das jetzt isoliert erstellt wurde, nur eines ohne Modularität ausführt, wird es möglicherweise in Zukunft an einem anderen Ort wiederverwendet, an dem Sie möglicherweise die bösen Auswirkungen der globalen Variablen vergessen haben, oder schlimmer noch, Sie sind weg und niemand weiß, dass es globale Variablen enthält. Globale Variablen sind so, als würden Sie Löcher im Boden lassen oder Rechen, die in die falsche Richtung weisen, darauf getreten werden können, oder Nägel in Ihrer Einfahrt.

Sie sind in vielerlei Hinsicht in unmittelbarer Gefahr und sollten manchmal als solche behandelt werden.

1
Steve Sether
Warum vermeiden viele Programmierer die Verwendung globaler Variablen und gibt es Beispiele für Sicherheitsverletzungen, die durch die Verwendung globaler Variablen verursacht werden?

Da es einfacher ist, Code zu ändern, der keine globalen Variablen zum Ausführen in unbeabsichtigten Anwendungen verwendet, Anwendungen, die der ursprüngliche Entwickler nicht vorausgesehen hat. Wenn Sie vom globalen Status abhängig sind, können Sie in einer Anwendung höchstens einen solchen Status ohne intensives Refactoring haben (was den globalen Status umgestalten würde).

Solche unbeabsichtigten Anwendungen können das Ausführen des Codes in Umgebungen mit mehreren Threads umfassen.

Was viele Menschen jedoch nicht erkennen: malloc() ist global!

Dieselben Personen, die sich gegen die Verwendung globaler Variablen aussprechen, verwenden ständig einen globalen Allokatorstatus.

Dies bedeutet, dass, wenn ein Teil Ihres Codes viel Speicher zuweist und malloc() mehr Speicher vom Betriebssystem anfordert, die Speicherblöcke mit denen verwechselt werden, die aus anderen Teilen Ihres Codes zugewiesen wurden, und wenn derselbe Teil Der Code gibt den gesamten verwendeten Speicher frei. Die Aufrufe von free() geben aufgrund der Fragmentierung keinen Speicher an das Betriebssystem zurück. Das Endergebnis ist, dass Ihr Programm mehr Speicher benötigt, als es sollte.

Genau die Leute, die sich gegen die Verwendung globaler Variablen aussprechen, verwenden tatsächlich einen Allokator mit einem globalen Zustand.

Ich frage mich, warum keiner der Standards der großen Standardisierungsorganisationen (C89/C99/C11/C18 von ISO, POSIX von IEEE) einen Allokator definiert hat, der es Ihnen ermöglicht, mehrere Allokatorzustände zu haben, d. H. Unabhängige Heaps.

0
juhist

Wenn nahezu jede Programmiersprache eine Variable global deklarieren kann, auf die nur im Rahmen des Implementierungscodes zugegriffen werden kann, ist dies kein Problem. Es gibt nicht viel Grund, globale Variablen zu verwenden.

Dies ist jedoch nicht der Fall, weshalb ich meine Projekte in C und nicht in C++ geschrieben habe, wo sie natürlich als statische Variable in der äußersten Klausel einer Klassendefinition unterstützt werden mit globalen Variablen auskommen.

0
Dehbop