Cross Site Scripting Angriffe

Vom Front-End bis SOAP.

Moderator: Moderatoren

STEPHAN
UDF-Programmierer
UDF-Programmierer
Beiträge: 95
Registriert: Do, 29. Mai 2008 20:46

Cross Site Scripting Angriffe

Beitrag von STEPHAN » Mo, 01. Jan 2018 15:11

Habt jemand einen Filter, der Cross Site Scripting Angriffe über Web-Eingabefelder filtert?

Ist betsimmt nicht schwer, wenn man weiss, was man filtern muss. Ich nutze xb2net.

In PHP gibt es da z.B.

filter_var(‘mark<script>@example.com’, FILTER_SANITIZE_EMAIL) markscript@example.com Sanitize emails.
filter_var(‘Testing <tags> & chars.’, FILTER_SANITIZE_SPECIAL_CHARS) Testing &#60;tags&#62; &#38; chars. Encode special chars.
filter_var(‘Strip <tag> & encode.’, FILTER_SANITIZE_STRING); Strip & encode. Remove tags.
filter_var(‘Strip <tag> & encode.’, FILTER_SANITIZE_STRING, FILTER_FLAG_ENCODE_LOW | FILTER_FLAG_ENCODE_HIGH | FILTER_FLAG_ENCODE_AMP) Strip &#38; encode. Remove tags with extra encoding flags.

ramses
1000 working lines a day
1000 working lines a day
Beiträge: 893
Registriert: Mi, 28. Jul 2010 17:16

Re: Cross Site Scripting Angriffe

Beitrag von ramses » Mo, 01. Jan 2018 21:18

Welche Datenbank verwendest du?
(DBF's oder SQL)

Gruss Carlo

STEPHAN
UDF-Programmierer
UDF-Programmierer
Beiträge: 95
Registriert: Do, 29. Mai 2008 20:46

Re: Cross Site Scripting Angriffe

Beitrag von STEPHAN » Mo, 01. Jan 2018 22:16

DBF.

Warum spielt das eine Rolle?

ramses
1000 working lines a day
1000 working lines a day
Beiträge: 893
Registriert: Mi, 28. Jul 2010 17:16

Re: Cross Site Scripting Angriffe

Beitrag von ramses » Di, 02. Jan 2018 7:16

Hallo Stephan

wenn du xb2net verwendest ist ein Eingabefeld ein String den du als String in ein Feld einer Datenbank schreibst oder mit val() zu einer Ziffer wandelst. Hier musst du höchstens prüfen dass der String die Werte enthält die deine Anwendung benötigt. Weitere Filter sind nicht nötig.

Unter SQL werden Strings aus Eingabefelder zu einem Befehls String zusammengesetzt der dann durch die Datenbank ausgeführt wird "execute" hier musst "Mann" aufpassen dass sich im Eingabefeld nicht Teile(Zeichen) befinden die als unterbefehl durch die Datenbank auch noch ausgeführt werden können. Unter PHP werden meist SQL Datenbanken eingesetzt deshalb ist da die Problematik da sehr ernst.

Wenn du allerdings natives Postgesql verwendest gäbe es da auch eine Funktionen die einen String aus einem Eingabefeld mit einem Aufruf zu einem gefahrlosen String wandelt.

Gruss Carlo

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14284
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von brandelh » Di, 02. Jan 2018 8:35

Zu SQL ist der Fachbegriff "SQL-Injection" schau mal hier zur Erklärung warum das gefährlich ist, wenn man SQL falsch aufruft !

:arrow: https://de.wikipedia.org/wiki/SQL-Injection
im Gegensatz zu ...
:arrow: https://de.wikipedia.org/wiki/Cross-Site-Scripting

Das trifft grundsätzlich nicht nur SQL, sondern auch DBF, wenn man aus der Eingabe ohne Prüfung eine Macro Befehlszeile aufbaut.
Allerdings zielt normalerweise keiner mehr auf DBASE Befehlszeilen, aber viel sicherer ist es Parameter als Parameter zu kennzeichnen und als Variable zu übergeben.

Script-Sprachen - vermute ich - sind grundsätzlich anfälliger, insbesondere wenn sie sehr bekannt sind.

Wenn man Variablen verwendet, kann man zwar jeden Schrott eingeben, aber weder die Xbase++ Runtime noch ein SQL Server werden es als Anweisung behandeln.
Hier ein Beispiel mit SQL-Express *** falsches Beispiel *** :

Code: Alles auswählen

cParameter := "("+cI+",'Hugo','Müller')"
oStmt:SQLString := "INSERT INTO KUNDE (id,vorname,name) VALUES "+cParameter
Jeder erkennt sofort, dass die Felder id, vorname, name mit dem Inhalt aus cParameter gefüllt werden sollen.
Auch wenn einer hier einen Befehl angehängt hätte 'Müller; drop database ;', würde der SQL Server nur den "seltsamen Namen" speichern ;-)
Gruß
Hubert

