[FRAGE] Gibt es ein Tutorial zu Sicherheit bei Javascript?

[berni15]

Ich habe viel Programmiererfahrung in anderen Programmiersprachen; Javascript ist aber noch recht neu für mich. Nun frage ich mich schon seit einiger Zeit, ob man hier Anfängerfehler bezüglich der Sicherheit machen kann - also sowas wie bei der Ausgabe von Benutzereingaben in PHP das htmlspecialchars() wegzulassen. Bei der Recherche im Internet komme ich immer nur auf Seiten, die mir erklären, wie ich meinen Browser härte, aber das ist ja nicht meine Frage.

Kennt jemand von euch ein Tutorial dazu, oder sowas in der Art? Oder muss man sich da bei Javascript keine Gedanken zu machen, weil ja eh alles auf dem Rechner des Benutzers läuft und nicht auf meinem?

 

[mikdoe]

ich wüsste dazu nur die frage, dass man den browser nicht zum absturz bringt z. b. durch endlosschleife. ansonsten ist der einzige fehler nur, wenn man von js angelieferte daten als sicher bezeichnen würde. bei vielen hat man den eindruck, sie fragen eingabedaten nur mit js ab bevor sie sie per php in die db schieben. das ist natürlich ungut.

 

[berni15]

ansonsten ist der einzige fehler nur, wenn man von js angelieferte daten als sicher bezeichnen würde. bei vielen hat man den eindruck, sie fragen eingabedaten nur mit js ab bevor sie sie per php in die db schieben. das ist natürlich ungut.

Ja, das ist mir klar. (Und natürlich auch keine Passwortabfragen komplett in JS.) Was ist mit globalen Variablen? Kann damit was passieren? Ich denke da an sowas, wie dass jemand noch einen zweiten Tab auf hat und dort auf der Seite Schadcode läuft, der dann auf meiner Seite was so verändert, dass der Benutzer denkt, es läge an meinen JS? Oder ist sowas zu weit hergeholt?

 

[kkapsner]

Was ist mit globalen Variablen? Kann damit was passieren?

Ja, du kannst dir damit selber ins Bein schießen, wie bei jeder anderen Programmiersprache auch.

Ich denke da an sowas, wie dass jemand noch einen zweiten Tab auf hat und dort auf der Seite Schadcode läuft, der dann auf meiner Seite was so verändert, dass der Benutzer denkt, es läge an meinen JS?

Nein - die Tabs sind (meistens) getrennt. V.a. wenn die SOP die beiden trennt.

 

[mikdoe]

man kann sehr vieles mit und ohne js machen. kommt immer auf den anwendungsfall an und danach richten sich die sicherheitsfragen. ich würde nicht hinten sondern vorne anfangen fragen zu stellen.

 

[SteelWheel]

Manchmal ist das gute, alte EVA-Prinzip aber auch noch angebracht. Da darf man gern hinten anfangen (bäh, klingt das anzüglich).

Typische Anfängerfehler sind ...
- globale Variablen (wie erwähnt) und
- unzählige Funktionen in der Breite,
- unzählige "var" (je Zeile) bei Definition in Folge,
- Laden von ext. Scripten ohne Einsatz (Motto: Hauptsache drin),
- Laden von Drittanbietern mit zu alten Scripten,
- Mischbetrieb von "JavaScript" und "JavaScript-Frameworks"
- fehlende Disziplin in puncto Source-Schreibweisen etc. (ey, die Binärhölle bei Wartung!)
- case-sensitive Fehlsicht (var i ist nicht var I)
- duplizierte Funktionen in verschiedenen Scripten für den gleichen "Job"
- eval() ist "evil"
- die Fehlerkonsole des Browsers ist Dein VERBINDLICHER Freund
- "geht nicht" ist keine Fehlermeldung

Läuft mir heute noch was über den Weg (ich darf genau sowas gerade von extern überarbeiten), gebe ich es hier zu Protokoll.

