Ansicht
Dokumentation

ABENDYNAMIC_PROGRAMMING_SCRTY - DYNAMIC PROGRAMMING SCRTY

ABENDYNAMIC_PROGRAMMING_SCRTY - DYNAMIC PROGRAMMING SCRTY

rdisp/max_wprun_time - Maximum work process run time   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Sicherheitsrisiken durch Eingaben von außen

Die meisten Sicherheitsprobleme in ABAP-Programmen entstehen in aller Regel dadurch, dass Eingaben, die von außen, d.h.

  • von einer Benutzungsoberfläche
  • aus einer Parameterschnittstelle
  • aus einer persistenten Ablage

in ein Programm übernommen werden, falsch oder unbedacht eingesetzt werden. Sicherheitsrisiken bestehen insbesondere immer dann, wenn Teile von Anweisungen, ganze Anweisungen oder Objekte, auf die in Anweisungen zugegriffen wird, dynamisch angegeben werden und damit keiner statischen Kontrolle unterliegen. Solche dynamischen Angaben kommen beispielsweise in folgenden Fällen vor:

  • Dynamische Angaben sind ganz natürlich in der Syntax einer Anweisung verankert. Beispielsweise ist die Angabe eines Dateinamens über eine Variable in einer Anweisung der ABAP-Dateischnittstelle eher die Regel als eine Ausnahme.
  • Ein verwendetes Framework ist vollständig dynamisch, wie beispielsweise ADBC, das ausschließlich dynamische SQL-Anweisungen verwendet.
  • Dynamische Angaben dienen der kompakten Programmierung von Funktionalität, die auch statisch programmierbar, dann aber umständlicher wäre, beispielsweise wegen vieler Fallunterscheidungen.

Hierbei sind zwei wesentliche Fälle zu unterscheiden:

  • Die dynamischen Angaben werden vollständig im gleichen Programm erstellt und enthalten keine Anteile, die von außen in das Programm gelangen.
  • Die dynamischen Angaben stammen teilweise oder ganz von außerhalb des Programms, d.h. sie werden einer Benutzungsoberfläche, Parameterschnittstelle oder Ablage entnommen.

Unter der Voraussetzung, dass der Entwickler eines Programms keine böswilligen Absichten hat, ist die Verwendung dynamischer Angaben im ersten Fall in der Regel nicht kritisch.

Der zweite Fall ist dagegen kritisch. Wenn eine Eingabe von außen ungeprüft und ohne Maskierung direkt als dynamische Angabe in einer ABAP-Anweisung verwendet wird, kann unbeabsichtigter oder schlimmer noch beabsichtigter Schaden angerichtet werden. Der Schaden kann vom Auslösen von Ausnahmen über das Verschwenden von System-Ressourcen (Denial of Service-Attacken) bis zur Manipulation von persistenten Daten reichen.

Die folgenden Abschnitte listen exemplarisch die wichtigsten Sicherheitsrisiken bei der Verwendung von Eingaben von außen in Anweisungen auf:

Das in diesen Abschnitten wiederkehrende Prinzip, dass Eingaben von außen immer geeignet überprüft und/oder maskiert werden müssen, gilt auch in allen Fällen, die hier nicht explizit aufgeführt sind, wie z.B. die Verwendung einer dynamischen WHERE-Bedingung bei Zugriffen auf interne Tabellen.

Hinweis

Nicht berücksichtigt sind hier Hintertüren (Backdoors), die ein böswilliger Entwickler über dynamische Angaben verwirklicht. Diese sind statisch nicht überprüfbar und werden, da sie nicht von außerhalb des Programms kommen, von einer statischen Überprüfung in der Regel nicht als gefährlich erkannt. In solchen Fällen hilft in der Regel nur das Mehr-Augen-Prinzip (Code Inspections). Siehe auch Verschleierung von ABAP-Quelltext.






Vendor Master (General Section)   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 4086 Date: 20240523 Time: 174719     sap01-206 ( 68 ms )