Clientseitige Sicherheit vers. Skriptsprachen
- Ersteller Kevin1986
- Erstellt am
Werbung:
![]()
Kevin1986
Neues Mitglied
Also unser Prof hat auch noch "Zugänglichkeit" in Bezug auf Sicherheit geprägt. Weiter hat er nichts gesagt.
Ich schreib hier noch mal die exakte Formulierung von ihm: "Ordnen sie folgende Skriptsprachen im Hinblick auf ihre clientseitige Zugänglichkeit (Sicherheit). Begründen Sie die gewählte Reihenfolge."
Ich schreib hier noch mal die exakte Formulierung von ihm: "Ordnen sie folgende Skriptsprachen im Hinblick auf ihre clientseitige Zugänglichkeit (Sicherheit). Begründen Sie die gewählte Reihenfolge."
Werbung:
![]()
vast
Neues Mitglied
ich versuchs mal, auch wenn ich mir nicht ganz sicher bin, ob das dir so weiterhilft.
a)JavaSkript,
unsicher, kann u.a. im browser abgeschaltet werden, und mit Hilfe von Tools wie firebug o.ä. manipuliert werden.
Wird vom browser interpretiert.
b) mysql,
nicht mein Fachgebiet, ich würde aber sagen, das mysql sicher ist, wenn die Infrasruktur vom Entwickler entsprechend erstellt wurde.
Soll heissen, kommt drauf an, wie man damit umgeht.
c) html,
ist eine Auszeichnungssprache, enthält den Inhalt der Seite (Text, Links, Bilder etc).
Wird vom browser interpretiert.
Hat also mit der Sicherheit nichts zu tun, weil sie nichts "kann" oder verarbeitet, sondern nur Informationen enthält.
d) php,
ähnlich wie bei mysql, man kann Dinge "sicher oder unsicher" implementieren.
Wenn du per php zB sensible Daten eines Formulars unverschlüsselt sendest, ist das unsicher.
Man kann das aber auch so machen, das es weitestgehend sicher ist, auch per php.
Hier kommt es wieder auf den Entwickler an, wie der das macht.
php wird vom Server interpretiert, erstellt quasi eine html-Seite serverseitig und sendet die an den browser.
Für Dinge wie Validierung eines Formulars etc is php auf jeden Fall die bessere/sicherere Wahl als clientseitige (javascript) Validierung.
e) css
wird vom browser interpretiert, ist ausschliesslich für die visuelle Darstelllung der Seite verantwortlich, hat daher mit Sicherheit nix zu tun.
PS: der post war ein schnellschuss zwischen tür und angel. Kritik erwünscht.
greetz
EDIT:
hab deinen zweiten Kommentar erst jetzt gesehen, sollte aber in etwa passen.
a)JavaSkript,
unsicher, kann u.a. im browser abgeschaltet werden, und mit Hilfe von Tools wie firebug o.ä. manipuliert werden.
Wird vom browser interpretiert.
b) mysql,
nicht mein Fachgebiet, ich würde aber sagen, das mysql sicher ist, wenn die Infrasruktur vom Entwickler entsprechend erstellt wurde.
Soll heissen, kommt drauf an, wie man damit umgeht.
c) html,
ist eine Auszeichnungssprache, enthält den Inhalt der Seite (Text, Links, Bilder etc).
Wird vom browser interpretiert.
Hat also mit der Sicherheit nichts zu tun, weil sie nichts "kann" oder verarbeitet, sondern nur Informationen enthält.
d) php,
ähnlich wie bei mysql, man kann Dinge "sicher oder unsicher" implementieren.
Wenn du per php zB sensible Daten eines Formulars unverschlüsselt sendest, ist das unsicher.
Man kann das aber auch so machen, das es weitestgehend sicher ist, auch per php.
Hier kommt es wieder auf den Entwickler an, wie der das macht.
php wird vom Server interpretiert, erstellt quasi eine html-Seite serverseitig und sendet die an den browser.
Für Dinge wie Validierung eines Formulars etc is php auf jeden Fall die bessere/sicherere Wahl als clientseitige (javascript) Validierung.
e) css
wird vom browser interpretiert, ist ausschliesslich für die visuelle Darstelllung der Seite verantwortlich, hat daher mit Sicherheit nix zu tun.
PS: der post war ein schnellschuss zwischen tür und angel. Kritik erwünscht.
greetz
EDIT:
hab deinen zweiten Kommentar erst jetzt gesehen, sollte aber in etwa passen.
Kevin1986
Neues Mitglied
Hi Vast,
erstmal Danke für deine Hilfe. Also gemeint ist sicherlich die "Hackbarkeit" verschiendenster Sprachen vom Homepc (Client) aus. Einige scheinen ja gar nicht dafür verantwortlich zu sein.
Kann mir vielleicht jemand jetzt noch ne Reihenfolge geben, wie "sicher" seiner Meinung nach die einzelnen Sprachen untereinander sind?
erstmal Danke für deine Hilfe. Also gemeint ist sicherlich die "Hackbarkeit" verschiendenster Sprachen vom Homepc (Client) aus. Einige scheinen ja gar nicht dafür verantwortlich zu sein.
Kann mir vielleicht jemand jetzt noch ne Reihenfolge geben, wie "sicher" seiner Meinung nach die einzelnen Sprachen untereinander sind?
vast
Neues Mitglied
eine genaue Einschätzung traue ich mir nicht wirklich zu, eigentlich kommt es wie gesagt darauf an, wie etwas implementiert wird.
html/css fliegt raus, weil verarbeitet nichts und kann nicht manipulieren.
per javascript kann man schon ein bischen mist machen, XSS (cross-site-scripting) verschiedenener Art, wobei die browser hier zum Teil schon blocken.
per php/mysql kann man wahrscheinlich den grössten Schaden anrichten denke ich, weil man hier ggf. auch auf Dateisysteme zugreifen kann etc.
Oder Stichwort mysql-injections etc.
Das wäre also meine "Reihenfolge".
Ich verstehe allerdings auch nicht genau, worauf dein Lehrer hinaus will:
Für mich klingt "clientseitige Zugänglichkeit" eher nach Accessibility/Barrierefreiheit als das das was mit Sicherheit zu tun hätte.
Jedenfalls:
php/mysql jedenfalls sind serverseitig verarbeitete Sprachen.
(Also ggf. keine clientseitige Zugänglichkeit, wenn ich den Mann recht verstehe...?)
javascript ist clientseitig und erlaubt Zugriffe auf die Webseite, dessen HTML und CSS, bzw das DOM (Document Object Model).
HTML und CSS sind keine skriptsprachen, sag das deinem Lehrer mal. ;)
Ich hoffe ich habe jetzt nicht mehr Verwirrung gestiftet, als zu helfen, evtl versteht jemand anders ja besser was dein Lehrer hören möchte.
greetz
html/css fliegt raus, weil verarbeitet nichts und kann nicht manipulieren.
per javascript kann man schon ein bischen mist machen, XSS (cross-site-scripting) verschiedenener Art, wobei die browser hier zum Teil schon blocken.
per php/mysql kann man wahrscheinlich den grössten Schaden anrichten denke ich, weil man hier ggf. auch auf Dateisysteme zugreifen kann etc.
Oder Stichwort mysql-injections etc.
Das wäre also meine "Reihenfolge".
Ich verstehe allerdings auch nicht genau, worauf dein Lehrer hinaus will:
Für mich klingt "clientseitige Zugänglichkeit" eher nach Accessibility/Barrierefreiheit als das das was mit Sicherheit zu tun hätte.
Jedenfalls:
php/mysql jedenfalls sind serverseitig verarbeitete Sprachen.
(Also ggf. keine clientseitige Zugänglichkeit, wenn ich den Mann recht verstehe...?)
javascript ist clientseitig und erlaubt Zugriffe auf die Webseite, dessen HTML und CSS, bzw das DOM (Document Object Model).
HTML und CSS sind keine skriptsprachen, sag das deinem Lehrer mal. ;)
Ich hoffe ich habe jetzt nicht mehr Verwirrung gestiftet, als zu helfen, evtl versteht jemand anders ja besser was dein Lehrer hören möchte.
greetz
Werbung:
![]()
mermshaus
Senior HTML'ler
Die Frage ist schwierig zu beantworten, ja. Das kann natürlich Absicht sein.
Die beiden wichtigsten Angriffsvektoren gegen Webanwendungen sind Cross-site scripting und SQL injection.
Cross-site scripting nutzt eine Schwäche in der serverseitigen Programmierung (PHP), um beliebiges JavaScript auszuführen und/oder den HTML-Code einer Seite zu verändern (etwa um ein Formular an ein anderes Ziel umzuleiten).
SQL injection nutzt eine Schwäche in der serverseitigen Programmierung, um unerwünschte Datenbankabfragen auszuführen.
Beide Angriffe erfordern Sicherheitslücken (unzureichendes Escaping von Eingabedaten) in der serverseitigen Programmierung (PHP), die es zulassen, den vom Server gelieferten HTML-Code zu beeinflussen oder JavaScript einzuschleusen oder SQL-Queries zu verändern. PHP wird also attackiert, um per HTML/JavaScript/SQL einen schädlichen Effekt auszulösen.
Etwas außen vor ist dabei das CSS, da dieses in aller Regel statisch abgerufen wird und keinerlei dynamische serverseitige Programmierung beinhaltet.
Meine Reihenfolge wäre:
1. PHP als notwendiges Medium zur Einschleusung von Schadcode.
2. SQL als Formulierungssprache von Datenbankabfragen. (Eine ungesicherte SQL-Query kann ganze Datenbanken leerräumen.)
3. JavaScript als geeignetster Träger für XSS-Attacken. (Wenn HTML injiziert werden kann, kann zumeist auch das hinsichtlich der manipulativen Kraft mächtigere JavaScript injiziert werden.)
4. HTML als das zu manipulierende Format, das vom Client interpretiert wird.
5. CSS als häufig rein statisch ausgelieferte Auszeichnungssprache, die in aller Regel von Nutzereingaben unabhängig ist.
Die massive Einschränkung dabei ist allerdings, dass praktisch jeder Angriffsvektor einen Fehler in der serverseitigen Programmierung verlangt. Nur weil ich auf einen Stuhl klettern und mir beim Abrutschen den Hals brechen kann, ist ein Stuhl nicht von sich aus ein „unsicherer” Gegenstand.
PHP steht an 1, da eine sichere serverseitige Programmierung praktisch alle Angriffe unwirksam macht.
Die Reihenfolge von 2 und 3 habe ich gewählt, da ein erfolgreicher SQL-Angriff ungleich verheerender sein kann, als ein erfolgreicher XSS-Angriff. XSS-Angriffe sind dagegen wesentlich häufiger anzutreffen.
HTML auf 4 beinhaltet nicht, dass jeder JavaScript-Code zur Ausführung auf ein HTML-Gerüst angewiesen ist.
Grundsätzlich nutzt der wesentliche Teil der Angriffe zwangsläufig eine Kombination aus mehreren dieser Technologien.
CSS auf 5 ist der eindeutigste Eintrag der Liste, da das Einschleusen von Schadcode nur unter sehr seltenen Bedingungen überhaupt möglich ist.
Edit: Ich setze voraus, dass Angriffe, die auf dem Rechner des Nutzers erfolgen (etwa per Trojaner oder Virus), unberücksichtigt bleiben.
Die beiden wichtigsten Angriffsvektoren gegen Webanwendungen sind Cross-site scripting und SQL injection.
Cross-site scripting nutzt eine Schwäche in der serverseitigen Programmierung (PHP), um beliebiges JavaScript auszuführen und/oder den HTML-Code einer Seite zu verändern (etwa um ein Formular an ein anderes Ziel umzuleiten).
SQL injection nutzt eine Schwäche in der serverseitigen Programmierung, um unerwünschte Datenbankabfragen auszuführen.
Beide Angriffe erfordern Sicherheitslücken (unzureichendes Escaping von Eingabedaten) in der serverseitigen Programmierung (PHP), die es zulassen, den vom Server gelieferten HTML-Code zu beeinflussen oder JavaScript einzuschleusen oder SQL-Queries zu verändern. PHP wird also attackiert, um per HTML/JavaScript/SQL einen schädlichen Effekt auszulösen.
Etwas außen vor ist dabei das CSS, da dieses in aller Regel statisch abgerufen wird und keinerlei dynamische serverseitige Programmierung beinhaltet.
Meine Reihenfolge wäre:
1. PHP als notwendiges Medium zur Einschleusung von Schadcode.
2. SQL als Formulierungssprache von Datenbankabfragen. (Eine ungesicherte SQL-Query kann ganze Datenbanken leerräumen.)
3. JavaScript als geeignetster Träger für XSS-Attacken. (Wenn HTML injiziert werden kann, kann zumeist auch das hinsichtlich der manipulativen Kraft mächtigere JavaScript injiziert werden.)
4. HTML als das zu manipulierende Format, das vom Client interpretiert wird.
5. CSS als häufig rein statisch ausgelieferte Auszeichnungssprache, die in aller Regel von Nutzereingaben unabhängig ist.
Die massive Einschränkung dabei ist allerdings, dass praktisch jeder Angriffsvektor einen Fehler in der serverseitigen Programmierung verlangt. Nur weil ich auf einen Stuhl klettern und mir beim Abrutschen den Hals brechen kann, ist ein Stuhl nicht von sich aus ein „unsicherer” Gegenstand.
PHP steht an 1, da eine sichere serverseitige Programmierung praktisch alle Angriffe unwirksam macht.
Die Reihenfolge von 2 und 3 habe ich gewählt, da ein erfolgreicher SQL-Angriff ungleich verheerender sein kann, als ein erfolgreicher XSS-Angriff. XSS-Angriffe sind dagegen wesentlich häufiger anzutreffen.
HTML auf 4 beinhaltet nicht, dass jeder JavaScript-Code zur Ausführung auf ein HTML-Gerüst angewiesen ist.
Grundsätzlich nutzt der wesentliche Teil der Angriffe zwangsläufig eine Kombination aus mehreren dieser Technologien.
CSS auf 5 ist der eindeutigste Eintrag der Liste, da das Einschleusen von Schadcode nur unter sehr seltenen Bedingungen überhaupt möglich ist.
Edit: Ich setze voraus, dass Angriffe, die auf dem Rechner des Nutzers erfolgen (etwa per Trojaner oder Virus), unberücksichtigt bleiben.