ramses
1000 working lines a day
1000 working lines a day
Beiträge: 893
Registriert: Mi, 28. Jul 2010 17:16

Re: Cross Site Scripting Angriffe

Beitrag von ramses » Di, 02. Jan 2018 9:12

Hubert

nein, wenn du dein Eingabefeld Müller nicht überprüfts ist es sehr einfach ein drop database einzufügen welches dann auch ausgeführt wird. Ich verzichte jetzt auf Details um nicht Anleitung für üble Sachen bereitzustellen.

Postgresql bietet Funktionen wie PQescapeIdentifier() und andere mit welchen Strings aus Eingabefeldern entsprechend geprüft und bearbeitet werden können.

Der entsprechende Tip aus dem Handbuch:
It is especially important to do proper escaping when handling strings that were received from an untrustworthy source. Otherwise there is a security risk: you are vulnerable to "SQL injection" attacks wherein unwanted SQL commands are fed to your database.

Macros sind kein guter Programmierstil, an die habe ich gar nicht mehr gedacht. Grundsätzlich hast du damit recht.

Gruss Carlo

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14284
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von brandelh » Di, 02. Jan 2018 9:51

Stimmt, das obige Beispiel baut ja eine SQL Befehlszeile auf, die später ausgeführt wird ... falsches Beispiel !

Dies war der SQL-Express Code, mit dem die Injektion nicht mehr funktionierte:

Code: Alles auswählen

      
      if oStmt:Execute() != SQL_XPP_ERROR
         oStmt:SQLString := "INSERT INTO Kunde (id, vorname, name) VALUES (?,?,?)"
         oStmt:Prepare()
         for i := 1 to nMaxAnzahl
             aPara[1] :=  i
             aPara[2] :=  cVorName[i]
             aPara[3] :=  cName[i] + "egal was für einen Schrott ..."
             if oStmt:Execute(aPara) = SQL_XPP_ERROR
                FehlerMelden()
                exit
             endif
         next
      else
         msgbox(oStmt:errorMessage,"ODCB - Fehlermeldung:")
      endif
Ob jetzt SQL-Express das gefiltert hat oder die Verarbeitung im Server anders ist, kann ich aber auch nicht beurteilen.
Wie gesagt ist lange her. Aber egal was ich an aPara[3] übergeben hatte, es wurde in dem Textfeld einfach gespeichert.
Gruß
Hubert

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7086
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von Tom » Di, 02. Jan 2018 10:00

Macros sind kein guter Programmierstil
Bullshit.
Herzlich,
Tom

ramses
1000 working lines a day
1000 working lines a day
Beiträge: 893
Registriert: Mi, 28. Jul 2010 17:16

Re: Cross Site Scripting Angriffe

Beitrag von ramses » Di, 02. Jan 2018 12:09

@Hubert

dann wird die erwähnte Prüfung des Feldinhalts sicher durch Sql-Epress durchgeführt. Denn ohne geht es nicht.

@Tom

In xbase sind Makros Texte aus Zeichen die erst zur Laufzeit des Programms in Code übersetzt werden. Das Verwenden von Macros in Xbase ist meiner Meinung nach Ursache für viele Probleme und Sorgen. Du kannst meine Meinung durchaus als "Bullshit" betrachten für mich sind und bleiben diese schlichtweg schlechter Programmierstil und ein unter allen Umständen zu vermeidendes Element.


Gruss Carlo

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7086
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von Tom » Di, 02. Jan 2018 12:20

Hallo, Carlo.