Und: "Ja, kenne ich ja schon" wäre dann aber nicht mehr der Umstand für "Anfängerfehler".

Beste Grüße

 

[kkapsner]

unzählige "var" (je Zeile) bei Definition in Folge

Finde ich jetzt nicht so schlimm. Bei nur einem var können sich durch ein unsachtsames ";" schnell globale Variablen einschleichen. Wobei dabei natürlich auch solche Tools wie jsHint (dessen Einsatz ich einem Anfänger wärmstens ans Herz lege) helfen.

 

[SteelWheel]

Ich glaube, dass Du meinen geschriebenen Source durchaus lieben würdest. Und - wie im gesehenen Beispiel - fünf unnötige "var" sind immer schon wieder Bytes, die keiner im Transfer braucht. Aufgrund meiner Natur achte ich auf alle möglichen Stellen zum Sparen (habe noch kein http2 im Einsatz).

 

[tsseh]

fünf unnötige "var" sind immer schon wieder Bytes, die keiner im Transfer braucht

der aber gezippt erfolgt

 

[berni15]

Eigentlich wollte ich mich gestern ganz artig für die erste Beiträge bedanken, weil ich jetzt weiß, dass ich nicht wirklich viel falsch mache. Nachdem ich aber den Hinweis zu jshint gelesen hatte, habe ich das zuerst mal angeschaut und auch eshint (bin damit aber nicht klar gekommen) und jscs und dann war es Zeit für's Bett. Für diesen Hinweis jedenfalls ganz besonderen Dank - die Programme kannte ich nicht.

Etwas irritiert bin ich bei jshint über die Meldung "Bad line breaking before '...'". Ich schreibe den Fragezeichen-Doppelpunkt-Operator, wenn die Zeilen sonst zu lang werden, gerne so (ähnliches bei zu langen Strings und mit && und || verknüpften Ausdrücken):

a = bedingung
    ?ausdruck1
    :ausdruck2;

Das meckert mir jshint jedesmal an. Mir ist aber nicht ganz klar, warum. In den Docs finde ich noch nicht mal, welche Option dafür zuständig ist. Ich kann die Meldung zwar mit "-W014: true" abschalten, aber das kann ja nicht der Sinn des Ganzen sein. (Wobei ich in der Endversion dann die js-Datei durch einen Obfuscator jage, der die Zeilen ohnehin wieder zusammenhängt, aber ich will ja auch was lernen...)

Das zweite in der Richung sind for-Schleifen, wo ich oft solche Situationen habe:

for (var i=1;i<=10;i++) {
  code;
}

for (var i=0;i<=100;i++) {
  noch_mehr_code;
}

Kann sowas Probleme verursachen?

Und noch eine Frage: Wie sinnvoll ist es "use strict" zu verwenden?

PS: jscs moniert mir den Ausdruck "a &= ~1" an (Implicit binary conversion), mit dem ich ein Bit ausmarkieren will. Ich verstehe weder, was daran falsch ist, noch wie man es verbessern könnte.

 

[mikdoe]

Etwas irritiert bin ich bei jshint über die Meldung "Bad line breaking before '...'". Ich schreibe den Fragezeichen-Doppelpunkt-Operator, wenn die Zeilen sonst zu lang werden, gerne so

auch wenn es umklammert ist?

Und noch eine Frage: Wie sinnvoll ist es "use strict" zu verwenden?

ich finde es sehr hilfreich und bin froh, dass js das auch endlich hat, nutze ich in perl schon lange.

deine frage zu den schleifen verstehe ich nicht. was soll da problematisch sein außer dass ich solche trivialen und wenig intuitiven hochzählschleifen immer versuche zu vermeiden.

 

[berni15]

auch wenn es umklammert ist?

Meinst du damit a = (bedingung?ausdruck1:ausdruck2) oder a = (bedingung)?(ausdruck1):(ausdruck2)? Die Fehlermeldung (besser Warnung) kommt jedenfalls in beiden Fällen, wenn man die Zeilenumbrüche wie oben einbaut.

