Web Security
SFL @ TU Dortmund
(Slides partially from and – thanks!)

Copyright By PowCoder代写 加微信 powcoder

Web applications
• Big trend: software as a Web-based service
• Online banking, shopping, government, tax preparations, customer
relationship management, messengers, …
• Application code split between client and server
• Client (Browser): HTML, CSS, JavaScript, WebAssembly • Server: PHP, Ruby, Python, Java, Perl, ASP, …
• Security is rarely the main concern of developers • Poorly written scripts with inadequate input validation • Insufficient protection of sensitive data

Top web vulnerabilities
• CSRF: Cross-Site Request Forgery
• Bad website tricks browser to reuse existing cookies (e.g., after login) for
unintended background requests to the same website
• XSS: Cross-site scripting
• Malicious code injected into a trusted context (e.g., malicious data
presented by a trusted website interpreted as code by the user’s browser)
• SQLi: SQL Injection
• Malicious data sent to a website is interpreted as code in a database query

Primer: HTTP, HTML and JavaScript

HTTP properties
• HTTP is the protocol for web (and several other) applications • Stateless protocol: single request, single response
• no inherent notion of „authentication“ or „sessions“ • HTTP 1.x is human-readable (unlike HTTP 2.x)
• ASCII-based plain text protocol
• Relies on TCP as underlying channel
• can be encapsulated in TLS connection (HTTPS) –

HTTP Requests (since HTTP/1.0)
• Consists of several, partially optional components
• Request Line with Request Method, Path, and Protocol
GET /index.html HTTP/1.0
• List of HTTP headers, as header:value Host: sfl.cs.tu-dortmund.de Cookie: session=UG9seWZvbiB6d2l0c=
• Empty line (CRLF, i.e., \r\n) to end headers
• Optional body message (used, e.g., with POST requests)

HTTP Example: GET Request
$ wget https://sfl.cs.tu-dortmund.de/test
GET /test HTTP/1.1
Host: sfl.cs.tu-dortmund.de
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Wed, 19 Jan 2021 13:23:30 GMT
Content-Type: text/html
Content-Length: 5
Connection: keep-alive
ETag: “59567173-5”
Accept-Ranges: bytes
Response Header
Response Body

• Purpose: retrieve resource from server
• Should not cause side effects on Web server’s state • dubbed „idempotent“ in W3C standard
• although it does far too often these days
• Should not carry a message body
• Parameters passed via URL
• /site.cgi?name=value&name2=value2%26 • ends up in log files and Referer (sic) header

• Purpose: send data to the server
• for storage or processing
• should be used for state-changing operations
• Can be combined with GET-style request parameters • Message body contains URL-encoded data

Uniform Resource Locator (URL)
• URL specifies the exact resource
Protocol Hostname

HTTP Response (since HTTP/1.0)
• Status Line: Protocol, Status Code, and Status Text HTTP/1.0 200 OK
HTTP/1.0 404 Not found
• List of HTTP headers, as header:value Server: Apache
• Empty line to end headers • Response Body

Example website
First name: Last name:
HTML: An Introductory Example

Example website

First name:



Last name:

JavaScript
• JavaScript is a script language and a key technology to Web
• Imperative, weakly typed, object-oriented and (usually) interpreted • Allows to create dynamic, highly-interactive web content
• Usually, JavaScript code is served by the server and executed on client • JavaScript code can read and modify the Document Object Model (DOM)
• Events trigger code execution (on load, click, hover, submit, etc.)
• Very popular despite its security problems
• Most websites ship (and require) JavaScript code
• All modern browsers support JavaScript, only rarely disabled

Example website
First name: Last name:
JavaScript: An Introductory Example

function verify() {
var fname = document.forms[“myform”][“fname”].value; var lname = document.forms[“myform”][“lname”].value;
if (fname == “” || lname == “”) { alert(“Names must be filled.”); return false;

Example website

First name:



Last name:

WARNING: Any client-side JavaScript code (such as this input
validation) can be disabled and circumvented by clients.

Cookie Security and Cross-Site Request Forgery (CSRF)

HTTP Authentication and Sessions
• Web clients usually authenticate using web forms
1. Client visits login page
2. Server serves authentication form (username / password)
3. User fills and sends form with its username / password
4. Server validates login, and if valid, it creates + stores + returns a (secret) cookie
5. Subsequent client requests include the cookie, server looks it up in DB
Lo gm· Successful

Cookies (1/2)
• Cookie = server-generated store that clients send with each request • Server can recognize the user in subsequent visits
• Allows to bring state to HTTP and thus enables sessions
• Example cookie after login: Name
Value Host Path Valid until Secure HttpOnly
sessionid ab2h4h4h4n00b1d1di7cafe sfl.cs.tu-dortmund.de / Tue, 13 Aug 2023 13:33:37 GMT No Yes

Cookies (2/2)
• Several directives/options to control cookies
• Expires=, determines when cookie should be deleted •Domain=, defaults to current host
– Can be set for parent domains and their subdomains (!!!)
– By default, cookie is only set for current domain without subdomains
– e.g., Domain=tu-dortmund.de on sfl.cs.tu-dortmund.de sets cookie for *.tu-dortmund.de
• Path=, only set cookie for this path (and sub-paths)
• HttpOnly, disallows access from JavaScript via document.cookie
• Secure, only transmit cookie over secure connection (HTTPS) •SameSite=Strict/Lax, do not transmit cookies on cross-origin requests

Stealing Cookies via JavaScript (1/2)
• Without precautions, JavaScript could access embedded resources □X
I\JeuerTab,
G Campu splan
N SN Cacti 8
Dea dli nes