Genau. Makros erlauben es, zur Laufzeit Code zu generieren und auszuführen. Datengetriebene Programme und komplexe frei gestaltbare Oberflächen sind damit möglich, dazu durchaus elegante Codevereinfachungen, die man mit detached locals oder ähnlichen Verfahren nicht hinkriegt. Man kann seinen eigenen Interpreter (ein)bauen und sogar eine Art Scriptsprache anbieten - all das mache ich. Und das ist kein "schlechter Programmierstil", sondern die bewusste und sinnvolle Anwendung eines sehr starken Werkzeugs. Deshalb folgte auf Deine Anmerkung die meine. :wink: Es gibt Dos und Don'ts noch und nöcher, über die man sprechen könnte, aber Makros sind keine Don'ts, wenn man sie "richtig" einsetzt.

Natürlich sollte man keine Makros verwenden, um den Inhalt von Eingabefeldern direkt zu verarbeiten. Aber - macht das jemand? Und wenn ja, warum? :oops:
Herzlich,
Tom

ramses
1000 working lines a day
1000 working lines a day
Beiträge: 893
Registriert: Mi, 28. Jul 2010 17:16

Re: Cross Site Scripting Angriffe

Beitrag von ramses » Di, 02. Jan 2018 17:55

Hallo Tom

wir haben nun beide "unsere" Macro - Standpunkte dargestellt und ich denke dies ist als Forumsbeiträge genug.

Noch zu den Oberflächen:
Ich und ein Team Web-Spezi bemühen uns seit Monaten in meinen Programmen den ADS-Server und alles Xbase++ GUI zu entfernen und alles als Web-App mit xb2net, PostgreSQL, HTML5-CSS-JQuery ... und wie die alle heisen umzubauen. Ich sehe nur darin die Zukunft und komplexe frei gestaltbare Oberflächen sind erst damit so richtig möglich. (Natürlich ohne Macros.)

Ich hoffe wir könnten das Thema bei einem Glas Bier weiterdiskutieren es wäre sicher sehr interessant.....

Gruss Carlo

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7086
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von Tom » Di, 02. Jan 2018 18:50

Hallo, Carlo.
wir haben nun beide "unsere" Macro - Standpunkte dargestellt und ich denke dies ist als Forumsbeiträge genug.
Wenn Du das denkst, dann sei es auch so, aber ich erlaube mir dennoch die Anmerkung, dass ich meinen Standpunkt argumentativ unterfüttert habe, während Du lediglich von "schlechtem Programmierstil" und von einer "Ursache für viele Probleme und Sorgen" gesprochen hast, die man "um jeden Preis vermeiden" sollte. Warum genau Du so denkst, hast Du nicht erklärt.
Herzlich,
Tom

georg
Foren-Administrator
Foren-Administrator
Beiträge: 2053
Registriert: Fr, 08. Feb 2008 21:29

Re: Cross Site Scripting Angriffe

Beitrag von georg » Di, 02. Jan 2018 20:00

Hallo,


zwei Gedanken zum Hauptthema.

1. Über ein Webformular eingegebene Daten schleuse ich IMMER durch ein $mysqli:real_escapce_string(). Die Funktion entschärft kritische Zeichen/Strings/Begriffe, indem sie in eine Form gebracht werden, die von der Datenbankschnittstelle dann als reiner Text intepretiert wird. Wenn man bei einer offenen Datenbank mal die Abfragen protokolliert, dann sieht man, dass mindestens einmal am Tag ein Script-Kiddie versucht, eine Schwachstelle beim Schreiben in die Datenbank zu finden.

2. Im schlimmsten Fall wirst Du die im ersten Beitrag angefragten PHP-Funktionen in Xbase++ neu schreiben müssen, das dürfte aber aus meiner Sicht kein so grosser Aufwand sein.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.

ramses
1000 working lines a day
1000 working lines a day
Beiträge: 893
Registriert: Mi, 28. Jul 2010 17:16

Re: Cross Site Scripting Angriffe

Beitrag von ramses » Di, 02. Jan 2018 20:14

Hallo Tom

du hast recht. Ich habe zu meinem Standpunkt keine Argumente geliefert. Meine Meinung hast du bereits mit "Bullshit" bedeckt. Ich wusste nicht was nachher kommt daher dachte ich es wäre besser nicht weiter zu schreiben.

Ich liefere dir gerne meine Argumente nach.