deine frage zu den schleifen verstehe ich nicht. was soll da problematisch sein außer dass ich solche trivialen und wenig intuitiven hochzählschleifen immer versuche zu vermeiden.

Die Variable i wird hier zweimal definiert.

 

[mikdoe]

Meinst du damit a = (bedingung?ausdruck1:ausdruck2)

Ja das meinte ich. Dann ist dieses Ding kaputt, oder?
Zumindest läuft der Code wunderbar:

<!DOCTYPE html>
<html>
  <head>
    <title>ternary operation</title>
    <meta charset="utf-8">
	<style>
	</style>
  </head>
  <body>
    <script>
      var a = 1 == 1
        ? 'Albert'
        : 'Berta';
      alert(a);
    </script>
  </body>
</html>

Die Variable i wird hier zweimal definiert.

Ja aber doch jedes mal für sich durch das var.

Wenn du Codefetzen oder einzelne Kommandos in Inline Tags (das C im Editor) setzt verhinderst du, dass das Forum aus Klammern Smilies macht und noch einiges mehr. Hab das mal nachträglich bei dir eingefügt.

 

[kkapsner]

Dann ist dieses Ding kaputt, oder?

Es geht bei diesem "Ding" auch nicht nur darum, die Syntax zu überprüfen, sondern auch einen guten Codestil. Das ist wahrscheinlich auch Gewohnheits- und Geschmackssache, aber ich finde diesen Stil schlecht lesbar. Das finde ich besser und jshint meckert es auch nicht an:

var a = 1 == 1?
        'Albert':
        'Berta';

Man erkennt nämlich in der ersten Zeile sofort, dass ein Trinitätsoperator ist und muss nicht erst die zweite Zeile lesen.

