-
TECHNISCHES GEBIET
-
Die vorliegende Erfindung betrifft Lösungen zur Netzwerksicherheit und insbesondere ein Verfahren und eine Vorrichtung zur Sicherheitsprüfung von Benutzereingaben bei Netzwerkanwendungen.
-
BESCHREIBUNG DES STANDS DER TECHNIK
-
Heutzutage nimmt die Zahl von Sicherheitslücken bei Webanwendungen rasant zu. Netzwerkanwendungen sind empfindlich gegenüber Angriffen wie z. B. seitenübergreifendem Scripting (Cross-Site Scripting, XSS), SQL-Einschleusung (SQL injection), LDAP-Einschleusung (LDAP injection), Command Access, PHP-Einschleusung (PHP injection) usw. Statistiken zeigen, dass 75% der Angriffe auf die Anwendungsschicht zielen und 90% der Sites anfällig gegenüber Angriffen auf Netzwerkanwendungen sind.
-
Bei den herkömmlichen Lösungen für die Sicherheit von Webanwendungen wird einerseits auf der Clientseite Prüfcode in Prüfprogrammen von Webanwendungen und andererseits auf der Seite des Webanwendungsservers eine Webanwendungs-Firewall eingesetzt, um bösartige Eingaben zu filtern und abzublocken. Da bösartige Benutzer das Anzeigeprogramm der Webanwendung auf der Clientseite umgehen und bösartigen Code bzw. bösartige Scripts direkt auf den Webanwendungsserver einschleusen könnten, ist es außerordentlich notwendig, Benutzereingaben auf der Seite des Webanwendungsservers weiteren Gültigkeitsprüfungen zu unterziehen.
-
Die Webanwendungs-Firewall, ein transparenter Schutzmechanismus auf der Seite des Webanwendungsservers, hat mindestens die folgenden Funktionen: Überprüfen der Gültigkeit von Benutzereingaben auf der Grundlage vordefinierter Sicherheitsregeln; Ergreifen von entsprechenden sicherheitsorientierten Schutzmaßnahmen gegenüber Benutzereingaben, die die Sicherheitsregeln verletzen, z. B. Blockieren der IP-Adresse, Abweisen der Anforderung, Erzeugen eines Protokolls oder das Neuschreiben der Nutzdaten usw.
-
Bei der Beobachtung von Online-Webanwendungen ist festzustellen, dass die Gültigkeitsprüfungen von Sicherheitsregeln durch Schutzmittel auf der Serverseite durch die folgenden zwei Umstände ausgelöst werden können
- 1. Unschuldige Benutzer machen einen Fehler beim Eingeben einiger Werte, die die Sicherheitsregeln verletzen.
- 2. Bösartige Benutzer umgehen den Mechanismus zur Gültigkeitsprüfung der Benutzereingaben auf der Clientseite und schleusen mithilfe einiger Hilfsprogramme bösartige Eingaben auf den Webanwendungsserver.
-
Vorhandene Lösungen zur Gültigkeitsprüfung von Benutzereingaben können jedoch unschuldige Benutzer und bösartige Benutzer nicht wirksam erkennen, und Schutzmittel können fast nie entsprechende sicherheitsgerichtete Schutzmaßnahmen ergreifen. Wenn z. B. Maßnahmen wie das Blockieren der IP-Adresse oder das Abwehren der Anforderung gegenüber unschuldigen Benutzern ergriffen werden, die einfach nur einen Fehler beim Eingeben machen, hat das schwerwiegende Auswirkungen auf die Erfahrungen dieser Benutzer der Webanwendung; wenn Anforderungen unabhängig von bösartigen Benutzern oder unschuldigen Benutzern während des Verstoßes zurückgewiesen und der Benutzer einen benutzerfreundlichen Sicherheitshinweis erhält, steigt der Leistungsverbrauch der Sicherheitsüberprüfungssysteme erheblich an.
-
Es besteht daher ein Bedarf an einem Sicherheitsüberprüfungsschema für Netzwerkanwendungen, das unschuldige und bösartige Benutzer wirksam erkennen kann.
-
ÜBERBLICK ÜBER DIE ERFINDUNG
-
Um die Mängel des gegenwärtigen Stands der Technik zu beseitigen, wird in der vorliegenden Erfindung ein Verfahren zur Sicherheitsüberprüfung einer Benutzereingabe in einer Netzwerkanwendung vorgeschlagen. Das Verfahren umfasst Folgendes: Bereitstellen einer Teilmenge von Sicherheitsregeln der Sicherheitsregeln der serverseitigen Schutzmittel für eine Vorprüfungskomponente, die auf einem Client installiert ist, sodass eine Sicherheitsprüfung einer Benutzereingabe auf der Clientseite durch die Vorprüfungskomponente anhand der bereitgestellten Teilmenge von Sicherheitsregeln möglich wird; Gültigkeitsprüfung der Benutzereingabe auf der Grundlage einer Sicherheitsregel der Schutzmittel; als Reaktion auf die Erkennung einer die Sicherheitsregeln verletzenden Benutzereingabe und auf die Tatsache, dass der Vorprüfungskomponente eine verletzte Sicherheitsregel nicht bereitgestellt wurde, das Ermitteln des Benutzers als zu einer ersten Klasse von Benutzern gehörig; und als Reaktion auf die Erkennung einer die Sicherheitsregeln verletzenden Benutzereingabe und auf die Tatsache, dass der Vorprüfungskomponente eine verletzte Sicherheitsregel bereitgestellt wurde, das Ermitteln des Benutzers als zu einer zweiten Klasse von Benutzern gehörig.
-
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, das ferner Folgendes umfasst: das asynchrone Durchführen einer dynamischen Aktualisierung einer der Vorprüfungskomponente bereitgestellten Teilmenge von Sicherheitsregeln; wobei in dem Schritt, in dem die Teilmenge von Sicherheitsregeln der Sicherheitsregeln der serverseitigen Schutzmittel der Vorprüfungskomponente bereitgestellt wird, und in dem Schritt, in dem eine asynchrone dynamische Aktualisierung der der Vorprüfungskomponente bereitgestellten Teilmenge von Sicherheitsregeln durchgeführt wird, eine Teilmenge von Sicherheitsregeln aus einer Menge von Sicherheitsregeln der Schutzmittel herausgefiltert wird.
-
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, bei dem die Vorprüfungskomponente eine eigenständige Javascript-Komponente ist, die auf einem Client-Browser laufen kann.
-
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, das ferner Folgendes umfasst: Durchführen unterschiedlicher sicherheitsorientierter Schutzmaßnahmen gegenüber der ermittelten ersten Klasse von Benutzern und gegenüber der zweiten Klasse von Benutzern.
-
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, bei dem der Schritt des Durchführens verschiedener sicherheitsorientierter Schutzmaßnahmen gegenüber der ermittelten ersten Klasse von Benutzern und zweiten Klasse von Benutzern Folgendes umfasst: Durchführen einer sicherheitsorientierten Schutzmaßnahme gegenüber der zweiten Klasse von Benutzern wie das zwangsweise Abblocken aller weiteren Anforderungen; und das Durchführen einer sicherheitsorientierten Schutzmaßnahme gegenüber der ersten Klasse von Benutzern, die dazu beiträgt, die guten Erfahrungen der Benutzer aufrechtzuerhalten.
-
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, bei dem die Sicherheitsrichtlinie eines oder mehrere der folgenden Elemente enthält: das Auswählen einer Sicherheitsregel mit einer hohen Regelverletzungsrate; das Ausschließen aller Negativregeln in der Menge von Sicherheitsregeln; das Ausschließen risikoreicher Sicherheitsregeln in der Menge von Sicherheitsregeln.
-
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, bei dem die Vorprüfungskomponente als Reaktion auf ein onPropertyChange-Ereignis in einem Eingabefeld die Sicherheit einer Benutzereingabe auf der Clientseite anhand der bereitgestellten Teilmenge von Sicherheitsregeln prüft.
-
In der vorliegenden Erfindung wird ferner eine Vorrichtung zur Sicherheitsprüfung einer Benutzereingabe in einer Netzwerkanwendung vorgeschlagen. Die Vorrichtung umfasst Folgendes: Mittel zum Bereitstellen einer Teilmenge von Sicherheitsregeln der Sicherheitsregeln der serverseitigen Schutzmittel für eine Vorprüfungskomponente, die auf einem Client installiert ist, sodass eine Sicherheitsprüfung einer Benutzereingabe auf der Clientseite durch die Vorprüfungskomponente anhand der bereitgestellten Teilmenge von Sicherheitsregeln möglich wird; Mittel zur Gültigkeitsprüfung der Benutzereingabe auf der Grundlage einer Sicherheitsregel der Schutzmittel; als Reaktion auf die Erkennung einer die Sicherheitsregeln verletzenden Benutzereingabe und auf die Tatsache, dass der Vorprüfungskomponente eine verletzte Sicherheitsregel nicht bereitgestellt wurde, Mittel, um den Benutzer als zu einer ersten Klasse von Benutzern gehörig zu ermitteln; und als Reaktion auf die Erkennung einer die Sicherheitsregeln verletzenden Benutzereingabe und auf die Tatsache, dass der Vorprüfungskomponente eine verletzte Sicherheitsregel bereitgestellt wurde, Mittel, um den Benutzer als zu einer zweiten Klasse von Benutzern gehörig zu ermitteln.
-
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, die ferner Folgendes umfasst: Mittel zum asynchronen Durchführen einer dynamischen Aktualisierung einer der Vorprüfungskomponente bereitgestellten Teilmenge von Sicherheitsregeln, wobei die Mittel, mit denen einer Vorprüfungskomponente auf dem Client eine Teilmenge von Sicherheitsregeln der Sicherheitsregeln von serverseitigen Schutzmitteln bereitgestellt wird, um auf der Clientseite mithilfe der Vorprüfungskomponente auf der Grundlage der bereitgestellten Teilmenge von Sicherheitsregeln die Sicherheitsprüfung einer Benutzereingabe durchzuführen, und die Mittel zum asynchronen Durchführen einer dynamischen Aktualisierung einer der Vorprüfungskomponente bereitgestellten Teilmenge von Sicherheitsregeln die Teilmenge von Sicherheitsregeln aus einer Menge von Sicherheitsregeln der Schutzmittel anhand einer bestimmten Sicherheitsrichtlinie herausfiltern.
-
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, bei der die Vorprüfungskomponente eine eigenständige Javascript-Komponente ist, die auf einem Client-Browser laufen kann.
-
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, die ferner Folgendes umfasst: Mittel zum Durchführen anderer sicherheitsorientierter Schutzmaßnahmen gegenüber der ermittelten ersten Klasse von Benutzern und gegenüber der zweiten Klasse von Benutzern.
-
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, bei der die Mittel zum Durchführen unterschiedlicher sicherheitsorientierter Schutzmaßnahmen gegenüber der ermittelten ersten Klasse von Benutzern und zweiten Klasse von Benutzern Folgendes umfasst: Mittel zum Durchführen einer sicherheitsorientierten Schutzmaßnahme gegenüber der zweiten Klasse von Benutzern wie das zwangsweise Abblocken aller weiteren Anforderungen; und Mittel zum Durchführen einer sicherheitsorientierten Schutzmaßnahme gegenüber der ersten Klasse von Benutzern, die dazu beiträgt, die guten Erfahrungen der Benutzer aufrechtzuerhalten.
-
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, bei der die Sicherheitsrichtlinie eines oder mehrere der folgenden Elemente enthält: das Auswählen einer Sicherheitsregel mit einer hohen Regelverletzungsrate; das Ausschließen aller Negativregeln in der Menge von Sicherheitsregeln; das Ausschließen risikoreicher Sicherheitsregeln in der Menge von Sicherheitsregeln.
-
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, bei der die Vorprüfungskomponente als Reaktion auf ein onPropertyChange-Ereignis in einem Eingabefeld die Sicherheit einer Benutzereingabe auf der Clientseite anhand der bereitgestellten Teilmenge von Sicherheitsregeln prüft.
-
Die vorliegende Erfindung betrifft darüber hinaus ein Sicherheitsprüfungssystem, das eine Vorrichtung zur Sicherheitsprüfung einer Benutzereingabe in einer Netzwerkanwendung umfasst.
-
Gemäß der technischen Lösung der vorliegenden Erfindung kann wirksam zwischen „einer zweiten Klasse von Benutzern” und „einer ersten Klasse von Benutzern” unterschieden werden. Hinsichtlich einer zweiten Klasse von Benutzern und einer ersten Klasse von Benutzern können unterschiedliche Lösungen konfiguriert werden, wobei die Relevanz des Gültigkeitsprüfungsprozesses erweitert wird. Gemäß einer Ausführungsform der vorliegenden Erfindung ist es möglich, die Benutzererfahrung „einer ersten Klasse von Benutzern” in Bezug auf eine Webanwendung so weit wie möglich zu gewährleisten und den nutzlosen Verbrauch von Systemleistung in einem maximalen Umfang zu vermeiden. Außerdem wird die Auslastung der serverseitigen Schutzmittel verringert und dementsprechend die Leistung des gesamten Gültigkeitsprüfungssystems erhöht.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Zum besseren Verständnis der vorliegenden Erfindung werden weitere Merkmale und Auswirkungen der vorliegenden Erfindung klarer und leichter nachvollziehbar, wenn die folgende Beschreibung in Verbindung mit den Figuren gelesen wird, wobei:
-
1 eine Systemstruktur schematisch veranschaulicht, in der eine Ausführungsform der vorliegenden Erfindung realisiert sein kann;
-
2 einen Ablaufplan eines Verfahrens zur Sicherheitsprüfung einer Benutzereingabe gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
-
3 einen Ablaufplan von serverseitigen Schutzmitteln und einer clientseitigen Vorprüfungskomponente gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht; und
-
4 eine schematische Ansicht des Zusammenspiels zwischen Modulen eines Sicherheitsprüfungssystems gemäß einer Ausführungsform der vorliegenden Erfindung wiedergibt.
-
In den vorgenannten Figuren bezeichnen gleiche Ziffern identische, ähnliche oder entsprechende Merkmale oder Funktionen.
-
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
-
1 veranschaulicht schematisch eine Systemstruktur, in der eine Ausführungsform der vorliegenden Erfindung realisiert sein kann. Die Bezugszahl 11 bezeichnet einen Client-Browser auf der Clientseite zum Senden einer HTTP-Anfrage des Benutzers an den Webanwendungsserver und zum Empfangen einer entsprechenden Antwort von dem Webanwendungsserver; 12 bezeichnet ein Netzwerk, über das der Webanwendungsserver auf die Anforderung antworten kann, die der Benutzer mithilfe des Client-Browsers gesendet hat; 10 bezeichnet Schutzmittel auf der Seite des Webanwendungsservers zum Prüfen eines Eingabewertes in der Benutzeranforderungen auf der Serverseite und zum Bereitstellen eines Sicherheitsschutzes für den Webanwendungsserver; 13 bezeichnet den Webanwendungsserver.
-
Wie in
1 dargestellt sendet der Benutzer eine Anforderung mit einem Eingabewert mithilfe des Client-Browsers
11 auf der Clientseite über das Netzwerk
12 an den Webanwendungsserver
13. Der Eingabewert des Benutzers muss geprüft werden, um die Sicherheit der Webanwendung zu garantieren. Normale Benutzer geben auf der Clientseite keinen bösartigen Wert ein, z. B. Logikcode wie etwa JavaScript-Logik, während mögliche bösartige Benutzer unter Umständen bösartigen Logikcode auf den Webanwendungsserver
13 einschleusen, um den Server anzugreifen und private Informationen anderer Benutzer usw. zu stehlen, wobei bösartiger Code wie z. B. JavaScript sensible Informationen von Clients stiehlt, wenn er vom Server an den Browser des Clients gesendet wird. Obwohl ein Prüfprogramm der Webanwendung (nicht dargestellt) auf der Clientseite so konfiguriert sein kann, dass Eingabewerte des Benutzers erkannt werden, können bösartige Benutzer das Prüfprogramm der Webanwendung umgehen, indem sie bestimmte Programme nutzen, um mithilfe eines Scripting-Einschleusungsprogramms einen bösartigen Wert direkt auf den Webanwendungsserver
13 einschleusen. Deshalb müssen die Schutzmittel
10 wie z. B. eine Anwendungs-Firewall auf der Serverseite mit vordefinierten Sicherheitsregeln konfiguriert werden, auf deren Grundlage die Schutzmittel
10 Eingabewerte von Benutzern prüfen. Wenn das Schutzmittel
10 einen Benutzereingabewert erkennt, der die Sicherheitsregeln verletzt, ergreift es entsprechende sicherheitsorientierte Schutzmaßnahmen gegenüber diesem Benutzer, um eine mögliche Gefährdung zu beseitigen. Tabelle 1 zeigt beispielhafte Sicherheitsregeln, die das Schutzmittel
10 übernehmen könnte. Tabelle 1
| Anwendungsspezifische Regel | ALLOWRULE ”URI/testresult.html;
narre ^[a-zA-Z0-9\s.-]*$;
age ^[0-9]+$”;
”ID=050000, SEVERITY=2,
ATTACKTYPE=malformed,
ACTION=deny” |
| Negativregel | NEGATIVERULE ”ALL
*(?:\b(?:\.(?:ht(?:access|passwd
|group)|www
?acl)|global\.asa|httpd\.conf|bo
ot\.ini)\blVetcV).*”
”ID=090001, SEVERITY=1,
ATTACKTYPE=File Injection,
ACTION=block” |
| Aliase | Regex |
| Sicherer Text | ^[a-zA-Z0-9\s.\-]*$ |
| eMail | /((\%3C)|<)((\%2F)|V)*[a-z0-9\%]+((\%3E)|>)/ix |
| Ganzzahl | (-|\+)?[0-9]+ |
| XSS-Einschleusung | /((\%3C)1<)((\%2F)|-)*[a-z0-9\%]+((\%3E)|>)/ix |
| SQL-Einschleusung | .w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix |
-
Das in Tabelle 1 dargestellte Beispiel von Sicherheitsregeln umfasst eine anwendungsspezifische Regel und eine Negativregel. Die anwendungsspezifische Regel schreibt bei verschiedenen Eingabefeldern Sicherheitsregelinformationen vor, die durch eine spezielle Anwendung festgelegt sind, z. B.
-
Informationen über Benutzereingabewerte, die in Feldern wie z. B. „name” (Name) und „age” (Alter) zulässig sind.
-
Beispielsweise sind Eingabewerte, die in „name” zulässig sind, durch einen regulären Ausdruck von „Sicherer Text” festgelegt; in „age” zulässige Werte sind durch einen regulären Ausdruck von „ganz Zahl” definiert. Die anwendungsspezifische Regel schreibt ferner vor, dass ein Angriffstyp, der diese Regel verletzt, „MALFORMED” (falsch gebildet) ist und die zu ergreifende sicherheitsorientierte Schutzmaßnahme „deny” (verweigern) lautet. Die Negativregel schreibt negative Werte aller Benutzereingaben vor, d. h. die Negierung aller Eingabewerte aller regulären Ausdrücke, die dem „XSS” (seitenübergreifendes Scripting) entsprechen. Die Negativregel schreibt ferner vor, dass es sich bei einem Angriffstyp, der diese Regel verletzt, um „XSS” (seitenübergreifendes Scripting) handelt und die zu ergreifende sicherheitsorientierte Schutzmaßnahme „deny” (verweigern) lautet.
-
Obwohl die Tabelle 1 ein Beispiel von Sicherheitsregeln zeigt, die im Schutzmittel 10 konfiguriert sind, können die Sicherheitsregeln im Schutzmittel 10 andere Formen umfassen. Vielmehr wird dem Fachmann anhand der folgenden Beschreibung klar, dass spezielle Formen und Inhalte von Sicherheitsregeln die vorliegende Erfindung nicht einschränken.
-
Bei Sicherheitsprüfungsschemata für Webanwendungen sollte Wert darauf gelegt werden, dass die Schutzmittel 10 gegenüber unschuldigen Benutzern, die beim Eingeben von Werten einen Fehler machen und dadurch eine vordefinierte Sicherheitsrichtlinie verletzen, die einfach nur auf der Sicherheitsrichtlinie beruht, keine sicherheitsorientierten Schutzmaßnahmen wie z. B. Blockieren der IP-Adresse und Abweisen der Anforderung durchführen, die schwerwiegende Auswirkungen auf die Benutzer von Webanwendungen haben; ferner sollte Wert darauf gelegt werden, zu verhindern, dass die Schutzmittel 10 gegenüber unschuldigen Benutzern, die bösartigen Code einschleusen, sicherheitsorientierte Schutzmaßnahmen wie z. B. das Senden eines benutzerfreundlichen Sicherheitshinweises oder sogar das Neuschreiben von Nutzdaten durchgeführt werden, die den Verbrauch an Systemleistung erhöhen. Bei einem Sicherheitsprüfungsschema gemäß der vorliegenden Erfindung können die Schutzmittel 10 Klassen von Benutzern, die Sicherheitsregeln verletzen, wirksam unterscheiden, sodass die Schutzmittel ordnungsgemäße und entsprechende sicherheitsorientierte Schutzmaßnahmen gegenüber regelverletzenden Benutzern ergreifen, d. h. die Benutzererfahrung einer ersten Klasse von Benutzern (die eher als unschuldige Benutzer einzuordnen sind) zu garantieren, ohne wertvolle Systemleistung für eine zweite Klasse von Benutzern (die eher als bösartige Benutzer einzuordnen sind) zu verschwenden.
-
Anzumerken ist, dass die erste Klasse von Benutzern entsprechend dem vom System bereitgestellten Sicherheitshinweis regelverletzende Eingaben wahrscheinlich korrigiert, bis die Benutzereingabewerte den Sicherheitsregeln entsprechen; die zweite Klasse von Benutzern jedoch beabsichtigt, bösartige Werte auf den Webanwendungsserver 13 einzuschleusen, und deren Eingaben werden nicht den Sicherheitsregeln entsprechen, die über benutzerfreundliche Dialoge im Gültigkeitsprüfungsprozess bereitgestellt werden. Deshalb wird in der vorliegenden Erfindung eine Konzeption vorgeschlagen, bei der die Schutzmittel 10 eine Vorprüfungskomponente auf dem Client-Browser 11 installieren und die Vorprüfungskomponente veranlasst wird, anhand einiger Sicherheitsregeln, die von den Schutzmitteln 10 bereitgestellt werden, eine Vorprüfung der Benutzereingaben auf der Clientseite vorzunehmen. Die Schutzmittel 10 prüfen die Benutzereingabe anhand der vordefinierten Sicherheitsregeln und ermitteln anhand der Vorprüfung auf der Clientseite und der von den Schutzmitteln selbst durchgeführten Gültigkeitsprüfung, ob der Benutzer zur ersten Klasse von Benutzern oder zur zweiten Klasse von Benutzern gehört, und es wird auf dieser Grundlage eine zu ergreifende sicherheitsorientierte Schutzmaßnahme ausgewählt.
-
2 veranschaulicht einen Ablaufplan eines Verfahrens zur Sicherheitsprüfung einer Benutzereingabe gemäß einer Ausführungsform der vorliegenden Erfindung.
-
Das Verfahren beginnt in Schritt S200.
-
In Schritt S210 wird der auf dem Client installierten Vorprüfungskomponente eine Teilmenge von auf der Serverseite in den Schutzmitteln vorhandenen Sicherheitsregeln bereitgestellt, sodass die Vorprüfungskomponente anhand der bereitgestellten Teilmenge von Sicherheitsregeln die Sicherheit eines Benutzereingabewertes auf der Clientseite prüft.
-
Die Vorprüfungskomponente auf der Clientseite kann durch die Schutzmittel auf dem Client installiert oder über das Netzwerk mithilfe eines Client-Zusatzprogramms (Plug-In) von den Schutzmitteln bezogen werden. Beispielsweise kann es sich bei der Vorprüfungskomponente um eine eigenständige Javascript-Komponente handeln. Bei einer Realisierung fügen die Schutzmittel die Javascript-Vorprüfungskomponente in eine Antwortseite der Anwendung ein, sodass die Vorprüfungskomponente durch den Client-Browser ausgeführt wird.
-
Sicherheitsregeln, die durch die Schutzmittel der clientseitigen Vorprüfungskomponente bereitgestellt werden, sind vorzugsweise eine geeignete Teilmenge von Sicherheitsregeln in den Schutzmitteln. Der Vorprüfungskomponente kann eine Sicherheitsrichtliniendatei bereitgestellt werden, in der die Sicherheitsregeln vorgegeben sind. Die Sicherheitsrichtliniendatei kann kurz zusammengefasst unter anderem einen Alias (z. B., eMail, URL, sicheren Text, XSS usw.), einen Feldnamen, die URI, die von der Vorprüfungskomponente auf der Clientseite so lange überwacht wird, wie reguläre Ausdrücke, die in der clientseitigen Vorprüfungskomponente definiert sind, kompatibel mit regulären Ausdrücken sind, die in den serverseitigen Schutzmitteln definiert sind.
-
In Schritt S220 wird bei Erkennung eines regelverletzenden Benutzereingabewertes ermittelt, ob die verletzte Sicherheitsregel der clientseitigen Vorprüfungskomponente bereitgestellt wurde.
-
Wenn in Schritt S220 festgestellt wird, dass die verletzte Sicherheitsregel der clientseitigen Vorprüfungskomponente bereitgestellt wurde, bedeutet dies, dass die serverseitigen Schutzmittel das Sicherheitsproblem erkannt hat, das durch die Vorprüfungskomponente auf der Clientseite hätte gelöst werden müssen, und das darin besteht, dass der regelverletzende Benutzer einen bösartigen Wert direkt in die Webanwendung eingeschleust hat, nachdem er den clientseitigen Vorprüfungsmechanismus z. B. mithilfe eines Angriffsprogramms umgangen hat. Deshalb wird der Regelverletzer in Schritt S230 als zu „einer zweiten Klasse von Benutzern” gehörig ermittelt. Diese zweite Klasse von Benutzern ist eher als eine Klasse von bösartigen Benutzern einzuordnen.
-
Wenn andererseits in Schritt S220 festgestellt wird, dass die verletzte Sicherheitsregel der clientseitigen Vorprüfungskomponente nicht bereitgestellt wurde, wird in Schritt S240 der regelverletzende Benutzer als zu „einer ersten Klasse von Benutzern” gehörig ermittelt. Diese erste Klasse von Benutzern ist eher als eine Klasse von unschuldigen Benutzern einzuordnen.
-
Vorzugsweise wird eine Teilmenge von Sicherheitsregeln, die der Vorprüfungskomponente bereitgestellt wird, in Schritt S250 asynchron aktualisiert. Die „asynchrone” Durchführung der Aktualisierung bedeutet, dass der Aktualisierungsschritt unabhängig vom gesamten Gültigkeitsprüfungsprozess durchgeführt wird. Beispielsweise kann bei einer Realisierung der Aktualisierungsprozess mithilfe des AJAX-Verfahrens (Asynchronous JavaScript and XML) im Hintergrund realisiert werden. Dieser Aktualisierungsschritt kann entweder in regelmäßigen oder unregelmäßigen Abständen durchgeführt werden, wobei die Schutzmittel gemäß einer bestimmten Sicherheitsrichtlinie eine Teilmenge von Sicherheitsregeln aus der Gesamtmenge der Sicherheitsregeln herausfiltern, die der Vorprüfungskomponente bereitgestellt werden soll. Die Schutzmittel können die einzelnen Sicherheitsregeln anhand einer Regelverletzungsrate, die auf der Statistik des Sicherheitsprüfungsprotokolls beruht, einstufen und Sicherheitsregeln mit hohen Regelverletzungsraten herausfiltern, die der clientseitigen Vorprüfungskomponente bereitgestellt werden sollen. Beispielsweise kann ferner angemerkt werden, dass die zweite Klasse von Benutzern Informationen über Sicherheitsregeln in der Vorprüfungskomponente erhalten könnte, indem Antworten (z. B. verschiedene Sicherheitshinweise usw.) der clientseitigen Vorprüfungskomponente auf Eingabewerte analysiert werden, sodass für die Vorprüfungskomponente eine Teilmenge von Sicherheitsregeln unter Berücksichtigung bestimmter Regeln herausgefiltert wird. Bei einer bevorzugten Ausführungsform kann die herausgefilterte Teilmenge von Sicherheitsregeln eine oder mehrere der folgenden Bedingungen erfüllen:
- 1. Auswählen von Sicherheitsregeln mit einer jeweils hohen Regelverletzungsrate;
- 2. Ausschließen aller Negativregeln in der Menge von Sicherheitsregeln;
- 3. Ausschließen von risikoreichen Sicherheitsregeln, d. h. von Regeln, die für das System eine ernsthafte Bedrohung darstellen, sobald die Systemsicherheit verletzt ist.
-
Durch das dynamische Aktualisieren der für die Vorprüfungskomponente bestimmten Teilmenge von Sicherheitsregeln wird der Bereich von Sicherheitsregeln vergrößert, den der Vorprüfungsmechanismus erfassen könnte, und für die zweite Klasse von Benutzern ist es schwer, mithilfe von Eingabeversuchen Informationen über Sicherheitsregeln zu erhalten, da der Aktualisierungsvorgang und der aktualisierte Inhalt vollständig von den serverseitigen Schutzmitteln abhängen. Auf diese Weise werden die Genauigkeit der Vorprüfung und die Systemsicherheit erhöht.
-
Das Verfahren endet in Schritt S260.
-
Da die technische Lösung gemäß der vorliegenden Erfindung die Klassen von Benutzern wirksam unterscheiden kann, können die Schutzmittel so konfiguriert werden, dass sie verschiedene sicherheitsorientierte Schutzmaßnahmen im Hinblick auf „eine erste Klasse von Benutzern” und „eine zweite Klasse von Benutzern” durchführen, die ermittelt wurde. Gegenüber „der zweiten Klasse von Benutzern”, die eher als „bösartige Benutzer” einzuordnen sind, können z. B. solche sicherheitsgerichteten Schutzmaßnahmen wie das zwangsweise Abblocken aller folgenden Eingabeanforderungen dieser Benutzer oder das Blockieren der IP-Adresse ergriffen werden; gegenüber „der ersten Klasse von Benutzern”, die eher als „unschuldige Benutzer” einzuordnen sind, wird eine sicherheitsorientierte Schutzmaßnahme ergriffen, die der Aufrechterhaltung der guten Benutzererfahrung dient, z. B. das Abweisen von Anforderungen und das Senden eines benutzerfreundlichen Sicherheitshinweises und/oder das Neuschreiben der Nutzdaten.
-
Im Folgenden wird die technische Lösung gemäß der vorliegenden Erfindung anhand eines Beispiels eingehender beschrieben, das den Ablauf und das Zusammenspiel zwischen Komponenten auf der Serverseite und auf der Clientseite zeigt.
-
3 veranschaulicht einen Ablaufplan der serverseitigen Schutzmittel und der clientseitigen Vorprüfungskomponente gemäß einer Ausführungsform der vorliegenden Erfindung.
-
Wie in 3 gezeigt wird in Schritt S301 eine Menge vordefinierter Sicherheitsregeln in den Schutzmitteln 10 eingerichtet. Diese Menge von Sicherheitsregeln kann anwendungsspezifische Regeln und Negativregeln umfassen. Es versteht sich, dass dieser Schritt asynchron zum Benutzereingabeprozess durchgeführt wird, und normalerweise durchgeführt wird, während die Schutzmittel 10 installiert werden.
-
In Schritt S302 schreiben die Schutzmittel die Antwortseite der Anwendung neu, um eine eigenständige Javascript-Vorprüfungskomponente in die Antwortseite der Anwendung einzufügen. Gemäß einer Realisierung der vorliegenden Erfindung kann die Javascript-Vorprüfungskomponente durch den Code in Tabelle 2 realisiert sein.
-
Tabelle 2: Codebeispiel für die Javascript-Vorprüfungskomponente, die durch die Schutzmittel eingefügt wird
-
In Schritt S303 wird die Javascript-Vorprüfungskomponente im Client-Browser 11 ausgeführt.
-
Die Javascript-Vorprüfungskomponente fügt zu jedem Eingabefeld auf der Seite eine Überwachungseinrichtung für onPropertyChange-Ereignisse hinzu, um den Vorprüfungsprozess bei einer Benutzereingabe zu aktivieren, indem ein onPropertyChange-Ereignis in einem Benutzereingabefeld überwacht wird. Die Javascript-Vorprüfungskomponente stellt ferner Mittel bereit, um eine Sicherheitsrichtliniendatei von den Schutzmitteln 10 zu erhalten, wobei die Sicherheitsrichtliniendatei eine Regelteilmenge der Sicherheitsregeln in den Schutzmitteln 10 darstellt.
-
Tabelle 3: Codebeispiel für das Hinzufügen einer Überwachungseinrichtung für das onPropertyChange-Ereignis
-
In Schritt S304 aktualisieren bzw. senden die Schutzmittel 10 die Sicherheitsrichtliniendatei an die Javascript-Vorprüfungskomponente im Client-Browser 11. Die in der Sicherheitsrichtliniendatei enthaltene Teilmenge von Sicherheitsregeln wird anhand der Statistik der von den Schutzmitteln 10 erkannten Regelverletzungsprotokolle aus der Gesamtmenge der Sicherheitsregeln in den Schutzmitteln 10 herausgefiltert. Die Sicherheitsrichtliniendatei kann eine Liste von Eingabefeldern und entsprechenden Eingabemustern mit einer hohen Regelverletzungsrate umfassen.
-
In Schritt S305 erhält die Javascript-Vorprüfungskomponente im Client-Browser 11 die Sicherheitsrichtliniendatei von den serverseitigen Schutzmitteln 10.
-
In Schritt S306 prüft die Javascript-Vorprüfungskomponente im Client-Browser 11 anhand einer Sicherheitsregel in der Sicherheitsrichtliniendatei ein Benutzereingabefeld als Reaktion auf ein onPropertyChange-Ereignis im Eingabefeld. Bei einer Realisierung kann die Funktion des Aktivierens der Vorprüfung durch den Code in Tabelle 4 realisiert sein.
-
Tabelle 4: Codebeispiel für das Aktivieren der Vorprüfung anhand der von den Schutzmitteln erhaltenen Sicherheitsrichtliniendatei
-
-
Wenn die Regelverletzung eines Benutzereingabewertes erkannt wird, wird dem Benutzer ein freundlicher Hinweis bereitgestellt, z. B. in Form eines Beispiels korrekter Eingabewerte und der Angabe des Fehlers im gegenwärtigen Eingabewert, sodass der Benutzer anhand des Hinweises eine korrekte Eingabe im Eingabefeld vornehmen kann.
-
In Schritt S307 sendet der Client-Browser 11 die HTTP-Anforderung des Benutzers an die serverseitigen Schutzmittel 10. Anzumerken ist, dass nicht alle der Eingabewerte des Benutzers durch die Javascript-Vorprüfungskomponente vorgeprüft werden, da die Javascript-Vorprüfungskomponente anhand der Sicherheitsrichtliniendatei unter Umständen nur einen Teil von Eingabefeldern oder Sicherheitsregeln prüft. Anders ausgedrückt, die vom Client-Browser 11 an die Schutzmittel 10 gesendete HTTP-Anforderung des Benutzers könnte vorgeprüfte Benutzereingabewerte oder Benutzereingabewerte umfassen, die noch nicht vorgeprüft sind. Es ist klar, dass die vorgeprüften Benutzereingabewerte den Sicherheitsregeln entsprechen, während die noch nicht vorgeprüften Benutzereingabewerte möglicherweise Sicherheitsregeln verletzen.
-
Unter Berücksichtigung des Vorstehenden prüfen die serverseitigen Schutzmittel 10 in Schritt S308 anhand der vordefinierten Menge von Sicherheitsregeln alle in der HTTP-Anforderung enthaltenen Benutzereingabewerte.
-
In Schritt S309 wird bei Erkennung eines Regelverletzung ermittelt, ob die verletzte Sicherheitsregel der clientseitigen Javascript-Vorprüfungskomponente aktualisiert wurde.
-
Wenn die Schutzmittel 10 eine Regelverletzung erkennen und die verletzte Sicherheitsregel der clientseitigen Javascript-Vorprüfungskomponente nicht aktualisiert wurde, wird in Schritt S311 der entsprechende Benutzer als zur „ersten Klasse von Benutzern” gehörig ermittelt. Diese erste Klasse von Benutzern ist eher als eine Klasse von unschuldigen Benutzern einzuordnen.
-
In Schritt S312 wird eine sicherheitsorientierte Schutzmaßnahme, die der Aufrechterhaltung der guten Benutzererfahrung dient, gegenüber der „ersten Klasse von Benutzern” ergriffen, z. B. durch Neukonfigurieren der Anforderung (Anforderung neu schreiben) und Senden der Anforderung an den Anwendungsserver. Diese erste Klasse von Benutzern ist eher als eine Klasse von unschuldigen Benutzern einzuordnen.
-
Wenn die Schutzmittel 10 eine Regelverletzung erkennen und die verletzte Sicherheitsregel der clientseitigen Javascript-Vorprüfungskomponente aktualisiert wurde, wird in Schritt S313 der entsprechende Benutzer als zur „zweiten Klasse von Benutzern” gehörig ermittelt. Dies geschieht deshalb, weil der Benutzer einen die Sicherheitsregel verletzenden bösartigen Wert direkt auf den Anwendungsserver einschleust, nachdem er den Vorprüfungsmechanismus im Client-Browser mithilfe eines Programms umgangen hat.
-
In Schritt S314 wird gegenüber der ermittelten „zweiten Klasse von Benutzern” eine sicherheitsorientierte Schutzmaßnahme ergriffen, die zwangsweise alle folgenden Anforderungen abblockt, z. B. durch Blockieren der IP-Adresse.
-
Für den Fachmann ist klar, dass bei unterschiedlichen Webanwendungen entsprechend den jeweils festgestellten Benutzern unterschiedliche sicherheitsorientierte Schutzmaßnahmen gegenüber „der zweiten Klasse von Benutzern” bzw. gegenüber der „ersten Klasse von Benutzern” ergriffen werden müssen. Der Fachmann kann sicherheitsorientierte Schutzmaßnahmen mit unterschiedlichen Einstufungen oder unterschiedlichen Merkmalen festlegen, die den konkreten Anwendungsanforderungen entsprechen, und diese sicherheitsorientierten Schutzmaßnahmen der ermittelten „zweiten Klasse von Benutzern” bzw. „ersten Klasse von Benutzern” zuweisen.
-
Es soll darauf hingewiesen werden, dass, obwohl die Javascript-Vorprüfungskomponente als Beispiel zur Beschreibung einer speziellen Ausführungsform der vorliegenden Erfindung in 3 verwendet wird, eine beliebige mit Webanwendungen kompatible Code-Sprache verwendet werden kann, um die Vorprüfungskomponente zu realisieren, z. B. VBscript. Darüber hinaus kann der Fachmann die Vorprüfungskomponente in einer beliebigen bekannten Weise auf dem Client installieren. Eine weitere Realisierung kann z. B. das Bereitstellen eines bestimmten Zusatzprogramms auf dem Client umfassen, um die Vorprüfungskomponente aktiv zu empfangen. Daher schränken konkrete Realisierungen der Vorprüfungskomponente die vorliegende Erfindung nicht ein.
-
4 veranschaulicht schematisch ein Funktionsblockdiagramm eines Sicherheitsprüfungssystems gemäß einer Ausführungsform der vorliegenden Erfindung.
-
Wie in 4 dargestellt sendet der Client-Browser 11 eine HTTP-Anforderung an den Webanwendungsserver 13 und erhält eine entsprechende Antwort vom Webanwendungsserver 13. Die serverseitigen Schutzmittel 10 führen anhand der Menge vordefinierter Sicherheitsregeln gegenüber der Anforderung vom Benutzer eine Eingabeprüfung durch, um die Sicherheit des Webanwendungsservers 13 zu garantieren.
-
Die Schutzmittel 10 umfassen Folgendes: optionale Installationsmittel 101 zum Installieren einer Vorprüfungskomponente auf einem Client-Browser; Aktualisierungsmittel 102 zum Bereitstellen oder aktualisieren einer Teilmenge von Sicherheitsregeln für eine clientseitige Vorprüfungskomponente; Gültigkeitsprüfungsmittel 103 zum Durchführen einer Eingabeprüfung gegenüber einer Anforderung von einem Benutzer, wobei die Eingabeprüfung anhand einer vordefinierten Menge von Sicherheitsregeln durchgeführt wird; und Ermittlungsmittel 104 zum Ermitteln eine Klasse von regelverletzenden Benutzern, wobei „eine erste Klasse von Benutzern” als eher unschuldige Benutzer bzw. „eine zweite Klasse von Benutzern” als eher bösartige Benutzer einzuordnen ist.
-
Bei den Schutzmitteln 10 fügen die Installationsmittel 101 alternativ eine Javascript-Komponente in die Antwortseite einer Anwendung ein, indem die Antwortseite der Anwendung neu geschrieben und eine Vorprüfungskomponente 110 auf dem Client-Browser 11 installiert wird. Die Aktualisierungsmittel 102 senden oder aktualisieren in regelmäßigen oder unregelmäßigen Abständen eine Sicherheitsrichtliniendatei zur Vorprüfungskomponente 110 im Client-Browser 11, wobei eine in der Sicherheitsrichtliniendatei enthaltene Teilmenge von Sicherheitsregeln anhand der Statistik der von den Schutzmitteln 10 erkannten Regelverletzungsprotokolle aus der Gesamtmenge der Sicherheitsregeln in den Schutzmitteln 10 herausgefiltert wird.
-
Die Vorprüfungskomponente 110 wird auf dem Client-Browser 11 ausgeführt, erhält die Sicherheitsrichtliniendatei von den serverseitigen Schutzmitteln 10 und prüft anhand einer Sicherheitsregel in der Sicherheitsrichtliniendatei ein Benutzereingabefeld, um zu gewährleisten, dass eine Benutzereingabe die aktuelle Teilmenge von Sicherheitsregeln nicht verletzt. Der Client-Browser 11 sendet die HTTP-Anforderung des Benutzers an den Webanwendungsserver 13.
-
Die Prüfungsmittel 103 in den Schutzmitteln 10 prüfen anhand der vordefinierten Menge von Sicherheitsregeln alle Benutzereingabewerte in der HTTP-Anforderung vom Benutzer. Nach der Erkennung einer Regelverletzung bewerten die Ermittlungsmittel 104, ob die verletzte Sicherheitsregel der Vorprüfungskomponente im Client-Browser 11 aktualisiert wurde. Wenn die verletzte Sicherheitsregel der Vorprüfungskomponente 110 im Client-Browser 11 nicht aktualisiert wurde, ermitteln die Ermittlungsmittel 104 dann den Benutzer als zu „einer ersten Klasse von Benutzern” gehörig. Wenn die verletzte Sicherheitsregel der Vorprüfungskomponente 110 im Client-Browser aktualisiert wurde, ermitteln die Ermittlungsmittel 104 dann den Benutzer als zu „einer zweiten Klasse von Benutzern” gehörig. Die Schutzmittel können so konfiguriert sein, dass sie verschiedene sicherheitsorientierte Schutzmaßnahmen gegenüber der ermittelten ersten Klasse von Benutzern und gegenüber der zweiten Klasse von Benutzern durchführen. Beispielsweise wird gegenüber der ermittelten ersten Klasse von Benutzern eine sicherheitsorientierte Schutzmaßnahme ergriffen, die der Aufrechterhaltung der guten Benutzererfahrung dient, z. B. das Neuschreiben der Anforderung (Anforderung neu schreiben); gegenüber der ermittelten zweiten Klasse von Benutzern wird eine sicherheitsorientierte Schutzmaßnahme ergriffen, die zwangsweise alle folgenden Anforderungen abblockt, z. B. das Blockieren der IP-Adresse.
-
Gemäß dem Sicherheitsprüfungsschema der vorliegenden Erfindung installieren die Schutzmittel auf der Seite des Webanwendungsservers eine Vorprüfungskomponente auf dem Client und stellen dieser Vorprüfungskomponente Vorprüfungssicherheitsregeln bereit und aktualisieren vorzugsweise dynamisch die Vorprüfungssicherheitsregeln. Daher können die Schutzmittel nach der Erkennung eines regelverletzenden Benutzereingabewertes durch die Entscheidung darüber, ob die verletzte Regel durch die clientseitige Vorprüfungskomponente geprüft wurde, ermitteln, ob der Benutzer zu „einer zweiten Klasse von Benutzern” gehört, d. h., der Benutzer sendet bösartigen Logikcode direkt auf den Webanwendungsserver, nachdem er den clientseitigen Vorprüfungsmechanismus mithilfe ungesetzlicher Mittel umgangen hat. Es ist gemäß der technischen Lösung der vorliegenden Erfindung offensichtlich möglich, wirksam zwischen „einer zweiten Klasse von Benutzern” und „einer ersten Klasse von Benutzern” zu unterscheiden, sodass die Schutzmittel so konfiguriert werden können, dass sie unterschiedliche Lösungen auf unterschiedliche Benutzer anwenden, d. h. unterschiedliche sicherheitsorientierte Schutzmaßnahmen durchführen. Gemäß einer Ausführungsform der vorliegenden Erfindung ist es möglich, die Benutzererfahrung „einer ersten Klasse von Benutzern” in Bezug auf eine Webanwendung so weit wie möglich zu gewährleisten und den nutzlosen Verbrauch von Systemleistung in einem maximalen Umfang zu vermeiden. Außerdem kann ein Teil des Prüfungsprozesses auf der Clientseite durchgeführt werden, indem ein Vorprüfungsmechanismus auf der Clientseite angeordnet wird, der dazu beiträgt, die Auslastung der serverseitigen Schutzmittel zu verringern und dementsprechend die Leistung des gesamten Gültigkeitsprüfungssystems zu erhöhen.
-
Wie für den Fachmann aus der vorstehenden Beschreibung konkreter Ausführungsformen ohne Weiteres ersichtlich ist, können das vorstehend genannte Verfahren, die vorstehend genannte Vorrichtung und entsprechende Systeme mithilfe von auf dem Computer ausführbaren Anweisungen und/oder mithilfe von Steuercode realisiert sein, der in einem Prozessor enthalten ist. Beispielsweise wird derartiger Code auf einem Trägermedium wie z. B. einer Magnetplatte, CD oder DVD-ROM, in einem programmierbaren Speicher wie z. B. einem Nur-Lese-Speicher (Firmware) oder auf einem Datenträger wie z. B. einem optischen oder elektronischen Signalträger bereitgestellt. Die Mittel und Einheiten in den Ausführungsformen der vorliegenden Erfindung können wie folgt realisiert werden: durch eine Hardwareschaltung wie z. B. durch ein VLSI- oder Gate-Array, durch Halbleiter wie z. B. durch einen Logikchip und einen Transistor oder durch eine programmierbare Hardwareeinheit wie z. B. durch ein vor Ort programmierbares Gate-Array und eine programmierbare Logikeinheit oder durch Software, die auf verschiedenen Arten von Prozessoren ausgeführt wird, oder durch eine Kombination der Hardwareschaltung und Software.
-
Die Beschreibung der vorliegenden Erfindung dient der Veranschaulichung und Beschreibung, ist jedoch nicht als erschöpfend oder einschränkend in Bezug auf die Erfindung in der beschriebenen Form gedacht. Vielen Abänderungen und Variationen sind für den Fachmann klar.
-
Daher wurden die Ausführungsformen ausgewählt und beschrieben, um die Grundgedanken und die praktische Anwendung der Erfindung auf bestmögliche Weise zu erklären und anderen Fachleuten das Verständnis dafür zu ermöglichen, dass alle Abänderungen und Umbauten keine Abweichung vom Geltungsbereich der vorliegenden Erfindung darstellen.