Seit Clipperzeiten haben wir Fehler jeweils analysiert. Den meisten Zeitaufwand und Probleme hatten wir mit Fehlern die in Macros auftraten. Dies waren oft Fehler die sporadisch auftraten und uns sehr viel Aerger verursachten. Im Vorteil der Codeerstellung/Übersetzung zur Laufzeit steht leider ein grosser Nachteil gegenüber. Der Code wird erst zur Laufzeit geprüft und die Funktion eines Macros ist meist schlechter lesbar. Die ganze Variablenprüfung usw. wechle der Compiler/Linker schon während der Entwicklung und dem Test übernimmt wird bei Macros erst zur Laufzeit beim Kunden durchgeführt und sichtbar. Dies dann meist nur noch zur Fehlermeldung und Programmabbruch führt. Anfangs der 00er Jahre noch vor xbase++ beschloss unser Team aus oben erwähnten Gründen Macros als "schlechten" Stil zu bezeichnen und darauf zu verzichten. Viele Sorgen sind damit verschwunden. Sicher hat sich seitdem einiges geändert, die Macrolänge ist nicht mehr begrenzt(verhindert viele Fehler), es gibt Fernwartung-die Fahrten entfallen, wir sind auch nicht mehr ein Team. Ich finde Code ohne Macros übersichtlicher vorallem bei Nacharbeiten. Aus diesen Gründen finde ich Macros noch immer schlechter Stil.

Gruss Carlo

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7086
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von Tom » Mi, 03. Jan 2018 9:29

Hallo, Carlo.
Meine Meinung hast du bereits mit "Bullshit" bedeckt.
Ich habe das auf die Aussage, Makros wären "schlechter Programmierstil" und "um jeden Preis zu vermeiden" geantwortet, was ja ebenfalls nicht besonders substantiell war. :wink:

Es ist richtig, was Du schreibst. Syntaxfehler in Makros treten erst zur Laufzeit auf. Wenn in Makros substituierte Variableninhalte verwendet werden, die wiederum Sonderzeichen enthalten, die im Makro interpretiert werden könnten (Klassiker: Anführungszeichen, aber auch geschweifte Klammern), kommt es zu Fehlern. Variablen, die in Makros verwendet werden, müssen PRIVATE oder PUBLIC sein, womit sorgfältig umgegangen werden muss, vor allem in Multithreading-Situationen. Man muss vorsichtig sein, aber das muss man immer. Es gibt wahrscheinlich ein paar Leute unter uns, die Passwörter klarschriftlich in irgendwelchen frei zugänglichen Tabellen ablegen. Oder andere Daten, die diskret behandelt werden müssten. Viele werden mit Cut&Paste arbeiten, wenn ähnlicher Code verwendet wird. Manch einer verwendet möglicherweise PRIVATEs, um Informationen in Funktionen manipulieren zu können, die nicht per Referenz an diese Funktionen übergeben werden. All das ist nicht so guter Programmierstil, und es gibt noch vieles mehr davon. Aber die Verwendung von Makros ist nicht grundsätzlich schlechter Programmierstil. Wenn man sorgfältig damit umgeht und den möglichen Schwierigkeiten entsprechend begegnet, hat man ein mächtiges Werkzeug, das es so in nicht sehr vielen Sprachen gibt. Schlechter Programmierstil wäre, Makros ohne Rücksicht auf die genannten Risiken und ähnliche einzusetzen.
Herzlich,
Tom

Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1884
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von Herbert » Mi, 03. Jan 2018 16:51

Interessante Diskussion. Danke. Insbesondere die Filterung, Georg.

Aber:
ramses hat geschrieben:
Di, 02. Jan 2018 17:55
Noch zu den Oberflächen:
Ich und ein Team Web-Spezi bemühen uns seit Monaten in meinen Programmen den ADS-Server und alles Xbase++ GUI zu entfernen und alles als Web-App mit xb2net, PostgreSQL, HTML5-CSS-JQuery ... und wie die alle heisen umzubauen. Ich sehe nur darin die Zukunft und komplexe frei gestaltbare Oberflächen sind erst damit so richtig möglich. (Natürlich ohne Macros.)
Das ist Sache der Möglichkeiten, die der Compiler anbietet-. Mittlerweile können wir das im GUI unter Windev sehr elegant. Die vom Benutzer veränderten Fensterelemente werden in einer Datei abgelegt (ähnlich wie aus einem Patch) und bei Laufzeit eingebunden. Natürlich ist das ähnlich einem Macro von der Interpretation her gesehen. Aber beim Aufbau auf dem Bildschirm fällt dies nicht auf und ist sehr reizvoll und elegant. Aber, nur etwa 1% der User tut so was...
Grüsse Herbert
Immer in Bewegung...

