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
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
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=
– 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=
• 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
Stealing Cookies via JavaScript (2/2)
• The Same-Origin Policy (SOP) limits capabilities of scripts
• No access to sub-documents (e.g., iframes, popups) that are in foreign domain
• No requests to foreign domains (unless Cross-Origin Resource Sharing enabled) • Domain is foreign if (protocol, host, port) triple does not match
• SOP stops the aforementioned attack and mitigates cookie theft • Unless we have XSS vulnerabilities (see later)
• Also, CSRF (see after next slide) aims to reuse cookies
Same-Origin Policy Implications
Neu er Tab
www.attacker-tries-to-steal-cookies.com
sfl.cs.tu-dortmund.de
Access Denied (different origin)
Source: ls4-www.cs.tu-dortmund.de Target: sfl.cs.tu-dortmund.de Access Denied (different origin)
+ CD www.attacker-tries-to-steal-cookies.com
Banking Cf IllCampusplan _., sandnet MSNCacti ~ Deadlines
<:! Q. Suchen
var c = window.frames[‘myframe'].document.cookie;
tutechnisclhe universitat dortmund
faku ltat fur
inform atik
Lehrstuhll fur pralktische lnformat ik
var c = window.frames['myiframe'].document.cookie; Sie sind hier:TU Dortmund > Fakulta:t fur lnformatik >
Ste ll enange bote
INIFORMATI
l Die Leitung die,
Cross-Site Request Forgery (1/2)
POST /login
HTTP/1.1 200 OK
Set-Cookie:
GET /attackscript