Das mit den mehrfachen Deklaration macht bei dir wahrscheinlich keine Probleme (und ich hab' auf github dazu sogar mal ein Issue geöffnet (https://github.com/jshint/jshint/issues/640 - war ihnen aber anscheinend nicht relevant genug), aber allgemein können mehrere var bei einer Variablen auf einen Logikfehler hinweisen. Aber wenn du mit ES6 arbeiten kannst, solltest du sowieso mit let arbeiten. Dann hast du keinerlei Probleme in diesem Zusammenhang.

Wie sinnvoll ist es "use strict" zu verwenden?

Sehr. Verwende das auf jeden Fall. Gewöhne dir als Anfänger gar nicht erst an, dich auf "Features", die nicht strict sind, zu verlassen.

jscs moniert mir den Ausdruck "a &= ~1" an (Implicit binary conversion)

Das JS keinen expliziten binären Typ (und auch kein Integer) hat, sind binäre Operationen mit Vorsicht zu genießen. Wenn wirklich exakt weißt, was du da tust, ist es OK. Aber wenn dir die Information über die Typen neu war, solltest du davon lieber die Finger lassen, bis du genau weißt, wie JS Zahlen speichert.

 

[berni15]

Es geht bei diesem "Ding" auch nicht nur darum, die Syntax zu überprüfen, sondern auch einen guten Codestil.

So wie ich das sehe, versuchen die Programmierer von jshint das gerade eben nicht mehr zu vermischen. Zumindest sind alle anderen Optionen, die nur auf Stil abzielen als "deprecated" und mit Hinweis auf jscs markiert. Insofern vermute ich, dass bei den Operatoren am Zeilenanfang doch mehr als nur Stil dahinter steckt. Vielleicht hängt es irgendwie mit diesen Strichpunkten zusammen, die JS bei "Bedarf" ergänzt? Bei folgendem Beispiel war das relevant:

return
    "mehrzeiliger Text"+
    "mehrzeiliger Text"+
    "mehrzeiliger Text";

Zurückgegeben wir hier nämlich undefined und nicht das, was ich gehofft hatte, weil nach dem return nämlich vom Interpreter ein Semikolon eingefügt wird. (Bei dem mehrzeiligen Text handelte es sich um eine ASCII-Grafik, nur für den Fall, dass sich jemand fragt, wie man auf die Idee kommen kann, das so zu formatieren.)

Sehr. Verwende das auf jeden Fall. Gewöhne dir als Anfänger gar nicht erst an, dich auf "Features", die nicht strict sind, zu verlassen.

Achso, ne auf die Features wollte ich mich nicht verlassen. Die Frage war für mich eher, ob es einen Unterschied macht, ob ich "use strict" hinschreibe oder nicht, wenn ich die nicht-stricten Features eh nicht nutze.

Das JS keinen expliziten binären Typ (und auch kein Integer) hat, sind binäre Operationen mit Vorsicht zu genießen.

Ah, ich verstehe. An Duck-Typing hatte ich nicht gedacht... In meinem Fall bin ich mir ziemlich sicher, dass ich einen Integerwert zwischen 1 und 2047 vorliegen habe. Allerdings scheint mir das für jscs nicht das Problem zu sein, sondern die explizit angegebene 1. Hab' grad mal den Sourcecode von jscs durchforstet: Da wird einfach jedes Auftreten von ~ als Unäroperator angekreidet. k -= k%2; funktioniert als Ersatz, finde ich aber unschön und geht auch nur wegen der expliziten 1. Bei größeren Zahlen müsste man sich was Neues einfallen lassen.

Wenn du Codefetzen oder einzelne Kommandos in Inline Tags (das C im Editor) setzt verhinderst du, dass das Forum aus Klammern Smilies macht und noch einiges mehr. Hab das mal nachträglich bei dir eingefügt.

Hups, danke. Wusste nicht, dass man hier auch Inline-Code markieren kann.

 

[mikdoe]

weil nach dem return nämlich vom Interpreter ein Semikolon eingefügt wird.

was genau meinst du an dieser stelle und in diesem zusammenhang mit "Interpreter"?

 

[berni15]

was genau meinst du an dieser stelle und in diesem zusammenhang mit "Interpreter"?

Naja, das Programm halt, das den Code ausführt.

- - - Aktualisiert - - -

So wie ich das sehe, versuchen die Programmierer von jshint das gerade eben nicht mehr zu vermischen. Zumindest sind alle anderen Optionen, die nur auf Stil abzielen als "deprecated" und mit Hinweis auf jscs markiert. Insofern vermute ich, dass bei den Operatoren am Zeilenanfang doch mehr als nur Stil dahinter steckt.

Ich hab' jetzt eben herausgefunden, welche Option dafür zuständig ist, nämlich laxbreak. Die ist ebenfalls aus diesem Grund als deprecated markiert. Also wohl doch nur stilistische Gründe...

 

[mikdoe]

Naja, das Programm halt, das den Code ausführt.

also der Browser. und welchen browser hast du für das return beispiel genutzt?

 

[kkapsner]

@mikdoe: das ist in allen Browsern so und auch in den Specs so definiert.

Vielleicht hängt es irgendwie mit diesen Strichpunkten zusammen, die JS bei "Bedarf" ergänzt?

Nein, denn ein Semikolon würde an dieser Stelle einen Syntaxfehler erzeugen.

Die Frage war für mich eher, ob es einen Unterschied macht, ob ich "use strict" hinschreibe oder nicht, wenn ich die nicht-stricten Features eh nicht nutze.

Ja, denn es werden nicht nur ein paar Features deaktiviert, sondern es ist auch das Verhalten an manchen Stellen anders. Dadurch werden Fehler schneller sichtbar, die man sonst ev. schwer fände.

 

[berni15]

Ok, dann danke ich euch erst mal. Ich denke, ich hab' jetzt zu all den Fragen, die mit der JS-Sicherheit zusammenhängen befriedigende Antworten erhalten.