STEPHAN
UDF-Programmierer
UDF-Programmierer
Beiträge: 95
Registriert: Do, 29. Mai 2008 20:46

Re: Cross Site Scripting Angriffe

Beitrag von STEPHAN » Mi, 03. Jan 2018 21:41

Hi!

Danke für Eure Antworten. Offensichtlich haben ich mich falsch ausgedrückt und die Diskusion geht in eine Richtung, die nicht gar nicht kannte.

Mir geht es in erste Linie darum, Eingabefelder zu filtern. Ich filtere die sowieso (z.B. bei Zahlen), aber wenn ich z.B. ein Kommentarfeld habe, dann könnte man dort script einschläusen. An manchen Stellen wird dieses Eingabefeld direkt wieder angezeigt, z.B. wenn man das Kontaktformular ausfüllt und keine Rufnummer angibt.

Ja klar kann man da jetzt unzulässige Dinge wegfiltern, aber ich kenne nicht genug HTML Tricks um alles sinnvoll wegzufiltern.

Deshalb dachte ich, das hätte schonmal jemand gemacht.

ramses
1000 working lines a day
1000 working lines a day
Beiträge: 893
Registriert: Mi, 28. Jul 2010 17:16

Re: Cross Site Scripting Angriffe

Beitrag von ramses » Mi, 03. Jan 2018 22:01

@Stephan

Wenn du dein Inhalt des Eingabefelds nicht in einem Marcro verwendest kannst du, solange DBF Daten verwendet werden auf alle Filterungen verzichten. Es lässt sich in der Konfiguration kein Script einschleusen bezw. ausführen.

@Herbert

Ich habe mir WinDev schon angeschaut. Es steckte damals schon zuviel Arbeit in der Web-App um den Server-Code auch noch auf eine andere Plattform zu bringen.


@Tom

Danke. Du schreibst auch von Risiko.
Fehlermanagement = Risiken systematisch entschärfen = Stärker Risikobehaftete Funktionen vermeiden bezw. nicht verwenden = Bessere Qualität

Gruss Carlo

STEPHAN
UDF-Programmierer
UDF-Programmierer
Beiträge: 95
Registriert: Do, 29. Mai 2008 20:46

Re: Cross Site Scripting Angriffe

Beitrag von STEPHAN » Do, 04. Jan 2018 0:54

Es geht nicht um Daten, die in einer DBF landen, sondern um Daten die in einem HTML EIngabefeld stehen und auch wieder in HTML ausgegeben werden.

Der Angriff ist auch eher unwahrscheinlich, aber eine Sicherheitsfirma, die uns prüfen muss, bemängelt, das mit Tricks so Scripts ausgegeben werden.

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 14220
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von Martin Altmann » Do, 04. Jan 2018 7:39

Moin,
nun mische ich mich auch mal ein.

Carlo,
Du erklärst etwas, das Stephan nicht gefragt hat - wenngleich sich beides ähnelt (Angriffe mittels eingeschleustem Programmcode), unterscheidet es ich doch in dem Ziel des Angriffs bzw. dem Ansatzpunkt für den "Dietrich". Schau dir mal Huberts Verweise auf die Wikipedia an.

Stephan,
da ich nicht genug Wissen bezüglich Deiner Installation und Deines Einsatzszenarios habe, kann ich nur bezogen auf meine eigenen Erfahrungen antworten. Wenn Du die selben Voraussetzungen erfüllst, bist Du im Moment noch auf der sicheren Seite und brauchst Dir noch keine Gedanken machen - das sieht aber morgen ganz anders aus (morgen bitte in Relation auf die "Alaska-Zeitschiene" sehen - also ein "Alaska-morgen"). Hier nun meine Umgebung, bei der XSS-Angriffe (derzeit) keine Rolle spielen und (derzeit) keinen Erfolg haben:
  • ich setze Xb2.NET als Webserver ein. Dadurch können nur Skripte auf Clientseite zur Ausführung kommen, da Xb2.NET kein Java oder Pearl o.ä. unterstützt.
  • ich nutze die von Boris vorgeschlagene Variante, den Funktionen, die innerhalb einer Session (also im Ablauf der Transaktion) aufgerufen werden können, ein Prefix voranzustellen, so dass keinerlei Xbase++-interne Kommandos wie quit ausgeführt werden können. Innerhalb des onGET- und onPOST-slots werden die entsprechenden Aufrufe durch hinzufügen des entsprechendes Prefixes entschärft - aus quit würde halt Mein_Persoenlicher_Prefix_quit. Da es diese Funktion bei mir nicht gibt, würde eine entsprechender Fehlermeldung im Webbrowser erscheinen (bzw. in meinem Fall einfach ein redirect auf die index-Seite erfolgen).
  • Der Webserver dient nur den Klienten meiner Kunden zur Erfassung der Daten. Meine Kunden greifen auf die Daten im Backend mittels einer Anwendung unter Xbase++ zu.
Würdest Du also den WAA einsetzen und somit den IIS oder Apache nutzen, müsstest Du dir Gedanken zur Vermeidung von XSS machen, da diese Webserver natürlich auch Skripte auf dem Server ausführen können (und damit eine entsprechende Vulnerabiltiy (Verletzlichkeit/Angreifbarkeit) aufweisen). In meinem Fall würden die Skripte ja nur im Webbrowser des Angreifers ausgeführt werden - eine Abfrage der Hardwareumgebung des Servers wäre somit z.B. nicht möglich.
Würdest Du auf die eingegebenen Daten ebenfalls per Webbrowser zugreifen, müsstest Du Dir ebenfalls Gedanken zur Vermeidung von XSS machen - ansonsten kämen die eingeschleusten Skriptanweisungen in dem Webbrowser bei der Bearbeitung der Daten zum Zuge!
Wenn Alaska morgen die Xbaseparts abgeschafft und alles auf die WebUI umgestellt hat, muss man sich immer Gedanken zur Vermeidung von XSS machen - in dem Fall ist auch die Anwendung als solches davon betroffen (auch ohne Xb2.NET, ISS oder Apache im Einsatz).

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

ramses
1000 working lines a day
1000 working lines a day
Beiträge: 893
Registriert: Mi, 28. Jul 2010 17:16

Re: Cross Site Scripting Angriffe

Beitrag von ramses » Do, 04. Jan 2018 12:46

Hallo Martin

nun hat Stepan den eigentlichen Kern der Frage dargestellt. Dieses Szenario eröffnet natürlich völlig neue Wege.....

Bei genügend langen Feldern könnte da doch schon einiges auf den Client-Browsern angerichtet werden. Was dann eine gewisse Filterung erfordert.

Gruss Carlo

STEPHAN
UDF-Programmierer
UDF-Programmierer
Beiträge: 95
Registriert: Do, 29. Mai 2008 20:46

Re: Cross Site Scripting Angriffe

Beitrag von STEPHAN » Sa, 06. Jan 2018 14:44

Da offensichtlich niemand einen Filter fertig hat - irgendwelche Vorschläge, was man filtern sollte?

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7086
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von Tom » Sa, 06. Jan 2018 15:33

Hallo, Martin.
Wenn Alaska morgen die Xbaseparts abgeschafft und alles auf die WebUI umgestellt hat, muss man sich immer Gedanken zur Vermeidung von XSS machen - in dem Fall ist auch die Anwendung als solches davon betroffen
Das halte ich für unwahrscheinlich. Alaska setzt für die WebUI einen eigenen bzw. eigens dafür angeschafften HTML-Rendering-Client ein; es wird keine Instanz irgendeines Browsers etabliert.
Herzlich,
Tom

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 14220
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: Cross Site Scripting Angriffe

Beitrag von Martin Altmann » Sa, 06. Jan 2018 16:38

Tom,
das kommt ganz darauf an, was der Client alles an Befehlen unterstützt!
Er wird auf jeden Fall Dinge nachladen können (per Referenzverweis auf CSS ist das ja im Prinzip schon drin) und Zugriff auf die Laufwerke hat er natürlich im Prinzip auch. Die Frage ist halt, wie weit Alaska das noch aufbohrt. Sie wollen jedenfalls alle Controls durch WebUI-Elemente ersetzen.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

STEPHAN
UDF-Programmierer
UDF-Programmierer
Beiträge: 95
Registriert: Do, 29. Mai 2008 20:46

Re: Cross Site Scripting Angriffe

Beitrag von STEPHAN » Sa, 06. Jan 2018 16:59

Martin, ich glaube wir reden von unterschiedlichen Dingen. Ich rede nicht von Angriffen auf den Server.

ich rede nur von Web Angriffen, die eine fremde Website in eine bekannte einbinden und so Daten abgreifen.

Antworten